As the timer code became more generic, coping with initialization on
demand, and variable width and speed us_ticker_api implementations,
wait_us has gradually gotten slower and slower.
Some platforms have reportedly seen overhead of wait_us() increase from
10µs to 30µs. These changes should fully reverse that drop, and even
make it better than ever.
Add fast paths for platforms that provide compile-time information about
us_ticker. Speed and code size is improved further if:
* Timer has >= 2^32 microsecond range, or better still is 32-bit 1MHz.
* Platform implements us_ticker_read() as a macro
* Timer is initialised at boot, rather than first use
The latter initialisation option is the default for STM, as this has
always been the case.
Make the option positively named, and as it is a platform config
option make sure it only affects platform code.
HAL functions still remain available even if platform is told not
to use them.
Make the following changes:
-Allow a vector specific ARM MPU driver by defining MBED_MPU_CUSTOM
-Allow ROM address to be configured for ARMv7-M devices by
setting the define MBED_MPU_ROM_END
-Add ROM write protection
-Add new functions and lock
-enable at boot
-disable during flash programming
Enable the MPU as part of the boot sequence and disable it before
starting a new application. Also add reference counted MPU lock and
unlock functions to allow code to execute from ram when necessary.
Refactor the Mbed 5 boot process to make is simpler and more modular.
This is done by breaking the boot sequence into 4 distinct steps -
Target setup, Toolchain setup, RTOS setup and Mbed setup. This patch
also move toolchain specific code into a per toolchain folder to make
it more maintainable.
1. Define RTX_NO_MULTITHREAD_CLIB to provide Mbed-specific multi-thread support for ARM/ARMC6
2. All overridden _mutex_xxx functions are declared with __USED to avoid excluded by linker
NOTE: Microlib doesn't support multi-thread
armcc fopen allocated a mutex using the retargeted system-level
_mutex_initialize function. Interestingly, malloc also uses this
same _mutex_initialization function, which prevents a full solution
relying on malloc. The solution previously implemented involved using
the rtx mutex pool for the first 8 mutexes, then falling back on
malloc.
The previous implementation relied on osMutexNew returning an error
on out-of-memory. An unrelated change causes osMutexNew to instead
assert (except for release mode). This meant if you exceed 8 system-
level mutexes in armcc you will hit an assert. Since the filesystem
code can call fopen an unlimited number of times, this is a problem.
Solution is to keep track of which static mutexes we've allocated, so
we know before calling osMutexNew if we need to call malloc.
Also _mutex_free never deallocated the malloced mutexes, which would
cause fopen to leak memory.
Update directory structure to include RTX for only cortex targets, and
for all cortex targets. This patch accomplishes this by moving mbed-os
specific RTX files and RTX itself into rtos/TARGET_CORTEX along with
removing TARGET_CORTEX_M from the RTX5 directory.
The old directory structure:
rtos/rtx5/<mbed-os specific RTX files>
rtos/rtx5/TARGET_CORTEX_M/*
rtos/rtx4/*
rtos/<mbed-os specific RTX files>
Is re-arranged to:
rtos/TARGET_CORTEX/rtx5/*
rtos/TARGET_CORTEX/rtx4/*
rtos/TARGET_CORTEX/<mbed-os specific rtx files>
This both encapsulates RTX code more cleanly and makes it easier to
experiment with non-cortex cmsis-os2 backends, such as a posix
based cmsis-os2 backend.
Note - A potentially better name for the CORTEX_M directory would be
something like FEATURE_RTX5 since this directory only contains RTX5
related files. This cannot be done because there is not an easy way
to turn this feature on, since it cannot be done from mbed_lib.json.
Kevin Bracey
deepikabhavnani
Martin Kojtal
Russ Butler
Senthil Ramakrishnan
Oren Cohen
ccli8
Christopher Haster
Jimmy Brisson