cpu/esp8266: Fixes and improvements of esp_wifi netdev driver [backport 2019.01] #10904
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gschorcht
added
Process: release backport
aabadie
added
the
CI: ready for build
Contributor
|
@gschorcht, the branch must be updated on the lastest version of 2019.01-branch, so can you rebase one last time ? thanks |
Since _esp_wifi_recv_cb is not executed in interrupt context but in the context of the `ets` thread, the receive function can be called directly. There is no need for a mutex anymore to synchronize the access to the receive buffer between _esp_wifi_recv_cb and _recv function.
Since _esp_wifi_recv_cb is not executed in interrupt context but in the context of the `ets` thread, it is not necessary to pass the`NETDEV_EVENT_ISR` event first. Instead, the receive function can be called directly which result in much faster handling, a less frame lost rate and more robustness.
Defines a number of lwIP functions that are required as symbols by Espressif's SDK libraries. These functions are only dummies without real functionality. Using these functions instead of real lwIP functions provided with the SDK saves arround 4 kBytes of RAM.
It seems to be more stable and less memory consuming to use auto reconnect policy.
Disconnecting from the AP in the send function if the lwIP packet buffer is exhausted is counterproductive since reconnecting usually fails on heavy network load. A better strategy is to slow down the sending of MAC frames from netif a bit to wait for flushing the buffer in the MAC layer.
It is not necessary to realize timeout handling in send function or to disconnect from AP if lwIP packet buffer is exhausted. Waiting that the frame allocated in lwIP packet buffer is freed by MAC layer led to the complete blockage of send function on heavy network load. Disconnecting from AP is counterproductive since reconnecting usually fails on heavy network load.
The situation where the firmware `lwIP` packet buffer is exhausted is an important indication that the traffic sent to and sent from the esp8266 is more than the esp8266 is able to handle. Therefore, it should be an error message.
Checking by the send function that at least two maximum size Ethernet frames fit in the remaining heap before the LwIP packet buffer is allocated seems to increase stability. This can be caused by the fact that WLAN hardware interrupts allocate additional memory when receiving a frame during the send attempt.
gschorcht
force-pushed
the
esp8266_esp_wifi_netdev_bp
branch
from
d724eef to
fa93fb3
Compare
Contributor
Author
|
@aabadie Rebased |
aabadie
approved these changes
Jan 30, 2019
Contributor
aabadie
left a comment
aabadie
left a comment
There was a problem hiding this comment.
Diff is exactly the same as original PR.
ACK and go!
Contributor
Author
|
Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #10862
Contribution description
This PR increases the performance and the stability of the
esp_wifinetdev driver. These are in detail:Since the
_esp_wifi_recv_cbcallback on frame receiption is not executed in interrupt context but in the context of theetsthread, it is not necessary to pass theNETDEV_EVENT_ISRevent first. Instead, the receive function_recvcan be called directly which leads to a much faster handling, a lower frame lost rate and more robustness.Since
_recvfunction and_esp_wifi_recv_cbare called in a deterministic order, there is no need for a mutex anymore to synchronize the access to the receive buffer between the_esp_wifi_recv_cband therecvfunction.The Espressif SDK includes its own
lwIPversion. SincelwIPis not required for RIOT, thelwIPlibrary from Espressif SDK is not used anymore. To satisfy symbol dependencies of the SDK libraries to thelwIPlibrary, a number of dummy functions are defined without real functionality. Using these dummy functions instead of reallwIPfunctions saves about 4 kbytes of RAM.The auto reconnect mechanism from SDK is used now since it seems to be more stable and less memory consuming.
Removes timeout handling and disconnecting in send function when the lwIP buffer is exhausted. This PR solves problems 2 and 4 in issue cpu/esp8266: Tracking open problems of esp_wifi netdev driver #10861. Waiting that the frame allocated in lwIP packet buffer is freed by MAC layer led to the complete blockage of send function on heavy network load. Disconnecting from AP is counterproductive since reconnecting usually fails on heavy network load.
Human readable disconnect reasons.
Generation of
NETDEV_EVENT_LINK_DOWNandNETDEV_EVENT_LINK_DOWNon disconnect and connect to the AP.Testing procedure
With this PR, the performance of pinging an esp8266 node should be noticeably better than before.
example/gnrc_networkingto at least one ESP8266 node using your AP configuration, e.g.,sudo ping6 fe80::<ESP_IID> -Ieth0 -s1392 -i 0should be stable. The packet loss rate should be 0. This should be also the case, if ping is executed on two nodes or in both directions.Issues/PRs references
This PR solves the problems 2 and 4 as described in #10861. It improves the stability and the performance a lot.