AVR-Chat

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