对RTT发展的几个建议

taishan

我们欣喜的发现RTT在逐渐成长，为了RTT的成长的更快、更强，提几个建议：

一、文档工作要跟上，清晰而有条理的文档，让人赏心悦目，使用的时候自然平添几分信心。
二、可靠性验证，这个比较难。这个鸟国家要做个验证你都找不到地方，不行去美国验证一下，呵呵（开玩笑的）。
三、易用性。每个分支要做好大量的工程模板，让用的人拿来就用，不要像ucos一样搞得每个人都像黑客似的。
四、模块之间的耦合要仔细推敲，松紧相宜、层次清晰、上下一致、一脉相承。

对RTT刚刚了解，说的不对的地方请多包涵。

SailJune

我也来点建议，如果有用这个做过项目的哥们儿，可以在不涉及公司利益的情况下，发给rtt几个外设驱动，到时候每个发行版下可以有个examples文件夹，带着这些外设驱动供参考，当然仅供后人参考。

oldtom

说的都挺好的，非常好。

可是搞开源的人也要工作，也要生活啊，RTT是ffxz他们利用业余时间搞的。

ffxz

1. 抱歉目前已经没有多余的精力来满足大家的更多要求，已经满负荷了。正如oldtom说的，RT-Thread是依靠大家业余时间完成。所以我希望，在我们业余时间付出的同时，大家也请多多付出，那怕是一些心得。
2. 内核的可靠性还是很不错的，目前内核 + lwIP + 文件系统都有商业应用的实例，并且反馈下来都还不错。期间，例如文件系统有些bug，也及时进行修复了。
3. 如1点所说，这方面的易用性很想做，但已没有这么多精力了。
4. RT-Thread在这块相信做得还是很不错的，但是一些地方也有不如人意的地方，这些就需要大家反馈，完善，以及我们自己的仔细推敲完善了。

关于GUI，近段时间大家也注意到了，RT-Thread在GUI方面有新的动向(并且对我们自身的冲击也非常大)，不得不说，融入FTK是我们以前也曾有过考虑的。即RT-Thread/GUI分两条路来走，一个是低资源占用，一个是高资源占用。当融入FTK后，那么原来的RT-Thread/GUI会彻底的放弃大资源路线的分支，仅保留小型的路线。由于FTK融入的考虑，所以原来RT-Thread/GUI已有的一些问题也悬着，这个非常抱歉。

文档上，在目前已有的《RT-Thread编程指南》一书的情况下，明年将开始编写《RT-Thread内核代码剖析》一书，争取上半年能够把书内容全部写完，主要解析RT-Thread实时内核代码以及移植部分内容。配套硬件上，我们已经在规划下一批硬件了，希望是STM32F2xx。

gpfrank

回复【3楼】ffxz  
-----------------------------------------------------------------------

期待《RT-THREAD内核代码剖析》一书。 RT的编程风格给人启发很多啊！

jiaowoxiaolu

个人感觉RTT的书写得还是可以的，不过要是能配一些图片就好了，比如实际运行例子的截屏什么的~

ffxz

回复【5楼】jiaowoxiaolu  
个人感觉rtt的书写得还是可以的，不过要是能配一些图片就好了，比如实际运行例子的截屏什么的~
-----------------------------------------------------------------------

嘿嘿，ls是图片控。。。现在还对你当时提的研讨会照片记忆犹新

taishan

刚刚看到线程管理部分，提个具体点的建议：
线程的优先级可否增加动态调整，比如，随着线程挂起时间的增加，由线程调度自动逐级提升其优先级。

ffxz

如果是动态调整的，那就不叫做实时操作系统了。RT-Thread提供动态调整优先级的接口，但是需要用户主动调用这个API，这样用户才能够确定的知道他干了什么。

junyizhi

期待 学习