There are two EventQueue.h in mbed-os codebase:
events/EventQueue.h
features/FEATURE_BLE/ble/pal/EventQueue.h
By accident, `mbed compile` generates includes.txt with the correct
order of include search paths. This is not the case for the CMake
exporter: targets with FEATURE_BLE enables fail to compile with errors:
mbed-os/features/cellular/framework/AT/ATHandler.h:99:60: error:
'events' has not been declared
Update all places to always include either "events/EventQueue.h"
or "ble/pal/EventQueue.h": to always find the correct header.
Fix the following build warning seen with GCC
Compile [ 51.2%]: thread_bootstrap.c
[Warning] thread_extension.h@88,44: statement with no effect [-Wunused-value]
Fix the following build warning seen when building with GCC
Compile [ 54.2%]: icmpv6.c
[Warning] icmpv6.c@1091,16: this statement may fall through [-Wimplicit-fallthrough=]
Socket network interface tests were failing due to DICONNECTED event
being advertised, where GLOBAL_UP was expected. It turned out that
nanostack receives two events: APPL_EVENT_CONNECT and
APPL_BACKHAUL_INTERFACE_PHY_UP. The second attempt to connect obviously
returns errors, but it also causes events to be sent out to the
application. The second attempt should not take place in case the
bootstrap is already started.
I also fixed two reports being sent with DISCONNECT status, while they
are actually something else.
Set tasklet parameters before connecting to prevent the parameters to be set to 0.
The tasklet parameters are reset to 0 when wisun_tasklet_connect gets called,
thus those need to be set in the wisun_tasklet_configure_and_connect_to_network
before they are used. This is also done this way in other tasklets.
Fix the following build warning found when building with
ARMC6 toolchain for NRF52_DK with mbed cli version 1.8.3
[Warning] thread_mle_message_handler.c@762,0: #188-D: enumerated type mixed with another type
[Warning] thread_mle_message_handler.c@834,0: #188-D: enumerated type mixed with another type
This also includes their Datagram counterparts: DTLSSocket and DTLSSocketWrapper.
Coverage missing for timer-related functionality, but this would require more advanced stub development.
The extra (d)tls_test_config.h is necessary for successful compilation without HW support for the mbedtls features in unittests.
I reused the mbedtls stub found in features/nanostack/coap-service/test/coap-service/unittest/stub/mbedtls_stub.c and amended it slightly with a few missing functions.
To get Wi-Sun mesh network working, also nanostack with Wi-Sun support
is needed. ws_empty_functions.c and ws_management_api.h are temporary
included here, so that wisun_tasklet will compiled without problems.
They will replaced with the official versions with next nanostack release.
mbed.h has 'using namespace mbed;', hence some of the files skip
adding required namespace to the code, it is always good to specify the
namespace around the elements in header and `using namespace` in
specific CPP files, instead of all
mbed.h was added in test, via greentea and utest header files. 'mbed.h' is removed
from header files and required header file and namespace is added to CPP/C files
Static Thread methods and signal methods have been deprecated. Remove
all references in the main code, and most of the tests. Some tests of
the deprecated APIs themselves remain.
TB_SENSE_12 would have been left behind by the changes in #7778. This commit implements the changes in mbed to allow targets to provide a default network interface for Silicon Labs targets.
Added check for valid interface ID to network scan timer start so that it
is not triggered after disconnect. Added variable for mac api so that it
is not tried to set again after re-connecting.
Removed main tasklet ID and used instead tasklet id. Added check
for valid interface ID to network scan timer start so that it
is not triggered after disconnect. Added small delay to re-connect
so that stack has time to send its status events to application
after disconnect.
Nanostack object constructor didn't actually initialise Nanostack.
Nanostack initialisation was deferred until an interface was actually
attached to the stack, which generally happened at first interface
connect.
Not normally a problem, unless you're trying to make direct Nanostack
setup calls prior to connect - some applications do this, and were
relying on ThreadInterface::initialise to do Nanostack
initialisation.
Unfortunately in 5.9 ThreadInterface::initialise no longer does
initialise Nanostack immediately, because the mesh interfaces were
aligned and integrated with the Ethernet interfaces, which did
initialisation on connect().
Make the Nanostack object constructor initialise Nanostack (as the LWIP
constructor does for lwIP), so calling Nanostack::get_instance() is the
5.9 API for Nanostack initialisation.
For future work, APIs like ns_file_system_set_root_path should be
exposed as methods of Nanostack, so everything happens with a single
Nanostack::get_instance().file_system_set_root_path().
Previously get_mac_address on a ThreadInterface returned the EUI-64
reported by the radio driver. This was required for commissioning, but
was inconsistent with other interfaces, and the API concept.
5.9.0 inadvertently changed this so that get_mac_address returned the
actual MAC address used by the radio, which is a hash result of the
EUI-64 for Thread.
The original "return the EUI-64" form was somewhat faulty, as
get_mac_address would not return the EUI-64 set by set_device_eui64() or
another mechanism before connect() was called.
Rather than revert to old behaviour, add a new API to get the device
EUI-64 to ThreadInterface, alongside the existing set API.