What is wrong with this LCD code?

I have 16x4 HD44780 base LCD module.

2 days ago I wrote the code and it worked but I wasn't pleased with it so i deleted it and started writing new one. And for the lase 2 days it won't work :((( I lost 5-6 hours already on this. I can't even get LCD to initialize and turn cursor and blinking ON.

Can you people find something wrong in this init code? MCU is LPC22129 with ARM7 running at 60MHz

void LCDInit(void) { IODIR0=0x7F00; IOCLR0=0x7F00; IOSET0=0x0200; LCDtoggle(); IOCLR0=0x7F00; IOSET0=0x0800; LCDtoggle(); IOCLR0=0x7F00; LCDtoggle(); IOSET0=0x0F00; LCDtoggle(); }

void LCDtoggle(void) { IOSET0=ENABLE; delayus(1); //wait for 1 microsec IOCLR0=ENABLE; }

Reply to
Mad I.D.
Loading thread data ...

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

60Mhz. So start with adding some realy slow delay loops between each I/O operations. Or even better, write some code that you can step manually through each I/O operation. And maybe things start working..

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

Reply to
StanV

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

1 or more milli-seconds. Start with a 10 ms delay between actual commands. Some can later be changed to 1 micro second.

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

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

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

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.

Reply to
Everett M. Greene

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

Reply to
Mike Silva

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

Reply to
cbarn24050

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

Reply to
mc

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

Reply to
Mad I.D.

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

Reply to
Mike Silva

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

Rene

Reply to
Rene Tschaggelar

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.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

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

Reply to
Mike Silva

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.

Reply to
cbarn24050

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

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
Jim Granville

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

Reply to
Mad I.D.

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

2 kHz timer interrupt to copy individual bytes from the the SRAM buffer to the LCD screen. For small screens this works fine. For bigger screens, you may not want to use so much SRAM.

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.

Reply to
Arlet

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.

Reply to
Mike Silva

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.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef

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?

Reply to
Everett M. Greene

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.