There are new pseudomodules for this driver:
- atwinc15x0_static_connect: Should behave as before, by trying to connect to an AP
by specified WIFI_SSIS and WIFI_PASS
- atwinc15x0_dynamic_connect: takes connection request via NETOPT_CONNECT
and provides the connection result via callback
- atwinc15x0_dynamic_scan: takes network scan requests via NETOPT_SCAN
and provides the scan result as a sorted list via callback
Currently when m2m_wifi_handle_events() fails, we end up in a busy
loop and the netdev thread becomes unusable.
Instead, reset (re-init) the WiFi module if this condition occurs.
While not ideal, it's certainly an improvement to the current situation.
A if `netdev_driver_t::confirm_send()` is provided, it provides the
new netdev API. However, detecting the API at runtime and handling
both API styles comes at a cost. This can be optimized in case only
new or only old style netdevs are in use.
To do so, this adds the pseudo modules `netdev_legacy_api` and
`netdev_new_api`. As right now no netdev actually implements the new
API, all netdevs pull in `netdev_legacy_api`. If `netdev_legacy_api` is
in used but `netdev_new_api` is not, we can safely assume at compile
time that only legacy netdevs are in use. Similar, if only
`netdev_new_api` is used, only support for the new API is needed. Only
when both are in use, run time checks are needed.
This provides two helper function to check for a netif if the
corresponding netdev implements the old or the new API. (With one
being the inverse of the other.) They are suitable for constant folding
when only new or only legacy devices are in use. Consequently, dead
branches should be eliminated by the optimizer.
esp32 vendor code and atwinc15x0 both define conflicting spi_flash_{read, write} functions. esp32 already have build-in WiFi, so it's unlikely to ever use this driver - just blacklist the architecture.
I noticed the wifi module would not receive any router advertisements
while an esp8266 did just fine.
Turns out joining the multicast groups was not enabled.
With this it works as expected.
The expandable GPIO API requires the comparison of structured GPIO types. This means that inline functions must be used instead of direct comparisons. For the migration process, drivers must first be changed so that they use the inline comparison functions.
