The CMake target `mbed-headers` brings in all headers, and we are
gradually moving away from it and explicitly use only headers needed
by each unit test.
The header `mbed.h` pulls in headers from a number of Mbed OS
components that are not necessarily used. It was intended for user
applications only, and libraries and unit tests should explicitly
include library headers it uses to limit dependencies.
This change avoids having to link unnecessary libraries in storage
unit tests' CMake definitions.
Move storage stubs from UNITTESTS/stubs into components inside the
top-level storage directory. Specifically,
* storage/blockdevice/tests/UNITTESTS/doubles/ for BlockDevice stubs.
* storage/kvstore/filesystemstore/tests/UNITTESTS/ for a stub used by
the FileSystemStore test. The stub has been renamed from
kv_config_stub.cpp to filesystemstore_kv_config_stub.cpp, to make it
evident why it doesn't go into storage/kvstore/kv_config/.
Assumption that greentea test file is always named main.cpp is
incorrect. Updated mbed_greentea_add_test() macro to make TEST_SOURCES
parameter compulsory, which is used to specify greentea test
file(s). This allows tests to use C, or have a different name.
Therefore also updated all pre-existing greentea test CMake files to
explicity add main.cpp to TEST_SOURCES.
Typically when adding a unit test directory to a CMake project a check
will be used to ensure the subdirectory is added only if the following
are true:
* The BUILD_TESTING option is set to ON.
* The current CMake project is the top-level project.
The reason being, if a downstream project includes our project they
generally don't want to build our unit tests.
In mbed-os, we do correctly specify the above condition before adding
the central UNITTEST subdirectory, which fetches googletest and adds the
"stub" libraries the unit tests depend on. However, we only check if
CMAKE_CROSSCOMPILING is OFF (or undefined) before actually adding the
unit tests. This mismatched logic would lead to unexpected build
failures in various scenarios. One likely case could be: a downstream
project including mbed-os happens to set CMAKE_CROSSCOMPILING to
OFF/undefined for any reason (possibly to build its own unit tests).
mbed-os would go ahead and attempt to build its tests without fetching
googletest or adding the required stub targets.
To fix the issue replace the check for CMAKE_CROSSCOMPILING in the unit
tests with the same BUILD_TESTING idiom we use for adding the central
UNITTESTS subdirectory.
- Remove redundant cmake script as already added the CMake configuration file
- Remove redundant empty_baseline as it is no longer needed with the help of CMake configuration file
- ChainingBlockModuleTest test case compares two strings with EXPECT_EQ
which normally compare strings residing memory address so replaced it with EXPECT_STREQ to compare strings.
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`.
Add const to function declaration. Const objects cannot access const
safe functions, a compiler error is thrown if one tries to do so. This
helps ensure that the object calling the method will not be modified.
This is espescially desirable in functions where all we need to do is
query existing data and not make any alterations.
[Q/O/SPIFBlockDevice::erase() begin with an alignment check,
after which unaligned erases should not happen or be allowed.
If the erase address is not aligned to the value returned by
sfdp_iterate_next_largest_erase_type(), it indicates an
internal error in erase table parsing which should not be
hidden.
From the datasheet of the only OctaSPI flash we currently support
(http://www.mt-system.ru/sites/default/files/docs/Macronix/mx25lm51245g_3v_512mb_v0.01.pdf):
After program/erase command is issued, auto program/erase
algorithms which program/erase and verify the specified page
or sector/block locations will be executed. Program command is
executed on byte basis, or page (256 bytes) basis, or word basis.
Erase command is executed on sector (4K-byte), or block (64K-byte),
or whole chip basis.
So the minimum write size is one byte.
Prior to this PR, the minimum program size (QSPI_MIN_PROG_SIZE) of
QSPIFBlockDevice was 256 by default and 512 for some targets.
Those values were in fact page sizes, not program sizes.
Here's an explanation:
* Most QSPI flashes can be programmed to a granularity of a
single byte or a few bytes - no need to be a whole page.
This should be the value of QSPI_MIN_PROG_SIZE. Applications
need to align buffer sizes to this granularity when
programming QSPI flashes.
* Each sending of the underlying QSPI program signal requires
destination bytes to be located within the same page.
If a QSPIFBlockDevice::program() call crosses page boundaries,
this function breaks down the operation into multiple chunks,
so it's not a concern for the application.
So this PR changes the default program size to 1 (byte), and
for targets with a 4-byte (1-word) read size it overrides the
program size.
Note: No config is needed for the page size, as it comes from
the SFDP table parsed during initialisation.
Jaeden Amero
Martin Kojtal
Lingkai Dong
giulcioffi
Hari Limaye
Robert Walton
Rajkumar Kanagaraj
rogeryou
George Psimenos
jeromecoutant
Martino Facchin
Hugues Kamba
Harrison Mutai
Ahmet Alincak