ucosii-2（选做）

1.ucos是如何分层的？

Ucos是个很好的平台，他可以让所有的功能化分为多个模块。在其之间有很好的独立性，就是说只要给我个任务，就可以完成一个功能。可是任务间有时也会牵扯到数据交互的问题，这个时候就使用模块接口。别人在加载您的模块接口头文件时后，所有的数据都可以通过接口传递了，这样块的封装就可以做的非常独立。这样的话功能的删除和增加会变的很简单。不用再为两个模块 重复的枚举，宏而担心。因为所有的变量，都是本地的（静态的）。哈哈，本地模块，就可以随心所欲，当然在保证编程规范的前提下。最主要的是接口函数，要清晰明了。别人看一眼也大概是什么功能，就很到位了。
Ucos以往是采用四层的方式，硬件相关层，驱动接口层，应用接口层，应用层。好的分层会让软件开发相对独立化，分工同步进行。

所有的硬件被抽象化，应用层的程序，基本上不用再考虑硬件的问题，也就是说，在硬件完全更换的情况下，只要硬件被更新，完全可以等同原先的所实现的功能。
这就要做到完全的划分，下面逐步对这几层做一个说明。

硬件相关层：

在这层中，要尽量所有硬件相关都囊括在其中。不管是GPIO还是定时器，或串行接口。只要提供标准统一的接口，就可以让上层会因此而变的很潇洒。这其中有三个最为重要的接口Open,Close,Ctrl。 Open主要来完成对应硬件初始化，形参中包括了些，初始化的相关参数。Close失能硬件。Ctrl来实现一些控制的修改如：优先级，中断回调函数等等，硬件的不同，内容也大为不同。

驱动接口层：

其实在上一层也算是驱动层，只不过因为硬件相关，而把他分离。这层中会用到一个或多个硬件层的接口，进行组合来实现特定功能的程序。这部分程序可举例进行说明。以Flash为列，它这里主要调用硬件层的SPI函数接口，但是主要的写，读指令都是在这里函数中完成的。在这层中需要提供5个标准统一的接口函数：

XXXOpen

XXXClose

XXXWrite

XXXRead

XXXIoCtl

没有被用到的函数，可以为空。本来还需要Install函数来进行动态加载和删除，因为stm32内存一般都很有限，所以舍弃动态分配。而把这5个函数用常量的形式直接编译到ROM中。在驱动的抽象接口层中可以做选择，哪些驱动要加载到内核，哪些不需要。不要的驱动不参与编译。这样有限的资源 可以得到合理的应用。这一层大部分工作可以说属于一次性投入。

应用接口层：

主要连接驱动和应用。又是连接应用层模块与模块之间的一层， 这一块有很强的特殊性，第一包括了驱动抽象接口层，第二包括了模块与模块的接口层。第三又与应用层密不可分。

先说下驱动抽象接口，在驱动层时也有提过，这个接口 其实就是通过ID去访问那ID对应的那五个函数。抽象接口也是一次性投入的函数，在设计时对其可靠性要很重视。

模块与模块的接口层，包括模块的接口头文件，这些头文件要求是非常独立的，不能加载模块内的内部头文件，应该包括接口函数的函数声明，在接口中尽量少用到全局变量。如果非要用到可以使用函数的方式进行传递，或ucos消息队列方式。最好用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               // 中断处理函数的相关实现

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

三、分析任务是如何切换

在我们理解任务切换概念时，首先说说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的指向）。

标签：ucosii,选做,HAL,函数,中断,硬件,stm32f2xx,任务
来源： https://www.cnblogs.com/L1079991001/p/12109546.html