
Microcontroller LCD Initialization (2012) - hharnisch
http://web.alfredstate.edu/faculty/weimandn/lcd/lcd_initialization/lcd_initialization_index.html
======
roland35
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!

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

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

But nothing really weird.

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

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

~~~
alxlaz
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).

~~~
rolph
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?

~~~
alxlaz
It's purely circumstantial :).

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

------
Nr7
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](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=vV8FbwobrKY)
[https://www.youtube.com/watch?v=pQk3XgpuaJ4](https://www.youtube.com/watch?v=pQk3XgpuaJ4)

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

~~~
benj111
"127 beats per minute"

This sounded slow to me, turns out it is

Some guy doing 20 beats per second
[https://www.telegraph.co.uk/news/newsvideo/weirdnewsvideo/10...](https://www.telegraph.co.uk/news/newsvideo/weirdnewsvideo/10187844/Worlds-
fastest-drummer-sets-record-with-over-20-beats-per-second.html)

Edit: Quoted wrong

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

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

