Date: 19960919
From: Werner Backes
To: Multiple recipients of list <mc68hc11@bobcat.etsu.edu>
Subject: Re: LCD
On 19960916 you wrote:
>I am using the hc11 to control a 2 line 16 character LCD and was
>wondering if anyone knows how to program it to display your own character set
>ie. I want to make my own characters)
See www.repairfaq.org/ELE/HTML/LINK/F_LCD_HD44780.html
There's a chapter about custom characters.
Greetings
Werner
Date: 19960924
From: HC11 Craig Keithley <keithley@openfirmware.lansys.apple.com>
To: Multiple recipients of list <mc68hc11@bobcat.etsu.edu>
Subject: Re: LCD (brings back memories)
Jaap wrote:
>Correct!
>
>And then for the 4 bits interface. (Why waste 4 I/O ports?):
>
Wow, all this _really_ brings back the memories. Back about 6 years ago
I was one of the firmware engineers for Apple's _first_ handheld
computer. It used an HC11 and a 44780 4 line x 16 character display. It
had really tiny ROM cartridges about the size of matchboxes, 2 ADB ports,
3 serial ports, a SCSI port and a sound input port. I wrote the entire
"kernel" or "BIOS" for the thing, which had a variety of drivers for the
serial ports, display, etc.
Getting the hardware engineer to accept that he didn't need to use all 8
bits was a little bit of a chore, but it allowed him to add a couple more
features using the other 4 bits.
The keyboard was scanned during interrupt time... The only downside was
that I couldn't get him to also run the row lines to an OR* gate so that
keypresses could generate interrupts. Which would have allowed me to put
the HC11 into a wait state (and saved the battery). So even during times
when it wasn't doing anything, it consumed power.
The handheld computer was named TechStep, and it was used only for
dealers and other tech support folks to diagnose sick computers. Mac*'s
back then (pre-Openfirmware) had a serial debugger that allowed for ROM
boot tests to be invoked, or for test code to be downloaded and run.
The build environment was a bit strange for it's day; we had HC11
assembly, 68k C, and 68k assembly all combined together into a single
.S19 file, with the some of the 68k Object symbols available to the HC11
code (so that the HC11 could locate & download test code).
Fun stuff...
Craig
--
Craig Keithley
Cross Platform Software Engineer
Apple Computer, Inc.
keithley@apple.com
From: Jaap van Ganswijk <ganswijk@xs4all.nl>
To: mc68hc11@bobcat.etsu.edu
Subject: Re: LCD
On 19960923 Svenn Are Bjerkem wrote:
>On 19960922 Grant Beattie wrote:
>gt;On 19960922 Jaap van Ganswijk wrote:
>gt;gt;Don't forget to tell him about the strange initialization sequences... ;-)
>gt;What strange init sequences?
>
>Ok, here comes an authorative answer to wipe out every possible
>misunderstanding. The following is taken from the Hitachi databook
>concerning the 44780 Display controller:
>
>4 Initialization.
>4.1 Initiallization by internal reset circuit.
>
>[...]
>
>[Cite starts]
>4.2 Initialization by instruction
>- power on.
>- wait more than 15ms.
>- send 000011**** (RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 respectively)
>- wait more than 4.1 ms
>- send 000011****
>- wait more than 100us
>- send 000011****
>[cite end]
>
>Before you have sent the last instruction you CAN'T check the BF if you
>have to use the initialization by instruction. If you can check the BF
>then you don't need to use this way of initialization. Use 4.1.
>
>Jaap and GB is talking of the last and the first way of initialization,
>respectively. Neither is more wrong than the other. Everything depends on
>how fast your Vcc* settles.
>
>Hope this clears up.
Correct!
And then for the 4 bits interface. (Why waste 4 I/O ports?):
send 000010 - Function Set (4 bits, still 8 bits instruction!)
send 000010 - Function Set (again, but now for real)
send 001xxx
send 000000 - Display OFF
send 001000
send 000000 - Display clear
send 000001
send 00000? - Entry Mode Set
send 0001is
For an 8-bit interface it's the same, but without the first
instruction and with the commands as 8-bits commands.
By the way, you can also leave out the busy flag line,
but then you will have to time all commands yourself.
Date: 19960922
From: Grant Beattie <grantb@nait.ab.ca>
To: HC11 Jaap van Ganswijk <ganswijk@xs4all.nl>
Subject: Re: LCD
On 19960922 Jaap van Ganswijk wrote:
>Don't forget to tell him about the strange initialization sequences... ;-)
What strange init sequences? I've used every brand going (OK, they all
have had the same controller), and the sequence has been the same...
wait for the BUSY flag to go away, then FUNCTION SET, and the other
options you want, waiting for the BUSY flag before accessing the LCD (each
time). I've never had to do that FUNCTION SET, FUNCTION SET, FUNCTION
SET, stuff mentioned in the manual...
GB
Date: 19960922
From: HC11 Grant Beattie <grantb@nait.ab.ca>
To: Multiple recipients of list <mc68hc11@bobcat.etsu.edu>
Subject: Re: LCD
On 19960922 Jaap van Ganswijk wrote:
>Don't forget to tell him about the strange initialization sequences... ;-)
What strange init sequences? I've used every brand going (OK, they all
have had the same controller), and the sequence has been the same...
wait for the BUSY flag to go away, then FUNCTION SET, and the other
options you want, waiting for the BUSY flag before accessing the LCD (each
time). I've never had to do that FUNCTION SET, FUNCTION SET, FUNCTION
SET, stuff mentioned in the manual...
GB
Date: 19960923
From: Werner Backes
To: Multiple recipients of list <mc68hc11@bobcat.etsu.edu>
Subject: Re: LCD
On 19960921 you wrote:
>I'm not sure this is technically true. Perhaps what you are seeing is
>some kind of LCD or eyeball persistence.
Hm... I don't think that this is true. This could only be achieved by
synchronizing the HC11 code with the internal LCD timings and I can't
see how this could be done. Every "free running" code would produce
only rubbish on the display (IMHO).
> If you display a user-def
>character and then modify it slowly (over a second or so), you can see
>the changes taking place to the visible char. I've noticed this with all
>44780 controllers.
I tried this yesterday. It works exactly the way GB describes. To get the
results Flavio told us (modifing a character without changing the display)
would only work, if there a kind of buffer between the display and the
character ROM/RAM. Graphic LCD of course have such a buffer and characters
are copied from the character ROM/RAM to the graphic buffer. So it would
be possible to change the character RAM without influencing the display.
(this is how I understand this things, but I must say that I never used
a graphic LCD :)
Maybe Flavio used some kind of graphic LCD ? or something different than
an ordinary 44780 ? I really can't imagine how his trick should work on
a plain 44780. I would really like to know HOW he did it. Having more than
8 user characters would be a nice feature.
Werner
Date: 19960923
From: HC11 Svenn Are Bjerkem <svenn@invalid.ed.unit.no>
To: Multiple recipients of list <mc68hc11@bobcat.etsu.edu>
Subject: Re: LCD
On 19960922 Grant Beattie wrote:
>On 19960922 Jaap van Ganswijk wrote:
>>Don't forget to tell him about the strange initialization sequences... ;-)
>
>What strange init sequences? I've used every brand going (OK, they all
>have had the same controller), and the sequence has been the same...
>
>wait for the BUSY flag to go away, then FUNCTION SET, and the other
>options you want, waiting for the BUSY flag before accessing the LCD (each
>time). I've never had to do that FUNCTION SET, FUNCTION SET, FUNCTION
>SET, stuff mentioned in the manual...
>
>GB
Ok, here comes an authorative answer to wipe out every possible
misunderstanding. The following is taken from the Hitachi databook
concerning the 44780 Display controller:
4 Initialization.
4.1 Initiallization by internal reset circuit.
The HD44780 automatically initializes (resets) when power is turned on
using the internal reset circuit. The following instructions are executed
in initialization. The busy flag (BF) is kept in busy state until
initialization ends. (BF=1) The busy state is 10 ms after Vcc* rises to
4.5 V.
(1) Display clear
(2) Function set
(3) Display ON/OFF
(4) Entry mode set
(5) Write DDRAM (Go ahead and fill her up. (SAB))
[Cite ends]
If the Vcc* rises too quick to 4.5 V (t < 0.1 ms) or too slow (t > 10ms)
the internal reset will NOT* operate normally. If you reset the display by
controlled removing of the Vcc* and the power OFF period is less than 1ms
(Vcc* must be less than 0.2 V) the reset will also NOT* work properly. In
this case the initialization by instruction must be conducted.
[Cite starts]
4.2 Initialization by instruction
- power on.
- wait more than 15ms.
- send 000011**** (RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 respectively)
- wait more than 4.1 ms
- send 000011****
- wait more than 100us
- send 000011****
[cite end]
Before you have sent the last instruction you CAN'T check the BF if you
have to use the initialization by instruction. If you can check the BF
then you don't need to use this way of initialization. Use 4.1.
Jaap and GB is talking of the last and the first way of initialization,
respectively. Neither is more wrong than the other. Everything depends on
how fast your Vcc* settles.
Hope this clears up.
____
/ oo \ Svenn Are Bjerkem
| .. | svenn@invalid.ed.unit.no
\\__// invalid.ed.unit.no/~svenn
__ |__
Date: 19960923
From: HC11 Neal Sedell <neals@pacifier.com>
To: Multiple recipients of list <mc68hc11@bobcat.etsu.edu>
Subject: Re: LCD
>Svenn wrote:
>...
>If the Vcc* rises too quick to 4.5 V (t < 0.1 ms) or too slow (t > 10ms)
>the internal reset will NOT* operate normally. If you reset the display by
>controlled removing of the Vcc* and the power OFF period is less than 1ms
>(Vcc* must be less than 0.2 V) the reset will also NOT* work properly. In
--^^^^^^^^^^^^^^^^^^^^^^^^^^^
>this case the initialization by instruction must be conducted.
I ran into just this situation several years ago. Big switcher for +5V
supply (80A) loaded with only 6 or 8 Amp* load. LCD always came up OK
from cold start, but turning power off and then back on without waiting
for a minute or two was very unreliable. Finally discovered that the
LCD was operating in 4-bit mode when it wasn't working right, and came
up with a sequence of commands that would switch it to 8-bit mode no
matter which way it came up.
If only the LCDs came with a reset pin....
(N)
