HD44780 / ST7066U Initialization

n compatible with the ubiquitous HD44780 LCD controller. The initializatio n 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 repeati ng sequence, so I'd like to eliminate anything that is not important in the commands. In particular the "magical reset sequence" includes the Clear D isplay command which takes 1.52 ms to complete while the other instructions mostly complete in 37 us (give or take as I mention below).

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 eas ily enough. The data is completely written on a periodic basis, so clearin g 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 s imply set the display data RAM address pointer without impacting the operat ion of the display?

to be sure of starting the chip off right? The data sheet I have shows tw ice for an 8 bit bus. I've seen people say three times for an 8 bit bus an d 4 times for a 4 bit bus.

Y bit. This won't be used to simplify the circuitry, instead fixed times w ill 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 n eed 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 pl ain chip variations. The author speculates this is the issue that causes s ome code libraries to fail.

cle as long as the minimum instruction processing delay. Then it won't eve n be remotely close to the minimum timing specs.

d to construct a test bench to test my code. Knowing the actual requiremen ts will help a lot.

Posting questions always helps me to think the problem though. The web pag e I found discussing the timing was good on that point. I guess he had a d ata 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 in dicate if this is inclusive of impact from variation in voltage and tempera ture, in fact, I assume not since the tables are not labeled that way. So

--

  Rick C. 

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

ion compatible with the ubiquitous HD44780 LCD controller. The initializat ion 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 repea ting sequence, so I'd like to eliminate anything that is not important in t he commands. In particular the "magical reset sequence" includes the Clear Display command which takes 1.52 ms to complete while the other instructio ns mostly complete in 37 us (give or take as I mention below).

y 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 e asily enough. The data is completely written on a periodic basis, so clear ing the memory is not useful. Does anyone know if this command does anythi ng 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 oper ation of the display?

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

USY 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 whic h 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 she et talks about using a resistor when "crystal oscillation is performed", bu t I'm pretty sure they are talking about an internal RC oscillator. I foun d 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.

cycle as long as the minimum instruction processing delay. Then it won't e ven be remotely close to the minimum timing specs.

eed to construct a test bench to test my code. Knowing the actual requirem ents will help a lot.

age 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 th e 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 tempe rature, in fact, I assume not since the tables are not labeled that way. S

While thinking about how I might incorporate a 1.52 ms idle slot in the mec hanics for controlling the LCD I was thinking of something that could be wr itten 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 w ill be pulled from a dual port memory to be written to the display. One po rt 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 com mands). To know this was for idle states would require decoding something. It could be the address, since I should know exactly how many instruction s there are.

That was when I realized there is one command definition missing from the d ata 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 processo r 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 th is wait. I've already extended a 1200 ns cycle to 37 us to deal with the f ast instructions.

I want to do the initialization on every data burst to assure the chip is p rogrammed 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 wou ld 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 Displ ay command entirely and hope it doesn't do anything important other than wh at is documented.

--

  Rick C. 

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

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

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 only ever send it twice - but I use 8 bit mode. you might need

3 times in 4 bit mode.

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

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

Initializing by Internal Reset Circuit

1. Display clear
2. Function set: DL = 1; 8-bit interface data N = 0; 1-line display

1. Display on/off control: D = 0; Display off C = 0; Cursor off B = 0; Blinking off

1. 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 t he 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.

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

The clocks may be faster, or they may be slower. The data sheets tend to e cho the Hitachi data sheets, but testing with individual displays can't ver ify timing of your code. The design has to be based on the spec. I defini tely see differences on the bus timing specifications, so those numbers nee d to be very conservative to be sure of meeting timing over a variety of su ppliers.

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

