What is wrong with this LCD code?

On Sunday, in article <450dc071$1_2@news.bluewin.ch>
     none@none.net "Rene Tschaggelar" wrote:

>Mike Silva wrote:
>> Mad I.D. wrote:
>> 
>>>I can say it is easier to program LCD with 8051 than with all-mighty ARM.
>> 
>> 
>> 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.

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
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

Rene Tschaggelar wrote:
> Mike Silva wrote:
> > Mad I.D. wrote:
> >
> >>I can say it is easier to program LCD with 8051 than with all-mighty ARM.
> >
> > 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.

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

Mike Silva wrote:
> Rene Tschaggelar wrote:
> > Mike Silva wrote:
> > > Mad I.D. wrote:
> > >
> > >>I can say it is easier to program LCD with 8051 than with all-mighty ARM.
> > >
> > > 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.
>
> 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.

Mad I.D. wrote:

> 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.
> 
And folks wonder why they should bother using version control systems. 
If it works -- I archive it.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Paul Carpenter wrote:
> On Sunday, in article <450dc071$1_2@news.bluewin.ch>
>      none@none.net "Rene Tschaggelar" wrote:
> 
> 
>>Mike Silva wrote:
>>
>>>Mad I.D. wrote:
>>>
>>>
>>>>I can say it is easier to program LCD with 8051 than with all-mighty ARM.
>>>
>>>
>>>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.
> 
> 
> 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).

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 ?

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

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

On Mon, 18 Sep 2006 19:36:50 +1200, Jim Granville wrote:
> 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 ?

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

Mad I.D. wrote:

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

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.

Arlet wrote:
>
> 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.

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.

In comp.arch.embedded,
Mike Silva <snarflemike@yahoo.com> wrote:
>
> Arlet wrote:
>>
>> 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.
>
> 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.

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

"Mike Silva" <snarflemike@yahoo.com> writes:
> Mad I.D. wrote:
> >
> > I can say it is easier to program LCD with 8051 than
> > with all-mighty ARM.
> 
> I know what you mean!  Why do we still have to put up
> with display interfaces that are '70s-slow anyway?

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?