[讨论] Device的新设计

[bernard]

当前的RT-Thread Device应该说设计得并不十分完美，有些东西交错复杂，也容易导致一个驱动设备节点内存占用过大
struct rt_device
{
   struct rt_object parent;                  /**< inherit from rt_object */

   enum rt_device_class_type type;               /**< device */
   rt_uint16_t flag, open_flag;               /**< device flag and device open flag */

   /* device call back */
   rt_err_t (*rx_indicate)(rt_device_t dev, rt_size_t size);
   rt_err_t (*tx_complete)(rt_device_t dev, void* buffer);

   /* common device interface */
   rt_err_t  (*init)   (rt_device_t dev);
   rt_err_t  (*open)   (rt_device_t dev, rt_uint16_t oflag);
   rt_err_t  (*close)   (rt_device_t dev);
   rt_size_t (*read)   (rt_device_t dev, rt_off_t pos, void* buffer, rt_size_t size);
   rt_size_t (*write)   (rt_device_t dev, rt_off_t pos, const void* buffer, rt_size_t size);
   rt_err_t  (*control)(rt_device_t dev, rt_uint8_t cmd, void *args);

#ifdef RT_USING_DEVICE_SUSPEND
   rt_err_t (*suspend) (rt_device_t dev);
   rt_err_t (*resumed) (rt_device_t dev);
#endif

   void* user_data;                        /**< device private */
};

1. 结构体中包含了大量的指针函数。由于一个设备驱动就是一个内核对象，而内核对象只能是动态的（必须能够被修改），它将直接变成一个个内存区域，进而消耗了"大量"的内存。
2. 对于从设备支持非常弱，基本上是采用一个个从设备就是一个内核对象的方式，内存浪费也非常严重。
3. 并不见得太适合于对象化编程(因为对象类不得不从rt_device类上继承，然后相应的内核对象类内存占用进一步增加)。

------------------------
新设计主要还是围绕着如何更精简，更可维护化着手（但也有可能导致一些代码阅读上的变扭，这个尽量依赖于面向对象化的编程模式消除掉）
/* 新的结构定义 */
struct rt_device
{
   struct rt_object parent;

   rt_uint8_t type;
   rt_uint8_t flags;

   rt_uint16_t item_count;
   const void* items;

   const struct rt_device_ops *vops;
   const void* user_data;
};

新的设计中，包括：
1. 把原来的堆积式的函数指针变成函数指针结构，使得可以把一个设备驱动的函数操作集变成了常量，直接放置于flash中。
2. 添加items域，以指向从设备分片，即从设备与主设备共享大多数的数据域，仅在一些小的细节上有出入，并且也可逐步转换成静态的常量数据不再占用多余的内存。<items的定义是否需要更进一步清晰化>
3. <vops是否可以考虑根据设备驱动类型的不同而变成不同的操作函数集？>
4. 更加不同类别的设备驱动，定义一些公共的方法，使得以后编写驱动时仅需要实现更小的方法集合。

--------------
缺点：将造成现有所有设备驱动的更改！
优点：内存占用会更小，对象化程度也会更高。

[xue110592]

现在的小型设备要么裸奔，要么上系统。裸奔的片子一般不在乎有没有操作系统概念

大多是大循环，状态机组成。对单片机资源需求也比较小。等到没有操作系统管理不了了，比如要tcp还要

文件系统，这时候有个管理助手就比较方便。一般能变迁到这一步就已经是硬件要跨越瓶颈了，这时候

需要操作系统来支持，那么使用大一些的内存和高档一些的cpu是没有人不接受的，所以一个中小型嵌入式的

更多关注部分首先是怎样‘易用’这一点很重啊不然ucos的使用人怎么那么多就是因为其微内核，易用；但是面对

高端的使用来说他的GUI部分就很难推广了，太难用。其次完善，高效，我认为能够把lwip这样的协议嵌套进来做完美

就是不错了，至于rtthread能够做到集成fat，gui这样的功能已经很不错了。我觉得不在于怎没样节省内存开销，怎样减少

代码量，我们能够学习和使用它更愿意它完善，安全，丰富。

      我们单位使用的还是44box这样的片子，很好，耐用，也有裸奔和带系统的两种，都没有太多的资源限制，一旦一个平台

