rt-thread规范化不足，太混乱

发布于 2015-09-10 15:29:03 浏览：7090 订阅该版

22 个回答

rtos8888 2015-09-10

这家伙很懒，什么也没写！

pigeon0411 2015-09-10

这家伙很懒，什么也没写！

rtos8888 2015-09-10

这家伙很懒，什么也没写！

bernard 2015-09-10

这家伙很懒，什么也没写！

bernard 2015-09-10

这家伙很懒，什么也没写！

rtos8888 2015-09-10

这家伙很懒，什么也没写！

aozima 2015-09-10

调网络不抓包，调I2C等时序不上逻辑分析仪，就像电工不用万用表！多用整理的好的文字，比截图更省流量，还能在整理过程中思考。

bernard 2015-09-10

这家伙很懒，什么也没写！

>有一个很实际的问题。做硬件抽象层即使像arm这样的公司制定出来的cmis规范，芯片厂商回应也很冷淡。rt-thread 作为一个rtos推自己的抽象层意义何在？一旦更换芯片所有底下要重新封装，做这种事是有很大风险的，这种工作应该是有芯片厂商去干。
>退一万步即使使用硬件抽象层为何不使用arm的cmsis规范定义的各种，比如arm 的mbed也基于这个抽像层接口去让芯片厂商往上靠。
>自己搞一套劳命伤财，用户，芯片厂商都不会卖帐。

---

你应该问，linux为什么驱动封装了这么一堆一堆的，驱动代码占据了大部分。

想明白这个，回过头来看RT-Thread的，

首先一个，RT-Thread并不想为了造什么东西而造什么东西，至少我个人的想法还是实用主义。能够拿来的还是选择拿来，除非不够用（所以这个里面我们看到了fatfs，看到了lwip。。。）。从实用主义出发，我们看到的并不是一个个外设，而是一个个的功能，能够完成功能#1，能够完成功能#2。。。这些功能，例如文件系统，例如TCP/IP协议栈。这些东西有了，再反过来想，如果是不同的芯片怎么办，难道你又重头移植一遍吗？所以中间得加入适配层，这个就逐渐地演变成驱动框架：希望对上层组件有统一的接口，不随底层而变动。所以也看到了，RT-Thread的设备框架不是一蹴而就的，是演变式的逐步进化，这个进化的过程也是在实际的使用过程中一步步完善、更新。

RT-Thread当然没这么大的号召力，不像ARM这样，能够号召芯片厂商。所以这部分工作只能自己做，把设备框架做好，当要写一个设备驱动时，能够非常容易的写（或基于芯片厂商的固件库等，别想着永远自己去发明轮子），我们能够做到的也仅仅是，把编写驱动的门槛想办法降低再降低<实际上现在也并没体现出来，这块文档还比较弱>。

对于用户来说，如果这些驱动都封装好了，OK，RT-Thread上很多的功能就有了；
对于芯片厂商来说，如果能够把驱动提供了，OK，RT-Thread上很多的功能就有了；

着眼点依然是功能，是实用主义。既然是实用主义，那么另外一个意思是，你习惯用什么就用什么，对你来说最好、最习惯的方法是什么就用什么。别陷到一定要把RT-Thread使用全的牛角尖里了。如果仅仅是用一个内核，还有很多其他RTOS可以选择，根据自己的习惯来就好了。。。如果没有习惯的，那么我依然推荐 RT-Thread，因为它是一套自内核到周边功能都很丰富，很健全，伸缩性很大的嵌入式OS，能够让你适配到多种不同的产品线上。入门确实有门槛，我个人也只能望洋兴叹，只能说一步步来降低这个门槛，更多的是希望大家一起来努力

sun_shine 2015-09-11

这家伙很懒，什么也没写！

>>有一个很实际的问题。做硬件抽象层即使像arm这样的公司制定出来的cmis规范，芯片厂商回应也很冷淡。rt-thread 作为一个rtos推自己的抽象层意义何在？一旦更换芯片所有底下要重新封装，做这种事是有很大风险的，这种工作应该是有芯片厂商去干。
>>退一万步即使使用硬件抽象层为何不使用arm的cmsis规范定义的各种，比如arm 的mbed也基于这个抽像层接口去让芯片厂商往上靠。
>>自己搞一套劳命伤财，用户，芯片厂商都不会卖帐。
>
>---
>
>
>
>你应该问，linux为什么驱动封装了这么一堆一堆的，驱动代码占据了大部分。
>
>想明白这个，回过头来看RT-Thread的，
>
>首先一个，RT-Thread并不想为了造什么东西而造什么东西，至少我个人的想法还是实用主义。能够拿来的还是选择拿来，除非不够用（所以这个里面我们看到了fatfs，看到了lwip。。。）。从实用主义出发，我们看到的并不是一个个外设，而是一个个的功能，能够完成功能#1，能够完成功能#2。。。这些功能，例如文件系统，例如TCP/IP协议栈。这些东西有了，再反过来想，如果是不同的芯片怎么办，难道你又重头移植一遍吗？所以中间得加入适配层，这个就逐渐地演变成驱动框架：希望对上层组件有统一的接口，不随底层而变动。所以也看到了，RT-Thread的设备框架不是一蹴而就的，是演变式的逐步进化，这个进化的过程也是在实际的使用过程中一步步完善、更新。
>
>RT-Thread当然没这么大的号召力，不像ARM这样，能够号召芯片厂商。所以这部分工作只能自己做，把设备框架做好，当要写一个设备驱动时，能够非常容易的写（或基于芯片厂商的固件库等，别想着永远自己去发明轮子），我们能够做到的也仅仅是，把编写驱动的门槛想办法降低再降低<实际上现在也并没体现出来，这块文档还比较弱>。
>
>对于用户来说，如果这些驱动都封装好了，OK，RT-Thread上很多的功能就有了；
>对于芯片厂商来说，如果能够把驱动提供了，OK，RT-Thread上很多的功能就有了；
>
>着眼点依然是功能，是实用主义。既然是实用主义，那么另外一个意思是，你习惯用什么就用什么，对你来说最好、最习惯的方法是什么就用什么。别陷到一定要把RT-Thread使用全的牛角尖里了。如果仅仅是用一个内核，还有很多其他RTOS可以选择，根据自己的习惯来就好了。。。如果没有习惯的，那么我依然推荐 RT-Thread，因为它是一套自内核到周边功能都很丰富，很健全，伸缩性很大的嵌入式OS，能够让你适配到多种不同的产品线上。入门确实有门槛，我个人也只能望洋兴叹，只能说一步步来降低这个门槛，更多的是希望大家一起来努力

---

门槛确实有点高，用了一段时间了有点上道了，个人感觉还是相关的参考和说明文档太少，太混乱，文档更新跟不上内核的更新。