A common mistake made by junior engineers when developing MCU programs

In this article, I am not going to talk about programming norms. If you want your program files to be at least intuitively beautiful and readable, I recommend looking for Huawei's "C Language Programming Norms". I just want to talk about what we should do when our microcontroller encounters data from multiple modules that need to be processed, similar to "multitasking"?

The background is this: in September last year, an engineer was assigned to work on an AC charging pile for electric vehicles, and the mechanical design part was handled by the company's mechanical structure department. The electronic part of the charging pile is generally divided into X parts (resources used), resistive touch screen (RS232), M1 card reading and writing (RS232), energy meter (RS485), voice prompt (SPI), power switch (relay IO), and communication interface (RS485, CAN).

The engineers were very diligent in the process and encountered many difficulties. They changed many versions and finally set up the charging pile in June this year.

Let's check it out. We found that the touch screen cannot be processed when reading the card, the card reading cannot be processed when playing voice, and the voice playback cannot be interrupted or skipped. In short, all events must be carried out one by one. Once an operation error occurs, it is necessary to execute, wait, or even start over multiple times.

How can an engineer who has worked for more than 3 years make a product like this? Take a look at the program!

It's okay at first glance, but I was shocked! The whole program has no logic, it just goes on in one line...

While(1)

{

//Power on to enter the main program or trigger the touch screen

//Play the prompt voice

Delay(); //Wait for playback to finish

//Read M1 card information

Delay(); //Wait for the card reading data to return

//Play the prompt voice

Delay(); //Wait for playback to finish

//M1 card data interaction, determine the next operation and prompt

Delay(); //Wait for data to be processed

…

…

}

What this means is that this engineer basically has no overall concept of the product he designed, or has no idea what actual effect the program he developed will have when used in the design.

He made several mistakes that we hate the most in program development:

1. Functions such as delay (dead wait) are only used in the process of verifying a certain function in the laboratory. In actual product development, they must not be used in the main while loop, the function it calls, or the interrupt service program.

2. The logical relationship between the various sub-modules of the product design is too strong. For example, you must wait for the broadcast to be completed before reading the card and proceeding to the next step.

We say that only when the logical relationship between each event processing module is weakened in product design can the processing be more flexible. For example: if there are two events A and B, if A is made a necessary condition for B event during program development, the triggering of B event must wait for the occurrence of A event. On the contrary, if A event is treated as a special case of B event processing, then program development becomes much more flexible.

3. It does not take into account that the MCU itself is a single-core single-task architecture. Each event will occupy the CPU core exclusively. When multiple task modules exist at the same time, we should distinguish each event. We should treat them differently according to the situation and the real-time requirements of the event.

So how should we deal with such problems or similar projects?

I have a few suggestions:

1. Divide the hardware system into independent units and make them into low-level driver functions and application functions. The functions should have parameters and return values, and the return value is necessary. How to measure such functions? Such functions are highly portable. As long as there is a .h file and a .c file, they can be put into any project at will. For example: voice playback, M1 card reading, 485 processing, etc.

2. Perform time evaluation on all functions in 1. There are two evaluation points: one is the execution time t of the function, and the other is the periodic time T of the function. The most basic condition is t < T, and the ideal condition should be t << T.

3. Establish a centralized logic processing function, in which the functions in 1 are scheduled. This function plays the role of system scheduling in embedded systems. This scheduling is the scheduling of all event processing in the entire hardware logic. Its purpose is to complete a processing process, but it does not rely on the necessary processing process of any event. In this way, the logical relationship between the events mentioned in question 2 is weakened, and the processing becomes very flexible, so that each relationship is no longer necessary.

4. In order to ensure the normal implementation of the above content, it is also necessary to establish a necessary time management function for the cycles of various events. The basis of the time function is generally completed by an internal timer interrupt. The interrupt cycle is generally considered to be 5-10ms. According to actual needs, N timer interrupts are defined as an event processing cycle TT. This cycle should ensure that all t that may occur in the worst case are processed, and ensure that TT < T.

5. There are exceptions. Some events with high real-time requirements should be completed by interrupts. The processing event of the interrupt processing function should be as short as possible. For time requirements, see 2.