One bug that I encounter many times in projects using similar displays is not giving enough time for commands to process. Often times what works while testing may work 99.99% of the time but that 0.01% it doesn't work could end up as an incorrect character or even an invalid command!
A recent bug I figured out later was sending a certain graphical character matched the "display off" command, and the command bit was not being set quickly enough due to a long cable connection. Once the display off command was sent the screen would not turn back on...
The best way to solve this is to implement firmware to read the status flag of the display, if you are lucky enough to have one. I find this helps a lot with all types of sensors and other external interfaces, send the data and read it back. You will thank yourself that 0.01% of the time it didn't work!
Gah I hate these bloody awful displays. You find out regularly that the display's memory isn't organised how you think (linearly) because the early displays were tiny, so writing say a line out on a 40x4 display turns into a nightmare.
The positive bit is once you've hidden all the oddness behind an API (mine is lcd_init(), lcd_cls(), lcd_pos(x,y), lcd_write(str) ) then they're totally fungible.
I think it's because bigger displays consist of multiple controllers, handling different sections of the display. (at the bottom, there should usually be 2 chips, but for bigger displays there are 3) So you have to address these separately.
You're 100% right but it's very inconvenient to use. For example if you want to copy a buffer to the display you have to track the position and then execute commands to move the cursor to the new region.
Less of a problem now in C but back in the day, Z80 asm / PIC asm it was a PITA.
Most of the programs I've seen do what the author calls "Initialization by Instruction" anyway. Bootstrapping and initialization are notoriously tricky to do in hardware, and a lot of us have been bit by this before. Besides, even a compliant power supply (i.e. one that normally meets the electrical requirements, which aren't all that strenuous, to be honest...) can end up being operated in a non-compliant environment.
The cool thing about these things is that most of them are 99% similar, which has helped with endurance more than anything else. It's a weird architecture, yes, but you can often replace a thirty year-old LCD with a brand new one and it'll work, often without any firmware adjustment. That is hard to beat (and, besides, there's hardly any reason to beat it).
interesting, "beat it" was the development name for the drumbeat project, and the lable of the main routine in the original source code. Is it circumstantial that you chose "beat it" in your comment or is there an inside knowledge?
For me it somehow shows a good point: Your architecture can be super weird and clusterfucked, but if it just works, people will use it neverthelesss.
I mean, you don't have to care about the architecture at all. You just throw some simple bits and characters at the screen and it displays that for you. I think the simplicity of that got these displays to the point where they are now
a neat thing about these LCDs is that there is a display buffer that holds the alphanumeric, but no need for the buffer to write to the display. the buffer can be written to and read from as if its memory [bcz it is!]
My favourite el cheapo displays are the SSD1306 OLEDs. They're tiny and work over I2C (or SPI). Cost about $3 from eBay from China. It's a fun weekend job writing your own printf and plotting libraries, trying to figure out the various modes. I2C isn't enough to do real-time refreshing of the entire display, but it's perfectly reasonable to plot sensor readings when you're just updating a few regions. You can also get libraries for the Raspberry Pi and Arduino (via Adafruit).
I remember years ago being quite proud of implementing a software variable-width font (since this wasn't a character display). Quite slow on an AVR, but looked nice.
in other words power must turn on and ramp time to operating level must be somewhere between 100 micro seconds and 10 milliseconds. this is accomplished easily with power conditioning between hardware and supply voltage.
My first digital project is still operating in niagara falls ontario up on the wall in 2 of the more popular museums.
the record fastest drumbeat in the world was held by "some guy" and was around 127 beats per minute. the brains of the project was a microcode 16f84, and 17f84. the 16f drove the display and fed alphnumeric while the 17f counted beats on a piezo electric drum pad and compared to the "record" beat.
the skin of the finished project was slick, the inside was a fibreglass bread board. $1500 pricetag at time of release for $150 in parts and some brainwork.
The device was built in 1997, the record was for single stick drumbeat and ">was> around 127 beats per minute" would be a closer paraphrase. In any event this is about the hitachi lcd display rather than drumming.
Certainly clearer than the old HD4470 FAQ was. So its a handy reference if you're coming across these for the first time. Many people I know end up writing one init routine and use it and reuse it again and again and again ...
A recent bug I figured out later was sending a certain graphical character matched the "display off" command, and the command bit was not being set quickly enough due to a long cable connection. Once the display off command was sent the screen would not turn back on...
The best way to solve this is to implement firmware to read the status flag of the display, if you are lucky enough to have one. I find this helps a lot with all types of sensors and other external interfaces, send the data and read it back. You will thank yourself that 0.01% of the time it didn't work!