参考本网站的的文档和介绍,对RT-Thread有了初步的认识,觉得RT-Thread优点还是比较多,比如定时器、时间片轮转调度等等都比ucos等商业实时嵌入时操作系统好用,但是在当我从使用的角度去考虑RT-Thread时,我发现有2个方面还需要改进/增加,如下:
1、最重要一点,缺少详细的API说明,虽然有《RT-Thread实时操作系统编程指南》可以参考,但是一般的应用工程师是没有时间去了解内核程序的,他们最喜欢的方式是厂商可以提供详细的API,细到每个函数各个入口参数,出口参数的说明,当然,与开发使用无关的函数就不必要这样了。所以,提第一个建议:尽量独立提供一份API使用手册,让开发工程师可以少走弯路,缩短开发周期,只有这样,开发工程师们才喜欢从他们习惯了的ucos或者Vxwork等收费商业操作系统过渡到RT-Thread,否则,操作系统再好,应用工程师不会使用,那就是一件本未倒置的事情了。
2、RT-Thread的编程风格太乱了了,各个模块之间的编程风格都不一样,让人看得比较烦燥。编程风格统一是一件比较重要的事情,重要过可以减少BUG的地步,但是国人中很多工程师不喜欢作注释,认为这样会减慢开发速度,但是为了减速几天的时间,而让程序无法读懂,让程序凌乱,这是否会让人觉得可惜呢?功能重要,美观出重要,何况编程风格的统一不仅仅是美观的作用而已。
以上是本人的一些愚见,不知道正确与否,言语间可以会有偏激之嫌,权当是爱之深恨之切自慰吧,愿RT-Thread系统越做越好,越来越让用户喜欢。
很高兴有这么好的建议。
这点正在做,相信RT-Thread 0.4.0版本发布的时候是相对较全的Kernel API参考。API参考会先覆盖Kernel部分,shell部分,然后再逐步的过度到File System, GUI组件等。
关于编程风格,这个有一定的历史原因。例如finsh shell,它的成型早于RT-Thread很多。同样,DFS文件系统也相对早一些。这两者的风格确实与RT-Thread存在一定的差距,DFS部分已经在慢慢调整,但是名称上比较为难,还是继续沿用吧。
总之,RT-Thread会逐步在实施改进,使得内部更为合理化,这个需要时间,需要精力。只有当更多人关注到,提出更多具体的细节建议,甚至是加入进来实施改进时,这个过程才会得到加速。