RF24

RF24 copied to clipboard

My master has changes which include a write() bug fix and dynamic timeout adjustment, multi SPI device compatibility, additional printDetails() debugging output (nice improvements BTW), some comment clean ups, a US/internationally friendly default channel, and some minor changes to pingpair for my own local testing. The pingpair changes can be ignored.

The bug fix on write() now monitors the proper radio register. Also included in this code is deadlock timeout logic which dynamically adjusts based on current ARD/ARC hardware configuration.

IMOHO, the bugfix and dynamic timeout adjustment alone is worth the pull.

Cheers,

Thanks, I look forward to checking it out. Have you merged my master in prior to this?

-----Original Message----- From: gcopeland Sent: Wednesday, August 17, 2011 10:47 AM To: [email protected] Subject: [RF24] Bugs fixes and enhancements (#2)

My master has changes which include a write() bug fix and dynamic timeout adjustment, multi SPI device compatibility, additional printDetails() debugging output (nice improvements BTW), some comment clean ups, a US/internationally friendly default channel, and some minor changes to pingpair for my own local testing. The pingpair changes can be ignored.

The bug fix on write() now monitors the proper radio register. Also included in this code is deadlock timeout logic which dynamically adjusts based on current ARD/ARC hardware configuration.

IMOHO, the bugfix and dynamic timeout adjustment alone is worth the pull.

Cheers,

Reply to this email directly or view it on GitHub: https://github.com/maniacbug/RF24/pull/2

Ok, I see now that you did merge the master in.  Yay.  That should make it a little easier.

1. Calculated write() timeouts.  Looks like a good enhancement.  Will certainly fold this in.
2. SPI speed.  As long as it passes the tests, its fine w/ me.
3. Default channel.  Sounds reasonable.  Could you write up something for the docs to explain why it's the best choice?
4. printf_P PA Power. Looks good.  I see you got the hang of how I want to do these.  :)  You can also see that I did want this info, just wanted it printed nicely.

Regarding a bug in 'write()'.  I do not see a bug in write() in the master branch of my repo.  "status = read_register(OBSERVE_TX,&observe_tx,1);" is a perfectly legitimate way of reading the status.  It's that way so that in SERIAL_DEBUG mode I can print out the value of observe_tx, otherwise it's ignored.

There definitely was a bug in the version you had, but you had a pretty old drop.  I had fixed the bug in there already.

For the SPI stuff, it's not clear what is being done here.  What is the user benefit of b76284700d86adb9c928 ?

What about this PR? I'm considering gcopeland version but I think that It should be merged

This PR would be great to merge in, especially the multi SPI support (the commit you called out, @maniacbug).

Currently your RF24 library assumes it’s the only thing using SPI, and that the NRF is the only slaved device. If you have multiple devices that you want to communicate with, your library will likely break because it doesn’t properly reset the SPI configuration before attempting to communicate with the radio (so it’ll get whatever configuration was last set, which’ll be for another device, and may not match the NRF’s spec).

im having issues tx values from imu to map calls i made for servo use, i notice in terminal i got some values being produce by the imu in master but in the terminal window for slave i have a servo and it only moves IF i restart the master terminal and only then it will tx to the rx terminal only one time so this mens i have to keep resetting the window so that i can tx imu value from a array to the slave and by the time that happens im sending old values whos data you cant match to the tx terminal, any clue why or is this fix you made to the write() is the reason why ?