选定其他的就是扩展变换，应用类的了。现在由stm的代理商支持转移整体平台了，呵呵以后都是m3的天下了，这个系统的片子

也就是低端的一些单片机，根本没有可能上系统，嘿嘿，我们的字库都是外挂的就这样一般的应用程序都在60-200k不等，哪里还有

空间跑系统。而那些需要系统的都有44BOX,2440完成，一般对处理器用了什么资源不会限制，我们单位一年的单片机综合用量应该

在100K以上，我是按照民用的思路去思考，衡量的，也是简单看法，请大家莫笑。

       最后衷心希望飞飞，shaolin等大虾越来越明，rtthread越来越多人，支持，追随。我个人祝愿他们的说明书，使用指南越来越

完善，能够快速指导我们这些时间不是很充裕的人迅速深入，呵呵，这是个矛盾呀，不想花精力还想有结果是一厢情愿了些。

 

2011-04-01 

[Michael]

能不能做成和linux一样呢？

[bernard]

是的，说得很对：“易用性”。

为什么提出这个，就是因为打算在外设驱动集成上更近一步。其实并不仅仅是内存占用的问题，还有对象化的问题。对象化设计好了，那么以后写驱动也会越来越容易，集成的驱动也会越来越多。所以，我也说这个会是以后RT-Thread区别于其他RTOS的重要一方面：用户拿来即可用（或仅仅需要少许修改）

[ip2004]

请教各位有使用trace32经验的兄弟，trace32里面说的支持很多种rtos到底指的是支持什么？普通的调试器如jlink不是也可以调试rtos吗？十分感谢。

[Lin Shao]

trace32支持rtos的任务级调试，也就是说可以实时显示当前系统中的任务以及内核对象信息，如信号量，互斥量，消息队列，定时器等，很类似于RT-THread Fish shell中可以打印出来的内核对象信息。trace32中提到的支持多种RTOS就是指支持任务级调试的RTOS。

在 2011年4月1日 下午5:01，ip2004 <ip2...@163.com>写道：

请教各位有使用trace32经验的兄弟，trace32里面说的支持很多种rtos到底指的是支持什么？普通的调试器如jlink不是也可以调试rtos吗？十分感谢。

[ip2004]

谢谢shaolin的回复，劳德巴赫不是os厂商，能把很多os支持到这种程度，确实很牛。考虑到jlink都要几千块的价格，trace32两万左右的价格还真不算是太贵……

[Lin Shao]

两万能买到trace32吗？我们这边光买一个ARM7的头就几万，要调试ARM9另外需要买头，又是几万，最近升级到Cortex A5,又花费了一大笔银子。贵啊！如果不是特别有钱的公司，要考虑trace32，不容易。

不过这东西确实好用，用过以后，再用其他的调试器感觉就是大炮换鸟枪了。

[Li Jin]

是啊！我估计应该不会只有2w这么便宜吧！一个正版的J都要1w呢。看他的广告说明好像很强悍，等有钱了一定要搞一个玩玩！

[ip2004]

2w确实买不了trace32，我查了一下要大概10w。以前的2w是在淘宝上看到的二手，现在想想很可能这些所谓的二手其实是那些仿制版本。

jlink没有1w那么贵，只要1900（stm32的一个在线研讨会说的，我在万利的网站上看到写的也是这个价格）。

sagger的jtrace我觉得他们把软件做强大的话应该也会很好用。网上找到的jlink和jtrace的区别：

J-Link就像照相机，程序（在断点处）停下来才能看调试信息，通过JTAG/SWD接口；J-Trace就像录像机，可以纪录、回放整个调试接口，通过ETM接口。最近一些Cortex-M3的芯片支持SWO接口，就好像是高速连拍照相机，采样间隔小的话，有那么点Trace的样子，这个调试功能在J-Link v7和EWARM v5.30中已经得到支持。

估计trace32的程序流记录/回放功能也是这么实现的吧，有了这个功能调试工具就不需要“实时”分析程序，把东西记录下来，用这些记录可以实现很多高级功能。

[yan]

这个改动太大了，有点得不偿失。只在flash中运行的平台有效果，慎重

在 2011-04-01 10:53:28，bernard <bernar...@gmail.com> 写道：

[yi mingyao]

