Winstar OLED display and custom characters

[lukecyca]

I've been using this library with a Newhaven NHD-0216K1Z LCD and it has worked great. However when I switched to a Winstar WEH001602 OLED display I have problems, particularly with printing custom characters. I'm suspecting a timing issue.

I can consistently get through most of the esp32-i2c-lcd1602-example right up to printing the special characters.

If I have it print one character at a time, I notice that:

• Print first character, and it displays
• Print second character, and nothing happens
• Print third character, and the second character displays (but is corrupt).

This suggests that the alternating high-nibble/low-nibble is getting out of sync. This is further corroborated when you see that ϰ 0@P` are in the top row of the character map and are exactly what you'd get if the nibbles were out of sync.

I've scoped out the signals and they look good, however the call to smbus_send_byte is taking about 350µs, which dwarfs the explicit calls to ets_delay_us in _strobe_enable. Not sure if being too slow is an issue.

I'm going to keep working on this. Just wanted to log what I've discovered so far.

[lukecyca]

It seems these OLED displays have a few additional requirements which I implemented and found that the OLED comes back to a known state when the library is initialized (previously I had to power cycle).

That doesn't solve the dropped nibble problem above though. I notice that in Adafruit's library they actually wait for the display's ack signal in waitForReady(). Perhaps that's what we need to do here.

[DavidAntliff]

@lukecyca thanks for documenting your findings. Unfortunately you're on your own a bit with this one as I don't have one of these OLED displays handy. If you get it working, I'd consider a PR. It's worth considering how this driver might best accommodate device-specific variations, since I didn't really plan for any, and I don't like #ifdefs much - anyway, I'd be interested in seeing the "diff" once you get it all going :)

[lukecyca]

I have not solved this in a way that's elegant enough for a pull request, but I now have a hacked-up fork that works for me over here with a couple diversions:

1. Changed the pin assignment on the PCF8574A because I apparently chose differently than most of the "backpacks" use. This has nothing to do with this issue.

2. Changed the init sequence to be more like Adafruit's character OLED library.

With these two changes, I'm successfully using this library with a Vishay Dale O016N002ABPP5N0000. I suspect that it would also work perfectly with a Winstar (since that's what Adafruit sells) but I broke mine. :(

[DavidAntliff]

I've read through the changes on your fork - do you know if there's any particular change in https://github.com/lukecyca/esp32-i2c-lcd1602/commit/61f8ed47ba85fdc28182b356c271dfebbe755950 that solves the problem for you, or do you need all of these changes together?

I wonder if it's possible to use the existing init code, followed by your changes, and see a successful result?

Or maybe I just change the init sequence to match yours - maybe it's more compatible. I just didn't want to copy another library blindly, so I wrote mine based on the datasheet for a chip I assumed was on my device - hard to tell what's really there unfortunately.

[DavidAntliff]

I'm curious about that 0x8 write in the Adafruit library, for "newer devices" - is this perhaps what you needed in your case? What does that command do?

[lukecyca]

I wonder if it's possible to use the existing init code, followed by your changes, and see a successful result?

It likely is possible to reconcile the two, yes. I have not done the necessary trial-and-error to do that though.

I'm curious about that 0x8 write in the Adafruit library, for "newer devices"

This is a pretty insightful comment that tries to explain why instead of cargo culting: https://www.raspberrypi.org/forums/viewtopic.php?p=514131#p513610

[DavidAntliff]

That link is useful - thanks.

I'm glad you got things working for your device. I'll keep this issue open for the time being and look at it more closely as time permits. In particular, I'll test your changes on my two LCD devices. I don't have an OLED device like this, and yours sounds like it's out of action, so it may be difficult to test!

Just to clarify, does your Vishay device work with my library, or do you need your fork? Is this the same as your "NewHaven" device in your first post? You originally reported this issue for your Winstar but then said that it's now broken, so I'm just trying to understand whether you also saw this issue with other LCD devices.

Are those Winstar devices available on AliExpress? I'd consider getting one for testing if it's not too expensive.

Lastly, do you still think a waitForReady-like call is required, as you suggested earlier?