关于设备驱动框架的一点想法

[LiuMing]

我的想法是将驱动程序划分为总线驱动和功能驱动，这两者对外的接口区别对待。

功能驱动的例子：串行Flash，实时时钟，U盘。用于驱动具有实际功能的设备。

总线驱动的例子：SPI，I2C，USB。总线驱动不操纵具有实际功能的设备，而是向功能驱动提供访问总线的接口函数。

 

总线驱动本身不向App提供接口，不同的总线驱动向上（即向功能驱动）提供的接口函数可能不一样。

 

功能驱动通过总线相关的接口访问总线（例如I2C接口的实时时钟驱动通过i2c_read，i2c_write来操纵I2C总线），同时向App提供一致的接口，如read,write,ioctl.

 

总线驱动和功能驱动的概念来自Windows Driver Model。

 

这样的话，App层可以得到一致的设备访问接口，同时rt-thread的用户如果要增加新的设备驱动，不需要改动总线接口，只需要利用相关总线的接口函数写功能驱动。

 

[陈兴友]

有没有可能实现设备驱动的动态加载（类似Linux的模块化内核）？

希望一块板上的USB接口可以驱动各种USB外设，但显然没法把所有驱动程序都写进单片机（那样根本存不下，而且未来会出现哪些新的设备很难预料），我指望可以从一个通信网络中下载驱动程序片并运行。

[陈兴友]

单片机往往单板单用，没必要把所有驱动都编译进最终产品，我觉得可以尝试给系统来一个动态加载驱动的功能，用dialog命令在编译之前配置rtconfig.h，需要频繁使用的驱动可以被编译进最终系统，偶尔用到的驱动编译成单独文件（保存到文件系统中，避免占用RAM），需要时加载，用完就卸掉（^_^，照搬Linux了）。当然，这会增加操作系统的复杂度，各位大佬们看看是否划得来（调试驱动时很有用的）。有了这个功能，产品出厂后的功能扩展也会容易一点。

不知大伙有没有考虑过：哪天单片机也需要像电脑那样连成一个网络，分工合作，共同完成某件事。

[bernard]

很划不来，如果这个是ARM9、ARM Cortex-A5一类的设备还好，微控制器不是自找麻烦么。当然技术上并不是什么问题。

以前针对于RT-Thread的应用模块，我当时列了几点（论坛上应该找得到），其中一个非常重要的是：调试。即一个应用模块如何调试？Linux是因为它有gdb、gdb server、gdb stub等一系列配套的工具。但是在微控制器上，Keil MDK、IAR + Jlink都做不到比较好的调试方法。所以还是需要从自身的开发模式上仔细考虑下，这样做真的好吗？

[禾兰豆]

是的，就微处理器的指令处理速度来说，很多微控制器上不上os是一个值得商榷的问题。像ARM7系列微控制器是一个分水岭。例如ARM的运算器速度跟大多数外设的运行速度基本一致，一般在ns级。所以很多厂家都把少量的flash集成到芯片中作为一个完整的SOC核销售。但是没听说过有在主频超过200MHz以上的芯片中集成flash的。简单分析下为什么70MHz一下的微控制器不适应上OS。上OS的前提是系统很复杂，任务比较多。但是OS调度会消耗一定的资源，这个有个属于被称为调度复杂度。在低频下，调度任务的效率和外设的效率很接近时，调度任务的开销就很明显了。当调度任务的效率小于外设的效率时，则要果断的放弃使用os。例如我们绘制一个640*480的图片，而且适应IO口直接驱动LCD。对于ARM7来说，IO的读写速率正好和LCD的读写速率匹配（都在ns级别），此时裸奔绘制整幅图片肯定要比用OS绘制的速度快，因为当速率匹配时处于临界状态，OS其它要开1~2个任务吧，那上OS就会打破这种匹配了。所有在低频的微控制器上用os不会提高效率。虽然理论上控制器工作在1Hz的情况下照样能够上os，但是可能吗。这也是为什么有些人把70Mhz以下的微控制器都称作单片机的原因。所有当我们想上os时，看看控制器与外设的速率是否适合。我在这里讲这些，是因为经常听到很多人持有不同的看法，可能是理解的出发点不同吧。

[ip2004]

Generally, if a system is not fast enough with a real-time operating system, it will certainly
not be fast enough without one. There are two reasons for this:
1. Systems running under a real-time operating system are always executing at the code
section that is most important at any particular moment.
2. The task of directing the work must be done, either by the operating system or by the
user code.
Intense competition between operating system manufacturers has produced some designs
with very high performance. For those who plan to make their own kernel, it is possible,
but not easy, to do better  in a reasonably short time.

[LiuMing]

对于一个上OS的系统来说，花在任务切换和自身代码上的开销远小于用户代码运行开销，OS自身代码运行对CPU的占用也就1%-3%吧。所以这种说法有一定的正确性。不过OS自身要占用Flash和RAM，而且常见的OS每个任务还要使用自己的Stack，对内存的浪费还是比较严重的。Keil出的RTX51号称可以多个任务共用Stack，实测下来RXT51的任务的Stack对内存的消耗确实很低，只是不知其实现原理。

