Skip to content
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

Split out Inky specific functionality #19

Open
wezm opened this issue Nov 1, 2020 · 4 comments
Open

Split out Inky specific functionality #19

wezm opened this issue Nov 1, 2020 · 4 comments

Comments

@wezm
Copy link
Owner

wezm commented Nov 1, 2020

This crate was originally built as part of my e-Paper conference badge project, which used an Inky pHat display. As a result there are some Inky pHat specific things in the code. Additionally it appears that the SSD1619 controller (used in the Inky wHat) is very similar to the SSD1675, but supports more rows and columns.

I would like to:

  • Make this a core crate that supports the SSD1619 and SSD1675 controllers without any specific display code.
  • Create a new crate specifically for the Inky pHat and Inky wHat that knows how to work with those displays. That could also incorporate display discovery as proposed in Add pHat/wHat discovery #18 and wHat support from Inky what #14.
@wezm wezm pinned this issue Nov 1, 2020
@danieldulaney
Copy link

One thing that might be a good design goal for an Inky-specific crate would be to provide pre-configured LUTs and pins for the common use-case of sticking a board on top of a Raspberry Pi (or other common configurations if they come up). That would make it substantially easier to just pick up and go, but with this crate still available if there are uncommon use-cases that come up (e.g. #8).

@danieldulaney
Copy link

Also, to add to the list: newer revisions of the Inky pHat also use the SSD1608 controller, which is related but requires a slightly different setup sequence, as well as some logic to offset the visual pixels to the logical pixels (visual (0, 0) is at approx. logical (6, 0)).

Additionally, there are a bunch of different boards based on the SSD16xx family, including from Adafruit, whose library supports a half-dozen different displays.

I guess one question is how far this crate should be willing to go to support different displays (especially if they're driven by different chips), as opposed to supporting a specific subset of chips and leaving the rest to other crates.

If there's interest, I have an SSD1608-based pHat to test with, so I can start putting together support for it.

@JeanBlignaut
Copy link

Suggestion: How about making this crate display agnostic, or configurable for different displays, but leave the other chip versions for a different crate - mainly due to the fact that this crate is named SSD1675..?

@wezm
Copy link
Owner Author

wezm commented Feb 13, 2022

Yes that probably a good idea. As evidenced from the age of this issue it's unlikely that I'll be able to get to it any time soon though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants