HD44780 / ST7066U Initialization

[Rick C]

I working with an LCD display using this chip which is apparently function compatible with the ubiquitous HD44780 LCD controller. The initialization sequence is a set of commands because no one trusts the internal power up reset. Rather than an MCU this will be driven from an FPGA with a repeating sequence, so I'd like to eliminate anything that is not important in the commands. In particular the "magical reset sequence" includes the Clear Display command which takes 1.52 ms to complete while the other instructions mostly complete in 37 us (give or take as I mention below).

I'm wondering if this command is strictly needed. It clears the display data RAM, resets the data RAM pointer and resets some cursor functions. I won't be using the cursor and I can manually reset the data RAM pointer easily enough. The data is completely written on a periodic basis, so clearing the memory is not useful. Does anyone know if this command does anything else that might be important? Or can I replace this command with one to simply set the display data RAM address pointer without impacting the operation of the display?

Does anyone know how many times the Function Set command needs to be sent to be sure of starting the chip off right? The data sheet I have shows twice for an 8 bit bus. I've seen people say three times for an 8 bit bus and 4 times for a 4 bit bus.

Then there is the timing... There is a read register which returns a BUSY bit. This won't be used to simplify the circuitry, instead fixed times will be used. The data sheets talk about times given a 270 kHz clock which seems to be generated internally. I'm unclear on how much margin I would need to include or if that is already included. Oddly enough the data sheet talks about using a resistor when "crystal oscillation is performed", but I'm pretty sure they are talking about an internal RC oscillator. I found one web site that talks about this discussing the impact of Vcc and just plain chip variations. The author speculates this is the issue that causes some code libraries to fail.

I don't need to worry about the bus timing. I'm going to make the bus cycle as long as the minimum instruction processing delay. Then it won't even be remotely close to the minimum timing specs.

I would fire this to measure, but I don't currently have hardware and need to construct a test bench to test my code. Knowing the actual requirements will help a lot.

Thanks

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Rick C]

Posting questions always helps me to think the problem though. The web page I found discussing the timing was good on that point. I guess he had a data sheet I haven't seen. The data sheet for the ST part doesn't have the graph, but does give a table limit of 190 kHz for the range. It doesn't indicate if this is inclusive of impact from variation in voltage and temperature, in fact, I assume not since the tables are not labeled that way. So throw in another ±10%.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[Rick C]

While thinking about how I might incorporate a 1.52 ms idle slot in the mechanics for controlling the LCD I was thinking of something that could be written that would not impact the display. The read operation would be ideal, but ordering a read in the works is more than I'd like to do. The data will be pulled from a dual port memory to be written to the display. One port writes and the other reads data to be shoved out to the display. I have 9 bit memory which gives me 8 bits of data and the RS control (data vs commands). To know this was for idle states would require decoding something. It could be the address, since I should know exactly how many instructions there are.

That was when I realized there is one command definition missing from the data sheet, the 0x00 opcode. They use a leading 1 detection scheme to allow varying sized data fields in the commands, but that leaves the 0x00 opcode as unspecified! I wonder if that would be a noop code. Still, I suppose it might involve whatever logic in the chip looking at it. If the processor is busy would this foul up the processing or would it just be ignored? I suppose one way out is to extend the length of the bus cycle to provide this wait. I've already extended a 1200 ns cycle to 37 us to deal with the fast instructions.

I want to do the initialization on every data burst to assure the chip is programmed correctly. This results in a total of 40 data and 7 instructions for 71 ms. That won't work well since the slow command clears the display and a character being blank for up to 70 ms would likely be noticed. Also, I'd like to refresh the display at least 10 times per second and that would be very noticeable.

So it is either accommodate a variable wait depending on the instruction or decode a "noop" command to perform reads or just leave out the Clear Display command entirely and hope it doesn't do anything important other than what is documented.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

[Jim Jackson]

I've held off from following up, because I'm no expert, but I was hoping
to learn some stuff. I have written LCD drivers - but just for myself.
When controlling an LCD directly connected to the SBC, I've used
checking the operation ocmpleted flag. But when using an I2C connected
LCD I just used, conservative, timing. Not an option for you.

On 2020-10-10, Rick C <gnuarm.del...@gmail.com> wrote:
>
> I working with an LCD display using this chip which is apparently
> function compatible with the ubiquitous HD44780 LCD controller. The
> initialization sequence is a set of commands because no one trusts the
> internal power up reset.

Maybe, but the device does need setting in 4/8bit mode.

> Rather than an MCU this will be driven from
> an FPGA with a repeating sequence, so I'd like to eliminate anything
> that is not important in the commands. In particular the "magical
> reset sequence" includes the Clear Display command which takes 1.52 ms
> to complete while the other instructions mostly complete in 37 us
> (give or take as I mention below).

