Globally declared C++ classes with vtables are not gced by current
toolchains, even if the C++ class contains no member variables and
no constructor. This causes all of lwip to be dragged into resulting
binaries, even if lwip is not accessed.
Adoption of the SingletonPtr class in lwip allows us to workaround
this issue.
- lwip socket api did not provide signaling mechanism compatible with
mutliple stacks
- lwip raw api did not support multiple threads
The netconn api provides the necessary signalling mechanism while still
supporting multiple threads. The netconn api also shares several design
similarities to the current socket api.
Additionally, the move to a higher-level api reduced implementation
complexity significantly and will hopefully reduce integration
difficulties
* NUCLEO_F746ZG : enable Ethernet and LwIP for this target.
Net tests were passed :
mbed-os-features-feature_ipv4-tests-mbedmicro-net-nist_internet_time_service
| OK
mbed-os-features-feature_ipv4-tests-mbedmicro-net-tcp_client_hello_world
| OK
The 2 other are failing because I cannot test them on my ST computer.
Refactor LWIPInterface so it is a NetworkInterface rather than a
NetworkStack. Rename LWIPInterface to EthernetInterface since it
is no longer a stack. Update tests to use this new name.
- Semaphore returns 0 on timeout, and negative was incorrect used for
errors
- Correctly checked error code on tcp_connect
thanks to @LiyouZhou
fixes#284, fixes#285, fixes#166
per the socket API documentation:
/** Get the local IP address
*
* @return Null-terminated representation of the local IP address
* or null if not yet connected
*/
virtual const char *get_ip_address() = 0;
LWIPInterface incorrectly returned "\0" if unconnected
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
Move the backend of LWIPInterface from the LWIP socket API to the
asynch UDP/TCP APIs used in https://github.com/armmbed/sal-stack-lwip.
Provides asynchronous functionality for the LWIPInterface.
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.
Christopher Haster
Armelle DUBOC
Russ Butler
Sam Grove
Devaraj Ranganna
Martin Kojtal
Bogdan Marinescu