ce(LOW) in startWrite about rf24 HOT 5 CLOSED

Per the datasheet, the CE pin is used to control transmission, and whether or not the radio stays in Standby-II or returns to Standby-I mode:

See section 6.1.5
"The TX mode is an active mode for transmitting packets. To enter this mode, the nRF24L01+ must have
the PWR_UP bit set high, PRIM_RX bit set low, a payload in the TX FIFO and a high pulse on the
CE for more than 10μs.
The nRF24L01+ stays in TX mode until it finishes transmitting a packet. If CE = 0, nRF24L01+ returns to standby-I mode. If CE = 1, the status of the TX FIFO determines the next action."

I would be interested to know whether adding delayMicroseconds(15); before ce(LOW); would make a difference, as well as what board you are using etc., especially if it does make a difference.

from rf24.

Yes, your're right. It was the pulse length. On a Teensy 3.0 with 96 MHz and Paul Stoffregen's optimized digitalWrite function, the sequence ce(HIGH); ce(LOW); gives me an 800 ns pulse. A delayMicroseconds(10); before ce(LOW) sorts this out.

However, in my project I have a requirement that effectively prohibits me to use delay() or delayMicroseconds(). My loop() function needs to terminate in less than 100 microseconds, so, anything that might block needs to implement as a state machine. For RF24, this includes SPI data transfers.

There is a terrific library for handling SPI transfers through DMA on the Teensy3 at https://github.com/crteensy/DmaSpi. I will try to integrate it into your code and I'll let you know about the results.

from rf24.

Hi. I am adapting your library to work with Chipkit's Uno32 and only could make it work by adding the delayMicroseconds(10) to the same spot, as the Chipkit gives a shorter than 10uS pulse with only the ce(HIGH); ce(LOW); pair.

As soon as I finish basic tests how can I send you my modified code ?

from rf24.

Thanks for the extra info. I believe the issue and fix is similar to what I have done on the RPi, being converting the radio.write() to use writeFast, then toggle the CE pin LOW after sending is completed or failed. This should work around the need for a delay. Haven't been able to do much lately, but I will be taking a quick look at it soon. Also code changes can always be submitted via GitHub forks/pull requests.

from rf24.

Ok, I think commit 1d18015 will address the issue.

I've added a delay to startWrite for non-Arduino and Teensy boards, and have modified the standard radio.write() to remove the need for a delay on all boards. It passes all my tests, so hopefully this will do the trick.

*Edit to add: jbliesener You may be best off using startFastWrite(); and just leaving the radio in standby-II mode.

from rf24.