Summary of nRF24L01 MCU communication--you will use it after reading it

In one week, I went from being an illiterate who had never used an STC microcontroller and didn't know what an SPI interface was to making the entire communication process of nRF24L01 completely bug-free. I'm excited and want to brag a little. I want to show off to those who are struggling with this awesome chip. I hope it helps. Enough of the bullshit. To the point:

I understand the basics, which are: 1. Use the 5-wire SPI interface to send data or instructions to the 2401. 2. The chip needs to be configured every time it is powered on. These configuration data are the so-called instructions. 3. After the configuration is completed, you know which mode the chip is in. And know which mode it will switch to. 4. Communication protocol. 5. Observe the phenomenon.

Well, the newbies must be eager to know where the problem is with their programs. The newbies must be eager to know how to configure it to work. The newbies must want to know how the various modes of this chip are connected and how they are converted to each other. Don't worry, I will explain them one by one.

If I were to say what the most important thing is, you would never think it is 4. Communication protocol.　

Why? Do you know what the communication protocol here is used for? Let me give you a simple example. When I first started designing, I wanted to use one module as a sending module to send data every second, and the other module as a receiving module to continuously detect whether the data was received. This is a simple communication protocol, which is our goal. It is our direction. Of course, the real communication protocol will never be as simple as these few sentences. It tells you what role your ideal module should play. Is it receiving? Is it sending? Or sending immediately after receiving. As a development stage, of course, the simpler the protocol, the easier it is to verify its correctness. Without further ado, let's design it according to what I call the "communication protocol".

Let's talk about the sending mode first.

To get to send mode, you have to go through several changes.

First, power on. After powering on, the chip is actually still in powerDown mode, because in order to save power, the chip needs to be powered on or off by software. PowerDown mode is the so-called standby mode. This mode is of course the most power-saving. What else can it do besides saving power? Configuration! The most important configuration. That is, you can send data to it through the SPI port, it can receive it, and it can be correctly written into the specified register. Generally, we can configure it at the beginning of initialization, and the chip is in this mode at this time.

Second, our goal is to configure it so that it can send data and be correctly received by the target device. So the registers involved (of course, the register area that comes with 2401) are:

1@The destination address to be sent. The address is actually virtual, it is like a key and a lock. When you specify an address in the receiving device, only the packets with this address will be received correctly. So the destination address here is the local address in the receiving device. As long as the two addresses are the same during design, there will be no failure to receive.

2@Received address. This name is not very good, a bit misleading. To put it bluntly, it is a local address. In a pure transmitter, it is not necessary because it never receives data~~~It is written here because: there is another thing in the transmission mode, which is the automatic answering function (of course, it can only be enabled through configuration. If it is not configured, it will not automatically answer, and there is no need to know the local address).

3@Speaking of automatic response, let's talk about it first. Generally, we would think, after sending a frame of data, should we wait for the other party to respond with data? The idea is good, but as I said, there is a communication protocol in control. Because here we just want to design it to send all the time regardless of whether the other party receives it. So the automatic response can be left unconfigured, just let it boot by default. But in fact, our communication protocol may be very complicated, and it will definitely not be sending all the time. And, after it sends a frame, it should indeed switch to the receiving mode to wait for the other party to send the response data. Of course, we can manually jump the mode ourselves, but there is an automatic response, that is, when you set the automatic response to turn on, then after it sends a packet of data, the chip will immediately switch to the receiving mode. "There is still one thing I don't understand here, that is, what mode will it become after receiving the response, will it automatically return to the sending mode or stay in the receiving mode. "　

