search

rm-hull / luma.oled

Python module to drive a SSD1306 / SSD1309 / SSD1322 / SSD1325 / SSD1327 / SSD1331 / SSD1351 / SH1106 OLED
https://luma-oled.readthedocs.io
MIT License
790 stars 162 forks source link

New Haven 2.7 oled with ssd1322 #353

Closed georgeharker closed 1 year ago

georgeharker commented 1 year ago

I’ve been having some issues with the same 2.7 New Haven display. Initially the modified _NHs class seemed to work. But grey ramps were messed up and anitalised text looked seriously wonky. I see that those classes were writing out byte values rather than nibble encoded 4bit / 16 grey levels. After some experimentation it looks very much like there’s something interesting going on here.

I /think/ every other nibble controls the alternate scan of the pixel. Very strange. Anyway if I write out data for wxh (rather than wxh/2) and duplicate every pixel into both the upper and lower nibble everything looks great - the ramps now display correctly and text renders as expected - where’s previously values like 240 (prior to send to device) would snap to an incredibly low display value which looks effectively black).

So sorry to reopen this but I think the nhd init routine / display routines are still wrong for things that aren’t pure black / white.

00F285F5-B0E5-4D09-A6EB-DA6C0E3E02B2

I will try and tidy up the copious init routine hacks and submit a PR.

George

Originally posted by @georgeharker in https://github.com/rm-hull/luma.oled/issues/199#issuecomment-1299382050

Further investigation of their example arduino code confirms they tie seg 1 and seg 2 together to form the driver for pixel one. Meaning both nibbles should be set to identical values to drive the display at one byte per pixel. See

https://support.newhavendisplay.com/hc/en-us/articles/4413877789591-NHD-2-7-12864WD-with-Arduino

Says 2 seg lines with one com is one pixel.

georgeharker commented 1 year ago

Created a PR : https://github.com/rm-hull/luma.oled/pull/354

rm-hull commented 1 year ago

I never had access to a newhaven device to test against. I believe it was introduced in #245 … @doug-burrell might be able to provide some insights/context?

doug-burrell commented 1 year ago

I never had access to a newhaven device to test against. I believe it was introduced in #245 … @doug-burrell might be able to provide some insights/context?

I'm sorry but I no longer have access to this hardware and can't remember the logic behind how it worked.

georgeharker commented 1 year ago

It is pretty unusual and makes the bitmap authoring prior to send to display a bit weird, but electrically I can see maybe why they do it - and their example code on newhaven indicates that they do indeed use two adjacent seg to drive one pixel. For black and white the approach would have worked identically - ie 0xFF or 0x00 would have resulted which would have looked ok. It's just the greyscale that would have been odd with low order bits somewhat randomizing the greyscale drive, and even then it probably looks ok in some circumstances. depending on the exact values.