| Author |
Message |
|
|
 Posted: Dec 29, 2008 - 04:50 AM |
|
Joined: Feb 23, 2008
Posts: 162
Location: Bangkok
|
|
Oh... I figured out the pins of the display!, but it displays a full line of block characters on the first line. Two blinks on start up and then the first line just stays full on.
Any idea what is that all about? |
|
|
| |
|
|
|
|
|
|
Posted: Dec 29, 2008 - 07:44 AM |
|
Joined: Feb 23, 2008
Posts: 162
Location: Bangkok
|
|
So I reckon this first line filled with black blocks means that there was an intialization error, right?
I put a delay before the initialization, in case the power wasn't kicking in fast enough. Still doesn't work.
I doubled the delays on the different functions in case they where too short. Nope
I changed the MCU frequency to 4MHz and still doesn't work.
I'm sure the wiring is right now, so I'm clueless about why it doesn't work.
Perhaps I should try with an external, crystal oscillator instead of the internal one? |
|
|
| |
|
|
|
|
|
|
Posted: Oct 01, 2011 - 12:11 AM |
|
Joined: Jan 05, 2008
Posts: 3
Location: Italy
|
|
Superfreak code of JohanEkdahl worked like a charm !!!
thank you *very* much ...
"same" code that worked ok in assembler was driving me fool with C and i was losing my religion dealing with the hundreds of libraries available here and there but i wasn't able to get a single pixel on 
Thank you again for sharing. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 25, 2012 - 03:30 PM |
|
Joined: Sep 05, 2001
Posts: 2496
|
|
|
JohanEkdahl wrote:
1. Wait at least 15 ms
2. Send the high nibble of a Function Set instruction
3. Wait at least 4.1 ms
4. Send the high nibble of a Function Set instruction
5. Wait at least 0.1 ms (100 us)
6. Send the high nibble of a Function Set instruction
7. Send the high nibble of a Function Set instruction for 4-bit interface
It is at his point the 4-bit interface becomes interactive. From now on you send complete 8-bit instructions as twop consecutive nibbles, high nibble first.
8. Send a Function Set instruction, 4-bit interface, and N and F bits set to your liking.
9. Send a Display Off
10. Send a Display Clear instruction
11. Send a Entry Mode Set instruction
And then finally
12. Send a Display On instruction
This sequence was wrong.
Every command need at least the minimal wait time (37µs) after it, so waiting 100µs was fine.
So you must insert 100µs delay after step 6 and 7.
Nevertheless your code works, because your LcdSendNibble command contain 5ms delay, which was a big waste of CPU time.
Peter |
|
|
| |
|
|
|
|
|
|
Posted: Oct 25, 2012 - 05:06 PM |
|
Joined: Mar 27, 2002
Posts: 18531
Location: Lund, Sweden
|
|
Thank you, Peter.
Yes, I should have made it clear that apart from the (special) delays explicitly mentioned in that sequence the "standard" timing requirements from the data sheet always apply.
It is my belief that after step 6 above the display interface is in "normal operation mode" so the usual timing requirements from the data sheet apply. Could have made that clearer also.
Re the 5 ms: The purpose of my small program has never been to be a real application. (For that, one is better off using e.g. your LCD code.)
The purpose has all the time been to introduce a minimal test - e.g. to prove that the hardware wiring is correct, the contrast control is set correctly etc. For that purpose code like the one from Procyon, Fleury, or your LCD code, can actually be troublesome for an LCD noob. Being clueless they have more code than necessary to mess around with, ultimately onfusing them even more. Then they either give up or come here displaying a total mess - and we then have to start them over from square one. While the minimal test code was evolving I have some time tossed in that 5 ms delay to be well on the safe side - not pretty perhaps, but will not do any harm for the purposes the code has. If all you're doing is testing "Hello LCD!" on your 44780-based module then you're wasting a lot of CPU time any way.. 
Never advocated using my minimal test code for a real app - I try to always recommend going with something already written and proved. E.g. your code. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 25, 2012 - 08:35 PM |
|
Joined: Mar 29, 2006
Posts: 567
Location: Western New York, USA
|
|
|
Quote:
It is my belief that after step 6 above the display interface is in "normal operation mode" so the usual timing requirements from the data sheet apply. Could have made that clearer also.
It is my belief that the data sheet flowchart is ambiguous about the BF at this point. For that particular instruction the information to the right says: "BF cannot be checked before this instruction." For the next instruction the information to the right says: "BF can be checked after the following instructions". There is no information given about the use of the BF between those two instructions. As Danni says "Every command need at least the minimal wait time (37µs) after it, so waiting 100µs was fine." I too use 100us since that is what was specified for the previous instruction.
Don |
|
|
| |
|
|
|
|
|
|
Posted: Oct 25, 2012 - 08:48 PM |
|
Joined: Feb 19, 2001
Posts: 25891
Location: Wisconsin USA
|
|
| My BFF and her BF had a short delay before checking the BF, but I had no BeeF with that. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 25, 2012 - 09:34 PM |
|
Joined: Mar 27, 2002
Posts: 18531
Location: Lund, Sweden
|
|
| Yes, Don. I agree with that. So, instead of relying on the BF at that point I assume that the timings for the execution of the instruction as given in the data sheet should be used. (Going on memory here - it's been a while since I dabbled with CLCDs on this level). |
|
|
| |
|
|
|
|
|
|
Posted: Oct 26, 2012 - 12:44 AM |
|
Joined: Mar 29, 2006
Posts: 567
Location: Western New York, USA
|
|
|
Quote:
I assume that the timings for the execution of the instruction as given in the data sheet should be used.
I didn't choose that approach because even though this 'looks like' a Function set instruction it really isn't one. There's really no sense skimping on a delay that is only going to be used once.
Don |
|
|
| |
|
|
|
|
|
|
Posted: Oct 26, 2012 - 01:19 AM |
|
Joined: Sep 04, 2002
Posts: 21253
Location: Orlando Florida
|
|
| I use a 50usec delay per byte. No delay between hi nib and lo nib. |
_________________
Imagecraft compiler user
|
| |
|
|
|
|
|
|
Posted: Oct 26, 2012 - 01:31 AM |
|
Joined: Mar 29, 2006
Posts: 567
Location: Western New York, USA
|
|
|
Quote:
I use a 50usec delay per byte. No delay between hi nib and lo nib.
That's fine for most (but not all) of the instructions after you have finished the first few steps in the initialization sequence.
In this case we are talking about the reset portion of the initialization sequence. Here all of the specified delays are significantly longer than 50 uSec and the mode is always 8-bit so there are no nibbles to consider.
Don |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
