Inky what #14
Draft
Inky what #14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
One potentially confusing thing is that this crate is named after the ssd1675, but these changes would make it work with what I assume is the ssd1619. (I guess the MAX_ constants make more sense if it's ssd1675-specific) |
Type of cols changed from u8 -> u16 throughout. Max values increased to what resolution of 400x300.
Thra11
commented
Jun 24, 2020
| self.config.write_vcom.execute(&mut self.interface)?; | ||
|
|
||
| // POR is HiZ. Need pull from config | ||
| // Command::BorderWaveform(u8).execute(&mut self.interface)?; | ||
| Command::BorderWaveform(0b00110001).execute(&mut self.interface)?; |
There was a problem hiding this comment.
Instead of / in addition to calling this in init, it might be nice to expose this via a set_border function.
|
I've ordered an Inky wHAT to try this out. I'm also looking to reorganise the crate a bit. I'd like to make it a bit less controller specific so that it captures the ssd1675 and others such as the ssd1619 you mention. I'd also like to move out inky specific stuff into a separate crate so that it's easier to deal with the different size and colour variants. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Draft as I still need to test this specific combination: I had bumped the embedded-graphics dependency in the branch I developed and tested the changes on: This branch drops the version bump, but I haven't yet refactored my application to use the old API in order to test that this still works.
Updates to
display.rsare mostly based on a recent version of pimoroni's python library. Need to double check that all the constants which I've used aren't display-specific. There's also some display-variant-specific code in the python library which I haven't copied yet:https://github.com/pimoroni/inky/blob/feb2303e377badbf4cf940e8e5e309da6a2e5168/library/inky/inky.py#L291-L294
Given that this ssd1675 crate already requires the user to provide the correct LUT for their display, we may also need to have them pass in the SourceDrivingVoltage values as well. It might be nice to provide a separate inky crate at some point with all the LUTs and display-specific knowledge.
The other changes are to allow the 400x300 resolution of the what, including widening the
colstype fromu8tou16, and fixing some multiplication overflows.I did wonder whether
MAX_GATE_OUTPUTS,MAX_SOURCE_OUTPUTSand the assertions based on them are really meaningful. As far as I can tell, they don't represent any limitation of the chip itself, nor do they represent a resolution above which the code no longer works (e.g. due to overflows, etc.). Having said that, I suppose they do represent the highest resolution which has been tested, so if a higher-resolution version comes out in future, then the user is warned that they are responsible for confirming that the calculations are still valid.