Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30022
| 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> |
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
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