I'm guessing just setting the char address, and increment, and writing
all the data in one go will be fine.

I seem to remember from last time I wrote 44780 code (a few years ago)
that the more modern clone I had was faster than the standard 44780 - I
certainly don't remember have timing problems when I developing the
code.

>
> I'm wondering if this command is strictly needed. It clears the
> display data RAM, resets the data RAM pointer and resets some cursor
> functions. I won't be using the cursor and I can manually reset the
> data RAM pointer easily enough. The data is completely written on a
> periodic basis, so clearing the memory is not useful. Does anyone
> know if this command does anything else that might be important? Or
> can I replace this command with one to simply set the display data RAM
> address pointer without impacting the operation of the display?
>
> Does anyone know how many times the Function Set command needs to be
> sent to be sure of starting the chip off right? The data sheet I have
> shows twice for an 8 bit bus. I've seen people say three times for an
> 8 bit bus and 4 times for a 4 bit bus.

I only ever send it twice - but I use 8 bit mode. you might need
3 times in 4 bit mode.

[Rick C]

On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote:
> I've held off from following up, because I'm no expert, but I was hoping
> to learn some stuff. I have written LCD drivers - but just for myself.
> When controlling an LCD directly connected to the SBC, I've used
> checking the operation ocmpleted flag. But when using an I2C connected
> LCD I just used, conservative, timing. Not an option for you.

Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing.

> On 2020-10-10, Rick C <gnuarm.del...@gmail.com> wrote:
> >
> > I working with an LCD display using this chip which is apparently
> > function compatible with the ubiquitous HD44780 LCD controller. The
> > initialization sequence is a set of commands because no one trusts the
> > internal power up reset.
>
> Maybe, but the device does need setting in 4/8bit mode.

If you are talking about relying on the power up reset, that sets the Function set register...

Initializing by Internal Reset Circuit
1. Display clear
2. Function set:
DL = 1; 8-bit interface data
N = 0; 1-line display
F = 0; 5 × 8 dot character font
3. Display on/off control:
D = 0; Display off
C = 0; Cursor off
B = 0; Blinking off
4. Entry mode set:
I/D = 1; Increment by 1
S = 0; No shift

The reason for performing a specific reset command sequence is because the device can not be relied on to reset itself unless the power up meets all the specs in the data sheet.

I'm doing the reset sequence to protect against glitches since the unit is not intended to be powered off. It has an internal battery backup.

> > Rather than an MCU this will be driven from
> > an FPGA with a repeating sequence, so I'd like to eliminate anything
> > that is not important in the commands. In particular the "magical
> > reset sequence" includes the Clear Display command which takes 1.52 ms
> > to complete while the other instructions mostly complete in 37 us
> > (give or take as I mention below).
>
> I'm guessing just setting the char address, and increment, and writing
> all the data in one go will be fine.

That's what I'm thinking, but not certain. Hard to tell from testing since that can't take into account the many variables.

> I seem to remember from last time I wrote 44780 code (a few years ago)
> that the more modern clone I had was faster than the standard 44780 - I
> certainly don't remember have timing problems when I developing the
> code.

The clocks may be faster, or they may be slower. The data sheets tend to echo the Hitachi data sheets, but testing with individual displays can't verify timing of your code. The design has to be based on the spec. I definitely see differences on the bus timing specifications, so those numbers need to be very conservative to be sure of meeting timing over a variety of suppliers.

> > I'm wondering if this command is strictly needed. It clears the
> > display data RAM, resets the data RAM pointer and resets some cursor
> > functions. I won't be using the cursor and I can manually reset the
> > data RAM pointer easily enough. The data is completely written on a
> > periodic basis, so clearing the memory is not useful. Does anyone
> > know if this command does anything else that might be important? Or
> > can I replace this command with one to simply set the display data RAM
> > address pointer without impacting the operation of the display?
> >
> > Does anyone know how many times the Function Set command needs to be
> > sent to be sure of starting the chip off right? The data sheet I have
> > shows twice for an 8 bit bus. I've seen people say three times for an
> > 8 bit bus and 4 times for a 4 bit bus.
>
> I only ever send it twice - but I use 8 bit mode. you might need
> 3 times in 4 bit mode.

The reset command sequence is about not knowing what mode the device is in. The best explanation of this I've seen is in the Wikipedia page for the controller although it explains the rational in a somewhat overly confusing manner. I proposed a more straightforward explanation in the talk page and will post it if there is no discussion in a week or so.

https://en.wikipedia.org/wiki/Talk:Hitachi_HD44780_LCD_controller

Bottom line is that if the controller is left in a state expecting the second nybble of a split transfer it takes three transfers to put it in a known state and you need to give it another command if you don't want 8 bit transfers, 1 line, 5x8 characters. If you want 4-bit mode, you need to send one more 4 bit transfer to put it into 4 bit mode and then a proper pair of 4-bit transfers to set the various bits in the Function set register, so a total of 6 enable pulses, all spaced at 37 us (plus whatever derating you are using) other than the last pair which only need to meet the standard bus timing specs.

I've been hitting the data sheets hard on this one because the data sheets are not very clear. The issue I'm concerned about is that there are details the Reset command does that are not fully documented, but it's not like this is an overly complex device, so probably not. Then there is the issue of the reset command blanking the display and it taking a (relatively) long time to get characters in all 32 positions plus the defined CGRAM characters (another 64 transfers). Using the minimum instruction delay (all commands other than the reset and home commands) to define the wait time for the slow commands only adds another 25 cycles to the ~100 I will be sending anyway. But I'm worried about the display dimming for the later characters that have been cleared and then take a while before being refreshed. I want to refresh the whole display on a rapid basis to allow blinking and quick response. We have a thermometer graph that is updated in real time, so at least 10x per second and >30 Hz would be better. At 100 Hz the refresh time of ~8 ms would certainly be noticed and even at 30 ms refresh interval I think it might be noticed.

So I'm thinking of leaving out the Reset command because of that. Then the characters are overwritten without being blanked and no dimming. Should work.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

[Clifford Heath]

On 13/10/20 3:08 am, Rick C wrote:
> On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote:
>> I've held off from following up, because I'm no expert, but I was hoping
>> to learn some stuff. I have written LCD drivers - but just for myself.
>> When controlling an LCD directly connected to the SBC, I've used
>> checking the operation ocmpleted flag. But when using an I2C connected
>> LCD I just used, conservative, timing. Not an option for you.
>
> Not sure why you say this is not an option for me. That's exactly what I plan to do, use "conservative" timing.

It's been over a decade since I wrote a driver for this family of chips
and my recollection has faded, but at the time, there were complaints in
the forums that the busy flag was unreliable for detecting completion of
some operations, and that the actual required time seemed to vary. Also
there are various clones of the chip that have different behaviour so
unless you know what you've got, you have to just use conservative
timing. It was the only real option, and is the one I used.

CH

[Rick C]

That's interesting. This is the first I've heard that the busy flag isn't reliable.

I've been pushing numbers around and given the amount of data I need to shove across the interface on every refresh I can't update as fast as I'd like using the Reset command without a significant portion of the time being blank for the last characters in the display. So I'll leave some flexibility and try omitting the Reset. Then it's just writing one char over another and after that it's just writing the same char over the old same char so no dimming, no worry of flicker.

We'll see what I think of it in the morning. Just watched the first half of Monday night football and I want to see if the Saints can win.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

[Stephen Pelc]

On Mon, 12 Oct 2020 19:14:27 -0700 (PDT), Rick C
<gnuarm.del...@gmail.com> wrote:

>We'll see what I think of it in the morning. Just watched the first half o=
>f Monday night football and I want to see if the Saints can win.=20

I didn't know that Southampton played on Mondays.

Stephen

--
Stephen Pelc, ste...@vfxforth.com <<< NEW
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612
web: http://www.mpeforth.com - free VFX Forth downloads

[Richard Damon]

First, it is NOT expected that this sort of chip gets 'Reset' for every
update, that is a good way to induce flicker. I would just do the Reset
sequence at first turn on, and maybe at occasional operational points
where you are naturally blanking and redrawing the full screen (so the
blanking isn't noticeable), and at other times just be doing the minimum
to update the screen contents.

[Rick C]

On Tuesday, October 13, 2020 at 6:54:25 AM UTC-4, Stephen Pelc wrote:
> On Mon, 12 Oct 2020 19:14:27 -0700 (PDT), Rick C
> <gnuarm.del...@gmail.com> wrote:
>
> >We'll see what I think of it in the morning. Just watched the first half o=
> >f Monday night football and I want to see if the Saints can win.=20
>
> I didn't know that Southampton played on Mondays.

No, no! Football, not futball. ;)

It was a good game. The Saints pulled it out at the end. The Chargers are a team to be reconned with though.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

[Rick C]

There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming.

I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed.

I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor.

It would be nice if a good data sheet where available that didn't leave so many half answered questions.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

[Richard Damon]

> much you