我也来谈一下驱动的看法。
早先接触RT-Thread就是喜欢那个对象化设计，但是驱动部分实际使用的时候发现和想象的不一样。
刚初设计系统时设想将硬件驱动按照层次排列，最底层为MCU的IIC、spi、uart，然后是各种芯片驱动（E2PROM，RTC，SPI flash）通过查找（find）来调用MCU驱动，顶层是使用了不同芯片功能的模块，这样可以使其它模块通过find简单快速获得所需要功能，以期实现一个层次感分明的、低耦合的驱动调用体系。
但是实际编写代码中发现矛盾重重，首先是GPIO的中断和使用，每个模块对于GPIO要求都不同，原计划通过让模块申请该GPIO的PIN号来实现独占（隔离不同模块的GPIO使用），结果发现除了占用大量内存以外，调用还十分复杂，最终放弃后，只能将各个GPIO代码耦合进不同模块代码中。
然后是IIC、SPI、UART等MCU组件，此类组件其实分为两组，首先是对于UART之类的可以用文件读写模型来模拟的组件，这种组件使用原有的驱动模型没啥问题。
第二种就是IIC和SPI这种使用起来无固定形式的组件，原有的模型对这种组件来说过于庞大，多数情况下此类组件只需要一把锁和一个名字即可，通过find命令查找组件有利于移植，也便于使用。
我在写代码的时候，一开始就为所有的组件建立了驱动，然后芯片驱动通过find调用组件驱动，通过write、read和control操作组件驱动，但是除了使用UART驱动十分顺利外，其余的驱动都是一再“退化”，最后SPI和IIC调用和芯片驱动牢牢的结合在一起（类似于radio项目中的SPI调用方式），低耦合更是无从说起，让人既恼火又无可奈何，总体来说，提出这个问题，希望大家帮忙想个好主意。
其三是芯片级驱动，其实芯片驱动还是比较明确的，目前就E2P、SPI-Flash和SD等存储设备需要写驱动外，其余的RTC、WDT都是直接通过线程和函数调用来解决。
不过我想说的问题是，我发现大家对于read和write的pos和count定义蛮随意的，没有明确规定是块地址还是连续地址，这样写很容易出错，也容易造成误解。

总体感觉原有驱动结构是用用还行，仔细想想问题蛮多的情况。
首先原有的驱动模型使用的是大型操作系统的驱动模型吧，第一眼看上去很漂亮，但是实际用上去发现对于RTOS来说有些负担重了。
我发现其余RTOS很少实现驱动模型（可能我见识浅），原有的MCU确实flash和ram都小，但是未来大容量的ram和flash必然是潮流，所以考虑RTOS的驱动模型也是迫在眉睫的事情。
看到bernard老大准备帮RT-thread改进驱动模型是非常好的尝试，只有更好的完善了底层，才能让我们更好的关注上层代码的实现。

我觉得光驱动模型还不够，驱动不但要易用，还要结构清晰，不但让使用者清晰，更让编写者知道自己编写的到底派什么用，放在哪里合适。
我认为RT-thread应该提出一个驱动层次模型，完善系统的驱动结构，这样大家提供驱动的时候也有地方可放嘛。

PS：我觉得可以不用const符号，简单的指针占不了多少空间，这样已经比以前清晰了不少了。

[bernard]

是的，本意就是为了加强RT-Thread在设备驱动方面的支持。

以前的，open/close/read/write/control接口可以看成一个标准的接口，但并不是每种设备都能够这样使用，或者这样使用后有可能仅仅使用到了control接口。

随着应用的进一步发展，发觉更多的东西并不仅仅是open/close/read/write/control可以覆盖的，而且有些地方也不必要实现这么麻烦的、可移植的接口形式：
整个体系结构可以分成：
   +------------------+         +------------------+ 
   |                  |         |                  | 
   |   Application    |         |   Application    | 
   |                  |         |                  | 
   +------------------+         +------------------+ 
 +--------------+ +---------------+ +---------------+
 |              | |               | |               |
 |  FileSystem  | |  LwIP TCP/IP  | |   Components  |
 |              | |               | |               |
 +-----/--------+ +-------/-------+ +---------------+
       |                  |                          
  +----\------------------\-------------------------+
  |                                                 |
  |                 Device Framework                |
  |                                                 |
  +------------------------------------/------------+
                                      /              
  +----------+  +-----------+         '              
  | SPI EMAC |  | SPI Flash |        /               
  +----------+  +----_.-----+       /                
        `.        _-`              /                 
          ',   _-`                 /                 
      +------------+        +-----/---------+        
      |    SPI     |        |     UART      |        
      +------------+        +---------------+        

