Due to dependencies between the config/target systems, the config
has been modified to preparse the mbed_app.json for overrides.
This means that attributes with dependencies in the targets are
only valid at the application level. A hard error has been
added for these attributes if they are supplied at the library
level.
Modified '_process_config_and_overrides' to update cumulative
attributes based on cumulative overrides found during walking config
files.
This should remove most of the disparity between the config target
cumulative overrides and cumulative attributes set in targets.json.
These cumulative overrides are updated after the global target
instantiation though, which may cause internal build tool state
dependent on cumulative attributes to not correctly reflect all
cumulative overrides.
In tools/config.py, Config now aggregates all cumulative attributes in
target overrides.
{
"target_overrides": {
"K64F": {
"target.features_add": ["UVISOR"],
"target.extra_labels_add": ["UVISOR_SUPPORTED"],
"target.macros_add": ["UVISOR_MACRO"],
"target.device_has_add": ["UVISOR_HAS"]
}
}
}
Note: no action is performed on overrides yet
NetworkStack/NetworkInterface overloads
- Multiple inheritance results in ambiguity
NetworkStack with templated get_stack overload
- get_stack hidden behind protected access prevents template match
- explicit call to NetworkInterface::get_stack does not follow vtable
Solution is to use two overloaded function for
NetworkStack/NetworkInterface, and an overload for a templated type that
supports a static_cast to NetworkStack. This resolves the ambiguity
without being blocked by protected access.
Moved duplicated overloads out to overload of common nsapi_create_stack
function.
Mostly reduced code duplication for NetworkInterface/NetworkStack
arguments.
Moved to templated Socket constructors/open member functions. This
allows multiple inheritance to be used for classes that provide
both a NetworkInterface and NetworkStack, such as the esp8266.
Provides a primitive structure for explicitly instantiating
network stack structures/vtables.
- Avoids reoccuring issue with non-gced vtables
- Provides thick api layer for additional nsapi features
- Provides more explicit seperation between implementation and user api
Now implementors have two options:
1. Extend NetworkStack and implement all of the abstract member functions
2. Fill out a nsapi_stack_api_t and provide a NetworkStack with nsapi_create_stack
option 1 provides an easy route for porting single drivers such as the
esp8266 or the c027 and can easily benefit from other C++ classes.
option 2 provides an easy route for porting full network-stacks such as
lwip or nanostack, which provide their own host of networking utilities
and only need a minimal socket interface.
typedef void *nsapi_socket_t
Helps avoid confusion with multiple void*s floating around,
especially when passing a nsapi_socket_t by pointer as a
destination.
The nsapi_socket_t is just an opaque handle, implementations
still need a cast to obtain implementation specific socket pointer.
Provides primitive type for network address that is more constrained
than "pointer to array of bytes".
- POD type avoids issues with constructors
- Removes complexity from SocketAddress class
- Easily passed through C interfaces
- Easily casted to SocketAddress and vice-versa
Remove read and write mutexes since multiple calls to send or multiple
calls to recv on different threads is undefined behavior.
This is because the size of data sent or received by these calls is
undefined and could lead to the data being interleaved. The code now
asserts that there are not multiple threads calling send at the same
or calling recv at the same time. Note that calling send and recv from
different threads at the same time is still safe and well defined
behavior.
By removing the read and write mutexes and associated timeout it
guarantees that a stack call will always be made and thus the value
NSAPI_ERROR_TIMEOUT cannot get falsely returned.
This patch consists of:
-Add NetworkInterface to wrap objects bound to a stack and update
socket code to handle this in addition to NetworkStacks
-Update MeshInterface to inherit from NetworkInterface
-Update NanostackInterface so it only inherits from NetworkStack
-Add MeshInterfaceNanostack and update LoWPANNDInterface and
ThreadInterface to inherit from this
Bytes are stored by default, however enough space is allocated in
a SocketAddress to generate the string representation if necessary.
Currently there is no support for shortened addresses
Pros
- Easier to implement
- More similar to SIGIO in BDS sockets
Cons
- Less information, but this information had a high risk of being
faulty/spurious
Pros
- Simplifies interface
- Easier base implementation
Cons
- May need shutdown functionality, in this case shutdown
can be added as another function in the future
Pros
- Allows memory to be statically allocated
- Avoids issues with Thread creation before entering main
- Matches existing APIs such as FunctionPointer and Ticker
Cons
- Does not enforce passing a NetworkInterface
The LF clock initialization is already handled by the SystemInit function.
This code was causing troubles when run on targets with an alternate LF
clock.
Christopher Haster
Sam Grove
Russ Butler
Russ Butler
Vincent Coubard