Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30019 > unrolled thread

HD44780 / ST7066U Initialization

Back to article view | Back to comp.arch.embedded

Contents

  HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-09 18:29 -0700
    Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-09 19:44 -0700
      Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-09 20:49 -0700
    Re: HD44780 / ST7066U Initialization Jim Jackson <jj@franjam.org.uk> - 2020-10-12 10:36 +0000
      Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-12 09:08 -0700
        Re: HD44780 / ST7066U Initialization Clifford Heath <no.spam@please.net> - 2020-10-13 09:26 +1100
          Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-12 19:14 -0700
            Re: HD44780 / ST7066U Initialization stephen@mpeforth.com (Stephen Pelc) - 2020-10-13 10:54 +0000
              Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-13 07:29 -0700
            Re: HD44780 / ST7066U Initialization Richard Damon <Richard@Damon-Family.org> - 2020-10-13 08:43 -0400
              Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-13 07:42 -0700
                Re: HD44780 / ST7066U Initialization Richard Damon <Richard@Damon-Family.org> - 2020-10-13 13:34 -0400
                  Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-13 22:07 -0700
                    Re: HD44780 / ST7066U Initialization Richard Damon <Richard@Damon-Family.org> - 2020-10-14 08:51 -0400
                      Re: HD44780 / ST7066U Initialization Rick C <gnuarm.deletethisbit@gmail.com> - 2020-10-14 08:32 -0700

#30019 — 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

[toc] | [next] | [standalone]

#30020

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

[toc] | [prev] | [next] | [standalone]

#30021

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

[toc] | [prev] | [next] | [standalone]

#30022

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
>

[toc] | [prev] | [next] | [standalone]

#30023

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

[toc] | [prev] | [next] | [standalone]

#30024

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

[toc] | [prev] | [next] | [standalone]

#30025

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

[toc] | [prev] | [next] | [standalone]

#30026

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

[toc] | [prev] | [next] | [standalone]

#30028

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

[toc] | [prev] | [next] | [standalone]

#30027

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.

[toc] | [prev] | [next] | [standalone]

#30029

On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#30030

On 10/13/20 10:42 AM, Rick C wrote:
> On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:
>> 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.
> 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.

[toc] | [prev] | [next] | [standalone]

#30031

On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote:
> On 10/13/20 10:42 AM, Rick C wrote:
> > On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:
> >> 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.
> > 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.

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

[toc] | [prev] | [next] | [standalone]

#30032

On 10/14/20 1:07 AM, Rick C wrote:
> On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote:
>> On 10/13/20 10:42 AM, Rick C wrote:
>>> On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:
>>>> 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.
>>> 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.
> 
> 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? 
> 

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.

[toc] | [prev] | [next] | [standalone]

#30033

On Wednesday, October 14, 2020 at 8:51:33 AM UTC-4, Richard Damon wrote:
> On 10/14/20 1:07 AM, Rick C wrote:
> > On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote:
> >> On 10/13/20 10:42 AM, Rick C wrote:
> >>> On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:
> >>>> 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.
> >>> 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.
> > 
> > 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? 
> > 
> 
> 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).

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web