On the Embedded Software Design

On the Embedded Software Design

This article No. article 21IC the public "for many years engineers embedded programming experience to share: Another programming" binding written on the basis of their understanding, some pictures and text from the Internet.

Front and back model

Model Introduction

When not using the OS development process, almost all are ultimately embedded program structure consists of a loop can not be stopped, i.e., a common while(1)or for(;;), is expressed by this flow chart:

graph TD stop [End] start [query IO or peripheral status] -> section1 [implementation of the relevant business logic] section1 -> conditionA {exit the infinite loop?} conditionA - YES -> stop conditionA - NO - > section1 start_sub [business logic] -> subconditonA {? execute business logic A} subconditonA {execute business logic A?} - YES -> subsection1 [subfunction A] subconditonA {execute business logic A?} - NO- -> subconditonB {execute business logic B?} subconditonB - YES -> subsection2 [sub-function B] subconditonB - NO -> stop_b [end] interp [triggered interrupts] -> baoliu [to protect the site] baoliu-- > interp2 [execute the interrupt service routine] interp2 -> tuichuzhongduan [quit interrupting] tuichuzhongduan -> huifu [to restore the site]

This process, the software in both states:

  • Is at a logic operation mode when no peripheral or IO request, order and associated logic program execution cycle
  • When an interrupt is triggered interrupts current business processes, execute the interrupt service routine.

The software that is designed around the station design, image representation that is:

This software is designed to lower the device can be based on real-time functionality required to classify, but requires less demanding real-time continuous refresh function as a subroutine execution order in the main loop, and will need to respond quickly to the function as an interrupt function for processing.

Problems

There are several problems with this approach:

  • When the high real work of the task is too large, too long interrupted occupation, the need to refresh the background task can not be up to date, namely the interrupt function too cumbersome, affecting the business logic.
  • Background tasks are executed sequentially, the next task could not be opened before a task can not be completed, which makes the update time for all tasks are the same, the more logic code, the longer the update time, thereby affecting the realization of certain tasks.

Solution

Of course, some of the above problems have a solution, but not quite perfect:

Interrupt bloated problem

The task interrupt task as a function of marker, and the split interrupt task, task only temporary interruption to the operating state flag, such as buttons, etc., for checking the state flag before the execution of each subtask in the main program:


int main()
{
    while (1)
    {
        if (interflag == 1)
        {
            subinterfuncs(); //执行中断子程序
        }
        else
        {
            backgroundfunc1(); //后台任务1
        }
        if (interflag == 2)
        {
            subinterfuncs(); //执行中断子程序
        }
        else
        {
            backgroundfunc2(); //后台任务1
        }
        //后续其他任务等等
    }
    return 0;
}

subinterfuncs()
{
    switch (subinterflag)
    {
    case 1:
        interfunc1(); //中断子任务1
        break;
    case 2:
        interfunc2(); //中断子任务2
        break;
    default:
        break;
    }
    return;
}

This approach solves the problem of bloated interrupt logic, but is only suitable for those trigger-action scenes, for example, to trigger a response action on the screen or other man-machine interface quickly when the button is pressed, but the action and It is not fully implemented, such as displaying "execution" and so on, you can solve the problem of speed of response, but for the need to display the full results of the action scenes still can not be solved on the LCD screen. In this case you can design interactive processes, improve the user experience.

Background bloated problem

Similar to the above solution with the sub-tasks continue to split, split a long time-consuming task, the higher the periodic time-consuming task interspersed with long task, namely the overall execution time in a high cycle time-consuming task high time required to perform multiple tasks. This solution increases the cost of maintenance procedures, and not all tasks can be effectively split, the execution cycle time-sensitive tasks are not fixed, and therefore is not a very effective solution.

Time slice model

Model Introduction

Since the front and back model problems mentioned above on the periodic task, resulting in a time-slice model to solve this problem, time slice model simply is divided adjust the order of execution of tasks through different time, to ensure that the periodic task time meet:

Only you need to perform the procedure in the cycle to the scheduler:

/*--------------------主函数-----------------------*/
void main(void)
{
    SCH_Init();//设置调度器
    SCH_Add_Task(任务函数名,任务调度延迟,任务调度周期);//将任务加入调度器的任务队列
    SCH_Start();//刷新任务队列
    while(1)
    {
        SCH_Dispatch_Tasks();  //执行任务调度器
    }
}
/*-------------------定时中断函数---------------------*/
Void SCH_Update(void)   interrupt
{
    //刷新任务队列
}

Such as task assignment and a period of 100ms 5ms cycle can be achieved by a 5ms timer, which judge should perform the task by cycle count, where similar RTOS task design, the task can be solved in time before and after the Taiwan model requires problem.

Problems

Time slice model problem is obvious:

  • Only after the implementation of a task can execute the next, which means that the current task execution time can not exceed the allocated time segment, if it exceeds the time has not quit, it will be interrupted by the timer interrupt, and the next a task, while the current task is interrupted until the next release, the execution cycle chaos

In this case the only reasonable task splitting, design a good program execution cycle, we can solve this problem.

A common process model

From time-sensitive tasks you can perform all the tasks can be divided into the following three:

  • Type the task in time: when the input comes must respond quickly, such as interface
  • Timing task type: Usually no external input, but more sensitive to the periodic time, for example, data collection
  • Background type task: not sensitive to cyclical time, to be able to refresh periodically, such as logging, status reporting, etc.

These three types of tasks in a timely manner on the type of task to handle interrupts, and give the highest priority interrupt, namely when the task trigger type in time, other tasks must be suspended.

Here there is a priority of the process, if the priority of the task is not a timing in response to the external priority is high, may also be considered when the task execution timing interrupt is enabled, the timing task limited warranty. In short determines the priority according to the actual scene

Timing pattern and background tasks by time slicing, regular type tasks themselves enjoy a separate timer, perform regular tasks when triggered by the timer, turn off the background type tasks while performing regular tasks interrupt, do not respond to external input, when the timing after the completion of the task execution enable interrupts, that task can be interrupted in time type type background task.

Time scheduling background tasks controlled by another timer, interrupt the lowest priority, the implementation process is not interrupted closed-type tasks can be timely and regular type tasks steals, steals the priority depending on the scenario, such as timely task's priority the total height can be closed in a timely interrupted task, open the master interrupt exit. When the timer interrupt scheduled task execution will shut down to avoid a background task to seize the scheduled task.

Guess you like

Origin www.cnblogs.com/RegressionWorldLine/p/11909331.html