Question: reading data in ISR?

[sh123]

To avoid incoming data loss when main loop cannot immediately read the data I would like to read packet in the ISR and place it in the circular buffer, so that main loop can process it further when ISR completes. It seems to work fine, but Is this scenario supported as there seems to be no such example code in examples?

[jgromes]

Assuming you're not using direct reception mode and referring to SX127x, there is no data loss in that part of the wireless link - the radio has a hardware buffer that stores the data until a packet is complete, so there's no reason to try and read it from ISR. Moreover, you really should be doing that, since reading data will require interrupts - and so you will be forced to service an interrupt routine while inside interrupt routine - that's prone to errors and not supported on a lot of platforms.

Also, as this is not an issue, so I'm convertin this to a discussion.

[jgromes]

1. You can't store multiple packets in the FIFO on SX1278.

2. Then your data rate would be significantly faster than what your system is able to process. In that case, no finite buffer will be sufficiently large. If you're producing data faster, than you can process it, you will run out of space eventually. The cleaner solution here would be using some RTOS, with one task dedicated to just servicing the LoRa module.

SPI transfer does not require interrupts

That is platform-dependent. On ESP32, it might not, on others it might.

[sh123]

So, if FIFO is full with single packet then it will be discarded when second packet arrives, right? Which means that other blocking operations in the main loop, which are longer than the packet length, will cause incoming packet loss, for example, when network re-connection is ongoing or when transferring data to/from network or another module?

Also, it seems that SPI transfers within ISR is not a problem: https://arduino.stackexchange.com/questions/14359/usage-of-spi-inside-an-isr

[jgromes]

I'm not entirely sure what whill be the behavior here to be honest, I've never actually seens such a case. As a rule of thumb, if your main loop is full of blocking operations taht take so long it affects other systems, it might be a sign you should redesign your system.

Also, it seems that SPI transfers within ISR is not a problem

As I said previously, that behavior is platform-dependent, it depends on each platform's implementation of SPI.transfer().

[sh123]

There are few packets arriving continuously as a "burst", I read first packet in the loop() by relying on this flag set in ISR and connect to TCP/IP server to forward it over, it takes a while for connection to be established, at that time second packet arrives and then 3rd, I forward 3rd packet over to TCP/IP server, but second packet is lost and I think that it did not arrive because of some RF issue (interference or low signal or ...).

If packets are queued in ISR then I process that queue after connection is established and nothing is lost. If this long queue will be saturated I can write log line to know that there is software overflow and there is no RF issue.

[jgromes]

Go for it if it's an option for you, but at this point I would probably switch over to RTOS.

This is most likely not something that I would implement, considering SPI in ISR is platform dependent.