ucos软件结构

在以往的软件开发中,在结构上吃了不少的亏。慢慢的对结构方面逐步重视起来,下面我写一些关结构方面的认识,希望大家指导批评。这样在不段指正下成长 方能造就出,可靠性高,移植性强,维护方便的程序出来。

个人感觉,在写代码时,尽量做到模块化。Ucos是个很好的平台,他可以让所有的功能化分为多个模块。在其之间有很好的独立性,就是说只要给你一个任务,就可以完成一个功能。可是任务间有时也会牵扯到数据交互的问题,这个时候就使用模块接口。别人在加载您的模块接口头文件时后,所有的数据都可以通过接口传递了,这样块的封装就可以做的非常独立。这样在功能的删除和增加会变的很简单。不用再为两个模块 重复的枚举,宏而担心。因为所有的变量,都是本地的(静态的)。嘿嘿,本地模块是你的,你就可以随心所欲。当然在保证编程规范的前提下。最主要的是接口函数,要清晰明了。别人看一眼也大概是什么功能,就很到位了。

到这里,就不得不说下在用ucos整个软件的层次了。笔者以往是采用四层的方式,硬件相关层,驱动接口层,应用接口层,应用层。好的分层会让软件开发相对独立化,分工同步进行。下面是以前找资料看到的结构,感觉很不错。

                       

所有的硬件被抽象化,应用层的程序,基本上不用再考虑硬件的问题,也就是说,在硬件完全更换的情况下,只要硬件相关层被更新,完全可以等同原先的所实现的功能。这样就极大成度上方便了移植。要做到完全的划分,下面逐步对这几层做一个说明。

硬件相关层:在这层中,要尽量所有硬件相关都囊括在其中。不管是GPIO还是定时器,或串行接口。只要提供标准统一的接口,就可以让上层会因此而变的很潇洒。这其中有三个最为重要的接口Open,Close,Ctrl。 Open主要来完成对应硬件初始化,形参中包括了些,初始化的相关参数。Close失能硬件。Ctrl来实现一些控制的修改如:优先级,中断回调函数等等,硬件的不同,内容也大为不同。

驱动接口层:其实在上一层也算是驱动层,只不过因为硬件相关,而把他分离。这层中会用到一个或多个硬件层的接口,进行组合来实现特定功能的程序。这部分程序可举例进行说明。以Flash为列,它这里主要调用硬件层的SPI函数接口,但是主要的写,读指令都是在这里函数中完成的。在这层中需要提供5个标准统一的接口函数:

XXXOpen

XXXClose

XXXWrite

XXXRead

XXXIoCtl

没有被用到的函数,可以为空。本来还需要Install函数来进行动态加载和删除,因为stm32内存一般都很有限,所以舍弃动态分配。而把这5个函数用常量的形式直接编译到ROM中。在驱动的抽象接口层中可以做选择,哪些驱动要加载到内核,哪些不需要。不要的驱动不参与编译。这样有限的资源 可以得到合理的应用。这一层大部分工作可以说属于一次性投入。

应用接口层:主要连接驱动和应用。又是连接应用层模块与模块之间的一层, 这一块有很强的特殊性,第一包括了驱动抽象接口层,第二包括了模块与模块的接口层。第三又与应用层密不可分。

先说下驱动抽象接口,在驱动层时也有提过,这个接口 其实就是通过ID去访问那ID对应的那五个函数。抽象接口也是一次性投入的函数,在设计时对其可靠性要很重视。

模块与模块的接口层,包括模块的接口头文件,这些头文件要求是非常独立的,不能加载模块内的内部头文件,应该包括接口函数的函数声明,在接口中尽量少用到全局变量。如果非要用到可以使用函数的方式进行传递,或ucos消息队列方式。最好用ucos进行传递,因为有很好的互斥保护功能。

应用层:这里所有模块都算是应用层,在前面以经提到过,在模块内所有变量,或函数(接口除处)应该都本地化。在模块内可以有本模块化共用的主头文件,来方便本模块的维护。对硬件的访问其实直接调用应用接口就可完成。

 

到些主要的结构就算是大概总结完毕,希望给大家一点点帮助,也希望大家给一定的指正和完善。

posted @ 2013-03-13 21:09  Hiker天下  阅读(4734)  评论(5编辑  收藏  举报