RF24 library with remote calls about rf24 HOT 19 CLOSED

No worries, I've been kind of watching and waiting to see how this turns out. I don't fully understand all the details, but from what I do understand this looks pretty cool. I would definitely want to look at including it or at very least a reference to it in this library fork. Hope to get a chance to take a closer look and test it out soon.
I'm willing to bet @henrikekblad will be interested in seeing this kind of progress as well.

from rf24.

@mz-fuzzy This project looks really good so far. I haven't had the opportunity to test it out yet fully, but it looks good so far. I like the change you made in simplifying the write functions, and think I'll incorporate something very similar into this fork now that everything is pretty much figured out and stable.

I think adapting it as a standalone library would be best, since it will be difficult to keep things in sync as hardware support etc. expands and things change in this fork, and is a bit beyond the scope of the core RF24 driver. It would also make it easier to try out and use for existing RF24 users, so I'm definitely willing to work with you to ensure compatibility, get it linked in RF24 docs etc.

Anyway, I'm very interested in how this will work with RF24Network and RF24Ethernet. Have you done any testing in regards to response and transfer rates?

from rf24.

@TMRh20 fine this way. I'll try to clean-up and minimize changes to RF24 that are needed for support of remote operation, raise a pull request and the rest I'll keep as a separate project.

I've tried it as a part of RF24Network, seems to work fine, just for now RF24Network has to be adapted to use RF24Frontend calss instead of RF24 (simple mod). This need should be removed by making RF24 methods virtual as a compile option.

For transfer rate measurement I've tried 'transfer' sketch and the result is ~4KB/s with VUsb; performance is definitely affected by remote calls. But so far I have not analyzed much the performance aspect, so there is some space for optimizing I guess.

For RF24Ethernet, I'm following your work, this looks amazing, but not tried to make this running for myself yet. What I was thinking would fit to this is to make an usb network/ethernet adapter with nRF24l01 (for example with RNDIS interface using LUFA library), then no tun or slip (that I see as suboptimal approach) is needed. But an avr controller with usb support would be needed for that.

Next point, as I went through your RF24 lib during adaptations, I think it needs some improvements from code culture point of view:

• declare constants instead of using naked numbers in code - max payload, repeating timeout values etc...
• as you mentioned optimize repeated code sections - in write functions etc...
• ifdefs for different platforms need review, a better structured approach would help, currently RF24_config.h looks ... not that much understandable
• make the library usable for avr without arduino environment
• create one universal and clean makefile usable for RPi, OneWire, avr, ... with possibility to set configuration
  if needed I can hint/contribute for improving some of that.

from rf24.

Well, yeah, I can't really argue against following standards 🍺

You aren't the first to make these kinds of suggestions, so if you plan on working on anything that requires a bit of work and/or discussion, just open an issue for tracking or send me an email. Of course, pull requests are always welcome, but its usually best to discuss or at least be aware of any real significant changes being worked on.

One of the things recently discussed is breaking the config.h file apart into completely separate files for each architecture, and then using the main config file to just detect the different devices as Arduino does it. This is probably one of the next things on my list regarding RF24, but if anybody else wants to work on it, feel free, just let me know please.

Thanks for the compliments on RF24Ethernet, it's made me question my sanity at times, but its a great chance to play around with the uIP stack and networking. I was stuck working some bugs out of that and RF24Network_DEV all weekend, but must my hands on this vUSB code soon.

from rf24.

trying to summarize changes needed in RF24 for RF24Remote implementation:

for VUSB, it's needed to disable timer0 interrupt and to call usbPoll every ~50ms. That means:

• not to use Arduino's delay() (this is not a problem) and not to use millis() (this is a bit problem, but usable solution is there).
• introduce a (protected) property for setting polling function to RF24, and if it's set then it will be called in every RF24's method that is blocking - in a loop that waits for an event. This will be used for usbPoll().

for easier implementation of RF24Remote:

• make some 'private' RF24 methods 'protected'

for better usage of RF24Frontend class, so it can be used in RF24Network, RF24Mesh, RF24Ethernet etc:

• compile RF24 with virtual methods

for most of that changes introduce a compile option so it's there only when needed.

Feel free to comment, if this is fine then I'll post a pull request once changes are ready.

from rf24.

It seems interesting library.
Currently i am finalizing my cryptographic and hash libs(finalizing my hmac
md5 ,sha1 and sha256 optimizations) . But then i will check it out.
On Jan 21, 2015 11:12 AM, "mz-fuzzy" [email protected] wrote:

trying to summarize changes needed in RF24 for RF24Remote implementation:

for VUSB, it's needed to disable timer0 interrupt and to call usbPoll
every ~50ms. That means:

• not to use Arduino's delay() (this is not a problem) and not to use
  millis() (this is a bit problem, but usable solution is there).
• introduce a (protected) property for setting polling function to
  RF24, and if it's set then it will be called in every RF24's method that is
  blocking - in a loop that waits for an event. This will be used for
  usbPoll().

for easier implementation of RF24Remote:

• make some 'private' RF24 methods 'protected'