在2011-04-08，ip2004 <ip2...@163.com> 写道：

-----原始邮件-----
发件人:ip2004 <ip2...@163.com>
发送时间:2011年4月8日 星期五
收件人:rt-threa...@googlegroups.com
主题:在一个rtos的user guide看到这样的说法，大家怎么看？

Generally,if a system is not fast enough with a real-time operating system, it will certainly
not be fast enough without one.There are two reasons for this:

[昊]

"当调度任务的效率小于外设的效率时，则要果断的放弃使用os。"要看看使用着的需求，如果效率不是最重要的因素，或者不是对实时响应要求不高的场合，还是可以接收的。

 

其实很多时候大家使用操作系统更重要的是看重其资源丰富带来的易用性、代码可复用性、以及产品代码可维护性等等优点，而大多时候其效率的下降是可以接收的。毕竟大多数时候其优点大于缺点。

加之我们大陆工程师已经习惯了大马拉小车。。。。。。

 

个人观点

--

中国最专业的ARM技术开源论坛；分享、交流、学习arm技术。  www.armjishu.com

 

神舟系列STM32开发板，为您提供专业的技术服务，让您的STM项目如虎添翼！

[bernard]

已经从0.4.0分支中为device framework做了一个branches：
/branches/device_framework

仅拉了个临时的STM32分支过来，后续的，各个分支维护人（例如fm3, efm3, lm3s等）想先尝试这个分支，也可以把相应的移植分支copy过去。

会在根目录中建一个readme.txt说明文档，对其中的一些设计做简单（清晰）的描述

在 2011年4月7日 下午7:07，LiuMing <ea...@163.com>写道：

[weety]

��Ҳ̸̸���豸��ܵĿ���������ΪҪ�Ƚ��豸����ʩ�������������dma�ӿڣ�����Ļ������������������ԡ������豸���Ӧ�ÿ������� �棬һ����Ϊ��Դ�ѷ����豸׼����Ҫ���ֳ����ڴ�ռ�ã���һ��ҪΪ��Դ�ḻ���豸���ǣ�Ҫ���ֳ������ܣ�����ͨ������ѡ����������֮������ѡ��


�� 2011��04��11�� 14:33, bernard �:

�Ѿ���0.4.0��֧��Ϊdevice framework����һ��branches��
/branches/device_framework

�����˸���ʱ��STM32��֧����������ģ�������֧ά���ˣ�����fm3, efm3, lm3s�ȣ����ȳ��������֧��Ҳ���԰���Ӧ����ֲ��֧copy��ȥ��

���ڸ�Ŀ¼�н�һ��readme.txt˵���ĵ��������е�һЩ������򵥣����������

�� 2011��4��7�� ����7:07��LiuMing <ea...@163.com>д ����

�ҵ��뷨�ǽ�����򻮷�Ϊ������͹����������߶���Ľӿ����Դ�

����������ӣ�����Flash��ʵʱʱ�ӣ�U�̡����������ʵ�ʹ��ܵ��豸��

����������ӣ�SPI��I2C��USB����������ݾ���ʵ�ʹ��ܵ��豸�������������ṩ�������ߵĽӿں���

 

�������?��App�ṩ�ӿڣ���ͬ�����������ϣ����������ṩ�Ľӿں�����ܲ�һ��

 

������ͨ��������صĽӿڷ������ߣ�����I2C�ӿڵ�ʵʱʱ����ͨ��i2c_read��i2c_write������ I2C���ߣ���ͬʱ��App�ṩһ�µĽӿڣ���read,write,ioctl.

 

������͹�����ĸ�������Windows Driver Model��

 

����Ļ���App����Եõ�һ�µ��豸���ʽӿڣ�ͬʱrt-thread���û����Ҫ�����µ��豸�����Ҫ�Ķ����߽� �ڣ�ֻ��Ҫ����������ߵĽӿں���д������

 

[勇者]

 这个建议我支持，应该对驱动进行分类：

1.按照总线与设备类进行分类；
2.按照设备的具体类型进行分类。

这样的话总线驱动就是中间层，甚至可以想VxWorks的VxBus那样，对于驱动的移植和扩展而言很好。

总线驱动之下是类设备驱动，然后是具体的设备驱动，VxBus对驱动进行实例化。

总线驱动之上是类设备应用接口，如块设备，块设备之上接文件系统，然后再和VFS对接，或者直接跟应用对接。

结构如下：

                应用

VFS  或 具体的应用接口组件（如各种文件系统，网络协议等）

        虚拟设备总线（根据用户请求，配置或驱动的探测函数，使用总线及设备驱动进行动态设备实例化）

        各种总线驱动

         类设备驱动

         设备驱动

         设备实例

在 2011年4月7日 下午7:07，LiuMing <ea...@163.com>写道：

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