background introduction
The following scenarios exist in embedded driver development:
Multiple tasks have the requirement to use the serial port to send data, or multiple tasks have the requirement to access EEPROM data. The following takes serial port data transmission as an example to expand the discussion.
There are generally three options for serial port transmission:
DMA solution: use DMA to send, and you must check whether the DMA is free before sending each time; however, some tasks have strict execution cycles, and you cannot just block and wait for the DMA to be free.
Interrupt scheme: use sending interrupt, check whether there is unsent data in the sending buffer in each serial port sending interrupt, if it exists, continue sending in the interrupt; this scheme needs to establish a sending buffer, and a set of sending buffer management mechanism; the disadvantage of this scheme is that there are too many interrupts, and the efficiency is much lower than DMA; the advantage is: as long as there is space in the buffer, you can directly start sending, regardless of whether the current serial port is idle;
Blocking scheme: Send data one by one, and check whether the serial port is idle before sending a byte; this scheme has few application scenarios, mainly because the efficiency is too low.
Multitasking Resource Management Solution
When there are multiple tasks that need to send data through the serial port, there are generally the following resource management schemes: Mutual exclusion
lock scheme: Add a mutex lock before and after the serial port sends data, so that when a certain task A is operating the resource, even if it is a high-priority task, in order to obtain the right to use the resource, it must wait for task A to release the resource.
Turn off the scheduling plan or turn off the interrupt plan: turn off the interrupt or turn off the scheduling before the resource is used, and then turn it on after use; so that once a task A acquires the resource, because the interrupt/scheduling is turned off, the task will not be interrupted by other tasks until it releases the resource.
Message reference scheme: build a special resource access task B, and any other task that wants to access the resource must send a message to task B, and the message sent is just a reference of the message, that is, a pointer is sent.
Message direct transmission scheme: Same as the message reference scheme, a dedicated resource access task is built. The difference is that the message transmitted in this scheme is not a pointer, but a data copy, that is, a complete copy of the message to be transmitted is sent directly.
program evaluation
Compared with the off-scheduling/off-interruption scheme, the mutex scheme has the problem of longer release lock time, while the off-interruption/off-scheduling scheme has the problem that high-priority tasks cannot be executed immediately; these two schemes have a common advantage: any task can directly send data without restriction, without worrying about resource competition; but this advantage is also a disadvantage:
On the one hand, the cohesion level of related modules is relatively low, and they are cohesive only because they need to complete a group of logically related transactions, which is logical cohesion; once there is a problem in sending, multiple modules are involved, and it is relatively troublesome to troubleshoot;
On the other hand, there are tasks that are blocked due to DMA busy, or the sending buffer is full.
The message reference and message direct transmission schemes solve the problems of low module cohesion level and blocking their own tasks in the previous two schemes, but they also have some problems. The problem with message references is that each transfer is just a reference/pointer. On the one hand, the sender must ensure that the sent pointer remains valid (must be static or global), otherwise it may cause a series of problems such as illegal access; on the other hand, there may be such a scenario. When task C sends a message request to send, the content sent is X1.
Of course, we can also use heap operations to solve the problems in the message reference scheme, such as applying for a heap space through malloc and other mechanisms to store temporary message content before sending messages, and then passing the heap address to other tasks through messages, and releasing the heap space through mechanisms such as free after other tasks have processed the message. This is a better solution for common applications. However, there are inherent security risks in heap operations. Some major manufacturers explicitly prohibit the use of heap operations in embedded development. For example, it is said that the US military prohibits the use of dynamic memory allocation in safety-critical embedded avionics codes.
The message direct transmission scheme solves the above-mentioned problems of message quoting because the message is directly copied and transmitted. However, there are also problems in the message direct transmission scheme: the serial port data transmission requirements of each task are basically completely different, that is, the structure size of the transmitted data is inconsistent. Is it necessary to create a corresponding message queue for each task? Obviously it is not realistic, because it consumes too much memory, and the memory of the single-chip microcomputer is already very tight.
Summarize
Which solution to choose needs to be analyzed according to the actual scenario. For example, according to the longest sending frame sending time, to identify the time that a task may be blocked due to waiting for the serial port to be idle, and evaluate whether the time is acceptable. If it is acceptable, you can consider whether to use the mutex solution or the off-scheduling/off-interruption scheme; if the evaluation time is too long for the task and is unacceptable, the mutex scheme and off-scheduling/off-interruption scheme may not be used.
Therefore, various solutions are not good or bad in themselves, and some are only suitable for their specific scenarios. What we need to consider is: whether all scenarios are considered, and then determine the applicable solution according to the scenario.