Hello. I enclose a copy of a message archived almost 2 years ago - it seems to have some bearing on the problem. I hope this helps. dwayne Archived copy follows: Regarding the good old fashioned LCD modules: Well I thought I knew all about the standard dot matrix LCD modules, I've been using them for long enough. But in sorting out a problem today I had a few surprises which may be of interest. A client had decided to update an existing PIC-powered product by replacing the LCD with a vacuum fluorescent module (Itron CU20025), supposedly a drop-in replacement. Ha Ha! Anyway it didn't work, so it came to me to be "fixed". The product drives the LCD in 4-bit mode, and tests the BUSY flag. It soon became clear it was hanging because the nibble order was somehow getting out of sync - hence it was testing bit 3 of the LCD data, not bit 7. Since the lower bits are a readback of the DD address, as soon as the address hit the right value, it all ground to a halt. But why - the LCD version was fine? To make a long story slightly less long, it seems (empirically) that when the VF module is polled for busy, in 4 bit mode, the normal requirement to always complete the twin cycle by polling for the second nibble does not apply - every poll returns the upper nibble only. That's UNTIL the busy flag drops, when you need to then read the other nibble before returning. So the standard code had a 50% chance of exiting in the wrong nibble phase. Modified the code to loop on the first nibble only. Works fine. Tried another tack, now I just take E high and poll D7, keeping E high instead of cycling it. When D7 drops, read the other nibble and off we go. This works fine too, strange but actually nicer than pumping E all the time! But this will mean different code for the LCD version? Oh no it doesn't, the LCD still works with the new code! Wrote some test code to look at it on the 'scope and sure enough, 2 mSec after the CLEAR command, D7 just drops with no other action. Well the Hitachi book seems to say you have to clock E continuously while testing busy, I've always done it that way, all the code I've ever looked at does it that way, but the clean and simple static method seems to work fine. The Hitachi book seems geared to direct CPU bus attachments where there is not usually the option to "stall" the cycle as one can with a port connection, so maybe the diagram showing the continous E cycles is misleading here? Sorry if this is old news to everybody, it certainly surprised me and seems to contradict the usual way of doing things. Does anybody else drive their modules like this? And does anybody lose any sleep about getting their 4 bit interface out of sync due to noise or whatever? I suppose that detecting a stuck "busy" bit would be a way to pick this up and reset the module. Regards to all, -- Alan Hall, Ipswich, UK (01473) 652301 Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 15 years of Engineering Innovation (1984 - 1999) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Do NOT send unsolicited commercial email to this email address. My posting messages to Usenet neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email.