cpu/cc2538: Wait for transmission to complete before returning from send() #5915
Conversation
This file contains 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
PeterKietzmann
added
Type: bug
PeterKietzmann
added
the
CI: ready for build
smlng
approved these changes
Oct 10, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
It seems that the cc2538 is capable of sending frames faster than some other radios are capable of processing them, resulting in high levels of packet loss when fragmentation is used. This PR introduces a non-blocking wait for transmission of each frame to complete before beginning construction of the next, which seems to slow things down enough to be compatible with other radios.
I would like the reviewer to please consider whether a non-blocking wait is most appropriate here, or whether we should use a blocking wait instead. Since #5803 has been merged I believe a non-blocking wait should be okay, since it will only yield to threads with higher priority, and the
cc2538_rfthread should now have higher priority than the network-layer threads. Before #5803, this non-blocking wait would have yielded to the 6lo thread during sending of large multi-fragment packets, allowing 6lo to fill and overflow the message queue before cc2538_rf had a chance to process them (since it is waiting).Fixes(?) #5786 and #5719