--- In [email protected], "Goudal Francois" <[EMAIL PROTECTED]> wrote: > If, for a strange reason, the Fox restarts but the LCD doesn't and the > restart occurrs between the two nibbles of a byte, then you have sent > only half of the command. But when you restart the fox, you don't know > that the screen is still in 4 bits mode and waiting for a 2nd nibble.
Valid point. And I also am in favour of using 8 bits, hence the hint to use an 8 or 16 bit I/O expander to control the LCD. But do not use the FoxBoard directly. However, to come back on your remark. As already said, it's a valid one. But when the FoxBoard restarts, then I think that the LCD asynchronism is the least of your worries. I think much more important things should be restored/re-synced when such occasions occur. If the FoxBoard for one reason or another restarts, then I would look for simply restart all communication in a defined way, including the one to the LCD driver. There is a way to reset the stuff (like you mentioned, you could also us a pin of the I/O expander to bring the LCD in a defined state). Once the LCD is restarted, look to what the previous state of your FoxBoard was and try to restore as close as possible the state prior to the FoxBoard crash (because that's what I call it: a restart is a crash for me...). Best rgds, --Geert
