suspect-devices/circuitpython/shared-module, branch 6.0.0-beta.1CircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.0.0-beta.12020-10-01T18:00:25+00:00Merge pull request #3497 from jepler/issue34732020-10-01T18:00:25+00:00Scott Shawcroftscott@adafruit.com2020-10-01T18:00:25+00:00urn:sha1:b9890f2d420665a96fcf56e196d36d0fc1032b66
sharpdisplay: Fix memory corruption across soft-resetMerge pull request #3495 from tannewt/esp32s2_metro2020-10-01T17:54:48+00:00Scott Shawcroftscott@adafruit.com2020-10-01T17:54:48+00:00urn:sha1:f303fb3d4103871e096699d5dcd4b419ac8acc3b
Add Metro ESP32S2Merge pull request #3449 from FoamyGuy/sdcard_odb_fix2020-10-01T17:13:13+00:00Scott Shawcroftscott@adafruit.com2020-10-01T17:13:13+00:00urn:sha1:be6e6eabd27e5e301decc93496a9fbc59f0f6bda
Sdcard odb fixsharpdisplay: Fix memory corruption across soft-reset2020-10-01T14:22:09+00:00Jeff Eplerjepler@gmail.com2020-10-01T14:21:39+00:00urn:sha1:d7c3f811afd924bae8e0b009a4cfadd6fab29584
It was incorrect to NULL out the pointer to our heap allocated buffer in
`reset`, because subsequent to framebuffer_reset, but while
the heap was still active, we could call `get_bufinfo` again,
leading to a fresh allocation on the heap that is about to be destroyed.
Typical stack trace:
```
#1 0x0006c368 in sharpdisplay_framebuffer_get_bufinfo
#2 0x0006ad6e in _refresh_display
#3 0x0006b168 in framebufferio_framebufferdisplay_background
#4 0x00069d22 in displayio_background
#5 0x00045496 in supervisor_background_tasks
#6 0x000446e8 in background_callback_run_all
#7 0x00045546 in supervisor_run_background_tasks_if_tick
#8 0x0005b042 in common_hal_neopixel_write
#9 0x00044c4c in clear_temp_status
#10 0x000497de in spi_flash_flush_keep_cache
#11 0x00049a66 in supervisor_external_flash_flush
#12 0x00044b22 in supervisor_flash_flush
#13 0x0004490e in filesystem_flush
#14 0x00043e18 in cleanup_after_vm
#15 0x0004414c in run_repl
#16 0x000441ce in main
```
When this happened -- which was inconsistent -- the display would keep
some heap allocation across reset which is exactly what we need to avoid.
NULLing the pointer in reconstruct follows what RGBMatrix does, and that
code is a bit more battle-tested anyway.
If I had a motivation for structuring the SharpMemory code differently,
I can no longer recall it.
Testing performed: Ran my complicated calculator program over multiple
iterations without observing signs of heap corruption.
Closes: #3473
remove remaining top level displayio background check2020-09-30T22:25:58+00:00FoamyGuyfoamyguy@gmail.com2020-09-30T22:25:58+00:00urn:sha1:422a7d4013ddaec7df5df9104e5d9ea533b31d1aAdd Metro ESP32S22020-09-30T19:57:39+00:00Scott Shawcroftscott@tannewt.org2020-09-29T20:04:39+00:00urn:sha1:a739d314f1a9f5fee6517eb425a2c691969fd7f7
Also fix two bugs:
* Crash when resetting board.SPI when it hasn't been inited.
* Reading back the output value is always false. Fixes #3353
Merge pull request #3450 from mdroberts1243/New_quirk_for_SH11072020-09-30T19:03:10+00:00Scott Shawcroftscott@adafruit.com2020-09-30T19:03:10+00:00urn:sha1:5ac3c36d64cf4be13e7a1ebc0c47fb546e689134
New quirk for sh1107removing top level displayio background check2020-09-30T19:03:03+00:00FoamyGuyfoamyguy@gmail.com2020-09-30T19:03:03+00:00urn:sha1:d1bda47d94c2ab9e42a74de4a5209df73e46a4eaRemoved redundant subrectangle sizing code2020-09-30T18:06:13+00:00Mark Robertsmdroberts1243@gmail.com2020-09-29T23:48:14+00:00urn:sha1:ef245ef54ebab7c483a935dbfb100e2ab100f0eaRan pre-commit locally2020-09-30T18:06:13+00:00Mark Robertsmdroberts1243@gmail.com2020-09-29T19:37:06+00:00urn:sha1:9f19a8a7600ad59851953a7c0454d09245eadf4d