Recently, I bought some FTDI breakout boards as USB to serial converter. At first, everything works, but later after a driver update, nothing works any more. After a little bit search, it turns out the chips are actually fake chips (f..k)!
I don’t want to throw away the chips just as that (meanwhile, I’ve placed another order from another seller, let’s cross fingers), so I did a little bit search and then come across this post:
Update for a fake cable
However, the procedure is much simpler:
1. Download the driver from FTDI official website
2. Change the PID in the two INF files to the one you see in the Hardware Properties of the fake chip when connected to the PC
3. Turn off the “Driver Signature Validation” on Windows, restart, install the driver from device manager. And then it’s working as before.
(Sorry, FTDI, I didn’t expect they also make fake copies of the chip which is already at a low price.)
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:
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).