Waterproof Dustproof Scanner,Dustproof Scanner,Waterproof Scanner,Waterproof Dustproof Scanners Guangzhou Winson Information Technology Co., Ltd. , https://www.barcodescanner-2d.com
From the time I first participated in an electronic design competition during university, to now, I've spent several years exploring the world of microcontrollers. Throughout this journey, I've accumulated various experiences and insights that I'd like to share.
When learning about microcontrollers, it's common to get caught up in the application of their various modules—such as serial port communication (RS232, RS485), controlling ICs, motor control via PWM, interrupt handling, timer usage, human-machine interface development, and CAN bus protocols. These are all essential steps in the learning process and form the foundation of embedded systems. Fortunately, my pre-competition training in the Electronic Design Competition gave me a solid understanding of MCU-based control. After that, I found that different MCUs are quite similar, each with its own strengths. It's relatively easy to learn new MCUs, even complex ones. Programming around an MCU typically involves managing peripherals and communication protocols like I²C, SPI, Intel 8080, or M6800. At first glance, programming around an MCU seems simple.
However, this is just the tip of the iceberg in embedded development. Once you work with multiple MCUs, encounter more complex design requirements, or even start using an operating system, you often find yourself returning to bare-metal development. This shift forces you to think about the overall architecture of your program. A well-structured program is a key difference between experienced engineers and beginners.
Here’s a summary of my understanding of the microcontroller program framework and some common development practices:
Time-critical tasks can be our biggest challenge. If necessary, we can increase hardware costs to avoid them. For example, if you want to display eight digital tubes, you must use dynamic scanning without dedicated hardware support. Dynamic scanning can interfere with other tasks. When the MCU is heavily loaded, using a peripheral like MAX8279 could be a better solution.
On the other hand, many tasks are not time-sensitive. For instance, keyboard scanning: the rate at which people press keys is limited, so we don’t need to scan the keyboard in real-time. Scanning every few tens of milliseconds is sufficient, and during that time, the MCU can handle other tasks.
Even though the MCU runs on bare metal, the actual needs may require us to implement a multitasking approach. For example, a typical scenario includes four tasks: keyboard scanning, LED display, receiving serial data, and sending serial data.
In the past, I used to place the keyboard scan in the main loop and handle serial reception via interrupts. The received data would be stored in a buffer, and the main loop would check for complete frames. However, this approach could lead to poor real-time performance if tasks became too long.
To improve this, we should eliminate time-consuming parts and decompose each task. Here are specific measures for each:
1. **Keyboard Scan**:
Software debouncing is standard, but using a delay function (like 20ms) can severely impact real-time performance. Instead, use a timer to handle debounce timing. Additionally, avoid infinite loops when waiting for key release, as they can block other tasks. For more complex functions, such as long presses or combinations, a state machine is more efficient.
2. **Digital Tube Display**:
Dynamic scanning is commonly used, and the human eye can't detect flicker above 50Hz. We set the scan interval to 4ms (250Hz). Using a timer to trigger the display update ensures smooth operation. Alternatively, the display can be handled in the main loop with a flag set by the timer.
3. **Serial Port Data Reception**:
Receiving a full frame in the interrupt service routine is inefficient. Instead, store incoming data in a buffer and process it in the main loop. This allows for flexible processing and avoids blocking the CPU.
4. **System Timing Framework**:
A global timer can be used to generate system ticks (e.g., 4ms). Functions that need to run periodically can be called based on these ticks. For example, feeding the watchdog, updating the display, scanning the keyboard, and checking for serial frames can all be scheduled.
By structuring the program this way, the system becomes modular, scalable, and easy to maintain. Even with limited resources, this approach works efficiently across different MCUs.
Overall, the system is built around a central flag mechanism, keeping things organized and avoiding fragmentation. While it uses one timer, it's highly suitable for resource-constrained MCUs. I’ve seen similar templates for 51-series MCUs, but they tend to be more compact and efficient. Still, the core idea remains the same: using global flags to drive events while ensuring no deep recursion and maintaining real-time responsiveness.