I've been fighting getting this Vacuum Fluorescent 16x2 text-display working...

It's supposedly compatible with standard character-LCD displays based on the Hitachi HD44780...

So, there's a datasheet for *the entire display*: Samsung 16T202DA1 but I found the HD44780's datasheet to be a bit more informative, so have been using it for timing-info...

Things were working fine until I started working with the "Busy Flag." Hardcoding excessively-long delays seemed to work fine, but reading that Busy Flag just resulted in all kindsa fail.

I thought maybe my port-direction stuff wasn't working quite right, since I hadn't done any other read-back from the display, prior. Maybe the data was floating too long, or something. This seemed somewhat corroborated by the fact that whatever *last* value was sent to it *seemed* to have an effect on whether it functioned or not... E.G. *for the most part*, if I sent a character that had bit 7 set to high, then the system would crash while waiting for the busy-flag (which is read-back on bit 7), but if I sent a value that had bit 7 set to low, then the system seemed to work fine. *For the most-part*. There were some other oddities that didn't *quite* align with this logic, but durn-close.

So then I implemented a simple test: I wrote a character to one position, then another character to another position, then read-back the character at the first position, and... it seemed *almost* to work, in some weird way... *almost* corroborating my theory that read-back wasn't quite implemented correctly...

And, eventually, the instructions seemed to get garbled.

I'm using this thing in 4-bit mode... so my thought was that the two-nibble reads were somehow getting misaligned, maybe one was missed here or there, or maybe there was too much noise on the line causing spurious "Strobes"... This could still be true, actually... Apparently the *chip* datasheet says the minimum High input-voltage on the *strobe* pin is *higher* than the data pins, 0.8VCC (4V) rather than 0.7VCC (3.5V). Yet the *module* datasheet says the minimum High input-voltage is the same for all pins, 0.7VCC... and I'm using a 3.6V processor, so... hmm...

But here's a more-glaring thing... The *chip* datasheet *explicitly states* (In *several* locations) that the Busy Flag ALWAYS RETURNS LOW.

The chip is marked: NEC D16314AGJ, the closest-match datasheet I can find is uPD16314... so it may be slightly different. BUT the ALWAYS LOW Busy-Flag definitely seems relevant...

This venture has led me in so many directions, I can't quite piece it all together. I'm certain I saw a recurring case where it seemed that the data read-back was read-back in 4-bit mode with the *same* data in both nibbles... matching almost-identically the last nibble sent. Then there was the case where it *almost* read back the actual data written to the previously-written character, except with one or two bits incorrect... This one worked fine for several seconds, then the instruction-garbling...

If I recall correctly, that was the last test, before I gave up and swapped out the VFD for a regular-ol' *actual* HD44780-based LCD display... which once plugged-in seemed to work *perfectly*... Prompting me to look up the NEC D16314's datasheet... and noticing the blaring statement that the Busy Flag is ALWAYS LOW.

(But how does this explain the *other* issues...? The 4-bit read-backs that seemed to be the last-nibble written, repeated twice...? And the fact that it eventually gets garbled instructions, even though *currently* I'm not actually *using* the busy-flag...? ... would seem I still have some friggin' work ahead of me.)

So, this is for my stupid [Audio-Amp] Motor-Driver Testing Experiments... The intention being to have easily-adjustable settings for things like minimum and maximum PWM values, to choose whether an output is locked-antiphase or direction/PWM, to vary the Proportional Constant (KP) for my positional-feedback-loop, and more...

HOW it's taken *literally* DAYS to get a stupid text-display working is beyond me... This is probably the third or fourth time I've worked on these stupid things and pretty much forced by oddities like these to go the ground-up route each time, despite having the old (functional before!) code at my fingertips.

That's alright, this new code is much more sophisticated; a (reentrant?) state-machine setup to prevent CPU-thumb-twiddling while waiting for things like the necessary delay between writing the "Address" (RS and R/W) and the rising of the strobe (E). These things could be handled by "wait-states" (and DMA!) on this PIC32's Parallel Master Port, but then it wouldn't be nearly as portable... I guess.

#commonCode (not exclusively for AVRs) for the win!