5v display with the Propeller?
Mercury1964
Posts: 15
I've scavenged a display from an Alphasmart 3000 for use in a project of mine. It's almost perfect - crisp, big, and with a nice DIP header at one end for easy prototyping. However, it runs at 5v. Looking at this forum post, all the control lines from the Propeller to the display seem to be unidirectional, with the display not sending anything to the Propeller. Does this mean that the Propeller won't be damaged by the higher voltage running the display? Does this display work on 3.3v logic levels?
Thanks,
John
Thanks,
John
Comments
Practically all the controllers that are used in character LCDs are TTL compatible, meaning that they accept any voltage above 2V as a high level. So that's not a problem with the Prop talking to the LCD then but what you have got to watch is the tendency for many to connect the LCD (and mandate the connection) in bidirectional fashion in the belief that this is required, it is not. Avoid any 5V to 3.3V problems by grounding the R/W line of the LCD and simply observe the minimum timing required during initialization and when a "clear display" command is issued. All other timings are too short and Spin has no hope of ever being too fast for it Note too that during an initialization that even when the R/W line is used in some designs that the busy bit is not read anyway as the init routine relies on delays only. I normally use all 8 data lines for reliability but many designs will favor the 4-bit data approach so that's up to you but normally my 8-bit data port is multi-purposed anyway as the LCD data usage is very short and very infrequent so my lines normally double as inputs or LED indicator etc.
Simplest solution would be to put 3.3K series resistors in all the leads from the Propeller to the display. This won't work if there are pullup or pulldown resistors on the display lines. Usually the Propeller's output voltage is adequate for a 5V logic input.
Actually the simplest solution is to tie this R/W signal low so that it never reads. The only information that is ever read normally in the original 80's address/data bus +wait-state implementation is the busy bit which has become redundant due to systems using parallel I/O rather than data bus access and the slow nature of Spin or even just the extremely low update rate of a character LCD. As mentioned too, any "busy" periods are well defined in the controller datasheet and really only affect initialization and the "clear screen" command (some cloned and abridged datasheets incorrectly state it's the home command that needs a delay but the controller takes time to clear RAM, not point back home). Both "busy" conditions are easily catered for in software without any side effects, without the complication of 5V translation, and also it saves one I/O line too. If only people were as logical as the logic chips they use.
EDIT: Just to back-up what I am saying I grabbed a bit of Spin code from the obex and timed it:
con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 clockfreq = ((_CLKMODE - XTAL1) >> 6) * _XINFREQ dbus = 0 RW = 4 RS = 5 E = 6 tp = 7 { This is a simple LCD test which always returns a not busy on the first read and shows how slow Spin is and why it is unnecessary to read the busy bit. Far easier just to tie the RW low, save an I/O and just use the delay figures for init and the clear sceeen command (if it's used). Testing this out I observe this timing: In a continual repeat loop the tp (test point) cycle time = 215us It takes >75us from text(n) to the first data nibble and E rising high and it takes 190us to the start of the second nibble Absolute slowest time the LCD takes for any instruction besides init and clear screen is 37us Commenting out the check_busy_flag results in a cycle time of 107us, still 70us slower than the slowest time for a normal command/data instruction. } pub start outa[E]~ dira[7..0]~~ repeat ' 215us cycle time text($55) !outa[tp] PRI text(data) check_busy_flag outa[RS]~~ send_nibbles(data) PRI send_nibbles(data) outa[3..0] := data >> 4 clock outa[3..0] := data clock PRI check_busy_flag | busy busy := 1 dira[3..0]~ outa[RS]~ outa[RW]~~ repeat while busy outa[E]~~ ' timing: 12us pulse here busy := 0 ' return immediate not busy signal outa[E]~~ clock dira[3..0]~~ outa[RW]~ PRI clock ' fastest pulse in Spin is 8us long outa[E]~~ outa[E]~