CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.1.0-alpha.0 2020-10-15T20:24:19+00:00 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 2020-10-02T20:07:36+00:00 Jeff Epler jepler@gmail.com 2020-10-02T20:07:36+00:00 urn:sha1:b1592564b286ca7a5374e77eba2c2efc768ffae9 An RGBMatrix has no bus and no bus_free method. It is always possible to refresh the display. This was not a problem before, but the fix I suggested (#3449) added a call to core_bus_free when a FramebufferDisplay was being refreshed. This was not caught during testing. This is a band-aid fix and it brings to light a second problem in which a SharpDisplay + FrameBuffer will not have a 'bus' object, and yet does operate using a shared SPI bus. This kind of display will need a "bus-free" like function to be added, or it can have problems like #3309. 2020-10-01T18:00:25+00:00 Scott Shawcroft scott@adafruit.com 2020-10-01T18:00:25+00:00 urn:sha1:b9890f2d420665a96fcf56e196d36d0fc1032b66 sharpdisplay: Fix memory corruption across soft-reset 2020-10-01T17:54:48+00:00 Scott Shawcroft scott@adafruit.com 2020-10-01T17:54:48+00:00 urn:sha1:f303fb3d4103871e096699d5dcd4b419ac8acc3b Add Metro ESP32S2