Forums

Another 16*2 LCD question..

Started by mjames_doveridge May 19, 2009
I already have a 2*16 LCD interfaced to an LPC2129 but, to be honest, it sucks, (the LCD interface was designed long ago by someone else). It works by polling the busy line to see if the LCD is ready for the next command. This makes the display slow, (the minimum 1ms OS sleep is too long for many commands), and wastes CPU cycles. I want to make the busy flag generate an interrupt when it goes not busy. The snag is that the LCD busy pin, (data MSB), is multiplexed and is used for data out as well as in.

My question is this - would it be better to use one pin on the LPC2129 to drive the MSB line and switch the function of the pin to and from GPIO/interrupt with PINSEL as required, or is this somehow dodgy and I should use two pins, one for GPIO, one for interrupt, and just enable the interrupt when I am waiting for command completion? The latter would surely work, but use up two pins:(

Anyone have advice/experience of this?

Rgds,
Martin

An Engineer's Guide to the LPC2100 Series

> I already have a 2*16 LCD interfaced to an LPC2129 but, to be honest, it
> sucks, (the LCD interface was designed long ago by someone else). It
> works by polling the busy line to see if the LCD is ready for the next
> command. This makes the display slow, (the minimum 1ms OS sleep is too
> long for many commands), and wastes CPU cycles.

What is the problem? If it is flickering of the display that can often
be eliminated by overwriting instead of clearing and re-writing.

Check the required delays (HD44780 datasheet). In most cases a short
busy wait will be sufficient, or a context switch (if it is indeed
guranteed 1ms minumum) and then continuing without checking the busy flag.

Another alternative: all display-writes go to an buffer. A
lowest-priority task continuously flushes this buffer to the display,
using just busy waits (there is nothing lower-level, so there is no
point in context switching - assuming you have a preemptive task switcher).

--

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

mjames_doveridge wrote:
>
> My question is this - would it be better to use one pin on the LPC2129 to drive the MSB line and switch the function of the pin to and from GPIO/interrupt with PINSEL as required,
The commands have known completion times, so you can use a
timer and make the output interrupt driven.

Think of it as a serial driver with a transmit buffer, except
instead of being driven by Tx FIFO low-mark interrupts it's
driven by timer interrupts. Implement the usual CR, LF, maybe
Ctrl-L to clear the screen, so it can be interchanged with a
serial driver. Maybe implement the SFE SetLCD control codes.

It's also too bad the EMC can't interface to the HD44780
directly and having to throw GPIO pins at it...

I don't believe you use bit 7 of the LCD as interrupt because you have to
perform a read cycle for it to reflect the state. I *think* that the E line
transition is what clocks the state out. Of course, you could always try it
and see what happens.

There's some LCD driver code in the http://jcwren.com/arm demo code. It
runs under FreeRTOS, but IIRC it wouldn't be too hard to retask it for
standalone or another RTOS.

--jc

On Tue, May 19, 2009 at 9:18 PM, Jan Brittenson wrote:

> mjames_doveridge wrote:
> >
> > My question is this - would it be better to use one pin on the LPC2129 to
> drive the MSB line and switch the function of the pin to and from
> GPIO/interrupt with PINSEL as required,
> The commands have known completion times, so you can use a
> timer and make the output interrupt driven.
>
> Think of it as a serial driver with a transmit buffer, except
> instead of being driven by Tx FIFO low-mark interrupts it's
> driven by timer interrupts. Implement the usual CR, LF, maybe
> Ctrl-L to clear the screen, so it can be interchanged with a
> serial driver. Maybe implement the SFE SetLCD control codes.
>
> It's also too bad the EMC can't interface to the HD44780
> directly and having to throw GPIO pins at it...
>
>
>