This issue results from PR #2756.

Problem:
Allowing SPI-transfers for example to receive data in interrupt context could lead to unwanted behavior. Assuming there is an ongoing SPI-transfer and at the same time an external interrupt is triggered by the transceiver. This will lead to two enabled chip selects and undefined behavior on the bus.

Former solution approaches:

1. Ensure that the transceiver is the only device on the bus to guaranty exclusive access to the SPI-bus.
2. Remove all SPI-transfers form the ISR and run them in another thread context.
3. Make sure that an interrupt can only be triggered by the radio during "safe" periods (deactivate interrupt during SPI read/write).
4. Enable only one radio interrupt source at the same time
5. Like 2) but additionally increase the priority of a thread that handles the radios and their IRQs

Criticism of the above proposals:
1)

• This is not the general idea of a bus
• There may be future devices with more than one integrated peripherals on an internal SPI-bus

• Could lead to timing difficulties
• Time critical actions could lead to problems due to slower and unpredictable task switching time spans
• Note: maxACK-timeout is in the range of 700-900us in 2.5Ghz devices (information source?)
• Could introduces additional overhead and task switches

• Could also introduce timing errors
• Can miss deadlines for ACK packets cause it may take too long to re-enable the IRQs

• The ISR-handler would have to decide accordingly to the current driver state
• For some states there are several possible results

• Could introduces additional overhead and task switches
• ?