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

Experiment with higher SPI speeds #13

Open
nyaray opened this issue Jun 8, 2019 · 9 comments
Open

Experiment with higher SPI speeds #13

nyaray opened this issue Jun 8, 2019 · 9 comments

Comments

@nyaray
Copy link
Collaborator

nyaray commented Jun 8, 2019

When looking at the Python library, I found this pimoroni/inky#30 which indicates that we might be able to make things go a bit faster.

This can be done independently of any other on-going work as one could, for example, make the SPI speed be a config-parameter that defaults to the current value if not set, thus making any change backwards compatible.

@lawik
Copy link
Collaborator

lawik commented Jun 11, 2019

Interesting. Now if only I knew what version of display I have..

@nyaray
Copy link
Collaborator Author

nyaray commented Jun 11, 2019

I have reached out to a Pimoroni developer regarding chipsets, in hopes of getting some information so we can figure this out.

@lawik
Copy link
Collaborator

lawik commented Jun 11, 2019

Nice. Hope they're up for some sharing :)

@lawik
Copy link
Collaborator

lawik commented Jul 26, 2019

You did a bunch of profiling for your new performance changes. Any good recommendations for attempting to profile this sort of thing? What did you end doing for measurements? I guess you didn't have to measure on-device since you were mostly processing data structures..

@Axel-Jacobsen
Copy link

Hello - Have you profiled at all at different SPI speeds? It looks like you are also using 448 kHz, so does this mean that you encounter issues when using the inky pHat at higher SCLK frequencies (say, 1 MHz)?

Cheers! :)

@lawik
Copy link
Collaborator

lawik commented Sep 29, 2020

I think I tried a few variations but ended up settling on what was used in the original python library. Feel free to try some things and measure the results :)

@Axel-Jacobsen
Copy link

Thanks! Were there display issues?

I may be playing around with this relatively soon, I will report back my results!

@lawik
Copy link
Collaborator

lawik commented Sep 29, 2020

I quite honestly don't recall :D

I believe during certain experiments there was blurriness from previous images. Not sure if that was was experimenting with speeds or with the blanking.

The biggest difference in update speed for me has been running the red inky configured as black. No color but much faster.

@nyaray
Copy link
Collaborator Author

nyaray commented Nov 14, 2020

You did a bunch of profiling for your new performance changes. Any good recommendations for attempting to profile this sort of thing? What did you end doing for measurements? I guess you didn't have to measure on-device since you were mostly processing data structures..

I think I just used the built-in timer in BEAM and created a simple utility for gathering tagging starts and stops of timers. I don't even recall how I did everything, hehe. I want to say that a fair bit of time was spent waiting for the hardware to run the cycles defined by the LUTs.

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