asynchronous radio API

[kkrentz]

The need for an asynchronous radio API was already discussed in #220. The asynchronous radio API I am proposing here is "stripped-down". That is, I delegate many tasks that are currently handled by radio_drivers to the upper-layer MAC protocol, namely:

• frame filtering - this can be done equally fast within ISRs and has the advantage that we can handle the new IEEE 802.15.4-2015 frame format correctly, including things like suppressed sequence numbers.
• the transmission of acknowledgement frames - as we usually want to authenticate acknowledgement frames, we need to send acknowledgements in software anyway
• checksums - this circumvents some problems I faced with CC2538 SoCs. As I started to send acknowledgement frames in software, I figured out that the built-in checksum validation of the CC2538 no longer works. Apparently, transmitting acknowledgement frames corrupts unread validation results. Also, the built-in checksum generation of the CC2538 can not be used in conjunction with the loop mode, which is, e.g., needed to implement CSL's wake-up sequences.
• clear channel assessments - this can be implemented by the MAC protocol via the get_rssi function

So far, I successfully implemented CSL and ContikiMAC on top of this API. Of course, we may need further changes so as to support other MAC protocols and radio modules.

Apart from the asynchronous radio API, this PR also adapts the packetbuf such that it is possible to call packetbuf functions from within ISRs. This now works by changing the variable packetbuf to point to some local memory space and restoring packetbuf before returning.

[simonduq]

Can you make the case for having a separate async driver instead of just adding new async functions, e.g., send_async etc?

[kkrentz]

Well, it may be feasible to enrich the current radio API with async functions, but the necessary integration effort feels like a waste of time if the long-term goal is to move to an asynchronous radio API anyway. Another aspect is that the radio drivers already became quite complex due to adding support for polling. Adding asynchronous functions would probably ultimately turn them into hydras. Of course, we could then think about splitting each radio driver into multiple source files, but this brings us to where we are now.

[simonduq]

But with separate drivers, we'll end up with much duplicate code won't we? Seems likely that both drivers will eventually diverge, with e.g. different assumptions in init functions or different config parameter and what not.

What do async functions do that add complexity to existing, non-async code? I haven't looked at the async code closely yet.

If you're concerned about file size, maybe just having the async functions in a separate file, linked to the main driver, would work?

[joakimeriksson]

I would very much also rather see add-on APIs to the current radio-drivers. Implementing async API and then a few lines of code for any sync-version of these should be very easy and kind of very similar. So I agree with @simonduq here.

[kkrentz]

As you suggested, I have added my new functions to the current radio API.

BTW, I came across a questionable mechanism inside cc2538-rf.c: If some unexpected error interrupt occurs, cc2538-rf.c "rejuvenates" by calling init again. In my experience, the CC2538 radio generates plenty of error interrupts even though everything works flawlessly. Therefore, I ignore error interrupts when operating asynchronously, but retained this mechanism when operating synchronously to avoid breaking anything. As a follow-up task, it may be worthwhile to check if CSMA and TSCH continue to work without this rejuvenation mechanism, too.

[simonduq]

Is there any chance this PR can be split into smaller, easier to handle parts? I see a lot of things here not related to the async radio API