ucosii-2
实验内容
-
阅读附件中的代码，回答：
-
1.ucos是如何分层的？
-
2.HAL都有哪些代码？
-
3.分析任务是如何切换的。
-
实验步骤
ucos的分层
-
1.共分三层，分别是：上层访问抽象接口层、设备管理核心数据结构层、硬件设备驱动模块层。
-
上层访问抽象接口层:
一般的抽象层设计会直接在这一层提供5个访问接口API，分别用于打开设备、读设备、写设备、设备控制和关闭设备。而在这个设计里面更改了这种定义模式提供两个公用的接口DeviceOpen 和DeviceClose,同时为不同的外设分别提供特定的抽象接口,在移植的时候利用这些抽象接口的不变性保证应用程序的可移植能力。这样做的优点更适合于有单片机开发经验的工程人员直接调用。 -
设备管理核心数据结构层:
这是通用驱动框架的核心，主要用每个设备分配一个设备控制块，通过链表形式进行管理，该链表定义为设备控制块链表DEV_CONTROL_BLOCK* HvlConList。 在这一层， 为系统中的每个硬件设备分配唯一的设备ID。上层应用程序通过将设备ID作为参数传递给DeviceOpen函数实现对相应设备的核心管理数据结构的定位搜索，通过搜索，DeviceOpen函数找到相应设备控制块，申请设备的使用权限，获得相应硬件设备的操作句柄，该句柄指向具体的外设底层操作函数列表，返回该设备句柄;再通过上层抽象接口层提供的接口函数对设备进行访问。 -
硬件设备驱动模块层:
这一层是硬件设备驱动模块功能的实现层，对各个硬件设备的驱动在相应的硬件设备驱动模块中完成。各个硬件设备驱动模块,原则上需要实现如下几个函数: DevGetch、 DevPut ch、DevControl,分别完成相应设备的读、写、控制，当然，可以根据具体设备的特性，只实现3个驱动函数的其中一部分，例如，如果某设备不支持写操作，那么就不用实现DevPutch函数。
-
任务的切换
- 1.函数周期与死循环
一般函数的生命周期很简单，从开始调用函数起，直到函数返回，即结束。这样一来就完成了这个函数的使命，它也就不再需要了。对于一般的函数就是这样，但是回过头想想，对于一个系统、OS、或者工业控制中的一个控制器重的系统个，函数返回是很轻易很随便的就能返回吗？返回就意味着函数结束，死亡，若是想系统这样一个很大的函数，它的返回就意味着系统结束。因此，对于系统的函数返回有些时候我们不希望它返回，返回时是需要好好设计的，像嵌入式中的控制程序我们也并不需要它返回，直接关机就好了。因此，一个系统往往就是一个很大的循环，不停的扫描，而我们编程的时候对于这个死循环是需要好好设计的。考虑以下一个控制要求，按键控制电机启、停、正转反转，并每秒发送CAN报文报告当前情况。
- 2.uCOS-II中的任务调度
后台就是指程序的大循环，程序一定要等到前台任务(可以说中断或某个功能函数)返回才能继续运行下去。而在RTOS中每个任务都有自己的控制块指向改任务，由任务调度器来决定这个时候该运行哪个任务。
所有这些任务控制快(TCB)构成一个双向链表，每个TCB中都有一些控制字，比如一个指向堆栈的指针(sp)，一个表明当前任务状态的位(State)，指明任务被挂起等待的超时时间(dly)，任务的优先级(Prio)，指向事件控制块的指针(Event，事件机制后面会讨论)。一个全局的任务就续表记录了当前任务是否就绪，任务调度器就靠查询任务就绪表寻找到就绪任务中优先级最高的一个任务。