Bottom line is that if the controller is left in a state expecting the seco nd 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 tran sfers, 1 line, 5x8 characters. If you want 4-bit mode, you need to send on e 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 t otal of 6 enable pulses, all spaced at 37 us (plus whatever derating you ar e 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 detail s the Reset command does that are not fully documented, but it's not like t his 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 characte rs (another 64 transfers). Using the minimum instruction delay (all comman ds 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 any way. But I'm worried about the display dimming for the later characters th at 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 r esponse. We have a thermometer graph that is updated in real time, so at l east 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 t hink 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 w ork.

--

  Rick C. 

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

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

ng

I plan to do, use "conservative" timing.

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 sho ve 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 bl ank 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 o f 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

I didn't know that Southampton played on Mondays.

Stephen

--
Stephen Pelc, stephen@vfxforth.com

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.

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

ping

f.

ed

at I plan to do, use "conservative" timing.

s

in

of

so

n't reliable.

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 bein g blank for the last characters in the display. So I'll leave some flexibi lity and try omitting the Reset. Then it's just writing one char over anot her and after that it's just writing the same char over the old same char s o no dimming, no worry of flicker.

lf of Monday night football and I want to see if the Saints can win.

There will only be flicker if the blanked time is significant in relation t o 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 refres h. I have not decided if the commands will also be in the RAM or if they w ill be hardwired in the FPGA. If in the RAM changing the configuration seq uence would require a slow rate timer (long length) to trigger a write to c hange 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 l ogic with less messy logic, but still more than desired. I prefer not to d o 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 curso r.

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

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.

:

hoping

elf.

cted

what I plan to do, use "conservative" timing.

ips

s in

n of

Also

o

isn't reliable.

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 be ing blank for the last characters in the display. So I'll leave some flexi bility and try omitting the Reset. Then it's just writing one char over an other and after that it's just writing the same char over the old same char so no dimming, no worry of flicker.

half of Monday night football and I want to see if the Saints can win.

y t

um

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

ints" are updates. The character data will be pulled from a RAM on each re fresh. I have not decided if the commands will also be in the RAM or if th ey 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 t he logic with less messy logic, but still more than desired. I prefer not to do this if not needed.

and all the characters are sent each time. Oh, and we are not using the c ursor.

so many half answered questions.

Will omitting the reset command cause any issues? The data sheets are crap py 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 an d 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 m ode. Some modes have fixed text and others lots of variables. One block R AM should cover them all.

We have two display features that are thermometer displays. Rather than de fine multiple characters and select the appropriate character in the displa y 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 CG RAM reducing the update time a lot.

Not sure about the start of your post. Are you saying the "scanning" of th e 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. Hav e you seen this behavior?

--

  Rick C. 

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

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.

:

te:

e:

s hoping

yself.

nected

y what I plan to do, use "conservative" timing.

chips

nts in

ion of

Also

so

g isn't reliable.

d 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 fle xibility 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 ch ar so no dimming, no worry of flicker.

t half of Monday night football and I want to see if the Saints can win.

ery

set

s

he

imum

tion to the unblanked time AND the rate of blinking is slow enough. Becaus e the update rate is pretty fast, ~100 Hz, my real concern is dimming of th e last written characters, not dimming.

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 configurati on sequence would require a slow rate timer (long length) to trigger a writ e 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 no t to do this if not needed.

ed and all the characters are sent each time. Oh, and we are not using the cursor.

ve so many half answered questions.

It

.

ll

crappy enough that I can't say there is nothing that the reset does that I can't duplicate with other commands.

c and the character data will be from RAM. The character data is updated o n a regular basis with simple computation of addresses. I may provide seve ral areas of RAM for the different display modes and fill in all of them, t hen let the display circuit select the right one for display depending on t he mode. Some modes have fixed text and others lots of variables. One blo ck RAM should cover them all.

n define multiple characters and select the appropriate character in the di splay RAM, I'm going to pick one CGRAM character each and change the charac ter on the fly. That will only be 16 bytes rather than the full 64 bytes o f CGRAM reducing the update time a lot.

f the DDRAM to generate the LCD driver data will be reset by the "Clear dis play" command? That's the sort of undocumented feature I'm worried about. Have you seen this behavior?

Yes, I know what you are talking about. I think you are assuming the "Clea r 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 cyc les 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 somethi ng like a script rather than anything like a reset. So it is unlikely the display timing would be interrupted.

All based on the assumption the display timing is impacted in any way by th e 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