CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.1.x 2020-11-28T16:54:34+00:00 2020-11-28T16:54:34+00:00 Christian Walther cwalther@gmx.ch 2020-10-17T11:49:10+00:00 urn:sha1:a4b84cf0e118f06cc3b563866d5c594b94b9b3fb Hybrid allocation is now part of the infrastructure. Moving memory contents would not be necessary because displayio can recreate them, but does not hurt. 2020-11-28T16:50:23+00:00 Christian Walther cwalther@gmx.ch 2020-10-11T12:59:33+00:00 urn:sha1:c7404a3ff89c738c002ec63448a58d56330dfcc3 This allows calls to `allocate_memory()` while the VM is running, it will then allocate from the GC heap (unless there is a suitable hole among the supervisor allocations), and when the VM exits and the GC heap is freed, the allocation will be moved to the bottom of the former GC heap and transformed into a proper supervisor allocation. Existing movable allocations will also be moved to defragment the supervisor heap and ensure that the next VM run gets as much memory as possible for the GC heap. By itself this breaks terminalio because it violates the assumption that supervisor_display_move_memory() still has access to an undisturbed heap to copy the tilegrid from. It will work in many cases, but if you're unlucky you will get garbled terminal contents after exiting from the vm run that created the display. This will be fixed in the following commit, which is separate to simplify review. 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-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-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-09-02T18:34:16+00:00 Jeff Epler jepler@unpythonic.net 2020-09-02T18:34:16+00:00 urn:sha1:17a5a85528525352ec1821127fafec2acb239196 2020-09-01T16:00:22+00:00 Jeff Epler jepler@gmail.com 2020-09-01T15:58:54+00:00 urn:sha1:3c083330f8a201d74b120c1f9f83baef8124fae5 @tannewt noticed this in a pull request review. The allocated memory was never used, but the GC would have collected it eventually. 2020-09-01T16:00:22+00:00 Jeff Epler jepler@gmail.com 2020-08-31T21:00:41+00:00 urn:sha1:ce603dfebfa9a6ef057110c14c5d5b819eb93069 2020-09-01T16:00:07+00:00 Jeff Epler jepler@gmail.com 2020-08-28T16:24:59+00:00 urn:sha1:e01ade3848cf828620ea25ada2b2b829dbe180f3 2020-09-01T15:55:45+00:00 Jeff Epler jepler@gmail.com 2020-08-28T16:17:07+00:00 urn:sha1:2f120c70eee692b8e036f8f0778af2b723e1f0e7 e.g., allocating a 192x32x6bpp matrix would be enough to trigger this reliably on a Metro M4 Express using the "memory hogging" layout. Allocating 64x32x6bpp could trigger it, but somewhat unreliably. There are several things going on here: * we make the failing call with interrupts off * we were throwing an exception with interrupts off * protomatter failed badly in _PM_free when it was partially-initialized Incorporate the fix from protomatter, switch to a non-throwing malloc variant, and ensure that interrupts get turned back on. This decreases the quality of the MemoryError (it cannot report the size of the failed allocation) but allows CircuitPython to survive, rather than faulting.