GitLab

Fix compile errors when trying to use any of the three libraries
together - should allow softspi and uartspi to play nicely with the std
SPI library now

- Revert SPI to default lib by default. Configure via RF24_config.h #24
- Corrected CRC status reporting per https://github.com/evorios by
checking AA register

- Added softSPI support for https://github.com/greiman/DigitalIO library
- Updated SPI_UART code to allow use at the same time as the SPI library

Uses the SPI_UART library at https://github.com/TMRh20/Sketches

Per a tip from Andrew A. this should be the final nail in the coffin of
issue #7

http://www.airspayce.com/mikem/bcm2835/bcm2835-1.37.tar.gz

- Merge with latest BCM2835 driver changes
- Should allow full support for RPi B+ but is untested

... not sure why the .h file was left out the first time...

http://www.airspayce.com/mikem/bcm2835/bcm2835-1.37.tar.gz

- Merge with latest BCM2835 driver changes
- Should allow full support for RPi B+ but is untested

Choose a standard pin layout for all the examples based on the pin connection table in the readme files.
Different pin layout in the example files could lead to not working examples.

 - Changes in the pin layout table to describe how to connect the NRF24L01 pins to different boards
 - Remove duplicate readme information in the RPi readme file and point to the default RPi/RF24/readme.md file.

Per a tip from Andrew A. this should be the final nail in the coffin of
issue #7

http://www.airspayce.com/mikem/bcm2835/bcm2835-1.37.tar.gz

- Merge with latest BCM2835 driver changes
- Should allow full support for RPi B+ but is untested

... not sure why the .h file was left out the first time...

http://www.airspayce.com/mikem/bcm2835/bcm2835-1.37.tar.gz

- Merge with latest BCM2835 driver changes
- Should allow full support for RPi B+ but is untested

Select a standard pin layout for the examples and update README files.

Choose a standard pin layout for all the examples based on the pin connection table in the readme files.
Different pin layout in the example files could lead to not working examples.

 - Changes in the pin layout table to describe how to connect the NRF24L01 pins to different boards
 - Remove duplicate readme information in the RPi readme file and point to the default RPi/RF24/readme.md file.

3-pin code enhancement by https://github.com/tong67

ATTiny example updated per https://github.com/tong67 and
https://github.com/Carminepz

All I can say is it compiled in IDE 1.5.7...

Fix "warning: binary constants are a GCC extension".

Change the binary constants to hex.

- Added delay to first call to available()
a: Only delays IF called after startListening AND called less than a
certain time after the last time it was called
- Corrected mistake on last commit where flush_rx was added back
inadvertently

- Add function to check if the rx fifo has been filled and potentially
overloaded
- TX FIFO is now only flushed when transitioning between reading/writing
as start/stopListening() is called IF dynamic payloads are enabled

When using dynamic payload lengths, payloads can be corrupted, and the
length will return 0. This adds a small delay to allow recovery time,
and prevent excessive errors.

- Added ATTiny example per tong67, issue #17
- included print functions in #define MINIMAL per Damme, issue #16
- add #define RF24_TINY for simplification

Previous behaviour:
1. Radio #1: Pipe 0 opened for writing (Address1), pipe 1 opened for
reading (Address2)
2. The radio would end up listening on the following pipes/addresses,
because pipe0 was not assigned a separate reading address.
Pipe0: Address1
Pipe1: Address2
3. This is generally not a problem with 2 radios, but when multicasting
with three. If two of the radios transmit to the same address, then
start listening, all three radios will be listening to the same address
on pipe0, unless pipe0 has been assigned a separate reading address

New behaviour:
1. Radio #1: Pipe 0 opened for writing (Address1), pipe 1 opened for
reading (Address2)
2. When calling radio.startListening() pipe0 is closed, because it is
not assigned a reading address
3. Pipe0 is re-opened for writing only, unless a reading address is
assigned to pipe0

This wouldn't really affect things while using auto-ack, because two
radios should not be writing to the same pipe/address.

- Add closeReadingPipe for RPi
- Also adjusted timing for startListening();
- Fix failure detect variable on RPi

Found issue with dynamic payloads on RPi - writeType was not specified
properly for dynamic ACKs with a NOACK payload set - Identified thanks
to mannkind   - See
https://github.com/TMRh20/RF24Network/commit/6e25453ffabf583c0304b701a3cfcf8f98c9fc94

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