其中，SPI EMAC是一个网口驱动接口，SPI Flash是一个文件系统用的块设备接口，SPI是一个单独的设备接口。针对于SPI，上层（例如EMAC、Flash驱动）也并不见得需要open/read/write等的标准接口，EMAC、Block驱动也类似。这其中的关键，这些底层驱动并不见得需要暴露/提供给用户。而是，系统中存在一些中间层组件，用户用到的是组件，而不是底层具体的设备！

即系统分成了几层：底层驱动，（RTOS和驱动框架）、中间组件，用户应用等。分层后，也能够看出用户应用真正关心的是什么。基于这个假设，当前的设备驱动框架可以进一步改写，例如实现SPI类的“标准”接口（而不一定是兼容的read/write接口），在这个类实现中，统一的考虑其中的buffer管理，片选等操作。而到用户真正实现SPI驱动时，将可以仅实现与硬件寄存器读写相关的接口，从而做到，用户添加驱动容易，上层使用驱动也容易的目的。

也许我们可以先在某一平台上拉一个分支出来，按照提议的情况试图把这块进行改写，然后看看效果如何。

[KF118]

 

 

我感觉 现在的驱动 一下子 还是不晓得怎么写自己的应用驱动， 所以我的那个UART 网卡的驱动 都还没修改， 希望能搞一个比较详细的说明 这个驱动怎么写 什么的文档。

看了手册 也只是说有这么几个函数。具体里面的机制什么的 看的头大， 可能是我水平不高的原因吧。

 

 

2011-04-05

---

KF118

---

发件人： yi mingyao

发送时间： 2011-04-05  00:18:40

收件人： rt-thread-cnusers

抄送：

主题： Re: Device的新设计之我的看法

[xue110592]

嗯，这个看法我赞成，如果有文档，我们能够明白原理，我们就可以参加到里边自己修改和定义了。我们现在都还是观望，学习，出不上力气，其真正原因是没有搞懂呀，函数一个嵌套一个调试几个来回就晕了，没有信心了，呵呵！一天进步一点点。很慢，那些原有的文档我是看过的，还是感觉不够详细，有些云里雾里可能本身资质太差，不免有些希望能够全面深入快一些。

[tony zhang]

大家好！

设备驱动这块应该是个非常重要的地方，应该好好考虑。

我个人想法，并不需要太关注各个器件的具体差别，而是要把这个架构设计好。

目前的0.3.x/0.4.x（继续完善稳定性等)对于16位（包括）以下的单片机，已经够了，不需要再增加什麽功能了！

以后主要的是考虑ARM 系列-->M0等以上，MIPS 系列，NIOS2, 其他32/64位的CPU，OS规模也介于RT0.4.x到linux之间，可能略小于uclinux的规模。版本号就直接提高0.5啦.

>>>也许我们可以先在某一平台上拉一个分支出来，按照提议的情况试图把这块进行改写，然后看看效果如何。

不太赞成马上开始这样的开发，最好有几个人先分工，把整个设计架构图拿出来，先把整个驱动框架设计(包括各个接口详细设计)好再去搞一个平台来验证性能。

非常平台相关的和细节只需要后来的人去具体实现，核心开发人员只负责这个架构在几年内不需要重写即可！

(下面可以不用看)

----------------------------------------------------------------------------------------------------------------------------------------------------------

比如：

就拿网络收音机(还没有看过代码)来说，不知道目前的收音机在一个完全不一样的平台上移植需要修改多少东西，如果说很容易，一般的人都可以依葫芦画瓢而移植的话，应该还不过时的，就像Windows/Linux 等等大而全的系统一样。

我是搞LCD Driver这块，平时主要接触手机平台的LCD部分，比如MTK/展讯/高通的LCD接口代码。

我把这块总结一下供大家参考:

Baseband 这部分一般都是有LCD 控制器，系统只提供标准几个接口给设计公司，设计公司再根据平台/MMI/不同厂家的LCD Driver的需要完善整个系统。然后设计公司在开一个小口子给LCD Driver厂家，让LCD Driver厂商再调试LCD的各种效果。好像Camera Sensor也是完全一样，我碰到最多的除了调屏外就是调Sensor其次是Touch panel,最后就是其他的各种小部件。

