> If you have an interrupt that reads the EEPROM, it must be disabled while
> a write is in progress.

In the Atmel vs PIC comparison table, once of the PIC's supposed advantages
is that it can access the EEPROM even while it is being written.  This seems
unlike what I'd expect of a normal EEPROM device, but seems to be Microchip's
claim.  Does anyone know if any/all of the 16x84's permit this and under what
conditions?

Also, re that table, I think Microchip makes some good points but some of the
complaints about the AVR are nonsensical.  For example, claiming that context
switch time is 128 cycles because of the need to save/restore all 32 registers
is ridiculous; odds are very good most ISR's will only need a handful of reg-
isters if that, and (esp. if programming in .ASM) they can be left unused in
the main program.  The PIC only has W, FSR, PCLATH, and STATUS to worry about,
but those (except for maybe FSR and--on the small devices--PCLATH) will need
to be saved/restored with just about any ISR.

Further, while having the stack pointer mapped in I/O makes SP manipulation
slower, there isn't the risk of corruption that Microchip suggests; while an
ISR will change the stack pointer during its execution, any non-terminal ISR
will always leave the stack pointer as it was on entry.  Thus, if I code [in
pseudo-ASM]:

        load    R0,SP
        sub     R0,#9
        store   R0,SP

An interrupt may occur at the old or new stack-pointer value, and R0 may or
may not have been loaded from the stack pointer, but it won't matter; unless
the interrupt routine changes the SP without changing it back (in which case
it would be hard for it to return anyway) the ReadModWrite process will work
just fine.