Update CMAKE_MODULE_PATH at once place.
Note, we update also CMAKE_MODULE_PATH in app.cmake. This is temporary until we get a proper way to include
Mbed Os (removing app.cmake need to be included by an application).
To avoid conflicts as we expose our CMake list files via CMAKE_MODULE_PATH. Some files already include it, this
aligns the rest of files.
I leave app.cmake as it is - it's user facing and it would be breaking change. We can clean this one for the next major version.
CMAKE_CURRENT_LIST_DIR behaves differently in functions. We store it in the CMakeLists itself, so anyone
calling a function would get the actual list dir where the scripts are.
To illustrate: if I call a function from src/CMakelists.txt, function located in src/scripts, `CMAKE_CURRENT_LIST_DIR` in the function would point
to the src/ folder but not to src/scripts.
All files within tools/cmake can now include within tools/cmake. We do not expose
internal folders like core/profiles/toolchains.
They should be included via toolchain file (mbed_toolchain in our case).
- list files included via module path
- <project-name>_SOURCE_DIR for sources that are out of the current processed CMake
- CMAKE_CURRENT_LIST_DIR for listfiles
mbed-nanostack should depend on mbed-802.15.4-rf to avoid a linker error
with an undefined reference to `NanostackRfPhy::get_default_instance()`.
The error occurs when `device_has: 802_15_4_PHY` is defined and the
consumer depends on mbed-nanostack in their CMakeLists.txt. Previously
we linked mbed-nanostack to mbed-802.15.4-rf, so mbed-802.15.4-rf's
usage requirements weren't forwarded to consumers who depended on
mbed-nanostack.
With the previous configuration, the consumer would have to depend on
mbed-802.15.4-rf directly to avoid an issue. This seems like a layering
violation: it appears that mbed-nanostack is "the API" and
mbed-802.15.4-rf is one of several possible implementations which are
selected based on configuration macros.
This commit changes the flow of dependencies so that mbed-nanostack ends
up with the correct symbol definitions.
At 9600 baud, a large part of the serial output of the crash reporting
example is missing on CI boards, causing the example test to fail. At
a higher serial speed (115200 baud), the entire output is intact.
This is in alignment with ARMmbed/mbed-os-example-crash-reporting#65.
Fixes#14535
Runtime code that analysed clock frequency to determine numerator and
denominator for conversion to standard 1MHz failed to handle the case
of either being 1 correctly.
Although it would spot other values that could be performed as shifts,
it failed to spot that 1 is "shift by 0", so would end up doing runtime
multiply and/or divide by 1. The runtime divide by 1 could be slow on a
Cortex-M0 device, increasing interrupt latency.
UART character loss on STM32F0 devices has been traced to this incorrect
code.
Correct the `exact_log2` routine so that `exact_log2(1)` returns 0 to
fix this.
Original code had a single special no-multiply-or-divide case for
hardware clock frequency being exactly 1MHz, as USTICKER is on STM32F0 -
this code lacks that but has a more general special case that covers all
shift-convertible frequencies like 500kHz or 8MHz, which should be
similar speed as shifts are cheap.
Martin Kojtal
Anna Bridge
Robert Walton
Jaeden Amero
jeromecoutant
reme
Chandran Praveen Babu (CYSC CSS ICW SW PSW)
Lingkai Dong
Kevin Bracey
s-bruce13