According to the schematic, the SDRAM part on this board is a
MT48LC4M32B2B5-6A, with "Row addressing 4K A[11:0]" (per datasheet). This
commit updates mpconfigboard.h from 13 to 12 to match.
This patch uses the newly-added esp32.Partition class to replace the
existing FlashBdev class. Partition objects implement the block protocol
so can be directly mounted via uos.mount(). This has the following
benefits:
- allows the filesystem partition location and size to be specified in
partitions.csv, and overridden by a particular board
- very easily allows to have multiple filesystems by simply adding extra
entries to partitions.csv
- improves efficiency/speed of filesystem operations because the block
device is implemented fully in C
- opens the possibility to have encrypted flash storage (since Partitions
can be encrypted)
Note that this patch is fully backwards compatible: existing filesystems
remain untouched and work with this new code.
- STM32F407VGT6 (1MB of Flash, 192+4 Kbytes of SRAM)
- 5V (via USB) or Li-Polymer Battery (3.7V) power input
- 2 x LEDs
- 2 x user switches
- 2 x mikroBUS sockets
- 2 x 1x26 mikromedia-compatible headers (52 pins)
https://www.mikroe.com/clicker-2-stm32f4
Mboot currently requires at least three LEDs to display each of the four
states. However, since there are only four possible states, the states can
be displayed via binary counting on only 2 LEDs (if only 2 are available).
The existing patterns are still used for 3 or 4 LEDs.
It was previously not taking into account that the list of pins was sparse,
so using the wrong index. The boards/X/pins.csv was generating the wrong
data for machine.Pin.board.
As part of this fix rename the variables to make it more clear what the
list contains (only board pins).
Prior to this patch mp_opcode_format would calculate the incorrect size of
the MP_BC_UNWIND_JUMP opcode, missing the additional byte. But, because
opcodes below 0x10 are unused and treated as bytes in the .mpy load/save
and freezing code, this bug did not show any symptoms, since nested unwind
jumps would rarely (if ever) reach a depth of 16 (so the extra byte of this
opcode would be between 0x01 and 0x0f and be correctly loaded/saved/frozen
simply as an undefined opcode).
This patch fixes this bug by correctly accounting for the additional byte.
.
With this patch alignment is done relative to the start of the buffer that
is being unpacked, not the raw pointer value, as per CPython.
Fixes issue #3314.
Damien George
cristian
Jim Mussared
Alex Albino
Christopher Wilson
Andrew Leech
Braden Mars
stijn
Tom McDermott
Jeff Epler
Milan Rossa