我们知道MTK/MStar/展讯等等很多功能都是以库的形式提供，高通的最复杂，支持SPI/并口/RGB/高速串口，但是对设计公司来说也仅仅是修改几个函数即可工作。

[王宇]

Linux的驱动模式也没有达到都能抽象为file。不过Plan 9完成了更好的抽象，可以参考Plan 9的实现。

2011/4/5 tony zhang <scz...@gmail.com>

[勇者]

在很早以前我就认为RTT的设备管理这块功力要加深，还有就是应用层的GUI，网络和数据库等，以及集成开发了。

当然GUI和网络也都有了，bernard一直以稳定性为重点的方向也没错。

个人对RTT驱动模型的设计有以下建议：

1.不能像Linux那样把麻烦全部交给驱动工程师，后来为了减轻驱动工程师的麻烦有在里面增加了大量的框架，个人觉得是用乱七八糟来形容。另外一个糟糕的地方是把所有设备都看作文件，对应用层来说也未必是好事，特殊设备用起来不仅麻烦，而且觉得效率不高。

2.比较推荐VxWorks的VxBus驱动模型，动态加载，不用把驱动都写死。但仅仅是借鉴哦，但没必要写成VxBus那样。

3.建议延续RTT的面向对象思想，对于每种设备单独进行抽象，而不是统一抽象成File。

个人认为动态加载对驱动和设备的管理比较方便，各类设备单独抽象比全部抽象成File好，对应用和驱动的编写来说都更为方便。

比如NandFlash类对象，LCD类对象，应用层对抽象基类操作，驱动层作为派生类使用复杂工厂模式进行实例化。

--
人定胜天,勇者必胜!

[勇者]

补充一点，这样的话驱动框架就成了如下形式：

   +------------------+         +------------------+  
   |                  |         |                  |  
   |   Application    |         |   Application    |  
   |                  |         |                  |  
   +------------------+         +------------------+  

    +-------------+ +---------------+ +---------------+ 
    |             | |               | |               | 
    | UART Class  | |  LCD Class    | |  TIMER Class  | 
    |             | |               | |               | 
    +--/-----\----+ +------/------\-+ +---------------+ 
      /       \          /          \      

+--------+ +--------+  +-------+ +-------+

| UART 1 | | UART 2 |  | LCD 1 | | LCD 2 | .........
+--------+ +--------+  +-------+ +-------+ 

所有驱动类及驱动各有一个Manager，各个实例化的设备也由manager进行管理。

应用层通过Manager使用设备驱动实例化指定设备对象，使用设备对象类方法进行访问。

这种设计有两个要点：

1.把设备分类抽象，而不是全部抽象成File。应用层要访问的设备类型不同，则访问接口不同。很多设备根本没必要抽象成File，File模型真的好用吗？

2.设备驱动和设备分别注册，设备和驱动都有一个Manager，先注册驱动，然后每个驱动都有一个probe函数，发现设备时OS调用驱动的probe函数判断是否是该类设备，如果是则用该驱动实例化这个设备。特点是一个驱动可以用于多个同类设备，设备动态加载，编写的驱动更容易移植，使用灵活。

--
人定胜天,勇者必胜!

[arda]

这样的话..
UART/USART，IIC，SPI，ADC，DAC，I2S，ETH，RTC....每个一类？ 呵呵，好像 Nucleus。

[yan]

也想谈谈对Device设计的一些看法。

我觉得在内核中保留一套一致的访问接口还是有必要的。例如init、open、close这3个接口，几乎每种设备都会用到，这个可以看做中间层。。当内核调用open（）函数后会取得一个设备描述符，描述符中包含了真正的设备访问函数。根据设备类型再提供不同的访问接口。例如字符类设备、块类设备、流式设备等，这些可以看做底层。

最上层的是用户应用程序。用户应该可以直接调用中间层接口函数进行访问设备。

这个模型描述如下：

   +------------------+ 
   |   Application    | 顶层，用户应用层
   +------------------+  
   +------------------+ 
   |   kernel call    | 中间层，系统调用层
   +------------------+ 
   +------------------+              /+-----------------------+

      |   device if      | 底层,设备驱动层  char, block, stream,...

      +------------------+              \+-----------------------+

