AVR-Chat

David Kelly wrote:
> On Fri, Feb 16, 2007 at 11:53:22AM -0000, Tim Mitchell wrote:
>> 
>> This is true - it's not a fault, just means your software has not
>> initialised the display. 
>> 
>> The controllers on the LCDs are really really slow compared to AVR
>> speed. If your LCD initialisation is not working, try putting wait
>> loops in everywhere - you have to wait several milliseconds for the
>> controller to initialise properly.
> 
> Most don't do it but I have always advocated polling the busy bit on
> the LCD controller rather than use timing loops. 

According to my LCD code (which does work, but I wrote it a while ago)
you can't use the busy bit while initialising the controller - you have
to just wait. And wait....

-- 
Tim Mitchell
tim@sabretechnology.co.uk http://www.sabretechnology.co.uk
Sabre Technology (Hull) Ltd, 3a Newlands Science Park, Hull HU6 7TQ
t:01482 801003 f:01482 801078

>
> According to my LCD code (which does work, but I wrote it a while ago)
> you can't use the busy bit while initialising the controller - you have
> to just wait. And wait....


I was going to mention that, but you beat me to it.

AFAIK, you can trust the busy bit for non-init parts, but during the init
sequence you simply have to do the waits.

What I usually do, is scan the data sheet for whatever I'm going to be
talking to, and look at the minimum time intervals that aren't in the
instruction cycle range.  microsecond level things I handle with push-pop
pairs. Most time spent for minimum codespace on that scale.   Then I work up
say a 100uS delay if that's the lowest significant delay, carefully trimming
so that it's greater than 100 but not by much.  Then I'd generate a millisec
by calling HMS_Delay 10 times, and so on.  That way all your "not less than
X" delays actually ARE.

Depending on the device and data sheet, undocumented requirements for delays
can be very frustrating.  I think the worst that I've run across was a color
LCD that had THREE undocumented delays in it's init sequence.  It's not a
bad idea to seed in significant delays (Call Ten_MS) inbetween significant
functions, as you can always pull them out after you get "first light" with
the particular device.

The only place that will get you into trouble, is if there is a "not more
than X" sort of timing requirement, but those are usually rare and well
documented.

I've also found this sort of thing in serial comms, typically with devices
that use an 8051.
It's not uncommon for them to talk at 9600, but be unable to deal with full
flow at that rate.
Usually inserting a mS delay between chars will fix it.


[Non-text portions of this message have been removed]

On Fri, Feb 16, 2007 at 04:10:02PM -0000, Tim Mitchell wrote:
> David Kelly wrote:
> > 
> > Most don't do it but I have always advocated polling the busy bit on
> > the LCD controller rather than use timing loops. 
> 
> According to my LCD code (which does work, but I wrote it a while ago)
> you can't use the busy bit while initialising the controller - you
> have to just wait. And wait....

Was looking this morning at the code I wrote in 1990 and haven't revised
since. In a loop I wrote 0x38 to my 8 bit port, toggled E, waited 15ms,
repeated 2 more times. Concern was if I caught the controller in 4 bit
hi or 4 bit low states that my desire to run in 8 bit mode would get
thru.

Later commands polled the controller for busy.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.