2020年是不平凡的一年：
这一年，世界在新冠疫情的阴霾中艰难前行；中国成功抵抗住新冠的肆虐成为全球唯一经济保持连续增长的国家；rt-thread成功发布了几个版本，也新推出了smart混合微内核，受众也越来越多；而我自己也在这一年首次将rt_thread应用于2个产品的开发，即将开始第三个项目的开展。一句话，都太TMD不容易了！
痛点，一般都是发现商机和行业机会的起点，rt-thread的诞生自然也不例外。我想开始之初，即熊大开发rt-thread的初心可能是解决单片机软件开发过程中：开发碎片化，代码可重用性差，不能像上位机一样能灵活的基于任务开发，没有一款，国产的，免费的好用的微操作系统，所以才亲自操刀，为大家开山凿路，这才有了rt-thread的端倪，而后众人拾材不断完善，才有了今天大家耳目一新的优秀的开源国产操作系统。在这里，我要对感谢熊大的辛勤付出，感谢rt-thread开源社区的热心坛友的积极热情，没有你们的坚持大家现在就可能就看不到如此优秀的国产微操作系统。
大家接受rt-thread的原因，开始大抵是因为免费，开源，支持国产；而后是因为其优雅清晰的代码所吸引也即它的小而美，最后因为其丰富的软件包和生态链而不愿放弃。随着rt-thread发展的越来越快，学习使用的人越来越多。当大家从例程代码学习到真正的产品化应用，过程中相信你会碰到许多问题，大家都解决了吗？都是怎么解决的？都有哪些感悟和想对rt-thread说的？
在这里我结合我2个项目的经历给大家说说我自己的一些看法，可能偏颇或不准确，但本心并非是贬低，而是真心希望rt-thread能越来越好。
1 希望rt-thread能像芯片的datesheet一样给出rt-thread的局限性说明：这并非是说rt-thread不好，而是清晰明白的阐明rt-thread的功能范围界限。我们知道没有什么药能包治百病。同样rt-thread也一样，比如目前的驱动框架在SPI双机通讯中从机的支持。虽然这个功能很少人用，但不代表人不会用到。当开发者整了很久找不到解决方法，细读开发文档后没有发现解决这个问题的任何蛛丝马迹，向人请教才知道rt-thread目前的SPI驱动架构不支持从机方式。虽说经历过一番可能对rt-thread认识更深刻，但也浪费了不少时间。如果一开始就明确阐明岂不更好？或者有可能目前不支持后续会解决完善，可以概要说明可替代的其它手段。否则开发者就会被迫裸机方案或者换其它操作系统，从而使人产生应该多学习（备）一种其它的微操作系统，碰到备rt-thread不支持的还有其它备留方案。
2 如今的rt-thread论坛做的已经非常好了，在首页面已经有各个标签，点进去是大家的同类相关问题帖子的汇总。我想对rt-thread说的是：如果rt-thread官方定期将这些问题帖子反应出的问题汇总提炼一下成为高质量的实战闭坑笔记，使后来者可以直接通过看这些精华就可以闭坑而不必翻阅多有帖子去寻找蛛丝马迹，而在总结里面找不到的情况下才再去逐个翻阅，这样是不是会更好。
3 软件包的质量问题：rt-thread吸引人的一大特色就是丰富的软件包解决方案，有时候单个的软件包没啥问题，但在软件包和软件包衔接的时候可能就会出问题。而这时候一方面很难直接面对软件包的维护者，即使网络和其中之一取得了联系，有可能会说配合的软件包不了解而相互推。我们理解开源软件是非盈利的，不能像盈利的公司组织那样得到专业的咨询服务。但也有可能好不容易吸引的RT_THREAD粉丝，在从例程模仿的菜鸟到决心在真正的产品开发中应用，因为这些问题而遗憾的从入门到放弃。从此对其再不信任。一个生态，获得底层入门者容易，想拥有真正的忠粉很难。所以我想对rt-thread说，请切实重视软件包或组件中的一些bug问题，这是真正考验软件的阵地窗口，平时大家学着玩怎么都行，一旦产品开发中碰到bug问题而不能及时解决，产品项目因此失败将会对rt-thread品牌形成极大的损伤。
4 linux如今是嵌入式软件的标杆，因为它确实经受住了PC和形形色色产品从简单到复杂等重重考验。因而人们信任他对其放心。这其中一部分是因为发展时间的验证，其它的是产品的验证，或者是出现了一批真正的大牛。rt-thread相信未来也一定可以获得linux一样的成就，那么如何培养一批rt-thread未来的大牛？或者我如何成为这样的大牛？但就我来说，我觉得首先我自己的能力水平姑且不论，首先得让我相信rt-thread能解决复杂的工程问题，在解决复杂问题时还能可靠的工作。即使我自己能力达不到，如果有这样牛逼的产品一个个出来，那么我就会去相信。相信这条路是走的通只要努力就行。所以我想对rt-thread说：可以多广告一批复杂功能强大的产品，让众人眼见为实的相信rt-thread能扛大旗担大任。如果能抽象说明其设计技巧那就更好了。
5 还要说一说hardfault:开发过程中碰到问题不可怕，平时裸机开发模式下有一套定位错误的方法。而加了微操作系统中间件后，有些因为改写或重定向异常处理，造成了原来的分析方法失效。rt-thread解决方案CmBacktrace给出的还是不能指明问题所在，但凡这种问题，外人又不可能有能力，有耐心的帮你去找原因解决问题。那么这种情况下工程师如何自救呢？在这里我想对rt-thread说：一 建议多汇总一些实战中碰到且已经解决的hardfault经典案例，让大家学会各种极端天气下的捕鱼技巧，眼界开阔了就会了应对之法；二 多支持一些追踪调试工具，即使是商业软件，只要能合作让大家都有利，这也不是不可能的，比如segger授权ST使用emwin, Tracealyzer支持freertos/rtx/vxwoks.也希望rt-thread能和Tracealyzer沟通合作使大家也能用到其它优秀的分析调试工具，扩大rt-thread的功能边界，提高调试分析的效率。
以上是最近一年的感悟所得，个人愚见望大家批评指正。2021.02.19