以char型设备为了,通过中间层的调用,得到char型设备的描述符,再使用char型设备的ioctrl接口实现具体的读写操作.

其他类型设备类似.这样就能够统一用法,也方便扩展新类型设备的驱动.用户只需关心具体的ioctrl接口接口.很多CPU的设备空间都映射到系统访问空间当中，使用这种方法可以实现直接访问寄存器，用不同的io命令区别寄存器地址，不用单独编写读写函数了。这样的代码，编译之后访问效率也是最高的。缺点是代码可读性较差。

[bernard]

我觉得或许可以考虑设备这边实现成两层：
DeviceFS和Device Framework

DeviceFS提供给用户的是文件的访问接口（open/read/write/close/ioctrl）等，并且也可以依据文件描述符的属性来约束设备的访问模式（只读、只写、非阻塞等）。Device Framework则是面向各类具体设备的框架，不一定需要采用（open/read/write/close/ioctrl）的形式。

Device Framework的框架效率会高一些，而DeviceFS则更普通一些。可以再仔细想想……

[ZhangPeng163]

可以参考一下Windows的COM对象的实现，不同IO设备可以实现自己的同步/异步IO接口。

[tony zhang]

基本上我同意yan的思路。

Kernel层 和 Device IF层可以采用微内核的方式来操作

设备层:

Char型:比如包括PS键盘/鼠标，Touch Panel,串口(可以有好多种驱动(CAN/Lin/RS485/I2C/SPI(很多种)等等，靠个人发挥),并口(单片机port口,单双向，3态等等),timer,ADC/DAC,PWM,......

Block: SPI/Nand/Nor flash, SD/MMC Card等，

Stream:

USB:

Video:(和Steam Gui等还要划分)

....

>以char型设备为了,通过中间层的调用,得到char型设备的描述符,再使用char型设备的ioctrl接口实现具体的读写操作.

>其他类型设备类似.这样就能够统一用法,也方便扩展新类型设备的驱动.用户只需关心具体的ioctrl接口接口.

>很多CPU的设备空间都映射到系统访问空间当中，使用这种方法可以实现直接访问寄存器，用不同的io命令区别寄存器地址，>不用单独编写读写函数了。这样的代码，编译之后访问效率也是最高的。缺点是代码可读性较差。

所有的设备驱动程序都通过提供应用接口给应用层使用，这里强调的是统一性，比如I2C/CAN/LIN/SPI等驱动，不同芯片的实现都会符合其通信协议，但是具体设置和实现会有微小差别，所以不能在一个文件中把所有芯片都做完，一定是多文件夹/多文件的。

所以在设备层，可以使用linux的方式，专门开发一套配置工具，对不同的开发板/Soc芯片提供设备详细配置并生成一个config表给编译系统，配合核心和应用层，最终完成SOC系统的软件部分。

这样可以把一个SOC系统的软件划分出来，应用层给开发人员具体开发，设备层一般芯片提供商已经把大部分功能调通了只要按照设备层规范集成即可，RT-Thread是灵魂，把底层/组件层和应用层紧密而又灵活的统一在一起！

比如复杂的开发板：比如三星的6410。简单的比如新唐NUC100型 32pin脚（M0核）单板系统（只有LPC1110内的资源),都可以通过先配置其设备层生成GCC/IAR/Keil等的Makefile文件，然后通过其开发系统生成整个软件！

。。。

在 2011年4月6日 下午6:53，yan <arm...@163.com>写道：

[tony zhang]

>（只有LPC1110内的资源)
NUC100内的资源。

[JinQiu Zhao]

这盘子是不是就这么变大了？

[Li Jin]

 我觉得很有必要对Device这部分进行重构，以前，写应用驱动的时候，好像很难用上原来的框架。

[tony zhang]

为了RT的将来，设备这层应该是迫在眉睫的事情了！

如果只是控制单片机，目前的效率还是可以的，但是和uboot没有两样。

可以想象，以后的只ARM系列还会不断增加，有数百种甚至数千种产品，是否这些都要按照现在的，都放在BSP里。

比如现在的mini2440和SEP4020的开发板，其实就是简单的把目前的已经有的代码放到里面去，而且也只是把uart等代码简单复制过来的。这个对RT的发展没有任何帮组，最终和UBOOT一样。

BSP这层并不是我们的目标，一般是谁在做BSP？如果RT是好产品，一些商业公司（做CPU/SOC的)会考虑自己做BSP这块，他们更有时间和条件去做这些事情，还有就是一些自愿者，或者是一些商业项目开发者，他们可能只要花几个小时或者几天的时间就把BSP部分弄好了。我们的开发人员本来都是部分时间工作(part time)的，让他们去做这些事情太浪费他们的智慧啦！理论上只需要一个管理者管理这些patch就可以了

而我们的目标是把架构搞好，出现什麽新的产品，新的设备新的技术我们都有机会把它加进来。

我们讨论了这么多具体要做什麽，我们的核心人员再想什麽，还在不断的扩大BSP数量？

其实有部分人员具体地谈到了点子上：

> ZhangPeng163  发送至 rt-thread-cnus.

3月24日 (13 天前)

可以参考一下Windows的COM对象的实现，不同IO设备可以实现自己的同步/异步IO接口。

bernard  发送至 rt-thread-cnus.

19:59 (14 小时前)

我觉得或许可以考虑设备这边实现成两层：
DeviceFS和Device Framework

DeviceFS提供给用户的是文件的访问接口（open/read/write/close/ioctrl）等，并且也可以依据文件描述符的属性来约束设备的访问模式（只读、只写、非阻塞等）。Device Framework则是面向各类具体设备的框架，不一定需要采用（open/read/write/close/ioctrl）的形式。

Device Framework的框架效率会高一些，而DeviceFS则更普通一些。可以再仔细想想……

我给核心维护人员的一个建议就是：

   比较分析目前大部分嵌入式系统，根据RT的应用目标，定一个初步的设备框架出来，然后再继续开发！

   一开始不需要大而全，一个简单的例子：

   USB： 目前好像只有收音机有一个masstorage的驱动，但是一看代码全是柔在一起的，啥都有。USB其实是很繁杂的，你一看linux或windows就知道了，但是目前的一个趋势是一些中高端的SOC的usb功能已经超过了PC主板的USB的功能.

呵呵，说了这么多就是喜欢RT，希望大家继续努力把它搞好，对于设备这层，大家不妨就已RTT-USB开始，讨论设备层的架构开发问题，如果RTT-USB能支持多种种传输模式/多个版本（1.1/2.0/3.0）/UHCI/OHCI/Bulk only/UFI/USB-Audio/Mordem/USB-Eth/USB-video/USB-uart/... 注意这些分支就是一个固定的类设备，每个SOC平台都是一样的版本(当然商业平台自己提供最好)，

USB能搞好，其他的问题都是小菜了，当然网络也是很繁杂，但是它可以有很好的简化和替代也很成熟（毕竟快30年了吧）。

[ZhangPeng163]

我赞成tony zhang的观点，我想没有必要把所有设备可能的功能都绞尽脑汁抽象出来搞一个大而全的统一驱动，然后为新出现的设备或者功能不停地进行维护，你能预估3年以后会有多少功能的设备出来？

RTT只需要定一个开放的设备驱动接口规范。举个例子，对于输入输出就只有一个接口 IO Interface，IO Interface继承于Unknown根接口，然后你需要read/write,master/slave，Get/Set,Send/Recv...... 一大堆功能就自己实现去，按照接口自己去写，调用完了自己负责释放内存）。大家都按照这个规范做，以后谁做的接口成熟了就可以添加到RTT专门的设备驱动类库中管理。一个开放的一致的可扩展的接口规范有助于设备驱动的商业化，有助于活跃RTT的整个开发市场。

[bernard]

说的好，谢谢建议！这个帖比在论坛上讨论好很多。

关于USB这块，会有一个单独的device、host栈代码，而不是类似Radio的代码（Radio的USB代码只是暂时这样，完全用的ST的固件库来完成的）。这份代码是一家商业公司赠送的，原来用于他们的产品上（上面也跑RT-Thread），然后时间期到了，就开源赠送给RT-Thread.org。然后后续会做一些集成融合，稳定性测试。

目前对BSP的支持依然在扩展，例如扩展到PowerPC芯片上，富士通FM3（Cortex-M3）芯片上，Jz47xx系列等等（有些是和芯片厂商合作的）。当然近期最重要的工作是RT-Thread 0.4.0 beta2版本的发布。关于device的框架，我的意思是如果要动就趁早（因为这类大规模改动，改得越晚，到时附加的改动，对现行代码的冲击也就越多），在0.4.0正式版发布之前能够把整个框架搭建完毕。

