CC2640R2F programming learning experience sharing

Jacktang

CC2640R2F programming learning experience sharing [Copy link]

1. The idea of low power consumption. Many people don't understand this concept. Let's explain this first. If you understand this, many things about BLE will be much clearer.
Low power consumption for people means that lying down saves calories more than walking, and walking saves calories more than running. This is easy to understand, right?
Then switch to the chip. The power consumption of the chip is determined by the crystal oscillator, and the frequency of the crystal oscillator determines the power consumption per unit time.
The crystal oscillator is used to provide timing signals to the processor. In the RISC instruction set, one timing triggers one instruction, so it can be concluded that the frequency of the crystal oscillator is proportional to the power consumption and the processing speed.
Looking back at CC2640R2F, there are 2 crystal oscillators, 1 is 32768HZ, and 2 is 24MHZ, which is multiplied to 48MHz in the chip. Now let's analyze 3 situations:
1. If both crystal oscillators are not working, then the power consumption is very low, the program is in a stopped state, and it will not run.
2. The 32768Hz crystal oscillator works, and the 48MHz does not work. The power consumption is relatively low, but the processing speed is very slow, and it is generally only used for timing.
3. The 24MHz crystal oscillator works, but the 32768Hz crystal oscillator does not work. The power consumption is very high, but the processing speed is very fast.
From the above three conclusions, we extend such an idea. Generally, in our actual application scenarios, we process a program very quickly, and then wait most of the time.
For example, for key scanning, we process 10 instructions at a time to determine whether there is a key, and then wait for 10-40ms (the general key scanning interval), and then scan again. According to the 48MHz crystal oscillator, we calculate that it only takes 20/48000000 seconds to process 20 instructions, which is 0.416uS time to process, and then the waiting time is calculated as 20ms. We actually only spend one ten-thousandth of the time working, and the rest is all waiting. Is this efficiency very low? Others such as ADC (even if the sampling frequency is 1kHz, most of the time is waiting), LCD display (generally 24Hz-60Hz), etc. are similar.
So, can we use 32768Hz for timing, start the 48MHz crystal oscillator to quickly process when the timing time is up, and then switch to 32768Hz to time the arrival of the next task time. In this way, the power consumption can be reduced a lot.
The low-power design of all MCUs is based on this idea. In CC2640R2F, 32768Hz is used for timing, and the 48MHz crystal oscillator is used for full-speed processing. In this working state, TI calls it PM1 or PM2 (the difference between PM1 and PM2 is whether some internal voltages are turned on or not.). The state of the above 1 is called PM3, which means it is completely stopped and can only be restarted by external interrupts (similar to Schmitt triggers). The state of the above 3 is called PM0, which is the full-speed working state.
This is basic low-power knowledge. Whether you use CC2640R2F or not, the idea is the same for all other MCUs.
Second, extending to the BLE protocol stack, why does BLE save power? It also uses this idea. First of all, the power consumption of the RF circuit is generated by the circuit oscillation. You can search for it yourself. I won’t go into details. Both transmission and reception require the circuit oscillation to be turned on. At this time, the power consumption is very large, but in fact, we don’t need to keep transmitting or receiving, right? We can refer to the mode of subway or high-speed rail. Isn’t it easier to understand:
the subway stipulates that there are several stations to stop (in the subway, it is a spatial interval, in BLE, it is a time interval.), only when arriving at the station can passengers get on and off, and the time for getting on and off passengers is fixed (there is also this window time in BLE, and both parties only exchange data within this window time, and they will not wait after the time is exceeded). As long as these parameters are set, the subway can run smoothly: when arriving at the station, passengers get on and off at a scheduled time, and the distance between the two stations runs at full speed, which greatly improves efficiency.
To explain BLE in reverse, it is actually to set a large time interval, and then use a very short time window to exchange data. In this way, in a very small time window, both parties work at full speed to complete the data exchange, and then in a large time interval, both parties rest, achieving the effect of low power consumption.
This large time interval is called the connection interval, and those who work with BLE should be very clear about this parameter. This parameter determines your power consumption. The larger the time interval, the lower the power consumption and the less data that can be exchanged; the shorter the time interval, the higher the power consumption and the more data that can be exchanged.
3. Now that we have understood the basic working conditions of the BLE protocol, we need to clarify how our application (APP) should cooperate with the BLE protocol stack. The following is an analysis of several points that are particularly prone to problems.
1. The CC2640R2F protocol stack has a read and write callback program in the GATT layer, as shown below:

Please remember that these two programs are running within the window time we mentioned earlier, so the main content of these two programs is to pass the content that the host wants to read and save the content that the host wants to write, and finally start a write callback of the application layer (there is no read callback because the data is passed out; write callback, because the new content is written in, it is necessary to notify the application layer through the callback). Many people write programs directly in this sub-function, which directly causes BLE disconnection. This situation is like when we take a train, passing Shangrao and stopping for 5 minutes. At this time, you hear the Shangrao chicken leg being sold. You get off the train and buy a chicken leg, then go back to the train and eat it when the train starts. Who knows that someone bought a chicken leg and ate it directly, and then got on the train after eating. As a result, it took you 6 minutes to eat the chicken leg, and the train left! The process of this program is similar to this. Write a data in, save it, notify the application layer, and then complete the remaining operations (receive the data and return a receipt to the host), and this data interaction ends. If you add a program here, it is like eating chicken legs when getting off the train in Shangrao.
2. Since BLE data only interacts when the connection interval is reached, the processing program you write cannot occupy the CPU for a long time. If you occupy the CPU for a longer time than the connection interval, you will most likely lose the BLE connection. Those friends who like to add a long delay when writing programs should relearn programming thinking. Programs are really not written like this.
3. The repeated entry of CC2640R2F events will cause the system to crash. What does this mean? It means triggering an event and then entering the event. Your program starts the timer of this event first. For example, the next 10ms will continue to trigger this event. Then in the following program, you delay 10ms, that is, you are still in the handler of this event, and the system triggers this event again. This forms a nest and causes a crash. Many people have encountered this, so you should pay attention to it. It is best to restart the timer instruction and put it at the end of this event sub-function.

rgbgirl

Very good, programming ideas are critical