Senior engineers teach you how to do the MCU project ideas

For a new engineer who doesn't have much programming experience, how to plan and organize the program is a worthwhile topic. In this article, the author combines his own experience, a brief talk about the programming ideas and steps in the project.

When we are learning a development board, a sample program, or a demo, we will find that this program design is a single peripheral or function, and the function implementation is successful. However, in the actual project design process, the programs that are often required to be designed are very large and complex, and the functions and project requirements of the project may be superb. At this time, in the program design, it is necessary for the MCU to take care of each peripheral at the same time without conflict, and to design the program structure reasonably, so that all the requirements can realize the related functions logically and clearly.

So the program design must have ideas. When we get a project demand, we can't knock the code as soon as we come up. Finally, the program logic written with the jumping thoughts stuns itself and has not yet achieved all the functions. Just like having a drawing before building a high-rise building, there must be a program structure before programming.

The program framework has nothing to do with the underlying layer. It focuses on the implementation and logical relationship of the overall requirements. For example, we refine a specific project requirement into 10 specific tasks, each of which performs some specific functions. Ignore the content of each task first, the 10 tasks and the switching logic between them constitute the program structure of this project.

With the programming framework, the next step is to implement the specific functions of each task. Different parts are written in separate modules. For example, the peripherals write a separate file, and the sensor driver separates a file. All the files are independent of each other. And when troubleshooting the problem, you can directly block a file and locate the problem more quickly.

First, the requirements are split and divided into tasks, each task to achieve the corresponding part of the function, design the switching conditions between tasks. At this point, we don't consider the underlying layer at the moment, just list the logical switching relationship between all tasks and tasks, so that there is a program architecture, and then plan how many specific functions are needed in each task, list a table, or write an empty function. Let go first. After listing the specific functions of each task, we look back at the requirements book, whether all the functions are implemented, and the switching logic between them is very clear.

After the first step is completed, the overall system architecture and logical relationship are clear. Next, we follow the function table of each task listed in the first step to complete the specific function implementation. At this point, don't rush to knock the code and continue planning. We know that for MCUs, usually all the functions are ultimately implemented by calling the underlying implementation. So next we have to plan how many underlying resources we need. According to the task-specific list of functions in the first article, we list an underlying driver table. For example, the function needs to use UART, SPI and other peripheral resources. All peripheral resources are listed as a peripheral table, which is all the peripheral resources that need to be used. If other drivers are needed, such as sensors, LCD, FLASH, etc., all devices list a device driver table.

With the first and second steps from top to bottom, we should already be very clear about how this project requirements book becomes a code implementation. At this point, start writing the program, from the bottom up, layer by layer.

First, the driver corresponding to each peripheral should be written according to the peripheral table. Each peripheral driver is listed with a separate file. After the preparation, the verification function is normal. This step is similar to the development board sample program mentioned at the beginning of this article. If the same peripheral needs to implement several outputs or inputs at the same time, for example, three different IIC outputs are required, then it is normal to start the three-way IIC verification function at the same time, and there will be no interference between each channel.

Every time you write a driver, you must verify the function of each function in the driver. Only if there is no problem at the bottom, can it be packaged.

Because many of the device drivers are based on peripheral drivers, after writing the peripheral drivers, using peripheral-driven functions to implement device drivers, such as FLASH, may be SPI communication, then we must first write well SPI driver file, then call SPI driver file, write FLASH driver file, complete specific function functions, such as FLASH erase, read and write.

Similarly, each device driver is written to test each function.

Perhaps in the project, there are some things that are not related to the underlying, such as some encryption algorithms, complex data processing algorithms, various communication protocols, and so on. You can divide each class into a module, and you must verify the function of each function after writing or porting.

After the driver files are ready, use the driver files, plus the necessary data processing, to complete each specific function in the task.

Again, every function function written is tested. Ensure that the function is implemented normally.

After completing step 6, test each task to see if it can achieve the functions required in the planning.

After completing step 7, the project is basically completed, because each layer is tested, so the whole system will not have much problem, but there may be some errors such as logic or resource conflicts. At this point, the entire system is tested repeatedly according to the functions required by the requirements book to find possible problems and further improve the program.

There are other considerations throughout the design process, such as:

● If you have a lot of interrupts, be sure to set a priority for each interrupt. Identify which priority should be prioritized.

● Two interrupts of the same priority are prohibited from triggering the second interrupt in the first interrupt, and the program will be stuck.

● Use less global variables, and the variables and states necessary for system operation can be placed in the structure. Then only define one structure variable.

● When members of a structure are of different data types, member ordering is very important. Optimizing sorting saves a lot of memory.

● When the structure is a formal parameter, in order to reduce the overhead of the stack space, it is better to set the formal parameters of the structure pointer type.

● You cannot return a pointer to the stack space.

● If the communication receives or sends no hardware FIFO, you can write a software FIFO to avoid packet loss.

● All variables are initialized with specific values, especially local variables.

● Define pointer type variables must be initialized.

● Only use functions or global variables used in this file, you must add static.

● The header file can only be declared and cannot be defined.

● Be sure to add the appropriate comments, most of the time the code doesn't know what to watch.

● Use data structures to store or process data, such as structures, enumerations, linked lists, queues, and more.

After reading these steps, do you think that the programming of complex projects is quite simple, so let's start the process of programming.