前言

大约是六年前，我在大学生电子综合赛（一个全国赛事）的校内培训上，遇到了培训阶段的第一个难题：如何在 win10 上安装 Keil 和 Proteus，前者是嵌入式开发常用的 IDE，后者提供了电路仿真和模拟 MCU 的功能。

当时实验室老师提供的 Keil 和 Proteus 的版本比较老，在代码补全和调试方面，体验欠佳。为了让自己编码体验好一些，我尝试在百度和 CSDN 上检索，如何安装更高版本的 Keil 和 Proteus。但具体怎么操作的细节我记不清了，记忆犹新的是百度和 CSDN 上满屏的广告。

整个过程跌跌撞撞，花了好几天，但最后还是被我安装好了，彼时，我成了整个实验室最靓的仔，当别人还在用旧版本学习的时候，我已经通过自己的努力，获得更好的体验了，这种“多走一步”或者“多追求一点”的感觉，让我获得极大地满足感。接着，越来越多同学想体验新版本的 Keil 和 Proteus，开始不断向我寻求帮助。

于是，我开始不厌其烦地为其他同学手把手的安装，后来安装次数多了，以至于我把整个安装流程都背了下来，但随着而来的，是激情和兴奋褪去后显露的枯燥。期间我也体验到了，被别人“提问”的感觉，为了把自己解放出来，我做了两件事：首先是编写了相关的技术文档，让别人可以跟着文档一步步安装；后来发现有的人还是不会，于是我就录制了安装视频，更详细地教大家如何安装。

那么接下来，我想谈谈，我是如何通过“提问”和“努力独立解决问题”，来让自己获得成长的。

什么是 “好的提问”

几年前 STC 刚推出 STC32G 系列的时候，姚老师委托我为这个芯片移植 FreeRTOS，并把成果开源出来，当时参与移植任务的，还有经验丰富的嵌入式工程师熊仔。熊仔是我的前辈，当时我刚刚毕业，经验不够丰富，在移植 FreeRTOS 的时候，自然而然，我们做了很多交流，其中不乏我向他请教问题的情景。移植过程，给我印象深刻的有两件事：

第一件事是网上缺乏 Keil-C251 编译器的资料，我们想优化 FreeRTOS 上下文切换的汇编写法，想通过内联汇编的方式来编写这部分的程序，由于缺少资料，毫无头绪。

当时我是怎么做的呢？首先查看了 Keil 的官方文档，在各种检索都无果以后，我想到了询问 STC 的工程师，相比个人开发者，他们有 Keil 的技术售后，这个问题应该很好解决。当时我把我的想法告诉了熊仔，他和我抱有同样的想法，于是一拍即合，我们整理了当前移植的成果，熊仔向 STC 工程师请教时，由于我们描述的比较详细，让工程师很快了解到我们卡主的点，于是轻松给出了我们想要的答案，进而帮我们进一步优化了上下文切换的代码实现。

所以我的感受是，好的提问，首先要有好的提问思路，要向对方展示自己的思考过程，提高沟通交流的效率，减少双方对这个问题理解上的歧义。

第二件事是任务调度的时候，我的代码在 Keil 仿真上运行和在实际硬件上跑的有差异。这是熊仔发现的，由于我手上没有精密示波器，很难通过点灯这类简单的现象观察到差异。从我的角度来说，最好的方式，还是通过代码静态 review，当时移植工作，我和熊仔都是独立开展的，所以为了验证，我的做法是，把我实现的思路和熊仔讲解了一遍，并通过代码切片排查的手段，让他协助我验证，整个过程我们交流了许多代码的实现细节，相互印证，对彼此代码都进行了一步优化，最后，我们一步步定位到出问题的地方，然后解决了它。

通过第二件事，我认为，好的提问，是一个好的交流过程，对双方都能产生收益。

目前我已将其开源：FreeRTOS for MCS-251

对"通过 STFW 和 RTFM 独立解决问题"的看法

读书的时候搞嵌入式，我有一个很深的体会，软硬件知识繁杂琐碎，根本学不完，与其记住所有知识和代码，不如掌握“需要用到某个知识点的时候，能快速找到并复现和利用起来”的方法。

顺着这个思路，那么学会使用搜索引擎和看懂 datasheet 或者官方文档的技能，是必不可少的，这可以说是最基本的技能。

当我想通这一点以后，我的学习路线变得清晰了不少，我不再纠结某些细枝末节，而是专注那些核心知识，比如编写嵌入式程序时，不再对某个驱动的细节钻牛角尖，而是思考怎么处理任务的调度，来更好的完成功能的实现。

后面我将其进一步实践，从零编写了一个 RTOS：AntOS。这套方法论，为我后面从事模拟器开发和学习 LLVM 都提供了坚实的基础，并且极大地提振了我的信心，让我自学技术的动力愈发十足。

总结

其实想说的，前面都讲透了，最后小节，想补充的就一点，just do it，完事开头难，行动起来，就有成果~