ce(LOW) in startWrite

[jbliesener]

I have a question about that ce(LOW) in line 689 of RF24.cpp. What is it for?

The state diagram on page 21 of the NRF24L01 datasheet tells us that CE needs to be high to remain in transmit mode. My version of the GettingStarted example freezes in the write method, as neither TX_DS nor MAX_RT come up in the status register, as long as CE is low.

The code works as soon as I comment out line 689.

[TMRh20]

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.

[jbliesener]

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.

[luizrrocha]

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 ?

[TMRh20]

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.

[TMRh20]

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.