I thought the best for time critical app is to have a shadow RAM for the
EEPROM so that when you read data you do not need to access to the EEPROM
and then when you write data you just put the new data to the place and
indicate somewhere (in a bitfield for example) that the place had been
changed. Next time when an interrupt occurs you can check whenever the
shadow had been changed and you can write the changed bytes into the EEPROM
-- when finished a new interrupt will be triggered..and so on. The only
problem is how to start the writing mechanism -- so that if there is no any
data waiting to be written already, you have to start the whole manually
(with an initial write) or do some tricks when timer or other interrupts
occur making sure not interfering with the EEIF.

Tamas


On 11/09/06, Maarten Hofman <cashimor@gmail.com> wrote:
>
> >
> > add a third one after it.. only the third one is done. Is there some
> delay
> > between consecutive writes? Thanks for any help, and for putting up with
> me
> > (come on, you love me really).
>
>
> Yes, generally you have to wait before the write is complete before
> starting
> a second one. Also, you have to make sure there is enough voltage/current
> to
> complete the write during that cycle. Note that the example code uses a
> "SLEEP" operating with interrupt to wait, this has the advantage that the
> power consumption of the rest of the chip is reduced during the write. If
> you don't use the sleep, you will still need to check for the interrupt
> bit
> (EEIF) to be set indicating that the write is finished. Usually you will
> have to clear this bit manually afterwards.
>
> Some people would also recommend reading the EEPROM after the write, to
> check if the value has actually been written to it.
>
> If your application isn't time critical, the best thing is to check for
> EEIF
> after your write, and wait for the write to complete that way. If it is
> time
> critical, you could postpone this wait until before you write, thereby
> allowing the write to continue while the rest of your program executes.
>
> Note that while you are writing, a read from the area you are writing to
> might not return the correct value. Most PICmicros will return the correct
> contents for all other memory locations though. An exception are certain
> revisions of PIC16F628A (and possibly 627A and 648A), which have a bug
> that
> will cause the write to fail in case you read the EEPROM at the same time.
> Possibly there are other PICmicros that have the same problem. Of course,
> this can be prevented by waiting with reading until the write is finished.
>
> Greetings,
> Maarten Hofman.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
unPIC -- The PIC Disassembler
http://unpic.sourceforge.net
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist