In this article, I'll focus on a common mistake made by junior engineers or the unnecessary detours that often occur during development. My goal is to help you avoid these pitfalls, even though my writing might not be perfect. There are many unclear parts in this article, but I hope it still provides some value.
I won’t talk about standard programming practices here. If you want your code to be clean and well-structured, I recommend checking Huawei’s "C Language Programming Specification." Instead, I want to discuss a real-world challenge: how to handle multiple data modules on a microcontroller, similar to multitasking. This situation is common in embedded systems, especially when dealing with devices like electric vehicle charging piles.
Let me share an example. In September, an engineer started working on an electric vehicle AC charging pile. The mechanical design was handled by the company's structure team, while the electronic part involved several modules: a resistive touch screen (RS232), M1 card reader/writer (RS232), energy meter (RS485), voice prompt (SPI), power switch (relay IO), and communication interfaces (RS485, CAN). The development process was tough, with many iterations and changes. By June of the next year, the system was finally set up—but problems arose.
We found that the touch screen couldn’t be used while reading the card, and the voice prompt couldn’t be interrupted or skipped. Everything had to be done step-by-step. If something went wrong, the program would wait, retry, or even backtrack. It was a mess. How could an engineer with over three years of experience end up with such a poorly designed system?
Looking at the code, it was clear that the logic was completely off. The main loop was filled with delays, which are only suitable for lab testing, not real products. The program was written in a linear way, where each operation had to wait for the previous one to finish—like a waterfall of dependencies. This created strong coupling between modules, making the system rigid and hard to maintain.
The key issues were:
1. Overuse of delay functions, which block the CPU and prevent other tasks from running.
2. Strong dependencies between modules, such as waiting for a voice prompt to finish before reading a card.
3. Lack of awareness that a microcontroller is a single-core, single-task device. Each task monopolizes the CPU, so we need to manage events carefully.
To solve these issues, here are some practical suggestions:
1. Break the hardware into independent units. Separate driver functions from application logic, and ensure they have proper parameters and return values. These functions should be portable and reusable across projects.
2. Evaluate all functions based on two metrics: execution time (t) and periodic interval (T). Ideally, t should be much smaller than T to ensure timely processing.
3. Implement a centralized scheduling function that manages all event processing. This function should act like a simple operating system, handling events without relying on any one module being completed first.
4. Use a timer interrupt to manage time-based events. A typical interval might be 10ms, and you should define a time window (TT) that allows all worst-case scenarios to be handled within it.
5. For high-priority tasks, use interrupts. However, keep the interrupt handler short and efficient to avoid blocking the main loop.
By applying these principles, you can create more robust, flexible, and maintainable embedded systems. The key is to think ahead, plan your architecture, and avoid the common traps that junior engineers often fall into.
On-Grid Solar Inverter,On Grid Solar Powersystem,Solar Inverter System,Solar Grid Inverter
JIANGSU BEST ENERGY CO.,LTD , https://www.bestenergy-group.com