[riot-notifications] [RIOT-OS/RIOT] RDM: The 802.15.4 Radio HAL (#13943)

Peter Kietzmann notifications at github.com
Mon May 18 23:38:12 CEST 2020

Recent discussions were about a synchronous versus asynchronous radio API and its implications. The potentials of an asynchronous API are clear in general, but it would be great if we could quantify this a little. A table with most common 802.15.4 radios and respective (hardware) processing times might help. While send/receive delays are obvious, state transition or PLL synchronization delays are not so obvious (at least not to me). Furthermore, it would be great to name the use cases on which we base our design decision for one or the other approach. Thirdpary stack requirements, multiple radios, single-thread network stacks, ... ? Which case gains performance by which design pattern? What are the costs? This should IMO go to the RDM in the midterm.

Please correct me if I make a mistake here, I'm trying to catch-up and summarize the main points from your discussion. An asynchronous pattern seems to be favored in general and one main focus is on synchronizing device operations. The following seem to be potential solutions:

**Blocking Radio HAL**
- Extend API by a blocking parameter and implement blocking behavior in driver.
- Implementation can either be poll-based or timeout based.
- Seems straight forward to use and no extra logic  is needed on the upper layer.
- Seems similar to current approach, thus, could simplify migration.
- Blows up the API, tends to code duplication (in driver code) and eventually does not exploit full performance potentials.

**Non-Blocking Radio HAL made Blocking**
- Synchronize fully asynchronous API by upper layer (radio HAL user).
- Mutex is locked on operation start and unlocked after a "finish indication", typically signaled by an interrupt.
- Interrupt does not always report a specific event, status needs to be checked and actions (mutex unlock) need to follow consequently.
- The "status check" involves a simple register access (e.g., on a Nordic radio) or a SPI transaction (e.g., on an Atmel radio).
  Where to processes the "status check"?
	- (i) Directly in the interrupt context. This should be avoided in the SPI case to prevent bus corruption or long ISRs, but it potentially exploits all benefits of a memory mapped radio controller.
	- (ii) In an "ISR offload process" (BH processor). This requires a dedicated context (thread) next to the application.

If the above assumptions are valid I am wondering:
- Is it worth to make *all* radio HAL functions asynchronous considering the management overhead discussed above?
- Is it worth to consider two different strategies for peripheral and SPI connected devices?
- Is it harmful to add a dedicated context to offload the ISR?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20200518/6ecbfcd1/attachment.htm>

More information about the notifications mailing list