| Author |
Message |
|
|
 Posted: Jul 25, 2011 - 04:38 PM |
|
Joined: Aug 06, 2008
Posts: 365
Location: Rockall
|
|
Afraid I am reading PINC, not PORTC, that was a deliberate red herring... (I've made that mistake enough times before, but not this time!)
The 8051 code may be unfamiliar but the example I linked to clearly tests the BF with enable high! At least two datasheets I have found give the impression that BF becomes valid immediately that Enable goes high.
Suffice to say I have tried putting the test before and during the strobe without getting a result.
But my instinct is that Johan is right and I should test BF after E goes low again, or at least try this one more time!
Oh and why 8 bits? Not least I have an abundance of pins to spare for this project (multi-chemistry battery charger). Glad to know 4-bits is easy as I might hang one off a M2313. |
_________________
Cheers,
Joey
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2011 - 04:48 PM |
|
Joined: Mar 27, 2002
Posts: 18505
Location: Lund, Sweden
|
|
|
Quote:
Afraid I am reading PINC, not PORTC, that was a deliberate red herring...
Are you not posting the code you actually have?
I've had a proper inspection of the Busy-flag running with success with both 4- and 8-bit interfaces and thought I might have some help to bring, but I could find few things more meaningless than looking at some code that is not used. I'm out. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2011 - 06:24 PM |
|
Joined: May 24, 2004
Posts: 5994
Location: Tampere, Finland
|
|
|
joeyAVR wrote:
Afraid I am reading PINC, not PORTC, that was a deliberate red herring... (I've made that mistake enough times before, but not this time!)
Well thanks for that. It made our LCD expert Johan leave.
joeyAVR wrote:
The 8051 code may be unfamiliar but the example I linked to clearly tests the BF with enable high! At least two datasheets I have found give the impression that BF becomes valid immediately that Enable goes high.
No. Reciting HD44780U controller chip datasheets say that data lines are valid maximum of 160ns after E is high. They may and will become valid before that, but they are guaranteed to be valid 160ns after E is high - so not exactly immediately. And the bus floats high with the weak pull-ups. An AVR running over 6.25MHz would thus read too fast if IO operations take only 1 bus cycle and it takes 2-3 bus cycles delay from the AVR input port syncronizers to pass the value on bus into the PINx register. So rising E and immediately reading DB7 would most often result in reading floating high value as the LCD has not yet driven the bus line low and that value has not passed through the input syncronizers for reading.
And it does not matter if you do the comparison with E high or low, the bus is driven by LCD when bus is high so the value on bus must either be stored somewhere for later comparison before E is lowered or compared when E is high but the actual bus cycle needs still to be completed by lowering E. But it has not occured to me before that anyone would do the comparison with E high. You can do it any way you like however. It just is not such a bus cycle a real CPU with the LCD on memory or IO mapped bus would do, but with GPIO this is possible.
joeyAVR wrote:
Suffice to say I have tried putting the test before and during the strobe without getting a result.
But my instinct is that Johan is right and I should test BF after E goes low again, or at least try this one more time!
No, do not read the data pin when E is lowered. The data bus is valid only for minimum of 5ns after E is lowered.
Put E high, delay at least 160ns while making sure E high pulse is over 500ns, read data input port into register or variable, put E low, then examine the data content in register or variable.
Of course these timings are for the HD44780 controller. Your display may have a compatible controller with better or worse timing specs, so it never hurts to be too slow. The timings you now have should work if AVR speed is very low like in the order of 1-2 MHz
Edit: You also seem to be overclocking your AVR, as Mega16 can only run at up to 16MHz. Things are not required to work at all when they are used out of the specification. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 09:39 AM |
|
Joined: Aug 06, 2008
Posts: 365
Location: Rockall
|
|
I will pm, Johan with an apology; but the code I posted wasn't what I'm using, it was something I typed in to ask 'would this work?'
Thanks for shedding the light I need on how E works.
But last night I got it to work reliably 100% of the time. But it only works reliably if you poll the BF immediately after E goes high and it is MUCH slower than having a delay in there, which suggests something very, very odd is going on.
Add a nop after E goes high, and you end up dropping a few characters. Add several nops to allow the BF line to stabilise and the result is the same as not bothering to poll the BF at all (i.e. alternate characters/commands are dropped).
Now as I've tried almost every variation on the software known to man and I have had the same issue with two chips (M16 and 4433) on two different boards with two different displays it isn't bad chip, bad board or bad display and probably not bad code. I've scoured the schematic and it isn't wrong pin allocations.
I have a theory; what would allow the LCD to work normally aside from preventing a proper read of the busy flag?
I have the board connected to the display by a bunch of yellow wires held together by heatshrink... what if I have transposed RS and RW wires, even though the board is set out right?
I'll check them very carefully tonight.
Quote:
You also seem to be overclocking your AVR, as Mega16 can only run at up to 16MHz.
Live dangerously  I don't think 10% over spec is pushing the envelope too much! |
_________________
Cheers,
Joey
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 09:59 AM |
|
Joined: Feb 12, 2005
Posts: 16254
Location: Wormshill, England
|
|
You can only read the LCD while EN is high. After all, at any other time the LCD o/p is disabled.
With ASM and 18MHz, any loops are pretty efficient. With an 1MHz AVR and C compiler, polling the BUSY flag takes a lot of cycles. You begin to wonder 'why not just use a timed delay?'
Think about it. Most LCD writes are strings. So you will sit waiting for the LCD to get through the whole string.
If you want efficiency, use buffered writes through an RTOS or timer IRQ.
No. I would not worry about a mega16 at 18MHz. The chip will get sufficient air-cooling in Rockall.
David. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 11:19 AM |
|
Joined: Aug 06, 2008
Posts: 365
Location: Rockall
|
|
|
Quote:
If you want efficiency, use buffered writes through an RTOS or timer IRQ.
Fair point, though this is a nice relaxed application - a battery charger, where the only critical issues are keeping the PWM rate high and not taking too long to limit a high current, neither involving the display. What matters to me is nice prompt display changes in response to button presses  |
_________________
Cheers,
Joey
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 11:46 AM |
|
Joined: Mar 27, 2002
Posts: 18505
Location: Lund, Sweden
|
|
Apology accepted 
Joey, have you read the data sheet? Particularly the timing diagrams and textual information near them.
If you draw a simplified version, removing all those itty-bitty rise- and fall-times, and put the actual timings from the table (in the data sheet near to the diagram) into your simplified drawing, you will end up with something like this (I don't have my simplified diagram handy, so here goes in text form):
1. RS should be set at least 40 ns before E goes high.
2. R/W should be set at least 40 ns before E goes high.
3. There is valid data on the DB7..0 (or DB7..4) lines after a maximum of 120 ns
4. E must be high for at least 230 ns
5. RS and R/W must remain stable while E is high and for at least 10 ns after it goes low.
6. Data on DB7..0 (or DB7..4) is valid for at most 5 ns after E goes low.
Notice that the last item in this list is very consistent with the observation you made.
[EDIT: Corrected us -> ns] |
Last edited by JohanEkdahl on Jul 26, 2011 - 12:05 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 11:54 AM |
|
Joined: May 24, 2004
Posts: 5994
Location: Tampere, Finland
|
|
Johan's sequence is what the datasheet says - except for the minor point of mixing nanoseconds and microseconds.
Some of those timings are few tens of nanoseconds faster than I remember seeing in most LCDs I have used, so it of course depends on the actual controller on LCD. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 12:05 PM |
|
Joined: Mar 27, 2002
Posts: 18505
Location: Lund, Sweden
|
|
| Thanks for the heads-up, Jepael! Corrected. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 12:37 PM |
|
Joined: Mar 27, 2002
Posts: 18505
Location: Lund, Sweden
|
|
|
|
|
|
|
|
Posted: Jul 26, 2011 - 12:58 PM |
|
Joined: May 24, 2004
Posts: 5994
Location: Tampere, Finland
|
|
| Johan, great pictures and the timings are like in my HD44780U datasheet, except the data bus stable during read is 160ns in my datasheet instead of 120ns. Is that a typo or do you have a different datasheet? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 02:01 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
Jepael wrote:
Johan, great pictures and the timings are like in my HD44780U datasheet, except the data bus stable during read is 160ns in my datasheet instead of 120ns. Is that a typo or do you have a different datasheet?
There are quite a couple of these chips around, from different manufacturers, and they have a slightly different timing. For example, Samsung KS0066 says 120ns, Sitronix ST7066 features 100ns (this all is at 5V nominal; the 3V nominal values range from 300ns to 360ns).
Now the trouble is, that one never knows what's under the epoxy blob, so IMHO the worst case should be catered for, which from my collection of datasheets appears to be the 160ns of the HD44780U.
JW |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2011 - 03:20 PM |
|
Joined: Mar 27, 2002
Posts: 18505
Location: Lund, Sweden
|
|
| I will continue discussion re my diagrams in the Tutorials thread where I attached them (but, yes, that is a typo). |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
