CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.0.0-rc.2 2020-10-26T21:44:38+00:00 2020-10-26T21:44:38+00:00 Christian Walther cwalther@gmx.ch 2020-10-24T15:50:11+00:00 urn:sha1:99a3750a2cfd1da8cdd266ca9a0367f0c3a54092 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. 2020-10-26T21:44:38+00:00 Christian Walther cwalther@gmx.ch 2020-10-24T15:23:17+00:00 urn:sha1:f4f80e07ca3dc2f5a93484e5342540837a94a505 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. 2020-10-26T21:44:38+00:00 Christian Walther cwalther@gmx.ch 2020-10-24T15:13:10+00:00 urn:sha1:1117edae63df7b66f1575980bf54d6836f9a8aa8 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. 2020-10-15T20:24:19+00:00 Jeff Epler jepler@gmail.com 2020-10-13T21:57:09+00:00 urn:sha1:88d07ef35b686ffd66487de81564396aac0818b8 @cwalther determined that for boards with 2 displays (monster m4sk), start_terminal would be called for each one, leaking supervisor heap entries. Determine, by comparing addresses, whether the display being acted on is the first display (number zero) and do (or do not) call start_terminal. stop_terminal can safely be called multiple times, so there's no need to guard against calling it more than once. Slight behavioral change: The terminal size would follow the displays[0] size, not the displays[1] size 2020-10-12T22:45:51+00:00 Scott Shawcroft scott@adafruit.com 2020-10-12T22:45:51+00:00 urn:sha1:1eb1434fc968cb05e3cfd69b40434331404ef5df rgbmatrix: update protomatter to 1.0.5 tag 2020-10-12T22:24:58+00:00 Scott Shawcroft scott@adafruit.com 2020-10-12T22:24:58+00:00 urn:sha1:2e5bea26297180515dd5bb41e68bc3523eafcae8 rgbmatrix: Don't crash when setting brightness=0 2020-10-12T18:28:20+00:00 Jeff Epler jepler@gmail.com 2020-10-12T18:26:58+00:00 urn:sha1:9696dbfd388aa4c21b686d4566832964c31f8035 If the display is paused, `_PM_swapbuffer_maybe` will never return. So, when brightness is 0, refresh does nothing. This makes it necessary to update the display when unpausing. Closes: #3524 2020-10-12T02:09:08+00:00 Jeff Epler jepler@gmail.com 2020-10-12T02:09:08+00:00 urn:sha1:774f2e16ba166b5976a46519c38ea894f897dca4 A call to supervisor_start_terminal remained in common_hal_displayio_display_construct and was copied to other display _construct functions, even though it was also being done in displayio_display_core_construct when that was factored out. Originally, this was harmless, except it created an extra allocation. When investigating #3482, I found that this bug became harmful, especially for displays that were created in Python code, because it caused a supervisor allocation to leak. I believe that it is safe to merge #3482 after this PR is merged. 2020-10-10T19:30:37+00:00 Jeff Epler jepler@gmail.com 2020-10-10T19:30:37+00:00 urn:sha1:5e38bb98cbcc2d1ab607b19d11e628def4f48f4c this is compile-tested on stm32f405 feather matrixportal nrf52840 feather but not actually tested-tested. 2020-10-03T02:16:32+00:00 Limor "Ladyada" Fried limor@ladyada.net 2020-10-03T02:16:32+00:00 urn:sha1:9535edb8f4be7a01158b75c78a2a56fe11e6d3f0 displayio: Fix matrixportal crash