This patch allows a particular board to independently specify the linker
scripts for 1) the MCU memory layout; 2) how the different firmware
sections are arranged in memory. Right now all boards follow the same
layout with two separate firmware section, one for the ISR and one for the
text and data. This leaves room for storage (filesystem data) to live
between the firmware sections.
The idea with this patch is to accommodate boards that don't have internal
flash storage and only need to have one continuous firmware section. Thus
the common.ld script is renamed to common_ifs.ld to make explicit that it
is used for cases where the board has internal flash storage.
The HAL requires strict aliasing optimisation to be turned on to function
correctly (at least for the SD card driver on F4 MCUs). This optimisation
was recently disabled with the addition of H7 support due to the H7 HAL
having errors with the strict aliasing optimisation enabled. But this is
now fixed in the latest stm32lib and so the optimisation can now be
re-enabled.
Thanks to @chuckbook for finding that there was a problem with the SD card
on F4 MCUs with the strict aliasing optimisation disabled.
The CMSIS files for the STM32 range provide macros to distinguish between
the different MCU series: STM32F4, STM32F7, STM32H7, STM32L4, etc. Prefer
to use these instead of custom ones.
This patch takes the software SPI implementation from extmod/machine_spi.c
and moves it to a dedicated file in drivers/bus/softspi.c. This allows the
SPI driver to be used independently of the uPy runtime, making it a more
general component.
Prior to this patch, storage.c was a combination of code that handled
either internal flash or external SPI flash and exposed one of them as a
block device for the local storage. It was also exposed to the USB MSC.
This patch splits out the flash and SPI code to separate files, which each
provide a general block-device interface (at the C level). Then storage.c
just picks one of them to use as the local storage medium. The aim of this
factoring is to allow to add new block devices in the future and allow for
easier configurability.
Which Wiznet chip to use is a compile-time option: MICROPY_PY_WIZNET5K
should be set to either 5200 or 5500 to support either one of these
Ethernet chips. The driver is called network.WIZNET5K in both cases.
Note that this commit introduces a breaking-change at the build level
because previously the valid values for MICROPY_PY_WIZNET5K were 0 and 1
but now they are 0, 5200 and 5500.
This is to keep the top-level directory clean, to make it clear what is
core and what is a port, and to allow the repository to grow with new ports
in a sustainable way.
Damien George