Open basilfx opened 12 years ago
Thanks for the patch! This makes a lot of sense. It's good to get update() working under interrupts. I took a quick look at the code, and it looks great. Will merge it in after I get a chance to try it myself. It would be super useful to have an EXAMPLE of using this, like helloworld_irq_rx.
Thought after some more thought, I am a bit worried that running update() under IRQ context is unsafe. An update() call can result in a call to write(uint16_t), which can cause significant changes to radio state. Have you tried it with a relay node running under interrupt?
I kind of think that making RF24Network really work right under interrupts, the IRQ should JUST take the packet off the wire and put it in the frame buffer. The main loop should still do the routing work.
From: Bas Stottelaar reply@reply.github.com To: maniacbug maniacbug@ymail.com Sent: Monday, April 2, 2012 11:20 AM Subject: [RF24Network] Modified update() to use in combination with interrupts and modified RF24::whatHappened() (#4)
This is the modified update()
method mentioned in https://github.com/maniacbug/RF24/pull/6
The parameter pipe_num
is not really of use, except for debugging ;)
Kind regards, BasilFX
You can merge this Pull Request by running:
git pull https://github.com/basilfx/RF24Network master
Or you can view, comment on it, or merge it online at:
https://github.com/maniacbug/RF24Network/pull/4
-- Commit Summary --
-- File Changes --
M RF24Network.cpp (83) M RF24Network.h (16)
-- Patch Links --
https://github.com/maniacbug/RF24Network/pull/4.patch https://github.com/maniacbug/RF24Network/pull/4.diff
Reply to this email directly or view it on GitHub: https://github.com/maniacbug/RF24Network/pull/4
I will try to modify the example, but currently, I have tested this approach in my meshping-merged-into-FreeRTOS project only. So far, it works without problems, but I haven't tested higher data rates and more than three nodes.
update()
might be context unsafe, but in my FreeRTOS project, I use a mutex to gain exclusive access to the radio and I still have another task (the sort-of main loop) to handle the packet queue, but it only requires access to the radio if it wants to reply instead of full access to update everything. Also, if you run RF24::whatHappened()
inside the interrupt routine (assume a non-RTOS project), it still would write to the radio to read the status. So indeed, the IRQ should only take the packet off if you do not have exclusive access to the radio.
I am VERY interested in this - I have put together a home control system using RF24 Network - that is, nodes can read and write digital and analog - and can read temperatures. A central node (0) polls active units in rotation, stores their state and updates them from the rules. The problem is - RF24 update is proving to be almost useless... any updates that take any time at all bring the network temporarily to a halt.. as I add more than one unit this compounds - my choices up to now are to add a second 328 chip to handle the radio alone - which is not very desirable - if UPDATE() could be run in the background under interrupts it would make a DRAMATIC difference to what we can do with RF24NETWORK. Do you have an example??
I should clarify - my project is using straightforward Arduino code - not FreeTOS... for anyone to use this I'm guessing we need an example - including setting up interrupts. As this code is the nearest we have to a low-cost network for Arduino you'd be doing everyone a service getting this to work reliably
Did this go anywhere? It would be so good to see this working generally under interrupts, I'm still at a halt with my own project because the software keeps losing packets while I'm doing something else.
Anything happening in here?
8 months later.... I've just tried this - on a typical RFNETWORK installation - it lasts about 2 seconds then falls over - I modified whathappened and the two files here meticulously - and fastened the interrupt to the relevant input on the Arduino.... I could see it work but then some corruption takes over. Shame.
This is the modified
update()
method mentioned in https://github.com/maniacbug/RF24/pull/6The parameter
pipe_num
is not really of use, except for debugging ;)Kind regards, BasilFX