ucosii-1(必做）
- 下载附件，尝试在vc6.0 中编译运行ucos
- 下载附件，尝试在vs2017中编译运行ucos，给出你遇到的问题和解决方式
下载附件，尝试在vc6.0 中编译运行ucos
下载附件，尝试在vs2017中编译运行ucos，给出你遇到的问题和解决方式
- 软件下载失败
ucosii(选做)
- 阅读附件中的代码，回答：
- ucos是如何分层的？
- HAL都有哪些代码？
- 分析任务是如何切换的
ucos是如何分层的
- 1.三层，分别是：上层访问抽象接口层、设备管理核心数据结构层、硬件设备驱动模块层。
- 2.上层访问抽象接口层: 一般的抽象层设计会直接在这一层提供5个访问接口API: DeviceOpen、DevGetch、DevPutch、DevControl. DeviceClose,分别用于打开设备、读设备、写设备、设备控制和关闭设备。而在这个设计里面更改了这种定义模式提供两个公用的接口DeviceOpen 和DeviceClose,同时为不同的外设分别提供特定的抽象接口,在移植的时候利
用这些抽象接口的不变性保证应用程序的可移植能力。这样做的优点更适合于有单片机开发经验的工程人员直接调用。 - 3.设备管理核心数据结构层:这是通用驱动框架的核心，主要用每个设备分配一个设备控制块，通过链表形式进行管理，该链表定义为设备控制块链表DEV_CONTROL_BLOCK* HvlConList。 在这一层， 为系统中的每个硬件设备分配唯一的设备ID。上层应用程序通过将设备ID作为参数传递给DeviceOpen函数实现对相应设备的核心管理数据结构的定位搜索，通过搜索，DeviceOpen函数找到相应设备控制块，申请设备的使用权限，获得相应硬件设备的操作句柄，该句柄指向具体的外设底层操作函数列表，返回该设备句柄;再通过上层抽象接口层提供的接口函数对设备进行访问。
- 4.硬件设备驱动模块层:这-一层是硬件设备驱动模块功能的实现层，对各个硬件设备的驱动在相应的硬件设备驱动模块中完成。各个硬件设备驱动模块,原则上需要实现如下几个函数: DevGetch、 DevPut ch、DevControl,分别完成相应设备的读、写、控制，当然，可以根据具体设备的特性，只实现3个驱动函数的其中一部分，例如，如果某设备不支持写操作，那么就不用实现DevPutch函数。
HAL代码部分
- 硬件抽象层（HAL）
- 硬件抽象层（HAL）是体系结构相关的底层程序
- 处理系统启动、硬件初始化以及中断与异常
- 硬件抽象层对内核其它部分提供统一的调用接口
- HAL可以提供BSP规范，提供跨平台可移植性
- 硬件抽象层具有与硬件密切相关性
- 硬件抽象层具有与操作系统无关性
- 接口定义的功能应包含硬件或系统所需硬件支持的所有功能
- 接口定义简单明了，太多接口函数会增加软件模拟的复杂性
- 具有可测性的接口设计有利于系统的软硬件测试和集成
分析任务是如何切换的
- 下图表明了任务状态之前切换的关系，调用哪种函数可以进行任务切换。uCOS-II就是通过这些直接或间接调用的系统函数进行任务切换的
- 每一个任务都是一个死循环，并且必须在循环内调用系统函数来释放CPU控制权，比如调用系统的延时函数OSTimeDly()延时一段时间，这个时候系统就会知道这个任务被延时了，延时时间记录在TCB中的超时时间dly中，任务调度器将其他任务予以运行。
- 实际的任务调度有两种机制：
- 1.中断级任务调度：任何中断返回时必须调用一个系统函数OSIntExit(void)，进行一次任务调度。比如一般任务调度器通常是一个定时中断，比如1000次每秒，成为OS时钟。每次OS时钟要返回时都会调用OSInitExit()进行任务切换，运行当前就绪的优先级最高任务。一般这个OS时钟的优先级很低，为整个系统优先级倒数第二低(倒数第一低的是Idle Task，空闲任务)，因此实际上这个OS时钟最终并不会返回。
- 2.任务级任务调度：在任务运行中执行一次OS的特定函数，比如前面提到的OSTimeDly()，此函数在返回之前会执行一次任务调度。
因此总的任务调度次数会远远高于OS时钟的轮询频率的。