HD44780 / ST7066U Initialization

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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 r
eset.  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 c
ommands.  In particular the "magical reset sequence" includes the Clear Dis
play command which takes 1.52 ms to complete while the other instructions m
ostly complete in 37 us (give or take as I mention below).  

I'm wondering if this command is strictly needed.  It clears the display da
ta RAM, resets the data RAM pointer and resets some cursor functions.  I wo
n't be using the cursor and I can manually reset the data RAM pointer easil
y 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 e
lse that might be important?  Or can I replace this command with one to sim
ply set the display data RAM address pointer without impacting the operatio
n of the display?  

Does anyone know how many times the Function Set command needs to be sent t
o be sure of starting the chip off right?  The data sheet I have shows twic
e 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 wil
l be used.  The data sheets talk about times given a 270 kHz clock which se
ems to be generated internally.  I'm unclear on how much margin I would nee
d to include or if that is already included.  Oddly enough the data sheet t
alks about using a resistor when "crystal oscillation is performed", but I'
m pretty sure they are talking about an internal RC oscillator.  I found on
e web site that talks about this discussing the impact of Vcc and just plai
n chip variations.  The author speculates this is the issue that causes som
e code libraries to fail.  

I don't need to worry about the bus timing.  I'm going to make the bus cycl
e 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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On Friday, October 9, 2020 at 9:29:54 PM UTC-4, Rick C wrote:
Quoted text here. Click to load it
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).  
Quoted text here. Click to load it
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?  
Quoted text here. Click to load it
 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.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
cle as long as the minimum instruction processing delay.  Then it won't eve
n be remotely close to the minimum timing specs.  
Quoted text here. Click to load it
d to construct a test bench to test my code.  Knowing the actual requiremen
ts will help a lot.  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On Friday, October 9, 2020 at 10:44:39 PM UTC-4, Rick C wrote:
Quoted text here. Click to load it
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).  
Quoted text here. Click to load it
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?  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
cycle as long as the minimum instruction processing delay.  Then it won't e
ven be remotely close to the minimum timing specs.  
Quoted text here. Click to load it
eed to construct a test bench to test my code.  Knowing the actual requirem
ents will help a lot.  
Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Re: HD44780 / ST7066U Initialization
On Monday, October 12, 2020 at 6:36:35 AM UTC-4, Jim Jackson wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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


Quoted text here. Click to load it
  
Quoted text here. Click to load it

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

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


Quoted text here. Click to load it
  
Quoted text here. Click to load it

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


Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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.  

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

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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On 13/10/20 3:08 am, Rick C wrote:
Quoted text here. Click to load it

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

Re: HD44780 / ST7066U Initialization
On Monday, October 12, 2020 at 6:26:51 PM UTC-4, Clifford Heath wrote:
Quoted text here. Click to load it
ng
 I plan to do, use "conservative" timing.
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On Mon, 12 Oct 2020 19:14:27 -0700 (PDT), Rick C

Quoted text here. Click to load it

I didn't know that Southampton played on Mondays.

Stephen

--  
Stephen Pelc, snipped-for-privacy@vfxforth.com <<< NEW
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On Tuesday, October 13, 2020 at 6:54:25 AM UTC-4, Stephen Pelc wrote:
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On 10/12/20 10:14 PM, Rick C wrote:
Quoted text here. Click to load it

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.

Re: HD44780 / ST7066U Initialization
On Tuesday, October 13, 2020 at 8:43:55 AM UTC-4, Richard Damon wrote:
Quoted text here. Click to load it
ping
f.
ed
at I plan to do, use "conservative" timing.
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
in  
Quoted text here. Click to load it
of  
Quoted text here. Click to load it
so  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
n't reliable.  
Quoted text here. Click to load it
 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.  
Quoted text here. Click to load it
lf of Monday night football and I want to see if the Saints can win.  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On 10/13/20 10:42 AM, Rick C wrote:
Quoted text here. Click to load it

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.

Re: HD44780 / ST7066U Initialization
On Tuesday, October 13, 2020 at 1:34:37 PM UTC-4, Richard Damon wrote:
Quoted text here. Click to load it
:
Quoted text here. Click to load it
hoping
elf.
cted
what I plan to do, use "conservative" timing.
Quoted text here. Click to load it
ips  
Quoted text here. Click to load it
s in  
Quoted text here. Click to load it
n of  
Quoted text here. Click to load it
Also  
Quoted text here. Click to load it
o  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
isn't reliable.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
half of Monday night football and I want to see if the Saints can win.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
 and all the characters are sent each time.  Oh, and we are not using the c
ursor.  
Quoted text here. Click to load it
 so many half answered questions.  
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: HD44780 / ST7066U Initialization
On 10/14/20 1:07 AM, Rick C wrote:
Quoted text here. Click to load it

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.

Re: HD44780 / ST7066U Initialization
On Wednesday, October 14, 2020 at 8:51:33 AM UTC-4, Richard Damon wrote:
Quoted text here. Click to load it
:
Quoted text here. Click to load it
te:
Quoted text here. Click to load it
e:
Quoted text here. Click to load it
s hoping
yself.
nected
y what I plan to do, use "conservative" timing.
Quoted text here. Click to load it
chips  
Quoted text here. Click to load it
nts in  
Quoted text here. Click to load it
ion of  
Quoted text here. Click to load it
  Also  
Quoted text here. Click to load it
 so  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
g isn't reliable.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
t half of Monday night football and I want to see if the Saints can win.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
ed and all the characters are sent each time.  Oh, and we are not using the
 cursor.  
Quoted text here. Click to load it
ve so many half answered questions.  
Quoted text here. Click to load it
It
.
ll
crappy enough that I can't say there is nothing that the reset does that I  
can't duplicate with other commands.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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.  
Quoted text here. Click to load it
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?  
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline