2019-2020-1 20175311 《信息安全系统设计基础》 ucosii-1的学习

夙愿已清 提交于 2020-03-05 22:58:19

下载安装vc6.0和Visual Studio 2017

按照题目要求,对vc6.0ucos进行下载解压安装,将ucos导入vc6.0即可编译运行。

可以在以下网址下载:

https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes



问题一:ucos是如何分层的?ucos分为硬件相关层,驱动接口层,应用接口层,应用层。

1.硬件相关层
在这层中,要尽量所有硬件相关都囊括在其中。不管是GPIO还是定时器,或串行接口。只要提供标准统一的接口,就可以让上层会因此而变的很潇洒。这其中有三个最为重要的接口Open,Close,Ctrl。 Open主要来完成对应硬件初始化,形参中包括了些,初始化的相关参数。Close失能硬件。Ctrl来实现一些控制的修改如:优先级,中断回调函数等等,硬件的不同,内容也大为不同。
2.驱动接口层
其实在上一层也算是驱动层,只不过因为硬件相关,而把他分离。这层中会用到一个或多个硬件层的接口,进行组合来实现特定功能的程序。这部分程序可举例进行说明。以Flash为列,它这里主要调用硬件层的SPI函数接口,但是主要的写,读指令都是在这里函数中完成的。在这层中需要提供5个标准统一的接口函数:XXXOpen、XXXClose、XXXWrite、XXXRead、XXXIoCtl。没有被用到的函数,可以为空。本来还需要Install函数来进行动态加载和删除,因为stm32内存一般都很有限,所以舍弃动态分配。而把这5个函数用常量的形式直接编译到ROM中。在驱动的抽象接口层中可以做选择,哪些驱动要加载到内核,哪些不需要。不要的驱动不参与编译。这样有限的资源 可以得到合理的应用。这一层大部分工作可以说属于一次性投入。
3.应用接口层
主要连接驱动和应用。又是连接应用层模块与模块之间的一层, 这一块有很强的特殊性,第一包括了驱动抽象接口层,第二包括了模块与模块的接口层。第三又与应用层密不可分。
先说下驱动抽象接口,在驱动层时也有提过,这个接口 其实就是通过ID去访问那ID对应的那五个函数。抽象接口也是一次性投入的函数,在设计时对其可靠性要很重视。
模块与模块的接口层,包括模块的接口头文件,这些头文件要求是非常独立的,不能加载模块内的内部头文件,应该包括接口函数的函数声明,在接口中尽量少用到全局变量。如果非要用到可以使用函数的方式进行传递,或ucos消息队列方式。最好用ucos进行传递,因为有很好的互斥保护功能。
4.应用层
这里所有模块都算是应用层,在前面以经提到过,在模块内所有变量,或函数(接口除处)应该都本地化。在模块内可以有本模块化共用的主头文件,来方便本模块的维护。对硬件的访问其实直接调用应用接口就可完成。

问题二:HAL结构与代码

HAL stub的框架比较简单,三个结构体、两个常量、一个函数,简称321架构。
@hardware/libhardware/include/hardware/hardware.h
@hardware/libhardware/hardware.c
三个结构体

0) 三个结构体指的是:hw_module_t, hw_module_methods_t,hw_device_t
1) led_module_t继承hw_module_t,也就是说led_module_t结构体中有hw_module_t成员变量。每个某块都需要继承hw_module_t。
2) 每一个模块都有各自独特的函数,led_device_t中的setON之类的。led_device_open中定义led_device_t

2. 两个变量
#define HAL_MODULE_INFO_SYM HMI
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"
这个就是led_module_t 的名字罢了,就是为了统一,就是HAL Stub的固定名字。
注册时有用会加载HMI地址。
3. 一个函数
int hw_get_module(const char *id, const struct hw_module_t **module);
通过module id(led.default.so中的led)获取hw_module_t。
4.两种架构

位于libhardware_legacy目录下的“旧HAL架构”和位于libhardware目录下的“新HAL架构”。两种框架如下图所示:

问题三:分析该任务是如何切换的?基于切换机制的任务切换

1、多任务的引入

  • 之所以引入多任务,主要在于提高程序运行的效率。多任务的过程,能够有效地发挥交换式任务的运作效率。类似的,由于一个任务里面也有瓶颈的地方,为了把瓶颈的地方抠出来,让它不影响整体效果,引入线程概念,各自为政,充分发挥各自效能;然而为了让各自协调执行,必须管理各个线程;概念引入只是其一,如何管理是其二。

2、切换机制

  • 需要任务切换时,就必须尽快切换(虽然由于优先级问题,仍然是本任务,但仍需相应一下);而一些处理器提供的中断机制就刚好满足这个需求,从而奠定了切换的基础。中断分为软中断和硬中断。所谓的软中断就是可有程序自身触发的中断(例如,SWI);而硬中断则是硬件本身检测到中断触发信号而强制触发中断。众所周知,任务就是一个个死循环,没有切换则一直执行程序。而切换又分为两类:自身切换(类似于自废武功)和强制切换(类似于暴力实施)。任务的自身切换是由程序自身触发的,从而使用软中断;强制切换则是达到允许执行时间后,而由硬件强制切换的,从而使用硬中断。
  • 任务的自身切换则是因为任务本身知道自身在等待某个消息,而不想让CPU在自己身上空运行而触发中断;从而任务切换程序里面 OS_Sched() 就是调用的软中断OS_TASK_SW();
  • 任务的强制切换则是因为任务本身的运行寿命到达限制,CPU强制切换到别的任务,让其他任务有执行的机会。从而负责强制切换的为定时器中断( interrupt  66 void OSTickISR(void)),其内部调用函数(void OSTimeTick (void))便负责任务切换的具体事务。然而,不管软中断也好硬中断也罢,它们只是手段;最根本的就是任务堆栈的切换(改变SP的指向)。

    下图表明了任务状态之前切换的关系,调用哪种函数可以进行任务切换。uCOS-II就是通过这些直接或间接调用的系统函数进行任务切换的。

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!