Now the communication is more or less okay.
With ACK with Payload, two way communication can be done without change the role of PRX and PTX.
BUT: with send ACK with Payload length >= 18 bytes. the PRX won’t be able to receive anything. I’m not sure whether it’s a problem in Arduino+NRF24L01(PTX)
or the STM32+NRF24L01(PRX).
31/03/2014: The problem turns out to be with the Arduino Mega board I’m using, when I use Serial.print to print the ACK package out with baudrate == 115200, arduino will halt after a while. I don’t know what’s the cause of this behavior. I decreased the baudrate to 57600 and reduce the data to be printed out, I can receive ACK package with payload length up to 32 bytes. However, I need to test what will happen when the distance increases. Anyway, next step is to design the two-way protocol.
And as for performance, I’m using interrupt on Arduino, but still I need to wait at least 8ms before sending another packet, so that I’m not quite sure this way is much better than the PRX-TX-switch-role solution.
I will try to implement the switch role solution and compare to see the exact results. I’m okay with the performance of the ACK-WITH-PAYLOAD now, I don’t want to spend extract time for implement approach (for now). (Maybe I will try with pcDuino).
01/04/2014: Arduino+nRF24L01 + STM32
The first past for Arduino to retrieve MPU6050 data from STM32 is done.
The C51 board helped me to quickly find the problem in the code for STM32. However, after some consideration, it’s not suitable for the task as remote controller agent connecting to PC (with USB2TTL converter). It has the basic controls over individual PINs and interrupt routines and everything, but effect to be put to make it work with UART and SPI interface together to have a proper communication protocol is just painful (for now), and the documentation and official support for this board/chip (it’s a custom-design board) is not so good. Most of all, the C51 board is difficult to be extended in future. While arduino is much better considering these disadvantages, pity though, the frequency is much lower than the C51 board (8/16 MHz comparing to 42MHz). But the coding should be simpler.
Basic SPI library in Arduino + NRF24L01+ =>
1. Receive data from UART and send through NRF24L01+ (SPI)
2. Receive ACK with Payload, send to UART
3. Interrupt instead of Polling
To achieve two way communication with NRF24L01+ modules, there are basically two ways:
1. Switch the role of PRX and PTX when it’s necessary, delay, idle time etc. need to be managed accordingly (may be tricky when complex and reliable communication protocol is to be implemented).
2. use ACK with PAYLOAD feature with Enhanced ShockBurst.
The drawback with this one is that since PRX won’t know what the ACK Payload should be before the MCU can download and handle the data from PTX, so that the Payload in ACK will be one package after the correct package. However, with proper protocol it could be usable.
Later I will investigate both the solutions and see which is easier to be implemented and which has the better performance regarding the communication speed.
The step for Dynamic Payload for nRF24L01+ module has finished. The communication is done with STM32 and a C51 board. The Dynamic Payload length varies from 1 to 32.
There are still some glitches in the code (could be the UART I’m using now for debugging).
Next step, ACK package with Payload (tried, but not working, could be problem in C51 board, however, the flow for sending ACK with payload is not clear at STM32 end neither).
It’s been a long time since I worked on this.
As recently I got two new USB2Serial converter plus an Android Uno acting like a USB2Serial Converter also (this can be done by connecting RST to GND [credits by someone else on the web, can’t find the source now]), besides I also have two C51 (STC12XXX) boards with working example for nRF24L01, I’m at a good position to start working on nRF24L01 with STM32 board now.
And today, since the example code of the C51 board for nRF24L01 is only for fixed-size payload communication, I’m able to do point to point communication with fixed-size payload using nRF24L01+ on STM32.
The next step would be change the code running on C51 and STM32 to use Dynamic Payload size.
[Previous problem causing nRF24L01+ not working with STM32 is that I made a typo mistake using a wrong register name macro in one of the helper functions]
[The code style is not so good: a lot of registers => a lot of register macro definition (register name, bits in the register, mask etc.). I’m wondering if there’s a better way to do this]