I took a slightly different approach than you (@authmillenon) did in #1733. I read the received packet already in the interrupt routine (as it was done before with the transceiver module) and afterwards notify the event handling thread. I think this is a better approach than to completely rely on the event handling thread for receiving the packet from the device (we cannot be sure that the event handling thread is the one taking over after the interrupt routine and the packet might get lost).

This is something that should also be discussed with @haukepetersen (and maybe @thomaseichinger) because it looks like it differs from your basic flow description. Nevertheless, I think the slightly longer interrupt routine is justified by the gain of certainty that the packet is read from the device timely.

@fnack how large are the packets / how large is the overhead?

I'm not quite sure, but instinctively I would say that with this kind of implementation you would risk to be easily DoS'd since you basically would never leave the ISR when you are flooded. I think the risk of not being able to respond outweighs the risk of loosing data because the OS was not fast enough. Making sure everything is received that should be is the task of the Link Layer (aka MAC Layer sometimes in our lingo) or the Transport Layer, but should never be the task of the driver (except the SoC offers some kind of congestion/packet loss control, of course, which is not the case for the cc1100 iirc).

+ You also loose data if you are in the ISR too long, because it can't react if it's working.

Why wouldn't it leave the ISR?
If it only reads one packet, and returns to user space then, this should not happen.

Scenario (copy in ISR):
RX -> copy -> RX -> copy -> RX -> copy …
vs. (copy in thread, notified by ISR)
RX -> notify -> co -> RX -> notify -> py -> do st -> RX -> notify -> uff -> copy -> do stuff -> copy -> do stuff.

@fnack I'm undecided on this as different hardware provides different features.

• at86rf2xx provides an option to drop all packets while the one in the RXFIFO isn't read. (not deployed)
• cc2420 has 128 bytes RXFIFO and fills it up. A discussion about the handling was in boards: Fix CC2420 RXFIFO overflow #1304. In either case (read in ISR or not) you can easily DoS this by sending many small packets.

I didn't really look into cc1100's features yet.

@authmillenon

RX -> notify -> co -> RX -> notify -> py -> do st -> RX -> notify -> uff -> copy -> do stuff -> copy -> do stuff

For this to work, at least for the cc2420, you'd have to disable radio interrupts, else, as mentioned above, when firing with minimal sized packets the notified thread could be outperformed by the number of interrupts. (And to assure the received data is valid)

To sum up, in either case we could/will loose data but, although currently implemented differently for rf2xx, I tend to support the notify strategy since in the not "evil" case we can react to other events more promptly.

(And to assure the received data is valid)

To assess that is also the job of an upper layer IMHO.

(And to assure the received data is valid)

To assess that is also the job of an upper layer IMHO.

Also yes, the radio driver should assure to receive valid and complete 15.4 packets.

The cc1100 is not a 15.4 transceiver ;-)

@authmillenon Yes, came to my mind as I pressed the button. As stated above I'm not familiar with this device but shouldn't it still do some CRC checking etc?

Yes, the CC110x does CRC checking.

I thought about it again and in some cases multiple interrupts are preferable/needed to handle packet reception from the device (for example when the packet length exceeds the CCxxxx's RXFIFO). In these cases handling the reception in the link layer thread using notifications with different event-types is probably the better approach. I think I'll adapt my implementation, but nonetheless I'd really like to hear @haukepetersen's opinion on this topic as well.

I have the same opinion: the (time consuming) data transfers should be done in the thread context. This way no other function with time critical operations will be disturbed by this long running interrupt. So the way I would imagine this is:

1. data arrives at the radio device
2. radio triggers external interrupt
3. in the RX ISR: send message to thread
4. thread is woken up/receives message from RX ISR
5. thread runs event(xx) call
6. event call takes care of the data transfer from the radio to the packet buffer

In case there are different events to be handled (receptions of data on multiple FIFOs...), the argument of the event callback can be used to tell the driver what to do.

I'll close this PR in favor of #2237 and because it was based on the old objectives from #2163.