Microcontroller LCD Initialization (2012) (opens in new tab)

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.

It's amazing that this weird architecture has endured for so many years. These displays continue to be cheap and handy.

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.

The 8-Bit Guy on Youtube made a great video series on character LCD screens and how to run them.

In the first video he shows how to drive one manually using just switches: https://www.youtube.com/watch?v=hZRL8luuPb8

In parts 2 and 3 he shows two ways how to drive them with a C64: https://www.youtube.com/watch?v=vV8FbwobrKY https://www.youtube.com/watch?v=pQk3XgpuaJ4

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.

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 ...