v0.1.5

All boards except the RP2350 move to omnipython-lvgl c34fbee, the successor of the archived lvgl-micropython, with LVGL's memory in TLSF pools. The RP2350 is unchanged: use v0.1.0.

Board	File	State
STM32H7_CORE V1.0 + IPS 1024x600	STM32H7_CORE-V10-v0.1.5.dfu, .hex	tested on hardware: this firmware (board checks, soft resets, the 10 examples); these sources: 15 min soak, touch
ESP32-4848S040	ESP32_4848S040-v0.1.5.bin	tested on hardware: this firmware (the 10 examples, the shell); these sources: pools, 15 min soak
STM32H7_CORE V1.3	STM32H7_CORE-V13-v0.1.5.hex	builds; same code as the V1.0, not run on this binding yet
DEV190806042	DEV190806042-v0.1.5.hex	builds, never run on a board: use at your own risk
FK743M5-XIH6	FK743M5-XIH6-v0.1.5.hex	builds, never run on a board: use at your own risk

What changes

• LVGL no longer slows down with a fragmented heap. Without the pools, LVGL's allocations walk MicroPython's heap from its first free block: with one free block below an application's data, a full redraw took 360 ms instead of 69 on the STM32H7_CORE (28 MB heap), 86 instead of 51 with a 490 KB heap, 470 instead of 71 on the ESP32. With the pools it stays at the fresh-heap time. They cost about 25 KB of heap and 1.5-4 ms per gc.collect().
• machine.bootloader() enters USB DFU on the STM32H743 boards, no buttons: then dfu-util as usual. It used to reset into MicroPython: the port jumped to 0x1ff00000, which reads as zeros on the H743, instead of the ROM bootloader at 0x1ff09800. Tested on the STM32H7_CORE V1.0.
• Touch on the STM32 boards within the GT911's 400 kHz: the bus ran at 1.07 MHz on the STM32H7_CORE V1.0 and 500 kHz over SoftI2C. The rare touch read errors (about 1 in 30 000 to 150 000) were only seen above the rating; a read with no touch now takes 241 us instead of 80.
• Examples: examples/shell, a shell for an ANSI terminal with vi and edit; Ctrl-C on an empty line leaves it.

Good to know

• ESP32-4848S040: about 128 KB less free heap than v0.1.4 (4.61 MB after import display_driver), with or without the pools. The cause is not known yet.

Flashing

• STM32H7_CORE V1.0: dfu-util -a 0 -d 0483:df11 -D STM32H7_CORE-V10-v0.1.5.dfu, with the board in DFU mode: machine.bootloader() from v0.1.5 on, or BOOT0 held while pressing RESET. See docs/flash-dfu.md.
• Other STM32 boards: scripts/stm32_uart_flash.py flash <file>.hex --verify, through the ST bootloader on UART1 (see docs/stm32h743.md).
• ESP32-4848S040, from v0.1.0 or later, keeping your files: esptool.py --chip esp32s3 -p <port> -b 460800 write_flash 0x0 ESP32_4848S040-v0.1.5.bin. From other firmware, erase_flash first (it erases everything on the board).

Sources: MicroPython 1.29.0, omnipython-lvgl c34fbee (STM32 and ESP32), ESP-IDF 5.5.2. Measurements and logs: docs/stm32h743.md, docs/esp32-4848s040.md, docs/log/. Checksums: SHA256SUMS.