Using Newhaven OLED 4x20 display
Don M
Posts: 1,652
I've been using these displays in several products of mine and have always had an issue of when re-flashing the prop the display will most of the time lock up or display gibberish. I'm using the 4 bit mode. If I power down then back up after reprogramming it always comes on correctly.
I've been in contact with Newhaven over this and the last thing she had me try is to duplicate the initialization of the display. There is no reset line to the display unfortunately nor a reset command. It was better but still not 100%. So my latest "fix" was to add a PNP transistor to control the Vcc to the display. I just toggle the power off/on for 500 mSec at the beginning of display initialization. Works every time.
Has anyone else run into this? Or maybe you have other suggestions?
Here's my initialization code:
pub initx(epin, rwpin, rspin, db4pin, cols, lines, pwr) | okay
'' Initializes OLED driver in 4-bit mode
'' -- allows non-contigous pin group
'' -- no pin error trapping; use with caution
'' added PWR pin to toggle power on reset
dira[PWR] := 1 ' Make output
outa[PWR] := 1 ' Turn OFF
pause(500)
outa[PWR] := 0 ' Turn ON
Finalize ' clear existing pins
e := epin ' oled.6
rw := rwpin ' oled.5
rs := rspin ' oled.4
db4 := db4pin ' oled.11
db7 := db4pin + 3 ' oled.14 Note: was + 7 changed 7/30/2013
if lookdown(cols : 8, 16, 20, 24, 32, 40) ' validate and set columns
lcdx := cols
else
lcdx := 16
if lookdown(lines : 1, 2, 4) ' validate and set rows
lcdy := lines
else
lcdy := 2
' Initialize_1 ' Added 2nd initialization for warm reboots or reset. Otherwise display locks up
' Unreliable
Initialize_2
okay := inuse := true
return okay
pub Initialize_1 ' Modified 4/20/2021
outa[e] := 0 ' Clear pins make low
outa[rw] := 0
outa[rs] := 0
outa[db7..db4] := %0000
dira[e] := 1 ' Make pins outputs
dira[rw] := 1
dira[rs] := 1
dira[db7..db4] := %1111
pause(2)
'' Function Set for 4 Bit Mode
outa[db7..db4] := $02 ' Send high nibble of 0x20 Function Set
BlipE
outa[db7..db4] := $02 ' Send high nibble of 0x20
BlipE
outa[db7..db4] := $08 ' Send high nibble of 0x08
BlipE
Wait_Busy ' Check if busy before proceeding
pub Initialize_2 ' Modified 4/20/2021
outa[e] := 0 ' Clear pins make low
outa[rw] := 0
outa[rs] := 0
outa[db7..db4] := %0000
dira[e] := 1 ' Make pins outputs
dira[rw] := 1
dira[rs] := 1
dira[db7..db4] := %1111
pause(2)
'' Function Set for 4 Bit Mode
outa[db7..db4] := $02 ' Send high nibble of 0x20 Function Set
BlipE
outa[db7..db4] := $02 ' Send high nibble of 0x20
BlipE
outa[db7..db4] := $08 ' Send high nibble of 0x08
BlipE
Wait_Busy ' Check if busy before proceeding
'' Finish initialization
Cmd($08) ' Display OFF command
Cmd($01) ' Clear display
Cmd($06) ' Set to data entry mode
Cmd($02) ' Set cursor to Home
Cmd($0C) ' Display ON command
pub Finalize
'' Makes OLED buss pins inputs
'' -- works only if OLED has been previously defined
if inuse
dira[e] := 0
dira[rw] := 0
dira[rs] := 0
dira[db7..db4] := %0000
inuse := false
Comments
That's a common difficulty with resetting these LCDs; works fine when it boots up in eight-bit mode, but fails a power-on reset when it is already in four-bit mode.
I can locate the exact source at the moment, but one of the Newhaven datasheets gave this as an initialization:
Alternately, if you have the R/W pin connected, you can check the busy flag. The busy flag will be high if in eight-bit mode following a command, but will remain low if in 4-bit mode, waiting for another 4-bits before executing the command.
Hope that helps.
Yep ... I've also seen that issue in the past with other drivers and other display brands.
Never had problems with my own driver. It is seems to do the initialization correctly and it also cares about the busy flag, still it is fast enough to update the custom characters on the fly to create a small graphical output on a text display
using different custom characters in different rows.
https://github.com/parallaxinc/propeller/tree/master/libraries/community/p1/All/HD44780 PASM driver
PS: also found the old thread: https://forums.parallax.com/discussion/117059/another-lcd-driver-hd44780
My resolution to this problem ended up using a small mosfet controlling the power to the display. I use a prop pin to toggle the power whenever there is a power on reset or reboot. Works flawlessly now.
@"Don M" ,
Is this one of the DZW-Ax5 series, or something different? Just curious, because I have an I2C-based driver for the 2x16 and 4x20 of the CW-Ax3 series (US2066 controller) that do have a discrete reset pin, and I haven't come across this behavior before. Looking at the datasheet for the DZW's - they seem to be quite a bit different, but don't mention which controller is used ('proprietary'??).
Don, when using parallel LCD modules back in the late 80s / early 90s I ran into similar problems on other platforms. It is because when you reset your MCU the I/O pins can go go back to inputs, then outputs again, causing the LCD to get erroneous data. My solution was to use the programmable reset sequence that Hitachi shows in the datasheet. I don't know if it would work in your case. I was using actual Hitachi chipset with 8-bit interface. The reset was done immediately after the I/O pins were initialized.
Yes it this series of OLED 4x20 displays. NHD-0420DZW-AX5 with the proprietary controller. Other than having to add a couple parts to the BOM it really is a bullet proof fix. Believe me if I could do a software fix I'd use that. I've tried a multitude of changes and they may work a few times but then bug out.
I was also looking at using the NHD-0420CW-AX3 series but then I'd have to write a new driver for that controller however I do like the slimmer size. And it does have a dedicated reset pin.
They use a proprietary controller which doesn't seem to fit with other industry standard controllers. But I'll take a look. Thanks Chris.
Yeah, it still may be sensitive to the changing of states of the I/O pins, so might be something to look at.