ucosii-2（选做）
题目要求
阅读附件中的代码，回答：
- ucos是如何分层的？
2.HAL都有哪些代码？ - 分析任务是如何切换的。
1. ucos是如何分层的？
共分三层，分别是：上层访问抽象接口层、设备管理核心数据结构层、硬件设备驱动模块层。
(1)上层访问抽象接口层: 一般的抽象层设计会直接在这一层提供5个访问接口API: DeviceOpen、DevGetch、DevPutch、DevControl. DeviceClose,分别用于打开设备、读设备、写设备、设备控制和关闭设备。而在这个设计里面更改了这种定义模式提供两个公用的接口DeviceOpen 和DeviceClose,同时为不同的外设分别提供特定的抽象接口,在移植的时候利
用这些抽象接口的不变性保证应用程序的可移植能力。这样做的优点更适合于有单片机开发经验的工程人员直接调用。
例如UART提供的抽象接口有: v. _MiniPrintf最小格式化字符串函数;UARTSet串口参数设置。暂时没实再格式化字符输入。
IIC提供的抽象接口有: I2CMasterSend IIC 主模式发送;
I2CMasterReceive IIC 主模式接收; I2CSlaverReceive IIC 从模式接收。
其它的还有SPI，外部中断管理。在里只简单介绍下UART和IIC。
(2)设备管理核心数据结构层:这是通用驱动框架的核心，主要用每个设备分配一个设备控制块，通过链表形式进行管理，该链表定义为设备控制块链表DEV_CONTROL_BLOCK* HvlConList。 在这一层， 为系统中的每个硬件设备分配唯一的设备ID。上层应用程序通过将设备ID作为参数传递给DeviceOpen函数实现对相应设备的核心管理数据结构的定位搜索，通过搜索，DeviceOpen函数找到相应设备控制块，申请设备的使用权限，获得相应硬件设备的操作句柄，该句柄指向具体的外设底层操作函数列表，返回该设备句柄;再通过上层抽象接口层提供的接口函数对设备进行访问。
(3)硬件设备驱动模块层:这-一层是硬件设备驱动模块功能的实现层，对各个硬件设备的驱动在相应的硬件设备驱动模块中完成。各个硬件设备驱动模块,原则上需要实现如下几个函数: DevGetch、 DevPut ch、DevControl,分别完成相应设备的读、写、控制，当然，可以根据具体设备的特性，只实现3个驱动函数的其中一部分，例如，如果某设备不支持写操作，那么就不
用实现DevPutch函数。
2.HAL都有哪些代码？
1.背景介绍：
硬件抽象层技术最初是由Microsoft公司为确保WindowsNT的稳定性和兼容性而提出的。针对过去Windows系列操作系统经常出现的系统死机或崩溃等现象，Microsoft总结发现，程序设计直接与硬件通信，是造成系统不稳定的主要原因。在得出这个结论的基础上，微软公司在WindowsNT上取消了对硬件的直接访问，首先提出了硬件抽象层(Hardware Abstraction Layer，简称HAL)的概念。
2.概念：
硬件抽象层就是：“将硬件差别与操作系统其他层相隔离的一薄层软件，它是通过采用使多种不同硬件在操作系统的其他部分看来是同一种虚拟机的做法来实现的。“后来，这种HAL设计思路被一些嵌入式操作系统参考，其系统内核被分成两层，上层称为“内核(Kernel)”，底层则称为“硬件抽象层”。在EOS中，HAL独立于EOS内核；对于操作系统和应用软件而言，HAL是对底层架构的抽象。综合分析HAL层的代码，可以发现这些代码与底层硬件设备是紧密相关的。因此，可以将硬件抽象层定义为所有依赖于底层硬件的软件。即使有些EOS的HAL在物理上是与系统内核紧密联系的，甚至相互交叉的，但是从功能上可以从分层技术的角度去分析它。
3.作用：
硬件抽象层是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化。它隐藏了特定平台的硬件接口细节,为操作系统提供虚拟硬件平台,使其具有硬件无关性,可在多种平台上进行移植。 从软硬件测试的角度来看，软硬件的测试工作都可分别基于硬件抽象层来完成，使得软硬件测试工作的并行进行成为可能。
硬件抽象层是一个编程层，允许计算机操作系统在逻辑层而不是硬件层与硬件设备交互。Windows 2000就是支持硬件抽象层的操作系统之一。操作系统核心或者硬件驱动程序都可以调用硬件抽象层。无论哪种情况，调用程序都不用了解硬件的具体设计细节，只需要给出抽象层所需的参数即可。
官方给出的HAL库的包含结构：
- stm32f2xx.h主要包含STM32同系列芯片的不同具体型号的定义，是否使用HAL库等的定义，接着，其会根据定义的芯片信号包含具体的芯片型号的头文件：
#if defined(STM32F205xx)
#include "stm32f205xx.h"
#elif defined(STM32F215xx)
#include "stm32f215xx.h"
#elif defined(STM32F207xx)
#include "stm32f207xx.h"
#elif defined(STM32F217xx)
#include "stm32f217xx.h"
#else
#error "Please select first the target STM32F2xx device used in your application (in stm32f2xx.h file)"
#endif
- 紧接着，其会包含stm32f2xx_hal.h:
stm32f2xx_hal.h：stm32f2xx_hal.c/h 主要实现HAL库的初始化、系统滴答相关函数、及CPU的调试模式配置
stm32f2xx_hal_conf.h ：该文件是一个用户级别的配置文件，用来实现对HAL库的裁剪，其位于用户文件目录，不要放在库目录中。
- 接下来对于HAL库的源码文件进行一下说明，HAL库文件名均以stm32f2xx_hal开头，后面加上_外设或者模块名（如：stm32f2xx_hal_adc.c）：
库文件：
stm32f2xx_hal_ppp.c/.h // 主要的外设或者模块的驱动源文件，包含了该外设的通用API
stm32f2xx_hal_ppp_ex.c/.h // 外围设备或模块驱动程序的扩展文件。这组文件中包含特定型号或者系列的芯片的特殊API。以及如果该特定的芯片内部有不同的实现方式，则该文件中的特殊API将覆盖_ppp中的通用API。
stm32f2xx_hal.c/.h // 此文件用于HAL初始化，并且包含DBGMCU、重映射和基于systick的时间延迟等相关的API
其他库文件
用户级别文件：
stm32f2xx_hal_msp_template.c // 只有.c没有.h。它包含用户应用程序中使用的外设的MSP初始化和反初始化（主程序和回调函数）。使用者复制到自己目录下使用模板。
stm32f2xx_hal_conf_template.h // 用户级别的库配置文件模板。使用者复制到自己目录下使用
system_stm32f2xx.c // 此文件主要包含SystemInit()函数，该函数在刚复位及跳到main之前的启动过程中被调用。 **它不在启动时配置系统时钟（与标准库相反）**。 时钟的配置在用户文件中使用HAL API来完成。
startup_stm32f2xx.s // 芯片启动文件，主要包含堆栈定义，终端向量表等
stm32f2xx_it.c/.h // 中断处理函数的相关实现
HAL库最大的特点就是对底层进行了抽象
1.三种编程方式:
HAL库对所有的函数模型也进行了统一。在HAL库中，支持三种编程模式：轮询模式、中断模式、DMA模式（如果外设支持）。其分别对应如下三种类型的函数（以ADC为例）：
HAL_StatusTypeDef HAL_ADC_Start(ADC_HandleTypeDef* hadc);
HAL_StatusTypeDef HAL_ADC_Stop(ADC_HandleTypeDef* hadc);
HAL_StatusTypeDef HAL_ADC_Start_IT(ADC_HandleTypeDef* hadc);
HAL_StatusTypeDef HAL_ADC_Stop_IT(ADC_HandleTypeDef* hadc);
HAL_StatusTypeDef HAL_ADC_Start_DMA(ADC_HandleTypeDef* hadc, uint32_t* pData, uint32_t Length);
HAL_StatusTypeDef HAL_ADC_Stop_DMA(ADC_HandleTypeDef* hadc);
其中，带_IT的表示工作在中断模式下；带_DMA的工作在DMA模式下（注意：DMA模式下也是开中断的）；什么都没带的就是轮询模式（没有开启中断的）。至于使用者使用何种方式，就看自己的选择了。
2.三大回调函数
在HAL库的源码中，到处可见一些以__weak开头的函数，而且这些函数，有些已经被实现了，比如：
__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
/*Configure the SysTick to have interrupt in 1ms time basis*/
HAL_SYSTICK_Config(SystemCoreClock/1000U);
/*Configure the SysTick IRQ priority */
HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority ,0U);
/* Return function status */
return HAL_OK;
}
所有带有__weak关键字的函数表示，就可以有用户自己来实现，如果，外部反现了同名函数，且不带__weak关键字，那么连接器就会采用外部实现的同名函数。HAL库包含如下三种用户回调函数（PPP为外设名）：
- 外设系统级初始化/解除初始化回调函数：HAL_PPP_MspInit()和 HAL_PPP_MspDeInit。例如__weak void HAL_SPI_MspInit(SPI_HandleTypeDef * hspi)。在HAL_PPP_Init() 函数中被调用，用来初始化底层相关的设备（GPIOs, clock, DMA, interrupt）
- 处理完成回调函数：HAL_PPP_ProcessCpltCallback（Process指具体某种处理，如UART的Tx），例如__weak void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef * hspi)。当外设或者DMA工作完成后时，触发中断，该回调函数会在外设中断处理函数或者DMA的中断处理函数中被调用
- 错误处理回调函数：HAL_PPP_ErrorCallback例如__weak void HAL_SPI_ErrorCallback(SPI_HandleTypeDef * hspi)。当外设或者DMA出现错误时，触发终端，该回调函数会在外设中断处理函数或者DMA的中断处理函数中被调用
3.HAL库移植使用
- 复制stm32f2xx_hal_msp_template.c参照该模板，依次实现用到的外设的HAL_PPP_MspInit()和HAL_PPP_MspDeInit。
- 复制stm32f2xx_hal_conf_template.h，用户可以在此文件中自由裁剪，配置HAL库。
- 在使用HAL库时，必须先调用函数：HAL_StatusTypeDef HAL_Init(void)（该函数在stm32f2xx_hal.c中定义，也就意味着第一点中，必须首先实现HAL_MspInit(void)和HAL_MspDeInit(void)）
- HAL库与STD库不同，HAL库使用RCC中的函数来配置系统时钟，用户需要单独写时钟配置函数（STD库默认在system_stm32f2xx.c中）
- 关于中断，HAL提供了中断处理函数，只需要调用HAL提供的中断处理函数。用户自己的代码，不建议先写到中断中，而应该写到HAL提供的回调函数中。
- 对于每一个外设，HAL都提供了回调函数，回调函数用来实现用户自己的代码。整个调用结构由HAL库自己完成。例如：Uart中，HAL提供了void HAL_UART_IRQHandler(UART_HandleTypeDef * huart);函数，用户只需要触发中断后，用户只需要调用该函数即可，同时，自己的代码写在对应的回调函数中即可！如下：
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart);
void HAL_UART_TxHalfCpltCallback(UART_HandleTypeDef *huart);
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart);
void HAL_UART_RxHalfCpltCallback(UART_HandleTypeDef *huart);
void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart);
3. 分析任务是如何切换的。
（1）函数周期与死循环
一般函数的生命周期很简单，从开始调用函数起，直到函数返回，即结束。这样一来就完成了这个函数的使命，它也就不再需要了。对于一般的函数就是这样，但是回过头想想，对于一个系统、OS、或者工业控制中的一个控制器重的系统个，函数返回是很轻易很随便的就能返回吗？返回就意味着函数结束，死亡，若是想系统这样一个很大的函数，它的返回就意味着系统结束。因此，对于系统的函数返回有些时候我们不希望它返回，返回时是需要好好设计的，像嵌入式中的控制程序我们也并不需要它返回，直接关机就好了。因此，一个系统往往就是一个很大的循环，不停的扫描，而我们编程的时候对于这个死循环是需要好好设计的。考虑以下一个控制要求，
@.按键控制电机启、停、正转反转，并每秒发送CAN报文报告当前情况。
我们可以有多种方法实现这一要求：
方法一：每次在循环体重扫描当前按键的电平，从而进入对应的控制电机函数，如果所有电平都没有信号则直接进入下一个循环。发送CAN报文就直接用一个定时中断。这样的好处就是编程简单直白，每次循环进入不同的电机控制函数，坏处很明显，一定要等待到下一个循环才能进入其他的电机控制函数，每次循环的时间不好控制，不管你用函数指针还是if/else来判断，每次循环一定要等待电机动作结束才能进入下一个循环。
方法二：改用外部中断来处理按键。仅当按键按下时触发外部中断，从而控制响应的电机进行操作。这样的好处就是循环体简单，可以仅仅就是一个计数器加一，所有控制都等中断来实现。但这样带来的问题也很明显，就是中断嵌套问题。比如当电机正转时按下停止按钮，这时由于是在中断中，停止按钮是否真的能够得到响应？这就涉及到中断嵌套问题，并不见得所有CPU都能支持中断嵌套。
方法三：采用RTOS的思想，加入任务调度系统。每次任务调度系统就是一个小小的循环，对于各个任务进行轮询，当这次轮询发现某任务是已经就绪的优先级最高的任务，则交给CPU处理，所有中断与任务，任务与任务之间有通讯机制可以交换信息。当然实际上并不仅仅只在任务调度器轮询时才进行任务的切换，实际上的操作比这个复杂一些，我的这篇文章就想以uCOS-II为例讨论RTOS的任务调度系统是怎样执行的。
（2）uCOS-II中的任务调度
回到前面的方法一，二，我们将这种任务称作前后台任务。
后台就是指程序的大循环，程序一定要等到前台任务(可以说中断或某个功能函数)返回才能继续运行下去。而在RTOS中每个任务都有自己的控制块指向改任务，由任务调度器来决定这个时候该运行哪个任务。
所有这些任务控制快(TCB)构成一个双向链表，每个TCB中都有一些控制字，比如一个指向堆栈的指针(sp)，一个表明当前任务状态的位(State)，指明任务被挂起等待的超时时间(dly)，任务的优先级(Prio)，指向事件控制块的指针(Event，事件机制后面会讨论)。一个全局的任务就续表记录了当前任务是否就绪，任务调度器就靠查询任务就绪表寻找到就绪任务中优先级最高的一个任务。
每一个任务都是一个死循环，并且必须在循环内调用系统函数来释放CPU控制权，比如调用系统的延时函数OSTimeDly()延时一段时间，这个时候系统就会知道这个任务被延时了，延时时间记录在TCB中的超时时间dly中，任务调度器将其他任务予以运行。
实际的任务调度有两种机制
1.中断级任务调度：
任何中断返回时必须调用一个系统函数OSIntExit(void)，进行一次任务调度。比如一般任务调度器通常是一个定时中断，比如1000次每秒，成为OS时钟。每次OS时钟要返回时都会调用OSInitExit()进行任务切换，运行当前就绪的优先级最高任务。一般这个OS时钟的优先级很低，为整个系统优先级倒数第二低(倒数第一低的是Idle Task，空闲任务)，因此实际上这个OS时钟最终并不会返回。
2.任务级任务调度：
在任务运行中执行一次OS的特定函数，比如前面提到的OSTimeDly()，此函数在返回之前会执行一次任务调度。
任务调度总结
先简单的利用前面的内容，回过头来看文章一开头的任务，搭建一个完整的电机控制系统。这里我们利用uCOS-II中的通讯机制进行设计。
例：带按键去抖的电机控制任务：
四个外部中断控制电机的启停，正转反转。外部中断服务函数中Post一个信号量给一个专门的电机调度任务，电机调度任务之后Post一个信号量给按键去抖任务，此任务会利用OSTimeDly函数延时一段时间，比如说20ms，再次判断刚才按键的电平值，若任然有按键值则说明不是抖动，可以控制电机，之后利用Resume，恢复一个电机转动的实际任务。
Post信号量启用一个任务跟Resume恢复一个任务是区别很大的，最大的区别是，Post信号量之后只能让接收方运行一次，必须不停的Post才能不停的运行，而Resume一个任务之后，被恢复的任务将一直运行，只能用Suspend将其再次挂起。
下图表明了任务状态之前切换的关系，调用哪种函数可以进行任务切换。uCOS-II就是通过这些直接或间接调用的系统函数进行任务切换的。