4@If there is an automatic answer, then the automatic resend function is indispensable. Why? First of all, let's understand why there is automatic resend. It is because when it is in the automatic answer mode, it determines whether the last data has been successfully received by the receiver by receiving data. It is like I sent a letter. If you don't reply, I will think that you may not have received the letter, and I need to send it again. That's the reason. The 8-bit automatic resend register is divided into two 4-bit small areas. The upper 4 bits store the resend interval time, which means that a total of 16 different intervals can be set. After this interval, there is still no response before resending again. The lower 4 bits are easy to say, just to store a maximum number of resends. The maximum can be set to 15, that is, if there is still no response after resending 15 times, it will ignore you and will not resend. And an interrupt will be generated. Finally, let's talk about the interrupt part. It should be noted here that when the automatic answer function is disabled, there is no automatic resend, no matter how many times you set the resend. So they affect each other. Also, if the number of retransmissions is set to 0, it is equivalent to disabling automatic retransmissions. Isn't this obvious? Hehe.

5@The most basic configuration, frequency. This chip can not only transmit with a 2.4Ghz carrier, but its bandwidth is 2.4G----2.512G. There are more than 100M bands in between, which can be divided into 2M channels. The value in this register indicates which channel you want to work on. Only devices set to the same frequency can receive it. It is easy to understand. For example, if you set it to 10 channels, then 10*2=20M, that is, the carrier frequency used when sending is 2400+20=2420MHz. Of course, only the receiving device set to 2420M can receive it.

6@Power, data rate. What is this? It turns out that there is also an automatic gain control part in 2401. We can set a suitable power to transmit data. First, it can be beneficial in terms of energy consumption. On the other hand, it is also very important to control the communication distance. For example, I only want to communicate within 2 meters, but the maximum communication distance of 2401 can reach hundreds of meters. Obviously, I need to reduce the transmission power to reduce the communication distance. The optional power values ​​are 0Dbm, -6dBm, -12dBm, and -18dBm. Obviously, 0 is the maximum transmission power here. Try to set it to 0 during development. If the receiver cannot receive data when it is set to 0, then the chip must be broken, and there is no need to consider reducing power consumption to communicate. These four power levels have communication distances from far to near, from tens of meters to a few centimeters. And during the communication process, the power value can be dynamically changed to achieve the best matching effect. What is the data rate? At first, I confused it with the rate of the SPI interface. I thought, how could a 4M microcontroller and chip communicate at such a high rate? In fact, it is not. This rate is the bit rate of the data added to the carrier. There are two optional values, 1Mb/s and 2Mb/s. That is to say, how many high and low levels can be sent out in 1 second.

After the above configuration commands, you can switch to the sending mode through simple instructions. Let's take a look at the configuration pseudo instructions:

1. sendCommand(TxAddress_5) . Because the address is optional from 3 to 5 bytes, a 5-byte address is selected here

2. sendCommand(LocalAddress_5), if you want to enable auto-response, the local address must be the same as the transmitting address, that is, LocalAddress==TxAddress. If it is not enabled, they do not need to be equal.

3. sendCommand(EnableAutoAck_0), because the chip has 6 channels, which can work and receive different data at the same time, so the automatic response here also has corresponding 6 bits to control separately. Here only channel 0 is allowed to automatically respond.

4. sendCommand(EnableAutoTransmit) . As long as the above sentence is configured to have automatic response, this sentence will take effect. That is, automatic retransmission.

5. sendCommand(RF_CH). This sentence sets the transmission frequency, that is, sets the channel. Generally, the default is channel 0, which is the 2.4G carrier.

6.sendCommand(RF_Power). Set the transmission rate and the transmission power to 0dBM.

The above are the necessary configurations for the transmit mode. If you are not involved in receiving, you can now turn to the transmit mode.

7.sendCommand(Config); Set the power-on control bit in the config register, powerup=1, to switch to idle mode, and config^0=0 to switch to transmit mode.

8.sendCommand(TxBuffer); Fill the send data into the buffer.

8.CE=1; This is a pin used to control the jump from idle mode to transmit or receive mode. It is not enough to just set the corresponding bit to transmit or receive mode. The chip now only needs the east wind, that is, CE=1 and keep it for at least 10us. Then it will start sending data.