A005-Software Structure-From Frontend and Backend to Scheduler

main content:

(1). Front and back end

(2) Event Management

(3). Time-triggered scheduler (time-division multiplexing)

(4). Event-triggered scheduler (state machine)

(5) The upper and lower half mechanisms of interruption

-------------------------------------------------------------------------------------------------------------------------------------

Development environment: AVR Studio 4.19 + avr-toolchain-installer-3.4.1.1195-win32.win32.x86

Chip model: ATmega16

Chip frequency: 8MHz

-------------------------------------------------------------------------------------------------------------------------------------

This article will gradually transition the software structure from a simple front-end and back-end to a scheduler.

-------------------------------------------------------------------------------------------------------------------------------------

1 Overview:

      The simple front-end and back-end structure is shown in the figure above.

      The foreground is interrupt-centered, and the background is CPU-centered.

      Here are three resources involved in the program: interrupts, RAM, and CPU, and an implicit fourth resource: time (what percentage of the CPU time is spent on a certain task).

      Under this structure, the data generated by each task is directly placed in RAM as a global variable and can be used directly by all tasks.

      in:

1. 1ms timing task: update the time count value every 1ms

2. Infrared receiving task: When receiving infrared code at any time (randomly), update the value of infrared receiving data

3. Numerical calculation 01 task: After counting is completed, update the value of calculation result 01

4. Digital tube refresh task: need to read the value of calculation result 01

5. Infrared sending task: need to read the value of the key code. If key 1 is pressed, start infrared sending once.

6. Key scanning task: press a key at any time (randomly) to update the value of the key code

      Such a structure is prone to the following problems:

1. If the number of tasks is large, there will be many task functions queued in the main loop of the background CPU waiting to be executed sequentially, which appears to be crowded.

      We cannot know for sure when a task will be executed, which means we can only roughly estimate how long it will take for a task to be executed.

      Tasks such as key scanning and digital tube refreshing are best performed periodically at stable intervals to ensure the final effect.

2. Tasks can directly call sub-functions of other tasks, which will lead to unclear code structure. The more complex the functions and the more mutual calls, the more troublesome it will be to maintain the code.

      The use of global variables to transfer data and information between tasks will increase the difficulty of such maintenance.

3. Some data may be used by multiple tasks at the same time, which may cause conflicts: Task 1 is using data A, and then the interrupted task 2 interrupts and modifies data A.

      After the program returns to Task 1, the modified data A may cause Task 1 to fail.

     In this regard, we can make the following improvements to address these problems:

1. Use some task scheduling method: time-sharing scheduling, event-triggered scheduling

2. Introduce event management and incorporate some shared data into the event queue for unified storage management

3. Introduce locks for data access

4. Minimize the number of preemptive tasks that can interrupt other tasks

5. Only send and receive data in the interrupt, and put the specific data processing into the background task, such as using the upper and lower half interrupt method

-------------------------------------------------------------------------------------------------------------------------------------

2. Backend CPU time-sharing scheduling tasks

      This step will use time-sharing scheduling to improve the task queue processed by the background CPU. The specific structure is as follows:

      The CPU schedules a task every 1ms until all tasks have been called.

      The general structure is as follows:

      Here, a task queue with a length of 6 is set. The CPU schedules one task in the task queue every 1ms until all 6 elements of the task queue are completely traversed.

      The scheduling cycle is 6ms, that is, each task is scheduled once every 6ms, or one task is scheduled at each moment, and the scheduling cycle is 6 moments.

      If the number of tasks is less than 6, the length of the task queue will not be reduced, because we need to keep the scheduling period of each task fixed.

      This implementation is quite concise and it is clear when the task is scheduled.

       The CPU can also allow each task to have its own cycle:

      (1). Schedule an infrared sending task every 10 moments (usually there will be no side effects if you delay 10ms before starting data sending)

      (2) Schedule a key scan task every 10 moments

      (3). Schedule a digital tube refresh task every 2 moments

      (4) Schedule a numerical calculation task every 1 moment

      This will be implemented using a time-triggered scheduler with the following structure (a task is considered ready once its scheduling period is reached):

-------------------------------------------------------------------------------------------------------------------------------------

3. Foreground time-sharing scheduling tasks

      Since the time value generated by the 1ms timer task is used to schedule tasks, you can also schedule a task directly in the foreground whenever a new time value is generated:

      The CPU does not need to do anything here and can just go to sleep after the task is completed.

      Every time an interrupt occurs, the CPU is awakened, and after the interrupt function is executed and returned, the CPU goes into sleep again.

      In many applications, this is also a good way. The entire system is completely driven by interrupt events, and the CPU is usually silent.

      For situations where there are many tasks and heavy functions, the CPU is generally used to schedule tasks to keep the interrupt light and simple.

      To cope with more interruption events, especially random interruption events.

-------------------------------------------------------------------------------------------------------------------------------------

4. Event/message management

(1 Overview

      The above is the organization of task scheduling, and the below is the organization of RAM data, so that tasks are isolated from each other and no longer use each other's sub-functions and global variables.

Event: The 1ms timer task generates a time value every 1ms, which can be regarded as an event generated every 1ms: a 1ms time-to-event, or a time (time base) update event.

            The key scanning task generates a key code after a key is pressed. We also regard it as an event: a key press event with one parameter (key number and key type).

Message: This article refers to the parameters of an event as a message to distinguish between the event itself and the event parameters.

          Event/message management is referred to as event management.

      In a simple foreground and background structure, events and messages are stored as data directly using global variables.

      Next, we need to put this data in an event queue for unified management, instead of distributing it to each task for individual management.

      The events generated by each task are uniformly handed over to the event queue for storage and management, and they are no longer task-private data.

      Background CPU time-sharing scheduling task mode under event management:

      For example, after the execution of the numerical calculation 01 task, two events will be sent to the event queue: calculation result 01 event (parameter = calculation result) and digital tube refresh event (parameter = calculation result).

      Although these data need to be displayed on the digital tube, the numerical calculation task 01 that generates these data does not call the display function of the digital tube.

      It is not responsible for this and does not care whether the data is used correctly by the digital tube.

      The digital tube refresh task will go to the event queue to query whether the digital tube refresh event is valid.

      If the event is valid, it will take out the parameters corresponding to the digital tube refresh event and send them to the digital tube for display. It does not care which task generates the data.

      In other words, tasks are independent of each other.

      For the application of event management in the front-end and back-end, you can refer to this article "Application of Message Mechanism in Software Design".

(2) Basic structure

The structure of the event queue is as follows:

      The structure of the event queue in the figure contains three pieces of information about the event: the event type (telling us what kind of event this is), the event parameters, and the lock status of the event.

       The event is placed in the type section, and the event message is placed in the data section.

      Corresponding to the following structure:

// Event queue structure (type[7bit], lock[1bit], data[32bit])

typedef struct 

{

    uint8_t type: 7; // Event type, such as digital tube data update: EVENT_SEG_UPDATE

    uint8_t lock: 1; // lock flag

    uint32_t data; // Event parameters, such as digital tube data: 1265214

}T_EVENT_LIST, *pT_EVENT_LIST;

      As for whether the message needs to be locked:

      1. If it is agreed that the event queue will not be accessed in all interrupts, no locking is required.

           At this time, the interrupt is made relatively small and only receives or sends data, and the data processing is completed in a task in the background.

           While a task is accessing the event queue, any interruption that interrupts it will not access the event queue, because there is no need to worry about the data being modified.

      2. If interrupts are allowed to access the event queue, a lock is required.