For more exciting content, please click the blue text above to follow me!
When using the uCOS-II operating system for embedded development, one must accept the new term “task”. From the beginning to the end of the uCOS-II textbook, there is no clear definition of “task”, which leads to confusion about what a task is and how to divide tasks in software.
Today, based on my understanding, I will provide an incomplete definition of “task”: a task is a segment of software that needs to be written to complete a specific function or job. This task can vary in size. I have previously shared some embedded case studies, such as: “Completing Electronic Clock Software on Embedded uCOS-II is So Simple“, “Software Design for Low-Power Electronic Products is Also This Simple (1)“.
Every function in the software we develop does not exist in isolation; there are always various data/instruction interactions between functions. For example, in “Software Development for Xiaodu Speaker Based on Embedded uCOS-II System (1)“, the “Time Task” function void TaskClockTime(void *pdata), although named a time task, also includes functionalities related to voice recognition (the reason for this division is explained within). Of course, the voice recognition part can also be defined as a separate voice recognition task.
What is “Intertask Communication”? Simply put, it is the information exchange between multiple tasks/function modules. Since a program within a device will complete multiple functions, these functions do not exist in isolation; there must be various information exchanges between them, which leads to the occurrence of “communication”.
This information transfer is called intertask communication, and there are two ways to transfer information between tasks:
The first method uses global variables
This method must ensure that each task or interrupt service routine exclusively owns the variable.
The only way to guarantee exclusivity in interrupt services is to disable interrupts.
If two tasks share a variable, the way to ensure that each task exclusively owns that variable can be achieved by disabling interrupts and then re-enabling them, or by using semaphores.(You can refer to the original textbook or I will share more later).
Please note: Tasks can only communicate with interrupt service routines through global variables, and tasks do not know when the global variable is modified by the interrupt service routine unless the interrupt program signals the task using a semaphore or the task continuously queries the variable’s value periodically.
The second method uses message mailboxes or message queues
Software engineers must learn to flexibly apply “message mailboxes” and “message queues”. For detailed content on message mailboxes, refer to the corresponding chapter in the original textbook, or see my previous sharing “Application of Message Mailboxes in Embedded Real-Time Operating System uCOS-II: A Detailed Explanation“.
The biggest difference between the two is that with a message mailbox, after sending a message, the sender must wait for the receiving task to accept it before sending the next message; only one message can be sent at a time.
In contrast, a message queue is completely different from a message mailbox; the sending task can continue to send messages until the queue is full, while the receiving task can receive one message at a time and can also continuously receive until all messages are received. After the receiving task reads one message, the sending task can continue to send as long as the queue is not full. The message queue operates on a first-in, first-out basis, so based on the program framework, the software can choose to use either “mailbox” or “queue”.
——–Author Introduction———————–
Linjiang Xian・DesignExperience Sharing
With over twenty years of deep involvement, dedicated to power research.
Leading product innovation.
In electronic design, experience is abundant.
Seeking solutions for electromagnetic compatibility, writing insights in spare time.
Creating a platform to assist new journeys.
Teaching component knowledge, collaborating on technology research.
Open platform for smooth communication, answering questions and resolving doubts together.
Discussing cutting-edge technology in detail.
Seeking development paths together, building a learning community.
—————————————
Creating is not easy; thank you for your attention, likes, and shares!
Classic articles from the past:
1、What is a CPU, and what are the common CPU brands?。
4、What electrical parameters should be considered when choosing a power supply? Do you understand these?
5、Summary of hardware design experience for low-power electronic products: Is this how you design it too?
2、Software Development for Xiaodu Speaker Based on Embedded uCOS-II System (1)。
3、Classification of Human-Machine Interaction MMI Touch Screen Technology Principles: Which type do you prefer for your product design?。
Since you are here, please give a thumbs up before you leave!~~~