Follow the blue text and reply “entry materials” to get a comprehensive tutorial from beginner to advanced on microcontrollers
The development board will guide you, we will help you fly
Written by | Wuji (WeChat: 2777492857)
The full text is about1507 words, reading will take about 5 minutes
I have been doing microcontroller development, but I don’t know what kind of debugging method Linux uses.
For microcontroller development, regardless of whether it’s UART, I2C, SPI, or USART, compared to online hardware emulation debugging like STlink, they are all inferior.
I used to debug program bugs using relatively low methods, such as using digital tubes, screens, UART, or even LED lights, because some products do not expose the UART interface.
These methods are actually very inefficient for more complex products, especially in cases of pointer exceptions.
My desire and understanding of online emulation debugging came a few years ago when I was working on automotive products and used the Gm81xx solution from Shengmai. My leader asked me to set up online emulation debugging.
I forgot which development tool I was using at that time, but it was definitely not Keil.
There was very little information available, and I had no support, which made me quite frustrated over several weeks, and then I asked my leader if we could skip online emulation, saying I could write the program faster.
My leader said no, but didn’t provide a reason. I ignored him and continued to write the program while researching. I still have the version records of the programs from that time.
At that time, I really didn’t understand why he insisted on the online emulation feature, which was not a necessity. I could still write programs and develop products without it. Was he just being difficult with me?
It wasn’t until later, when I encountered some complex projects and faced some tricky bugs, that I understood his intention and the importance of online emulation debugging.
For example, in our Wuji project training camp, projects 3 and 6 have menu systems.
Before the menu system runs, we need to initialize it and link various submenus together using a linked list.
When we want to switch menus, we don’t need to remember which menu to jump to; we can simply point the system menu pointer to the address of the current menu’s child/parent menu.
This method allows us to manage dozens or even hundreds of submenus without confusion, making it more convenient and flexible.
However, using a linked list can be quite troublesome during the debugging phase, as it involves many structures and pointers. Without STlink online emulation to check pointer addresses, one bug could take a whole day to resolve. With online emulation, it could be fixed in just a few minutes.
Therefore, once you have enjoyed online hardware emulation debugging, it is hard to go back to using UART for debugging unless the hardware doesn’t support it.
USART is also used frequently; if it’s for debugging purposes, it is usually configured in UART mode.
Thus, USART and UART can be considered the same for debugging.
Microcontroller development typically does not use IIC and SPI for debugging. If someone does, I would gladly call them a master!
I think it’s necessary to understand the differences between these protocols:
| Feature/Protocol | UART (Universal Asynchronous Receiver-Transmitter) | USART (Universal Synchronous/Asynchronous Receiver-Transmitter) | IIC (Inter-Integrated Circuit) | SPI (Serial Peripheral Interface) |
| Synchronization | Asynchronous communication | Supports synchronous and asynchronous communication | Synchronous communication | Synchronous communication |
| Number of Wires | 2 wires (Tx and Rx) | 2 or 3 wires (Tx, Rx, and optional RTS/CTS) | 2 wires (SDA and SCL) | 4 wires (MOSI, MISO, SCLK, and SS) |
| Baud Rate | Variable, set by software | Variable, set by software | Variable, set by software | Variable, set by software |
| Communication Speed | Slow to moderate | Variable, supports high-speed communication | Slow to moderate | High-speed communication |
| Error Detection | Parity check | Configurable parity check or no parity | No built-in error detection, can use CRC | No built-in error detection |
| Hardware Complexity | Simple | More complex, requires additional hardware support | Simple | More complex |
| Multi-Master Support | No | Yes | Yes | No |
| Application Scenarios | Serial communication, debugging interface | Microcontroller communication, RS-232/RS-485 interface | Low-speed device communication, such as sensors, EEPROM | High-speed device communication, such as SD cards, LCD displays |
IIC and SPI are not used for debugging. In my personal experience, debugging needs to be done through a computer serial port to view data conveniently. Computers have serial ports, but they don’t have IIC and SPI interfaces (maybe there are serial adapters for IIC and SPI, but that’s redundant; it’s better to use UART directly).
Another point is the distance issue. With a serial port and an RS-485 adapter, the distance can be extended significantly, making it easier to debug devices that are located far away.
end
Here are more original articles from Wuji about personal growth experiences, industry insights, and technical content.
1.What Is the Growth Path of an Electronic Engineer? 10 Years, 5000 Words Summary
2.How to Quickly Understand Others’ Code and Thinking
3.How to Manage Too Many Global Variables in Microcontroller Development Projects?
4.Why Is Global Variable Form Most Commonly Used in C Language Development for Microcontrollers??
5.How to Achieve Modular Programming in Microcontrollers? Practicality That Is Astounding!
6.Detailed Explanation of the Usage and Actual Role of Callbacks in C Language
7.Step-by-Step Guide to Implementing a Queue in C Language Code, Easy to Understand and Extremely Detailed!
8.Detailed Explanation of Pointer Usage in C Language, Easy to Understand and Extremely Detailed!