Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
fixed initialization sequence #5
Hi Adafruit! Please see this thread with all of the people having issues making the Winstar 16x2 OLED Character display work correctly. Everyone was getting an "ax ax" on their screens. Turns out there was just a little issue with the initialization sequence. Please see the full explanation of these changes here http://forums.adafruit.com/viewtopic.php?f=22&t=42179&p=218812#p218812
Now perhaps this will be fine going forward, but I have no way to test this with older displays that presumably worked with this library. Hopefully it is backwards compatible.
Hi @adafruit-support ! Interested to read you mention "old displays". We might be able to help each other here. Are you aware of this library? https://github.com/lukecyca/WinstarOLED. He's using a 2N700 to physically cycle the power to the OLED. Works 100% for me to init into a Winstar 100x32 Graphic OLED text mode (based on the same WS0010 controller).
However, I've been having an extremely long (months) difficult and expensive time trying to get these working in grpahic mode and have been watching this thread. Text, fine. Graphics CS1, fine. As soon as second half (CS2 - rows 16-32) kicks in, the display is corrupt. Winstar support are, well, non-existent. No example code exists, all they say is "customer must choose correct sequence from datasheet". When I point out that I am, there's no response. But they've quietly release a "rev b" version, which appears to be identical in spec.
So many people have looked at this display and failed to make it work in graphic mode that we're beginning to wonder if the Rev A version has a fault that Winstar are not acknowledging. BTW, you don't sell these graphic ones, so it's not your fault, but any info would be gratefully received!
@lardconcepts I was aware of that library before making this fix, but unfortunately you have to break the ground connection on the OLED display, not Vcc.. or you might be able to just power the display from a digital output. I don't believe there are any open collector/drain outputs on the arduino. Breaking power is kind of a hacky fix in my opinion.
The code I added could be an optional compiler define and you could use it going forward... but then if you #define OLDER_OLED in your sketch it puts it back to the old way in case you ran into problems.
Not sure how many old displays are out there vs. newer ones... or if you can even get the older type from Winstar anymore. Depending on which one is the majority, will probably steer you in supporting old or supporting new by default.
We are weighing the various options for supporting both versions. Unfortunately, other than the QC date code, the markings on the old and new displays are identical. Both are labeled "REV.G".
My 'new-stock' display has a QC date of 4/18/13. We first started hearing about these problems in late July. QC date will probably be the best metric for deciding which version to try first.
Hello @technobly. Thanks for your work on this. I tried your code to "warm boot" my WS0010 based Winstar OLED which is a WEG010032ALPP5N0000 100x32 character/graphic display with 2 chips.
When initialising into text mode with your code after a "warm start", I don't get the "ax ax", but I do still get display corruption, but of the form of shifted text, or random placement. Which is a start, I suppose! :)
You also wrote: "unfortunately you have to break the ground connection on the OLED display, not Vcc" - is there any particular reason for this, do you know?
It's a shame Winstar are completely unresponsive to questions about this display. I'm thinking it might be a known problem they're trying to pretend isn't a problem.
I've got two displays here - happy to hook them up and try anything if anyone wants to fire ideas my way!
Hi @adafruit-support Yes, dates are all: 10/11/12-073030 and on the PCB is: EGO10032A/B REV.0(G)
Here's an image of my display: http://i.minus.com/ihDIvYpSL3Z1u.JPG
in fact, despite ordering all 3 over a period of a year, they codes are all the same. Please note that as I'm in the UK, these weren't ordered from you (you don't stock this one anyway) but if we can help each other, I'm willing to try! I've tried about 5 different alternative init sequences from various libraries, all with a varying degree of lack of success.
The "power breaking" option I linked to before does work, but as technobly notes, it's certainly not ideal. And still doesn't resolve me "can't get both halves working together properly" problem.
Have you, at Adafruit, had or tried any of the 100x32 "two half" displays?
@lardconcepts the reason you must break the GND connection, is because when you break the VCC connection the display is still getting power through a sneak path from either RS, EN, or some combination of the data lines. Breaking GND seems to effectively sever the current path.
If you powered the display from one of the digital outputs, you could write a function that set all of the OLED pins low for a period of time (50ms maybe), effectively hard resetting it.
I saw the shifted text as well when I used the standard LiquidDisplay library with the blue 16x2 Character OLED display from Adafruit. Likely due to various initialization issues.
In the Adafruit library, begin() is called at the end of init(), so technically you don't need to call begin() which is effectively warm rebooting the display and exposes these issues with the initialization routine. For your specific display which is not a 16x2, try commenting out this line in the library https://github.com/ladyada/Adafruit_CharacterOLED/blob/master/Adafruit_CharacterOLED.cpp#L58 and leaving the
This should effective power up your display and initialize it once. It may work for you since you said power cycling works. Obviously if you press the reset button you are not resetting the lcd, but just the code. Maybe having the code only try to initialize as whatever your display actually is just once will fix your issue.
You could alternatively try to change the code at the end of the init() routine in the library to
added a commit
this pull request
Dec 30, 2013
I added a backwards compatibility option for older displays and updated the example with clear instructions if problems occur:
// initialize the library with the OLED hardware // version OLED_Vx and numbers of the interface pins. // OLED_V1 = older, OLED_V2 = newer. If 2 doesn't work try 1 ;) Adafruit_CharacterOLED lcd(OLED_V2, 6, 7, 8, 9, 10, 11, 12);
Defaults to the newer OLED version to support present/future Adafruit sales, and Sparkfun's 16x2 OLED display who are referencing this pull request currently.
All versions tested, and error cases such as forcing a non-supported version or not including a version at all.