Shop OBEX P1 Docs P2 Docs Learn Events
Using Newhaven OLED 4x20 display — Parallax Forums

Using Newhaven OLED 4x20 display

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:

    PRI init
      wait(15_000)                                                                  ' > 15ms
      outa[D7..D4] := %0011                                                         ' Set 8-bit mode
      clock
      wait(4_100)                                                                   ' > 4.1ms
      outa[D7..D4] := %0011                                                         ' Set 8-bit mode
      clock
      wait(100)                                                                     ' > 100us
      outa[D7..D4] := %0011                                                         ' Set 8-bit mode
      clock
      wait(40)
      outa[D7..D4] := %0010                                                         ' Set 4-bit mode
      clock
      command(%0010_1000)                                                           ' 4-bit mode, 2-line, 5x8 pixel characters
      command(%0000_1100)                                                           ' Turn display on, no cursor, no blinking
      command(%0000_0110)                                                           ' Increment cursor, no display shift
      clear
    

    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.

  • MagIO2MagIO2 Posts: 2,243
    edited 2021-05-04 14:26

    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 :smile: 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

  • Don MDon M Posts: 1,652

    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'??).

  • SavageCircuitsSavageCircuits Posts: 264
    edited 2021-05-29 20:27

    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.

  • Don MDon M Posts: 1,652

    @avsa242 said:
    @"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'??).

    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.

  • Don MDon M Posts: 1,652

    @SavageCircuits said:
    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.

    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.

Sign In or Register to comment.