With the RTOS, the STACK_SIZE specified here is unrelated to the stack
size available for the main thread (that runs pre_main). Save memory by
reducing the stack size to a more reasonable amount.
On uVisor, HEAP_SIZE is both a minimum available and maximum available
heap size. The heap can't grow beyond the end of the heap into the
neighboring stack. On all uVisor-supported platforms, guarantee at least
0x6000 bytes of heap space. This increases the portability of uVisor
applications as the memory available for legacy heap allocations is
guaranteed. This helps to avoid out of memory errors on platforms that
were previously guaranteeing less memory.
A copy paste error snuck into the uVisor related updates to the EFM32GG
linker script. Fix the error by replacing "m_data" with "RAM".
Fixes: 89641bc7e0 "uVisor: Update K64F and EFM32GG linker scripts"
Add sleep/deepsleep functions to platform layer which are replacing HAL
functions with the same name, rename existing symbols in HAL layer
to hal_sleep/hal_deepsleep. This way sleep functions
are always available, even if target doesn't implement them, which makes
the code using sleep clearer. It also enables us to make decision on in
which builds (debug/release) the sleep will be enabled.
This commit improves consistency between different platforms' linker
scripts. In particular, we use "__UVISOR_SRAM_START" instead of
"__UVISOR_BSS_START" as the uVisor BSS sections might be outside of the
SRAM (for example, when using a tightly-coupled memory).
Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure.
* In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...)
* Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals)
* Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
First wave of squashing header files in order to get to a more sensible folder tree.
* Moved header files with 100% similarity to common folder
* Created a CommonPinNames.h header containing the base pin names P[A-F][0-15] and NC
Jaeden Amero
Martin Kojtal
Bartek Szatkowski
Alessandro Angelino
Steven Cooreman
Christopher Haster