Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modified update() to use in combination with interrupts and modified RF24::whatHappened() #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

basilfx
Copy link

@basilfx basilfx commented Apr 2, 2012

This is the modified update() method mentioned in maniacbug/RF24#6

The parameter pipe_num is not really of use, except for debugging ;)

Kind regards,
BasilFX

…n interrupt is triggered when data is received.
@maniacbug
Copy link
Owner

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 maniacbug/RF24#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:

#4

-- Commit Summary --

  • Added a method to only update the network for a specific pipe after an interrupt is triggered when data is received.

-- 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:
#4

@basilfx
Copy link
Author

basilfx commented Apr 2, 2012

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.

@scargill
Copy link

scargill commented Oct 9, 2012

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??

@scargill
Copy link

scargill commented Oct 9, 2012

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

@scargill
Copy link

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.

@scargill
Copy link

Anything happening in here?

@scargill
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants