This PR enforces that the default_build in a target's definition in
hal/targets.json is set to standard to be included in the version 5
release.
This is being enforced because small builds do not support
multi-threading. This makes the capabilities more consistent across all
boards in the version 5 release.
NOTE: This removes the MOTE_L152RC and the LPC11U68
from the version 5 release list because the 'default_build' for these
targets is currently set to 'small'.
The configuration system uses `mbed_config.h` to export configuration
data, but when this change was made, the documentation was not properly
updated. This commit updates the documentation with the correct
behaviour of the configuration system.
The key 'release' in hal/targets.json is ambiguous. This changes the key
to 'release_versions' to emphasize that the entries should be version
numbers/strings and that it should be an array, not a singular value.
This modifies the behavior of 'mcu_toolchain_matrix' in build_api.py. It
now prints release version support in the matrix. It also defaults to only
showing targets in mbed OS 5. You can still show older release versions by
modifying the 'release_version' parameter of the function.
Previously, the condition for including a target in a release was decided
by a 'release' key being set to 'true' in hal/targets.json. This doesn't
have enough granularity when we release multiple versions of mbed. This PR
changes the 'release' key to an array of strings, where each member is a
version that the target supports. Currently the valid versions are '2' and
'5'.
This PR also adds more robust checking for invalid target configurations
in a release. This is enforced whenever the release list is built from the
data, preventing invalid targets from coming into the release.
Finally, it updates the build_release.py script to use the new api for
fetching release targets.
Make the journal object in cfstore_test_startup static since the call
to FlashJournal_initialize keep a copy of this for future use. This fixes
an intermittent crash start started showing up when optimizations
were set to "-os".
In cmsis_os.h OS_TIMERS is undefined unless the timer thread is
disabled, in which case it is defined to 0. When comparing against
an undefined value, the undefined value will evaluate as if it were
0. Because of this the MAIN_THREAD_ID was always set to 0x1.
This patch fixes that problem by checking if OS_TIMERS is defined
before comparing it to 0.
This problem only effects IAR since it has a different heap/stack
layout. GCC_ARM and ARM have a dedicated stack region so
the presence of a guard word and stack checking does not cause
problems.
This problem manifested on the NRF51_DK in the pull request
https://github.com/mbedmicro/mbed/pull/2211
as a c_strings test failure on floating point. This is because the
guard word of the main stack overlapped with standard library
data used by sprintf and corrupted it.
Move the library files used by both nanostack and client into a common
location. This allows both client and nanostack to be built stand-alone.
The patch moves the following libraries into a common location:
-mbed-client-c
-mbed-client-randlib
-mbed-trace
-nanostack-hal-mbed-cmsis-rtos
-nanostack-libservice
-sal-stack-nanostack-eventloop
And moves the library 'coap-service' from client into nanostack.
Replacing with source code replicated from respective repositories including
mbed-client - TAG mbed-os-5.0-rc1
mbed-client-c - TAG mbed-os-5.0-rc1
mbed-client-classic - TAG mbed-os-5.0-rc2
mbed-client-mbed-tls - TAG mbed-os-5.0-rc1
mbed-client-randlib - TAG mbed-os-5.0-rc1
coap-service - TAG mbed-os-5.0-rc1
Adding CONTRIBUTING.md file explaining how to submit patches for any of the components belonging to FEATURE_CLIENT
Contains same version of libraries as https://github.com/ARMmbed/mbed-os/pull/453
Tagged versions
* mbed-mesh-api mbed-os-5.0-rc1
* mbed-trace mbed-os-5.0-rc1
* nanostack-hal-cmsis-rtos mbed-os-5.0-rc1
* nanostack-interface copied. no remote repository
* nanostack-libservice mbed-os-5.0-rc1
* sal-stack-nanostack mbed-os-5.0-rc1 Binaries generated from v5.0.5
The M3 build is used for both M3 and M4 devices.