> There will only be flicker if the blanked time is significant in relation to the unblanked time AND the rate of blinking is slow enough. Because the update rate is pretty fast, ~100 Hz, my real concern is dimming of the last written characters, not dimming.
>
> I don't wish to add complexity to the design. The only "operational points" are updates. The character data will be pulled from a RAM on each refresh. I have not decided if the commands will also be in the RAM or if they will be hardwired in the FPGA. If in the RAM changing the configuration sequence would require a slow rate timer (long length) to trigger a write to change the sequence and then back after a refresh (lots of messy logic). If the commands are in logic then the same timer can add the command in the logic with less messy logic, but still more than desired. I prefer not to do this if not needed.
>
> I'm thinking the reset is not needed if the set address command is used and all the characters are sent each time. Oh, and we are not using the cursor.
>
> It would be nice if a good data sheet where available that didn't leave so many half answered questions.
>

The problem is that if you send a 'Reset' command, at a minimum you
interrupt the scan sequence, so regularly doing this will at a minimum
say that later parts of the scan will appear less than earlier parts. It
also tends to mean you need to resend more initialization data to the
chip, much you want to send before turning the display back on, so the
display is refreshed less, and maybe even will be perceptibly flashing.
(At 100 Hz, most people probably won't perceive flashing, but a small
minority may sense a 'something')

Much better is to just set the display ram address to the beginning of
memory and streaming the array of data for the update, and not do a full
reset for the update.

[Rick C]

Will omitting the reset command cause any issues? The data sheets are crappy enough that I can't say there is nothing that the reset does that I can't duplicate with other commands.

But that's what I'm going to try. The command stream will be from logic and the character data will be from RAM. The character data is updated on a regular basis with simple computation of addresses. I may provide several areas of RAM for the different display modes and fill in all of them, then let the display circuit select the right one for display depending on the mode. Some modes have fixed text and others lots of variables. One block RAM should cover them all.

We have two display features that are thermometer displays. Rather than define multiple characters and select the appropriate character in the display RAM, I'm going to pick one CGRAM character each and change the character on the fly. That will only be 16 bytes rather than the full 64 bytes of CGRAM reducing the update time a lot.

Not sure about the start of your post. Are you saying the "scanning" of the DDRAM to generate the LCD driver data will be reset by the "Clear display" command? That's the sort of undocumented feature I'm worried about. Have you seen this behavior?

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

[Richard Damon]

I don't know that particular chip well enough to know if it has some
internal state that really needs a reset. Most chips needs some form of
reset to initialize, but often then can get that by internally
generating a Power On Reset. It might be good enough to just have a
capacitor on the Reset line to force a Reset at power on. That does say
you will need to wait a certain period of time after power on, (so the
chip comes out of reset) and then send the initial config sequence.

What I was talking about is the way the controller actually works, it
doesn't control all the bits of the display at once, as that would take
a LOT of connections, but these sorts of chips divide the display into
rows and columns (that might not match the physical display, the HD44780
has 40 columns of up to 16 rows) and at any given instant in time are
driving one column of pixels, and cycle through the columns at a fast
rate, so it appears always on. Cheaper devices tend to go slower, as it
is it is a bit easier to do. If you even had a device that the display
seemed to flicker likely was scanning just a bit too slow. The problem
with doing a reset (or even a periodic blank/update/unblank pattern) is
that if you stop this scanning in the middle, the last columns will have
one less update than the first, and appear dimmer. This will be a lot
more noticeable if you do this at a small multiple of the scan time (as
3/4 is a lot smaller than 999/1000, and 0/1 is REALLY noticeable).
Reading the data sheet, the scan time from the device is a function of
its configuration, but it looks like in all cases it is over 10 ms, so
doing a reset pattern at 100 Hz (10 ms) would be bad, and some of the
display never shown. In fact, even updating the display at 100 Hz has
some potential problems as 'fast' motion might become jerky.

[Rick C]

Yes, I know what you are talking about. I think you are assuming the "Clear display" command is an actual global reset of some sort which I'm pretty sure it is not. The commands on this device take a minimum of 10 clock cycles to execute. The Clear display and Return home commands take 1.52 ms or 182 clock cycles. That says to me it is a state machine executing something like a script rather than anything like a reset. So it is unlikely the display timing would be interrupted.

> Reading the data sheet, the scan time from the device is a function of
> its configuration, but it looks like in all cases it is over 10 ms, so
> doing a reset pattern at 100 Hz (10 ms) would be bad, and some of the
> display never shown. In fact, even updating the display at 100 Hz has
> some potential problems as 'fast' motion might become jerky.

All based on the assumption the display timing is impacted in any way by the Clear Display command. I don't have a unit I can test, but I'll ask one of the software guys if they can check this out for me.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209