GitLab

Added delay results in better response times. The RPi is just too quick
here.

Removed the wrong rx_flush() on RPi code after testing - caused strange
behaviour in some cases
Corrected failureDetect variable

Introduced a bug by changing payload_size value to a static value of 32
and forgot to revert it. The commit was:

https://github.com/TMRh20/RF24/commit/aac1650646b2c440c8822deb2f99514f4e2e4ddd#diff-6dbdcee25d60de0476cb76000ce10fd3

Discovered due to #12 - Issue submitted by cbolanos79

Seems to be the same as issue 9 affecting Due and RPi. Enabled the 140us
delay on startListening for all boards.

Per issue #5 by sven337
- Add optional failure handling/timeout
- Un-comment #define FAILURE_HANDLING in RF24_config.h to enable
- Add radio.errorDetected variable - indicates if an error/timeout was
detected
example:
if(radio.failureDetected){
delay(1000);
radio.begin();
radio.failureDetected = 0;
radio.openWritingPipe(addresses[1]);
radio.openReadingPipe(1,addresses[0]);
report_failure(); //blink leds, send a message, etc.
}

Additional:
- removed unused wide_band boolean
- remove rx buffer flushes for RPi also

Modified write() to use startFastWrite, then toggle CE after completion
to remove need for a delay on some boards.
Added delay to startWrite for non-Arduino boards.
Removed receive buffer flushes. This prevents an issue in the
RF24Network library, where payloads would be received, but flushed when
a transmission takes place prior to reading.
Should address issues #7 and #11

- Discovered a bug affecting Arduino Due using extended SPI methods, it
seems an extra delay is required before switching to TX mode
- Found the same bug affected the RPi, and removed all delays from
bcm2835 driver, since this bug caused the strange behaviour on RPi

- Modified spi transfernb hopefully for the last time, re #9
- Updated RPi examples to minimize CPU usage
- Updated transfer example for Arduino and RPi to exit TX mode after 4ms
per manufacturer. Improves multicast streaming.
- Bit of a cleanup on RPi examples

- Adjusted spi writes (delay vs no delay)
- Re-enabled buffer flushes on start/stop listening
- Adjusted delay for transfernb()
- Testing indicates that with gettingstarted_call_response example, ack
responses may not be written soon enough if CPU load is high on RPi. eg:
testing indicates this is a limitation of the hardware, not the driver.

- Moved printf.h to root library folder
- Modified printf.h for better compatibility with Arduino Due and Teensy
- Fixed some potential bugs preventing Teensy from working
- Improved Due support and performance
- may help correct issue #7

- moved radio.flush_tx(); to public
- adjusted call_response example to use tx_flush();
- adjusted write_payload, read_payload

- added delays to stop/start listening on RPi
- removed buffer flushes on start/stop listening for RPi
- added modified transfernbd function to BCM library - one has no
delays, also removed one delay period from both by waiting for RX data
- modified transfernb function to stop sending if RX fifo is full
- added delay to stoplistening for arduino etc. (actually seems to
improve performance)
- tests on-par with Arduino performance

- Added _BV define for Due
- adjusted defines

- Adjusted define in RF24_Config.h for teensy
- Teensy doesn't seem to support extended SPI methods, may not perform
as well as on Due
- Currently compiles, but is untested with teensy

- Changed from using reinterpret cast to memcpy for storing pipe0
address

Updated examples to use proper include path

https://github.com/TMRh20/RF24/issues/6

- Added setAddressWidth()  - allows address widths of 3 to 5 bytes
(24,32 or 40 bits)
- Addresses can now be specified via a byte array
- Thanks to Zephyrr for suggestion

Since RPi behaves more like a PC than Arduino, users should be able to
execute various programs without powering down the radio module, where
an Arduino needs to be re-programmed between code changes, so a full
power-down is not such a dramatic step.

Thanks to sej7278 (GitHub) see:
https://github.com/TMRh20/RF24Network/issues/2

Makefile fixes

Restore closeReadingPipe merge for mysensors

Restore closeReadingPipe to be compatible with mysensors

- Enabled use of hardware CS1 pin
- Removed custom_cs code for software driven CSN
- Modified BCM driver to allow use of hardware SPI pins not in use while
SPI is active.
- Updated constructor in examples

Added support for hardware SPI on RPI per jscrane fork:
- Fixed a few bugs with single SPI transfers
- Aligned with optimized RF24 library fork
- Updated bmc2835 files per
http://www.airspayce.com/mikem/bcm2835/index.html
- Merged bcm files with changes from
https://github.com/farconada/RF24Network
- Added example files
- Added setup info to readme

- fixed mistake with changes to setPALevel prior to pushing

- Using status register is faster to read TX FIFO status - Zephyrr (GitHub)
- Fixed typo on FLUSH_RX cmd
- Added support for pwr levels on SI24R1 chips with smaller code

- Updated some example files and tests
- Small changes to minimize code size

For nRF24L01+ to go from power down mode to TX or RX mode it must first
pass through stand-by mode.
There must be a delay of Tpd2stby (see Table 16.) after the nRF24L01+
leaves power down mode before
the CEis set high.

5ms is the maximum defined in the v1.0 datasheet

- Added new function: enableDynamicAck()  to enable single-write NOACK
payloads (merge closer with gcopeland fork)
- Added single NOACK writes for write(), writeFast(), startWrite() and
startFastWrite()
- powerUp() now checks to see if radio is powered on. No delay if
powered up.
- radio must still be powered up manually if powered down manually
- use setRetries function in begin()
- set CE low on powerDown
- updated readme

ATTiny support pulled in from https://github.com/jscrane/RF24
- SPI support for ATTiny is included with the library. Do NOT include
SPI.h with tiny.

Pin info etc can be found at:
http://programmablehardware.blogspot.ca/2013/09/rf24-with-attiny84.html

ATTiny 85 Example:
RF24 radio(4,3);    // CE: 4  CS: 3

Merge improved write_payload() and read_payload()  - looks good and passes my testing.