Optimization of C language program structure in single chip microcomputer system

In early 2002, I started to write a working program for an IC card prepaid electricity meter. The meter used Philips' 8-bit 51-expanded single-chip microcomputer 87LPC764 , and was required to realize many functions, including display off, load calculation and control, indicator flashing, and query of various parameters of the meter. In short, many time units were required. I used ASM51 to complete the writing of this program at that time, and the size of the program after completion was a little more than 2KB. Later, for various reasons, this program was not really used. It was only used for timing and load calculation on an aging device after some modifications. About a year later, I rewrote the code again.

1 System Improvement

It can be said that the code implemented with ASM51 has no organization at all. Any functions needed are added, making the structure of the program very loose. In fact, this is also the reason why the author finally decided to rewrite the code.

As we all know, 87LPC764 has 4KB Flash ROM, while the author's program size is only a little over 2KB, so the first idea is to use C language as the main development language, which should not lead to insufficient code space. Secondly, considering that there are many modules (or tasks, hereinafter referred to as tasks) that require timing functions, it is necessary to manage these tasks in an orderly manner. The author considers using the time slice polling method, that is, giving each task that requires time management a time interval, and when the time interval is reached, running its code, so as to achieve the purpose of reasonable use of system timer resources. For the 51 system, generally at least one timer can be used for time slice polling. Based on the above ideas, the following data types are constructed.

typedef unsigned char uInt8
typedef struct {
void (*proc)(void); //processing procedure
uInt8 ms_count; //time slice size
} _op_;

After the data structure is defined, the next step is to implement the code, which includes three parts, namely initializing data, refreshing the time slice, and executing when the time comes.

Initialize data.

#define proc_cnt 0x08 //Define the number of processes or tasks
//Task stack initialization
code _op_ Op[proc_cnt]={{ic_check, 10}, {disp_loop, 100}, {calc_power, 150}, {set_led, 2}, …};
//Set the initial value of the time slice
data uInt8 time_val[proc_cnt]={10, 100, 150, 2, …}; Time slice refresh.
void time_int1(void) interrupt 3
{ uInt8 cnt;
Time_Counter:=Time_Unit;
for(cnt=0;cnt { time_val[cnt]--;
}
}

Execution of tasks.

void main(void){
uInt8 cnt;
init(); //Program initialization
interrupt_on(); //Turn on interrupt
do{
for(cnt=0;cnt { if(!time_val[cnt])
{ time_val[cnt]=Op[cnt].ms_count;
Op[cnt].proc();
}
}
}while(1);
}

In the above structure definition, proc cannot have parameters. The communication between tasks can define a parameter memory block and exchange data information through a mechanism, such as defining a global variable. For a small-capacity single-chip system, there are not many tasks that need to be done in this way, and the total task volume will not be too large, so this coordination is not too difficult to handle.

Perhaps everyone has this understanding, that is, in a real-time system, almost all specific tasks have time attributes. Even for processes or tasks that do not require timing, they do not necessarily need to be queried and refreshed all the time. For example, for IC card media detection, it is sufficient to ensure that it is done once per second. Therefore, these tasks can also be included in this structure.

In the above program code, considering the RAM limitation of the single-chip system, the task stack cannot be built in RAM like some real-time OS. The author built the task stack in the code space, so it is impossible to dynamically add tasks when the program is running. Therefore, the task stack is required to be determined when the program is compiled. At the same time, a set of count value flags time_val are defined to record the amount of time when the program is running and refresh it in a timer interrupt. Changing the Time_Unit in the time slice refresh interrupt procedure statement Time_Counter:=Time_Unit; can change the refresh granularity of the system time slice. Generally, this value is determined by the system's minimum time measurement value. [page]

At the same time, from the task execution process, it can be seen that this system structure does not change the nature of its front-end/back-end system, but only effectively manages the back-end logical operation sequence. At the same time, if the task execution process is changed and the tasks with small time slices are guaranteed to be placed in front, such as the following program.

do{
for(cnt=0;cnt if(!time_val[cnt]){
time_val[cnt]=Op[cnt].ms_count;
Op[cnt].proc();
break; //After execution, re-prioritize scheduling
}
}
}while(1);

The system becomes a task scheduling system that prioritizes execution frequency. Of course, this method must be set very carefully, and attention must be paid to the allocation of time slices. If the time slice is too small, it may make it difficult to execute tasks with low execution frequency; and if there are two identical time slices, it is even more dangerous, as it may cause the second task with the same time slice not to be executed. Therefore, the allocation of time slices must be reasonable and ensure its uniqueness.

2 Performance Analysis and Task Splitting

The above two task management methods, the former is scheduled in sequence according to the order of the task stack and the size of the time slice, which is temporarily called flow operation scheduling; and the latter is called frequency priority scheduling. Both methods have their own advantages and disadvantages. The tasks of flow operation scheduling have equal priority, and they will be called in sequence as soon as the time slice arrives. The order and uniqueness of the time slice size are not required; the disadvantage is that it may cause the task with a small time slice, that is, the task that is required to be executed faster, to wait too long. The tasks of frequency priority scheduling are prioritized according to the size of their time slice, that is, the execution frequency. Tasks with a small time slice have a high execution frequency and always have a higher priority, but the allocation of time slices must be coordinated, otherwise it may cause tasks with a low execution frequency to wait for a long time.

It should be noted that both methods may cause some tasks to wait for a long time, and the time set by the time slice cannot be used as the basis for accurate time. According to the requirements or needs of the system, some protection work may even be performed during the execution of the task, such as interrupt shielding, so attention should be paid when planning the task. If a task is more complicated or may have to wait for a long time, the task should be split into smaller tasks, and a long-time task should be divided into multiple short-time tasks to complete its function in a coordinated manner. For example, if the waiting time is long, a timed task can be added. When the timed task arrives, a message flag is sent. If the main process does not detect the message flag, it will return immediately, otherwise it will continue to execute. The following is a sample code. Assuming that the task will wait for a long time, it is now split into two tasks proc1 and proc2 to complete the original work in a coordinated manner. Proc1 is executed once every 100 time units, and proc2 is executed once every 200 time units.

//Define two tasks and add them to the task stack.
code _op_ Op[proc_cnt]={…,{proc1,100},{proc2,200}};
data int time1_Seg; //Define a global flag
//Task implementation
void proc1(void){
if (time1_Seg)
exit;
else
time1_Seg=const_Time1; //If the time is up, restore the initial value and
//then execute the following code.
… //Task actual execution code
}

void proc2(void){
if(time1_Seg)
time1_Seg--;
}

From the above example, we can see that after the tasks are split, they hardly take up too much CPU time, which greatly reduces the waiting time of the tasks and gives the CPU enough time to manage and schedule the tasks. At the same time, the structure and readability of the program are also greatly enhanced.

Conclusion

After rewriting the IC card meter program based on the above ideas and structures, the system's structural performance has been greatly improved. After all the writing is completed, the program code volume is about 3KB. It can be seen that this kind of program construction does not cause a lot of system overhead (most of the overhead is due to the use of C), but simplifies the development. This only requires subdividing the system into a series of tasks, and then adding them to the task stack for compilation. It is very suitable for the development of small-capacity single-chip microcomputer systems, and the author has successfully applied this structure in multiple systems.