关于新的device框架，希望大家能够考虑到：
1. 对微控制器的帮助;（体积占用上，驱动的集成度）
2. 对于多类驱动的兼容性; （也不要期待着把所有驱动用统一接口进行兼容，现实意义并不大）
3. 相互之间的耦合性，以及可剪裁性; （RT-Thread面向的是嵌入式系统，剪裁性必不可少）

至于说动态载入模块做驱动，目前看起来似乎还未到时机（技术上使用目前的应用模块，这部分已经不存在问题了）。

[tony zhang]

>目前对BSP的支持依然在扩展，例如扩展到PowerPC芯片上，富士通FM3（Cortex-M3）芯片上，Jz47xx系列等等（有些是和芯片厂商>合作的）。当然近期最重要的工作是RT-Thread 0.4.0 beta2版本的发布。

对于RISC的SOC几乎没有太大问题， X86的怎么样呢，毕竟ATOM也是比较给力的平台！

>关于device的框架，我的意思是如果要动就趁早（因为这类大>规模改动，改得越晚，到时附加的改动，对现行代码的冲击也就越多），在0.4.0正式版发布之前能够把整个框架搭建完毕。

 

可以两条腿走路呢，一个0.4X版本，一个是0.6X版本（直接上，就从0.4.0 Beta2开始上)

0.4X 横向不断扩充，同时增强稳定性，0.6X纵向扩充，进一步提高它的性能和灵活度。

建议分开，核心层要统一，设备层也算核心一部分但不强求统一，但是要做到兼容。这样compenent和应用层从0.4x到0.6转化不会太困难。

>关于新的device框架，希望大家能够考虑到：
>1. 对微控制器的帮助;（体积占用上，驱动的集成度）

   这个其实不用非常在意，摩尔定律在CPU不起作用但在SOC上还是有其市场。看看现在ST322XX的FLASH和RAM完全不用外挂了

   而成本来说，随着65n/45n/40n的不断应用，目前的Die Size在两年后将是现在4倍到10倍门数量。而价格不会有太大变化。
>2. 对于多类驱动的兼容性; （也不要期待着把所有驱动用统一接口进行兼容，现实意义并不大）

   驱动之间无从谈起兼容性，linux的File模型是符合它的市场需求的，而且完成的很好。

  ZhangPeng163谈到IO设备的特点，其实目前很多设备都和IO有关系，比如linux下的不管Char还是Block很多都算是IO操作，

  这类设备的驱动程序的目标可能就是怎么样提高它的IO性能

 你也谈到DeviceFS和Device Framework的，那这个就是怎么样管理这些IO(同步/异步/pass through/..）以提高他们的安全性/可靠性。

  如上的这两个目标是相背的，所以就需要核心和设备层来兼容

>3. 相互之间的耦合性，以及可剪裁性; （RT-Thread面向的是嵌入式系统，剪裁性必不可少）

  其实设备层和核心不会占用太多资源，支持设备的驱动程序可能是真正资源开销者。

比如一个存储设备驱动程序，他在采用不同的Cache策略时，可能开销会差别很大

有一个源代码可以参考一下:NT3.x-NT4.0的源代码，它的核心和设备管理层其实是很小的！

NT3.x的时候的PC机的性能和目前的arm7-9，M3-4是差不多的！

估计以后的嵌入式系统除了高端和超高端的话， M0-M8是比较主流的，差别只是外设的多少和性能问题！

[yan]

bernard的出发点是考虑了兼顾微内核的情况,在资源比较缺乏的情况下,驱动确实会消耗很多RAM,但是tongy zheng讲的也很有道理.驱动最重要的是易用性和可靠的性能,在很多时候性能会压倒一切.bernard可以考虑在framework基础上扩展一个user_command,通过这个命令字来兼顾弱资源的情况.即直接调用固化的驱动接口.

DFS的架构决定了很多设备也可以被看作文件,如果很多设备不支持这个特性,就太可惜了.例如suart设备,如果有用FIFO,那它就应该可以被映射成文件,甚至可以被mount到dfs下,这样才能发挥设备驱动的作用.