ucosii- II

一、ucos是如何分层的

返回目录

二、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               // 中断处理函数的相关实现
    main.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模式下也是开中断的）；什么都没带的就是轮询模式（没有开启中断的）。至于使用者使用何种方式，就看自己的选择了。

1. 三大回调函数
   在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的中断处理函数中被调用

1. 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);

相关文件可参考
返回目录

三、分析任务是如何切换

在我们理解任务切换概念时，首先说说ucOS的系统模式-前后台模式。

这种系统可称为前后台系统或超循环系统(Super-Loops)。应用程序是一个无限的循环，循环中调用相应的函数完成相应的操作，这部分可以看成后台行为(background)。中断服务程序处理异步事件，这部分可以看成前台行 foreground。后台也可以叫做任务级。前台也叫中断级。时间相关性很强的关键操作(Critical operation)一定是靠中断服务来保证的。因为中断服务提供的信息一直要等到后台程序走到该处理这个信息这一步时才能得到处理，这种系统在处理信息的及时性上，比实际可以做到的要差。这个指标称作任务级响应时间。最坏情况下的任务级响应时间取决于整个循环的执行时间。因为循环的执行时间不是常数，程序经过某一特定部分的准确时间也是不能确定的。进而，如果程序修改了，循环的时序也会受到影响。

因为UCOS-II是基于任务运行的。一个任务，也称作一个线程，是一个简单的程序，该程序可以认为 CPU 完全只属该程序自己。实时应用程序的设计过程，包括如何把问题分割成多个任务，每个任务都是整个应用的某一部分，每个任务被赋予一定的优先级，有它自己的一套 CPU 寄存器和自己的栈空间(如下图所示)。

可以这么理解，UCOS-II的每一个任务都有一个CPU，任务在运行时占用CPU的全部资源，同时拥有自己的一套寄存器，当任务执行完毕后（时间片到），他把自己的CPU寄存器所有内容保存到自己的堆栈中，同时把CPU让给别的任务，那么得到CPU使用权的任务把自己的CPU寄存器从自己的堆栈中放到真正的CPU寄存器中开始运行，就这样周而复始。

每个任务都是一个无限的循环。每个任务都处在以下 5种状态之一的状态下，这5种状态是：

• 休眠态：休眠态相当于该任务驻留在内存中，但并不被多任务内核所调度。就绪意味着该任务已经准备好，可以运行了，但由于该任务的优先级比正在运行的任务的优先级低，还暂时不能运行。
• 就绪态：
• 运行态：运行态的任务是指该任务掌握了 CPU 的控制权，正在运行中。
• 挂起态：挂起状态也可以叫做等待事件态WAITING，指该任务在等待，等待某一事件的发生， （例如等待某外设的 I/O 操作，等待某共享资源由暂不能使用变成能使用状态， 等待定时脉冲的到来或等待超时信号的到来以结束目前的等待，等等）
• 被中断态：发生中断时，CPU提供相应的中断服务，原来正在运行的任务暂不能运行，就进入了被中断状态。
  如下图表示μC/OS-Ⅱ中一些函数提供的服务，这些函数使任务从一种状态变到另一种状态。
  

在理解了这几种任务任务状态之后，任务中断就很好理解了：

我们可以简单的把每一次任务的切换当成一次中断，这个中断不同于我们在使用前后台模式时的中断，那个中断是硬件中断，中断时需要保存的CPU寄存器是由硬件实现的，而在UCOS中的任务切换是软中断，CPU保存了必要的寄存器后在切换时系统会在保存任务使用的寄存器。

• 切换
  任务的自身切换则是因为任务本身知道自身在等待某个消息，而不想让CPU在自己身上空运行而触发中断；从而任务切换程序里面 OS_Sched() 就是调用的软中断OS_TASK_SW();
  任务的强制切换则是因为任务本身的运行寿命到达限制，CPU强制切换到别的任务，让其他任务有执行的机会。从而负责强制切换的为定时器中断（ interrupt 66 void OSTickISR(void)），其内部调用函数（void OSTimeTick (void)）便负责任务切换的具体事务。
  然而，不管软中断也好硬中断也罢，它们只是手段；最根本的就是任务堆栈的切换（改变SP的指向）。

返回目录