The macros are MICROPY_HEAP_START and MICROPY_HEAP_END, and if not defined
by a board then the default values will be used (maximum heap from SRAM as
defined by linker symbols).
As part of this commit the SDRAM initialisation is moved to much earlier in
main() to potentially make it available to other peripherals and avoid
re-initialisation on soft-reboot. On boards with SDRAM enabled the heap
has been set to use that.
This patch allows a given board to configure which pins are used for the
CAN peripherals, in a similar way to all the other bus peripherals (I2C,
UART, SPI). To enable CAN on a board the mpconfigboard.h file should
define (for example):
#define MICROPY_HW_CAN1_TX (pin_B9)
#define MICROPY_HW_CAN1_RX (pin_B8)
#define MICROPY_HW_CAN2_TX (pin_B13)
#define MICROPY_HW_CAN2_RX (pin_B12)
And the board config file should no longer define MICROPY_HW_ENABLE_CAN.
This patch forces a board to explicitly define TEXT1_ADDR in order to
split the firmware into two separate pieces. Otherwise the default is now
to produce only a single continuous firmware image with all ISR, text and
data together.
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.
Newer versions of the HAL use names which are cleaner and more
self-consistent amongst the HAL itself. This patch switches to use those
names in most places so it is easier to update the HAL in the future.
mpconfigboard_common.h now sets the defaults so there is no longer a need
to explicitly list all configuration options in a board's mpconfigboard.h
file.
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
Andrew Leech
forester3