Skip to content

Make displayio more flexible to support more controllers (like the one in Waveshare 1.54inch e-Paper V2) #7560

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dquadros opened this issue Feb 9, 2023 · 3 comments · Fixed by #7891
Assignees
Milestone

Comments

@dquadros
Copy link

dquadros commented Feb 9, 2023

At the moment displayio makes many assumptions on the format of the display controller commands, limiting the controllers it can support.

In my particular case I tried to create a driver for the Waveshare 1.54inch e-Paper V2 display (datasheet). While the display has a 200x200 pixels resolution, the row addressing commands (0x45 and 0x4F) use a two byte, LSB first, parameter for the row. Function displayio_display_core_set_region_to_update() (at displayio_core.c) assumes a one byte parameter for self->ram_height less than 256 and a two byte (MSB first) parameter for self->ram_height greater than 255.

To support this controller there is a need of a more flexible way to specify the format of row addressing commands (or a way to override this in the python code, which would probably have performance issues).

@tannewt
Copy link
Member

tannewt commented Feb 9, 2023

It looks like this display is using an SSD1681: https://www.good-display.com/product/208.html

We have a CircuitPython driver for it here: https://github.com/adafruit/Adafruit_CircuitPython_SSD1681/blob/main/adafruit_ssd1681.py

The main trick is that you can set ram width >256 but then say this display is only 200 wide. That'll use the two byte form but only compute 200 pixels wide.

@dquadros
Copy link
Author

dquadros commented Feb 9, 2023

It looks like this display is using an SSD1681: https://www.good-display.com/product/208.html

We have a CircuitPython driver for it here: https://github.com/adafruit/Adafruit_CircuitPython_SSD1681/blob/main/adafruit_ssd1681.py

The main trick is that you can set ram width >256 but then say this display is only 200 wide. That'll use the two byte form but only compute 200 pixels wide.

I actually tried that before opening this issue... It does not work because the byte order for the row is different. In display_core.c we have:

if (self->ram_height < 0x100) { data[data_length++] = y1; data[data_length++] = y2; } else { data[data_length++] = y1 >> 8; data[data_length++] = y1 & 0xff; data[data_length++] = y2 >> 8; data[data_length++] = y2 & 0xff; }

The display datasheet (and the manufacture's example code) shows:

image

Anyway, thanks for the fast reply!

@tannewt tannewt reopened this Feb 9, 2023
@tannewt
Copy link
Member

tannewt commented Feb 9, 2023

Ah ok. @makermelissa wrote that driver and can let us know why it is that way. We could add a flag for byte order if needed.

@dhalbert dhalbert added this to the 8.x.x milestone Feb 17, 2023
@dhalbert dhalbert assigned dhalbert and tannewt and unassigned dhalbert Apr 14, 2023
dhalbert pushed a commit that referenced this issue Apr 26, 2023
Add address_little_endian for epaper displays with little endian
(low byte first) addresses.

Also clears allocated display and display bus memory so it has a
known state. The acep member wasn't always set so it varied
accidentally.

Fixes #7560. May fix #7778. Fixes #5119.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants