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
Stop moving I2C and SPI objects and remove release_displays()
.
#8675
Comments
A note about (2): the pycamera has to release and reinitialize the display multiple times during a single application run. would it change to doing a deinit call on the specific display object instead of calling release_displays()? |
Yes, you'd deinit the specific display. |
My comment is specific to the For a novice user - which CircuitPython has as a core persona - the behavior of With respect to ePaper displays, treating them as general purpose for console output is potentially damaging. Every time the user has an error in their code or hits These are two separate issues. I am not sure if they are orthogonal or not. Question 1: Should Question 2: How will the developer of a board with an integrated display indicate the display is (or is not) suitable for console output? |
I agree. That's why I think it should be removed.
We do treat eink specially internally. Specifically we respect the refresh time spacing that manufacturers suggest be 180 seconds. Showing errors is very valuable. Note, with the proposed
Yes, in case you need to reinitialize the display with different settings. If you need the display as-is, then don't do release displays.
|
The refresh time is a problem. The user can set this when creating an epaper display using one of the libraries such as
Opt-In is definitely my preference.
One problem with having a the ePaper display show errors is when first using a new board, beginning with a new code project, or the initial CircuitPython tutorials. A fresh install of CircuitPyton on a new board creates Having the ability to configure the board specific CircuitPython firmware build to opt-out will be a great addition. In the meantime, we will plan to ship with some workaround. |
This sounds good, as long as I can still set I wonder, though if we don't want to make |
Yup, that'd be the idea.
That would be good idea for the transition release. |
Right now display core will move I2C and SPI objects that they need to keep outside the VM. This is bug prone. Instead we should ensure the used object is already outside the Python VM. It can either be statically allocated (likely for use in
board
) or allocated dynamically to the outer heap.This will be easier once we move to a model where only one display lives past VM reset.
displayio
currently lets all displays outlive the VM. In practice, this is almost always 1 because of the display limit. We can remove this limit with the split heap switch in 9 but it doesn't make it clear which display to use for the terminal. Instead, we can add an explicitsupervisor.runtime.display =
that allows for setting a single display to preserve outside the VM and use for the terminal. It also allows for user code to access a previously constructed display without needing to reconstruct it afterrelease_displays()
. The assignment can also validate that all objects are present outside the Python VM and won't need to be moved.So:
supervisor.runtime.display =
that validates that the display and anything it uses won't need to be moved (is in `board.)release_displays()
a no-op and release any other displays at VM end.This will break display behavior because the "lives outside VM and is used by CP" will be explicit. Boards with displays can set this automatically though.
The text was updated successfully, but these errors were encountered: