Introduction
About six years ago, during on-campus training for the University Student Electronic Design Contest (a national competition), I hit the first obstacle of the training phase: how to install Keil and Proteus on Windows 10. Keil is a commonly used IDE for embedded development, and Proteus provides circuit simulation and MCU emulation.
At the time, the Keil and Proteus versions provided by the lab teacher were rather old, and the experience was poor in terms of code completion and debugging. To make my own coding experience better, I tried searching Baidu and CSDN for how to install newer versions of Keil and Proteus. I no longer remember the exact steps, but what I still remember vividly is the wall of ads on Baidu and CSDN.
The whole process was bumpy and took several days, but I eventually got it installed. At that point, I became the most impressive person in the lab: while others were still learning with the old version, I had already earned a better experience through my own effort. That feeling of taking one more step or aiming a little higher gave me enormous satisfaction. Soon, more and more classmates wanted to try the newer versions of Keil and Proteus, and they kept coming to me for help.
So I began patiently installing it for other classmates, hand in hand. After doing it enough times, I had memorized the entire installation flow. But with that came the dullness that appears after the excitement wears off. I also experienced what it felt like to be on the receiving end of other people’s questions. To free myself, I did two things: first, I wrote a technical document so others could follow it step by step; later, I found that some people still could not get it done, so I recorded an installation video to teach everyone in even more detail how to install it.
So next, I want to talk about how I have grown through “asking questions” and “trying hard to solve problems independently.”
What Is a “Good Question”
A few years ago, when STC had just launched the STC32G series, Teacher Yao asked me to port FreeRTOS to this chip and open-source the result. Another participant in the porting work was Xiongzai, an experienced embedded engineer. Xiongzai was my senior. I had only recently graduated and did not yet have much experience, so during the FreeRTOS porting work we naturally communicated a lot, including many occasions where I asked him questions. Two things from that process left a deep impression on me:
The first was that there was very little online documentation for the Keil-C251 compiler. We wanted to optimize the assembly used in FreeRTOS context switching and write that part of the program with inline assembly. But without enough documentation, we had no clue where to start.
What did I do at the time? First, I checked Keil’s official documentation. After all the searches turned up nothing, I thought of asking STC engineers. Compared with individual developers, they had technical support for Keil, so this problem should be easy to solve. I told Xiongzai about my idea, and he felt the same way. So we immediately aligned, organized what we had accomplished so far, and when Xiongzai consulted the STC engineers, we described the issue in enough detail that the engineer quickly understood where we were stuck. They then easily gave us the answer we needed, which helped us further optimize the context-switching implementation.
So my feeling is that a good question first needs a good way of asking it: you should show the other side your thought process, improve communication efficiency, and reduce ambiguity in how both sides understand the problem.
The second thing was that, during task scheduling, my code behaved differently in Keil simulation and on real hardware. Xiongzai discovered this. Since I did not have a precision oscilloscope at hand, it was hard to observe the difference through something as simple as toggling an LED. From my perspective, the best approach was still static code review. During the porting work, Xiongzai and I were developing independently, so to verify my implementation, I explained my approach to him and, through code-slice-based inspection, asked him to help me validate it. Throughout that process, we discussed many implementation details, cross-checked each other’s work, and each of us improved our code a bit. In the end, we located the issue step by step and fixed it.
From the second thing, I believe that a good question is a good communication process that benefits both sides.
The project is now open-sourced here: FreeRTOS for MCS-251
My View on “Solving Problems Independently Through STFW and RTFM”
When I was in school doing embedded development, I had a strong realization: hardware and software knowledge is too broad and fragmented to ever fully memorize. Rather than remembering every concept and every line of code, it is better to master the ability to quickly find, reproduce, and apply the knowledge you need when a particular point comes up.
Following that line of thought, learning how to use search engines and how to read datasheets or official documentation becomes essential. You could say these are the most basic skills.
Once I understood that, my learning path became much clearer. I stopped getting hung up on minor details and instead focused on core knowledge. For example, when writing embedded programs, I no longer obsessed over the details of a specific driver, but instead thought about how to handle task scheduling so I could implement the required functionality better.
Later, I put this into further practice by writing an RTOS from scratch: AntOS. This methodology also gave me a solid foundation for my later work on simulator development and my study of LLVM, and it greatly boosted my confidence, making my motivation for self-learning even stronger.
Conclusion
What I really wanted to say has already been covered above. In the final section, I only want to add one thing: just do it. The hardest part is getting started; once you take action, results follow~