These are moved:
* Display -> busdisplay.BusDisplay
* FourWire -> fourwire.FourWire
* EPaperDisplay -> epaperdisplay.EPaperDisplay
* I2CDisplay -> i2cdisplaybus.I2CDisplayBus
`paralleldisplay` is now `paralleldisplaybus` (and registered as
`paralleldisplay` too).
Bus related helpers are split out of display_core into bus_core.
It is in still displayio since it is a dependency of both
busdisplay and epaperdisplay.
Fixes#7667
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.
After calling board.SPI().deinit(), calling board.SPI() again would return the unusable deinited object and there was no way of getting it back into an initialized state until the end of the session.
Fixes#3581.
Pins were marked as never_reset by common_hal_displayio_fourwire_construct() and common_hal_sharpdisplay_framebuffer_construct(), but these marks were never removed, so at the end of a session after displayio.release_displays(), {spi|i2c}_singleton would be set to NULL but the pins would not be reset. In the next session, board.SPI() and board.I2C() were unable to reconstruct the object because the pins were still in use.
For symmetry with creation of the singleton, add deinitialization before setting it to NULL in reset_board_busses(). This makes the pins resettable, so that reset_port(), moved behind it, then resets them.
At the end of a session that called displayio.release_displays() (and did not initialize a new display), a board.I2C() bus that was previously used by a display would wrongly be considered still in use. While I can’t think of any unrecoverable problem this would cause in the next session, it violates the assumption that a soft reboot resets everything not needed by displays, potentially leading to confusion.
By itself, this change does not fix the problem yet - rather, it introduces the same issue as in #3581 for SPI. This needs to be solved in the same way for I2C and SPI.
Scott Shawcroft
Dan Halbert
Scott Gauche
microDev
Jeff Epler
Christian Walther
root
Mark Olsson
Dave Marples
Hierophect