Use RFM69 without interrupt pin ?

[napo7]

Hi !

I'm making a dimmer, controlled via RFM69.

So, the dimmer must have very precise timings, and so the interrupts must be the shortest possible.

I was wondering if it would be possible to run the RFM in receive mode, without being interrupted when receiving data.
So, the idea would be that interrupts would be dedicated to dimmer control, and then I'll have to poll in the main loop if radio data has arrived ?

Would it be possible ?
I suppose it would need some modifications to the library ?

Regards !

[ChemE]

This absolutely should be possible with some modification to the library.  It is possible that your receiver could miss a packet in a busy network but you don't need interrupts to receive a packet.  You could either poll the radio to see if the FIFO is full (packet received and in there) or else you could run it in automode and periodically check the FIFO and empty it as needed.

[perky]

There's no real reason you can't use nested interrupts, that is an interrupt of a higher priority can interrupt an interrupt routine of lower priority. That way you can get the best timings for your dimmer and still have the radio interrupt driven. Look up 'nested interrupts'.
Mark.
Edit: To give you a hint, if your MCU doesn't have interrupt levels (xmegas for instance do), the rather simplified procedure is this:
When an interrupt happens global interrupts are disabled by the hardware when entering and during the ISR, but the RETI instruction at the end of the ISR will re-enable them again. So in the low level ISR, when you enter it mask all low level interrupts first to stop them responding, and re-enable global interrupts. That will then allow a higher level interrupt to happen. At the end of the low level ISR turn global interrupts off, then unmask your lower level interrupts.

[joelucid]

It is possible that your receiver could miss a packet in a busy network but you don't need interrupts to receive a packet.

The nice thing here is that the rfm69hw will not rx another packet until you've cleared the fifo. So it's not really necessary to copy the data somewhere else. Yes you could lose a packet if you take too long to read the first one. But it won't be from overwriting the previous packet.

Unless you implement a rx queue I see very little good reason to use irqs with the chip. The one good reason is to sleep the mcu while in RX/TX.

[napo7]

Thanks for all your replies.

I'll try to code with both interrupts, and if I fail, I'll revert to the interrupt-less programming for the radio

[perky]

Unless you implement a rx queue I see very little good reason to use irqs with the chip. The one good reason is to sleep the mcu while in RX/TX.

I agree, I don't use interrupts at all from the RFM69. The main code is all state machines that park themselves where nececessary, and the radio stuff is done with normal blocking code. It's entirely possible with that to get real time control over the radio part.

[napo7]

What makes me doubting is this line :

https://github.com/LowPowerLab/RFM69/blob/master/RFM69.cpp#L109

In the driver code, especially in the constructor, an interrupt is set for the IRQ pin.

I agree that I can modify the code to disable this line... but it should be more clean to have a flag on the constructor to enable or disable the interrupt ?

Perhaps I should open an enhancement issue on github...

Perky : second question : if the interrupts is triggered each time the radio receives a packet, this means that if I put a node on sleep because it has nothing to send, I should check the reason that woke it ? In this case, it could be woke-up by all frames received ! Second good reason to disable interrupt !!

Edit : I'm wrong : interrupt would be set only if radio is in "listen mode". But before going to sleep, I'll put radio in sleep mode also !