Implementation analysis of 1325_FreeRTOS queue sending function

All learning summary: GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.

I saw the creation function of the queue earlier, and today I will analyze the implementation of the sending function of the queue.

First of all, you need to know that, like the previous creation interface, this sending interface is actually a macro-defined wrapper implementation.And the general sending interface used by the packaging, one of the parameters in this is where to send to the queue.From this point of view, the general method is actually the orderly sending of the queue, first in first out, so the newly sent information is sent to the end of the queue.

The first part of the function is to judge some conditions.First, the queue must be valid, and the equivalent is actually the success of allocating storage space to the queue.Second, if the size of the data object passed in by the queue is not 0, then the address of the incoming object cannot be NULL.Third, only when the length of the queue is 1, the copy position will be an overwrite operation.Fourth, if you need to control the sending of the queue to wait for a valid tick value, you must ensure that the scheduler is running normally.The scheduler has three states: not started, suspended, and running normally.

Data copying is actually a very simple action, which is mainly processed from the perspective of queue element insertion position (before or after), whether to overwrite writing, etc.The core action is a memcpy.Regarding the application of the return value, it does not actually take effect in my current configuration. This feature is mainly used for mutexes.In general queuing applications, scheduling control triggered by priority will not be involved.

For the time being, let's analyze according to the actual design of the current system, then skip this paragraph first.

It can be seen from this that the mechanism of queue triggering tasks is still very efficient.This does not depend on interrupt information such as tick, but carries a possible task scheduling switch request in the send action.If the priority of the task is high enough, it can be activated directly.

Regarding the processing when the queue is full, there are two cases: direct error reporting and waiting.The latter's system tolerance seems to be stronger.

When the queue is full, the processing of the queue is performed according to whether the time expires.The processing is actually divided into two states of sending and receiving. In this process, it is necessary to consider the impact of interruptions, which will change the content of the queue. The logical level of this processing needs to be considered carefully.There may be many attempts in the entire sending process, and the final exit is success or failure.

In fact, there are not many effective parts of processing in this section, mainly dealing with data transmission in the process of queue locking.

The same processing concept, there should also be a processing process on the received data.From here, we can actually have a certain understanding of the infinite loop design of the sending interface, because such data changes may be a dynamic mode.This is very interesting and reminds me of a "dynamic clearing" argument.

The above is probably the implementation of queue transmission, mainly the information processing of the borrowed linked list and the delayed linked list, with the addition of data handling in the middle.