HD44780 / ST7066U Initialization

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

On Friday, October 9, 2020 at 9:29:54 PM UTC-4, Rick C 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.  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

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

On Friday, October 9, 2020 at 10:44:39 PM UTC-4, Rick C wrote:
> On Friday, October 9, 2020 at 9:29:54 PM UTC-4, Rick C 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.  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
> 
> 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%.  

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

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

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

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.deletethisbit@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 &times; 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

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

On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote:
> 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.

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

On Mon, 12 Oct 2020 19:14:27 -0700 (PDT), Rick C
<gnuarm.deletethisbit@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, stephen@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

On 10/12/20 10:14 PM, Rick C wrote:
> On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote:
>> 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.
> 
> 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. 
> 

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.

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