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


Groups > comp.arch.embedded > #30022

Re: HD44780 / ST7066U Initialization

From Jim Jackson <jj@franjam.org.uk>
Newsgroups comp.arch.embedded
Subject Re: HD44780 / ST7066U Initialization
Date 2020-10-12 10:36 +0000
Organization A noiseless patient Spider
Message-ID <slrnro8cde.2ik.jj@iridium.wf32df> (permalink)
References <0f3e8293-39a0-4bb0-b5c6-f24e6c8d8231o@googlegroups.com>

Show all headers | View raw


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
>

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web