for better usage of RF24Frontend class, so it can be used in RF24Network,
RF24Mesh, RF24Ethernet etc:

• compile RF24 with virtual methods

for most of that changes introduce a compile option so it's there only
when needed.

Feel free to comment, if this is fine then I'll post a pull request once
changes are ready.

—
Reply to this email directly or view it on GitHub
#63 (comment).

from rf24.

So I finally managed to break away from my own code to test this out, and have mostly been looking at the changes you've made to RF24 in your fork in regards to how they would carry over directly into this fork. The first thing I noticed in testing the RF24 code changes is some sort of timing issues, I suspect it may just be related to the default delays in the setDataRate function vs how the polling is done now, but haven't tested a lot. The issues are more apparent using RPi or Due vs Arduino, but I would need to look at it closer to give some useful info.

In reviewing the RF24 code again, I recall that I previously tried to break out the polling, but it always resulted in bigger code, with no real gain. A couple hundred bytes may not seem like a lot, but regarding ATTiny etc, it can make a difference. My suggestion, after about a year of hit-and-go thought on the subject, is maybe to attempt to break more of the base functions out, but not use them directly in the library, so RF24 can work more like a state machine if needed. I'm assuming then, that vUSB could implement its own state-like functions, to replicate and execute the given commands? Is this workable? Opinions on this?

it's needed to disable timer0 interrupt and to call usbPoll every ~50ms

a: I don't understand why it's needed to disable timer0 interrupt? The vUSB docs indicate that vUSB uses the INT0 vector, while timer0 uses its own (lower priority) overflow vector. Another suggestion might be to look at using interrupts instead of polling for the RF24 module if possible, when transmitting. The state of available and/or tx_ds and max_rt could be made available without having to do an SPI read. This may only save a few us or ms, but when performing multiple reads/writes delays tend to add up very quickly. Again, this would require the vUSB lib to contain custom methods to replicate RF24 functions. Just throwing out possibilities here, I have no idea what the best approach is at this point.

b: Calling usbPoll every 50ms seems awfully slow no? The troubleshooting docs seem to indicate that calling less than every 10ms can cause some sort of issues.

The other changes don't seem too dramatic, but I'm mostly interested in how performance and code size is affected. I usually need to see some code and test it out before committing fully, but this is definitely an interesting project. Hopefully this is somewhat coherent, I'm at the end of a long run coding etc.

from rf24.

Thanks for opinions. My comments on that:

The first thing I noticed in testing the RF24 code changes is some sort of timing issues

Yes, I also experienced something like this, it would be great if you can check that.

A couple hundred bytes may not seem like a lot, but regarding ATTiny etc, it can make a difference.

Definitely agree. For the changes made in my fork, take this just as a dirty hacks for now; final pull request I plan to clean things up and minimize impacts. Also any major changes made for vUSB should be switchable by #ifdefs. By default, impact on the RF24 library size/functionality/speed should be zero. Impacts only when the feature of supporting RF24Remote is switched on by a #define.

break more of the base functions out, but not use them directly in the library, so RF24 can work more like a state machine if needed

well, I also considered this approach. Finally I decided not to propose this due to keep the original RF24 code as it is also for use in RF24Remote and not to deal with radio funcionality much. Not to be than much dependent of RF24 library changes. Not to have issues with timing etc.. in RF24Remote. Keep the radio-related logic inside RF24 lib. This is my preference currently.

I don't understand why it's needed to disable timer0 interrupt?

I don't understand either :-) In theory interrupts should work with vUSB. But I had problems with reliability then. I tried to tune Arduino's ISR, even make it empty, change prescaler values, enable timer0 for code sections where it's needed... but unreliability of vUSB was still there. Also refer to same experience here.

Another suggestion might be to look at using interrupts instead of polling

not quite sure what you mean here... to call usbPoll in avr's ISR? Not possible by design of vUSB. Or you mean to use IRQ pin of nRF24l01?

Calling usbPoll every 50ms seems awfully slow no? The troubleshooting docs seem to indicate that calling less than every 10ms can cause some sort of issues.

okay, it's not called every 50ms, I mentioned this as really usb limit of USB interface. In RF24 it's called every polling loop in blocking methods of RF24 lib and so far it works reliably.

from rf24.

Finally I decided not to propose this due to keep the original RF24 code as it is also for use in RF24Remote and not to deal with radio funcionality much. Not to be than much dependent of RF24 library changes. Not to have issues with timing etc.. in RF24Remote.

Well, this solution :
a: Requires changing the original code
b: Is dependent on RF24 library changes regardless
c: Actually introduces timing issues.

What you want to do can be done without any changes to existing code if using interrupts, or simply by exposing the get_status() function. See here for a simplified example of how to run RF24 using interrupts. There is also an option to mask specific radio IRQs.

As an example, a 16mhz Arduino can easily manage about 45KB/s using the transfer example, so 4KB/s is quite a dramatic hit. Without getting into actual radio functionality, I'm hesitant to say this can be improved to the point of being comparable.

Basically what I'm getting at, is that the add-on should accommodate the core library functionality, not the other way around.

from rf24.

Forgot to mention, I'm having trouble compiling the FrontEnd code on RPi, any ideas where usb.h is or is from? :

g++  -Wall -I. -I../ -I../.. -I../../RF24Remote -I../../RF24Serial -I../../RF24VUsb -D_RF24_FRONTEND pingpair_dyn.cpp ../RF24Frontend.cpp ../../RF24Remote/RF24Remote.cpp ../RF24ComVUsb.cpp ../RF24ComSerial.cpp ../opendevice.c -lusb -o pingpair_dyn
In file included from pingpair_dyn.cpp:18:0:
../RF24ComVUsb.h:4:17: fatal error: usb.h: No such file or directory
compilation terminated.
../RF24ComVUsb.cpp:2:17: fatal error: usb.h: No such file or directory
compilation terminated.
In file included from ../opendevice.c:17:0:
../opendevice.h:25:77: fatal error: usb.h: No such file or directory
compilation terminated.
Makefile:26: recipe for target 'pingpair_dyn' failed
make: *** [pingpair_dyn] Error 1

from rf24.

libusb-dev

from rf24.

ok, I'll explore more in details for the interrupts...

In my opinion and up to what I observed so far, actual speed reached with vUSB has nothing to do with selected design which we are discussing, but rather with vUSB communication and it's limits. So speed tuning trials should go this way rather that digging into radio functionality.

For timing issues I suspect that inperfect replacement for millis can be the reason.

from rf24.

Well, this is just my opinion, but IMHO process is everything when it comes to interacting with real-world devices. I would say that 90% of my development work is refining and testing the (sometimes seeminngly insignificant) process and process flow. The end result in RF24toTUN and RF24Network for example, was the difference between a 5-8KB/s vs 15-20KB/s transfer rate. Writing the functions and layout is always the easiest part.

from rf24.

ok, after considerations I have to admit that it's not a good idea to put it that changes into RF24 lib, at least not for now, I'll handle them in inherited classes. So I'm limiting needed changes to RF24 to:

• make some 'private' RF24 methods 'protected'
• add option to compile RF24 with virtual methods
  Is that fine?

from rf24.

Ok, those changes sound likely to be ok, but without seing code or knowing which methods.

from rf24.

@mz-fuzzy vUSB implementation looks good. I already started to adapt LittleWire in such a way, that the RF24-calls are directly in the library itself, but fortunately I can stop now :-D

Thank you for making us (or at least me) aware of the already finished vUSB implementation.

I ported RF24 to LittleWire a while ago yet it is VERY slow due to the fact that each SPI call is done via vUSB and therefore at around 1 kHz.

To incorporate your (@mz-fuzzy) vUSB class, it would be the best to stick to the RF24 class and only implement the vUSB stuff in another implementation of this class. Currently, we have an Arduino (different µC), a Raspberry Pi and a LittleWire implementation, which are unfortunately not separated enough, yet I'm working on that. Serial looks also good and can be incorporated.

I thought that we can have on interface (maybe an actual C++ interface) and implementations of it in different binary libraries (except Arduino). We also need an abstraction layer for the examples such that we can use the very same examples for all platforms (aside from special initialization). Or we can generate the examples for all other platforms from the Arduino ones automatically (and build automatic tests for it).

These are the things I have currently in mind, yet I do not have a roadmap or release plan or something like that.

from rf24.

@lnxbil or anyone, did you have chance to try RF24 via VUSB and/or Serial already? Any observations concerning functionality/reliability/speed so far?

I have created a new project for that, RF24Remote, where the vUSB/Serial will be separated from RF24, this is in progress.

Concerning code/interface, my intention now is:

• to use current RF24.h as the interface. All public methods should be optionally declared as virtual so it's possible to derive & override (for that, a change to RF24 is needed as announced earlier).
• on avr/backend side, derive a new class from RF24 where adaptations for VUSB/Serial will be implemented. This is now only partially, parts of adaptations are directly in RF24, to do is to remove it from there
• on frontend side, RF24VUsb and RF24Serial will be derived and remote calls will be implemented (actually it's already now)

Other approaches - for example to have a abstract class with interface and derive from that classes with it's implementation, or from other end change the library's interface to RadioHead.... But my focus is now on making VUsb/Serial reliably working, with interface I can adapt in case of any other agreement is in place.

What I plan additionally is to add implementation for avr chips with native USB support, like ATMega32u4. I hope for improved speed there compared to VUSB. I've also recently designed PCBs for rf24 usb sticks with twin nRF24l01 modules, prototype PCBs in production. They should be usable also for RF24Ethernet as discussed here.

from rf24.

just to post a keepalive message:

• separate RF24Remote project brought to a working state
• needed RF24 adaptations minimized and are available here; this is also linked from within RF24Remote repo
• better make files and shared libs
• RF24Frontend class is now derived from RF24, so in applications/other libs it's possible to pass it whereever RF24 class is expected
• feel free to try, follow readme & provide feedback

from rf24.

since there was no discussion on this for some time, closing this ticket. Feel free to open a new one as part of RF24Remote project if you see a need to report an issue or to raise a question.

from rf24.