nRF24L01 and Interrupts
RS_Jim
Posts: 1,753
Jesse (avsa242) has written an excellent Driver and Demo program for the nRF24. After a bunch of issues with trying to compile the demo program with bst, I got the demo up and running. watching the receiver output in the demo program, the demo program displays the receiver continuously and you only see “valid” data for one line when data is transmitted. The driver has an interrupt enable call that I am not understanding. The data sheet states that the nRF chip default condition enables all interrupts. I would like to use WAITPNE instruction at the beginning of the receive loop so that only the latest transmission is displayed. I don’t have a scope so I can watch the pin while the program is running, so I don’t know if in fact Jesse has disabled interrupts on startup or he is using his function to disable unwanted interrupts. Anyone understand this better than me?
Jim
Jim
Comments
Thanks!
Interrupts aren't something I'd really implemented fully within the driver. I gave the ability to set which events would trigger an interrupt, with the IntMask method, but there's no facility for monitoring whether an interrupt has occurred, via the dedicated IRQ pin. The driver does implement discrete methods for reading the same status bits, though:
PayloadReady(): New RX data ready
PayloadSent(): Data was sent
MaxRetransReached(): TX retransmits reached maximum limit
Each of those can be used to get the current status by calling them with any value other than -1 or 1 (TRUE), or to clear the interrupt, call them with -1 or 1.
I don't explicitly set an enabled interrupt mask in the driver anywhere, so the driver starts up with whatever state the chip was already in (the datasheet shows all three IRQs are enabled by default).
As for monitoring the IRQ line using waitpne/pe instructions, I haven't used it myself, but this is probably the more reliable way to go on the P1 because I realize you could potentially miss an event trying to read the status over SPI.
The datasheet says the IRQ line is active low (0). Are you waiting for this state and not high (1)?
I can try this out in a bit to play along and see if there's a bug somewhere...
Jim
Ohhh, I see. In that case then, unless I'm misunderstanding how your RC system works, I don't think you'd have to use interrupts to achieve this. The nRF24's aren't like the "bare-metal" packet radio transceivers like a CC1101, SX1231, etc. where as long as they receive a signal strong enough, data is received into the FIFO (even if it's just background noise or traffic not intended for it).
With a nRF24, the receive FIFO is only filled with data if:
* A transmitter sent it to a pipe address that your receiver has a matching address to
* The CRC check passes
* The payload length from the transmitter has to match the length the receiver's pipe was set to (unless you're using the DynamicPayload feature?)
So really, it would just depend on validating the payload received from your robot controller. Do you find you're receiving packets even if the transmitter isn't powered on?
This is also PropTool/PST compatible - no preprocessor code.
Jim
I looked at your interrupt code, used you INT_PIN designation and my pin number, copied the line involving the waitPNE , used parts of your setup routine to establish the correct I/O and vola, it worked! This is all done without starting a new cog. I am attaching two log files, one without interrupt control and one with. You can see why I wanted to implement the ISR. These files are from text in OpenOffice and PDF.
Jim
Glad it worked! So, you're just using the waitpxx statements in your main loop somewhere? Typically it'd live in a separate cog so the main cog can be free to do the application-level stuff, but if it works, it works! The way the output is formatted in those attachments...is that the way any of my demos are showing up? They shouldn't be if you're using one of the -PST demos with the Propeller Tool terminal...or if you're using one of the other ones with any ANSI-compatible terminal. If you've modified them purposely that's another thing, though
Cheers
The output capture was using using a terminal program like Minicom. or Teraterm in the VT100 mode. I did not wish to sort out whether the data that I was receiving from the receiver was valid or not. As you can see from the log file(reduced from 64 pages) there are at least 32 reads of invalid information before I get the data I want. Halting the read function until the receiver actually has something to say, saves trying to make some kind of determination as to the validity of the incoming data. The wait until an interrupt makes that all really easy. I probably don’t even need a method to do the pause, just a WAITPNE inline with the fetching code. Thanks for showing how to use the “pipes” as I can use that to easily sort out from which control a command is coming.
Cheers
Jim