<p></p>
<blockquote>
<p>Although I like this pattern, I think it would be hard to implement for SPI radios (there's no way to know which event was triggered unless <code>irq_handler</code> was called).</p>
</blockquote>
<p>With ISR above I was referring to whatever code is handling the interrupt request; even if this is deferred from interrupt context to thread context. For users of the API this is an implementation detail; they won't notice a difference if their thread is unblocked from an ISR or anotther thread.</p>
<p>That said: This should often be possible from interrupt context. When switching from TRX_OFF to IDLE, often no other events can occur other than PLL_LOCK_REACHED. And even if other causes of IRQs are possible (but do not need to be attend to), features like the IRQ_MASK of the AT86RF233 are available for most transceivers to filter out interrupt sources not interested in. (But I do not want to imply that this is indeed the way every driver should implement it - that decision is likely best made individually with the specific context of the device and driver in mind.)</p>
<blockquote>
<p>Also, AFAIK some radios (e.g CC2420) don't report PLL_ON (this could be simulate though with a timer).</p>
</blockquote>
<p>That is a pity. But yet again this problem needs to solve in any case: If the API would blocking, users would expect that <code>set_trx_state(IDLE)</code> only returns once the PLL lock is reached. So we would have fall back to either a timer (with a worst case delay) or periodically polling the PLL state, anyway. So I think that the timer (or polling) is in place anyway, we would just turn the code into an async API.</p>
<p>(Note that e.g. <code>xtimer_wait()</code> is internally also build on top of an async API with the callback function unblocking the caller of <code>xtimer_wait()</code>. So the async API would here have less overhead.)</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/pull/13943#issuecomment-628561086">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABE7WYCBTML26JENHZU37WTRRPGBVANCNFSM4MQHPSVA">unsubscribe</a>.<img src="https://github.com/notifications/beacon/ABE7WYGCZVNF6R65X6DIEWLRRPGBVA5CNFSM4MQHPSVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEV3RJPQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/RIOT-OS/RIOT/pull/13943#issuecomment-628561086",
"url": "https://github.com/RIOT-OS/RIOT/pull/13943#issuecomment-628561086",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>