mbed-usb (which provides `USBDevice_Types.h`) is a higher-level USB
library in Mbed-OS that sits on top of the HAL. Targets should not
implement the HAL and use higher-level libraries, hence, the dependency
should be removed. This dependency also causes errors when building with
the bare-metal profile.
C++ files were excluded from target_sources, this meant that those files
were being missed entirely during the build process. This adds any files
that may have missed in the first commit.
If GPIO_PINMAP_READY is defined for the target,
- PinMap_GPIO table is expected in PeripheralPins.c
- weak gpio_get_capabilities function is implemented
Due to a known issue in Mbed TLS's architecture determination
(ARMmbed/mbedtls#1077), we get the error
error: inline assembly requires more registers than available
when compiling `bignum.c` for Cortex-M0/0+/1/M23 which do not have
the macro `__thumb2__` set by the compiler.
The workaround is to define the macro `MULADDC_CANNOT_USE_R7` which
is already defined by Mbed CLI 1 but missing in our CMake support.
FixesARMmbed/mbed-os-example-lorawan#220
Each block of HeapBlockDevice is only allocated from the heap when
that block is programmed. And erasing a block frees the associated
buffer.
To decide if there is enough heap to run the TDBStore Whitebox tests,
we need to perform a trial program() instead of erase().
From the documentations of `BlockDevice::get_erase_value()`:
-1 if you can't rely on the value of the erased storage
and `BlockDevice::program()`:
The blocks must have been erased prior to being programmed
So, `BlockDevice::erase()` should always be called regardless of
erase value.
Currently `TDBStore::offset_in_erase_unit()` and
`TDBStore::check_erase_before_write()` loop through erase units
one-by-one, until the entire range is covered. This is very inefficient
when the erase size is tiny, e.g. one-byte on a non-flash device for
which we use program as erase.
This commit reworks the algorithms, based on the fact that a block
device can erase or program as many units as needed in one go.
The "erased_set_get" test case deinits `FileSystemStore`, erases the
block device, and reinits `FileSystemStore`. This of course fails,
because `BlockDevice::erase()` removes all stored data including the
format of the `FileSystem` (middle layer), unless the particular type
of block device has a no-op erase implementation.
Note: Previously `HeapBlockDevice::erase()` was essentially a no-op
so this test case did not fail. We recently added the freeing of heap
memory and it uncovered the problem.
Mbed OS does not enable C++ exceptions, so we should call `new` with
`std::nothrow` which returns a C-style NULL pointer when allocation
fails to allow error handling.
For consistency of style within the same file, this commit also
replaces `malloc()` and `free()` to `new (std::nothrow)` and `delete`.
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.
jeromecoutant
harmut01
Martin Kojtal
s-bruce13
mbedmain
Chun-Chieh Li
Debdeep Saha
Saheer Babu
Lingkai Dong
Anna Bridge
Robert Walton
Jaeden Amero