What is wrong with this LCD code?

I can't comment on your code, but first thing that comes to my mind is timing. Many of these LCD Displays are slow compared to a ARM7 op

Otherwise, read and reread all the datasheets, in my experience, i was always wrong, not the datasheet.

Check the data sheets as the FIRST initialise command(s) are expected to be

LCD controllers like these are VERY slow compared to the micros.

There is some C code meant for H8 on GNUH8 site listed below.

Very, very true about needing loooong time delays between commands. There's also a status line that can be read to confirm completion of the previous command but be advised that the status does not perform correctly for the first couple of initialization commands.

That was exactly my thought. The OP should look on a scope at the actual signals sent to the display, and confirm all the timing is within spec (setup times, strobe times, hold times, everything).

If memory serves the initialisation routine required is around 20mS long, your seems to be about 4uS. Read the datasheet slower.

Try a 4- or 5-millisecond delay, not a 1-microsecond delay.

On Sun, 17 Sep 2006 09:41:26 +0200, Mad I.D. wrote: /cut

It works again after 3 hours od programming :) Yes, ARM is too fast, and delays are very important.

Another thing, there has to be initialization software (the one that is already done by power up) because it wont work when you do a chip reset.

I can say it is easier to program LCD with 8051 than with all-mighty ARM.

ByTheWay I wrote LCDWait function (it checks busy flag).

And one last thing, here in Croatia 20x4 LCD costs 38 ¤ ! :-( Sad thing

I know what you mean! Why do we still have to put up with display interfaces that are '70s-slow anyway?

Because they have to run on a few mA, at most.

Rene

An open drain/collector output to signal ready/interupt is the best improvement that can be made, and would avoid MOST of the timing delay issues (except timeout for no device which could be a long tiemout anyway).

Secondly having I/P latches capable of latching at higher speeds from the supplied clocking method, would also help greatly.

I don't think that would increase the mA that much and would help reduce code size and speed problems for the majority of controllers. Especially as more and more compute intensive applications require LCDs even as portable applications, so interfacing becomes more and more of a grind.

Some have to, yes. But must we really still deal with 40us/char data writes for this capability 20 years later? (an honest question, not a rhetorical one).

Thats the problem with a "standard" device licenced to all and sundry, It's desgn becomes frozen in time. In this case there is no real benefit to making it faster so why spend the millions.

And folks wonder why they should bother using version control systems. If it works -- I archive it.

I have not tried it, but what happens if you hold the BUS in read and watch the BUSY flag - does that change when ready, or do you need to cycle the E line to update the BUSY flag ?

I've always thought the sensible next step was a dual SPI/parallel interface, but that seems to have never caught on. Philips had a couple of LCD variants with i2c but perhaps they just could not compete with the inertia, and very low costs of the entrenched controllers ?

-jg

My check busy function works and I cycle enable all the time.

In a recent project where I've interfaced an ARM with LCD screen, the firmware kept a local copy of the LCD contents in its SRAM, and used a

This saves an I/O line, and avoids wasting many CPU cycles on waiting for the slow display. Also, this means you can write to the LCD screen from interrupt routines and high priority tasks, since you only write to the SRAM buffer.

With a little bit of extra code (~15 lines) you can even implement blinking characters by alternating between writing buffer contents and spaces in the timer update routine. Of course, you'll need to maintain an extra attribute bit per character to indicate blinking.

Yes, that (500us interrupt) is not a bad way of doing it with a fast processor. Still, it's only the best of a set of bad choices. Another choice is to add a small micro to handle all the slow IO (not just the display) and pass it to and from the big, fast micro.

I don't know what CPU you are using, but in a simular situation on an Atmel AT91 we have used the PDC of a spare serial channel to do the lcd update. Tx looped back to rx and use the baudrate to set the time between bytes. Requires that the register the data must be written to is mapped to a block of memory, not a single address. We did this by connecting C/D of the lcd controller to A16 instead of the standard A0.

There wouldn't be any functional improvement if it were. LCDs have a rather slow response and the humans reading the display are only slightly faster. You could make the interface easier to program, but you'd probably have to have a delay somewhere to slow the screen update rate.

Rhetorical question: Why do the controllers need 20 msec. or so to initialize?