标签：inf 应该 gpio 独立 sch 调度 形参 目录 window
分为四层：
应用层
该层中所有模块都算是应用层。模块内所有变量，或函数（接口除处）应该都本地化。在模块内可以有本模块化共用的主头文件，来方便本模块的维护。对硬件的访问其实直接调用应用接口就可完成。
背景介绍：
硬件抽象层技术最初是由Microsoft公司为确保WindowsNT的稳定性和兼容性而提出的。针对过去Windows系列操作系统经常出现的系统死机或崩溃等现象，Microsoft总结发现，程序设计直接与硬件通信，是造成系统不稳定的主要原因。在得出这个结论的基础上，微软公司在WindowsNT上取消了对硬件的直接访问，首先提出了硬件抽象层(Hardware Abstraction Layer，简称HAL)的概念。
概念：
硬件抽象层就是：“将硬件差别与操作系统其他层相隔离的一薄层软件，它是通过采用使多种不同硬件在操作系统的其他部分看来是同一种虚拟机的做法来实现的。“后来，这种HAL设计思路被一些嵌入式操作系统参考，其系统内核被分成两层，上层称为“内核(Kernel)”，底层则称为“硬件抽象层”。在EOS中，HAL独立于EOS内核；对于操作系统和应用软件而言，HAL是对底层架构的抽象。综合分析HAL层的代码，可以发现这些代码与底层硬件设备是紧密相关的。因此，可以将硬件抽象层定义为所有依赖于底层硬件的软件。即使有些EOS的HAL在物理上是与系统内核紧密联系的，甚至相互交叉的，但是从功能上可以从分层技术的角度去分析它。
作用：
硬件抽象层是位于操作系统内核与硬件电路之间的接口层，其目的在于将硬件抽象化。它隐藏了特定平台的硬件接口细节,为操作系统提供虚拟硬件平台,使其具有硬件无关性,可在多种平台上进行移植。 从软硬件测试的角度来看，软硬件的测试工作都可分别基于硬件抽象层来完成，使得软硬件测试工作的并行进行成为可能。
硬件抽象层是一个编程层，允许计算机操作系统在逻辑层而不是硬件层与硬件设备交互。Windows 2000就是支持硬件抽象层的操作系统之一。操作系统核心或者硬件驱动程序都可以调用硬件抽象层。无论哪种情况，调用程序都不用了解硬件的具体设计细节，只需要给出抽象层所需的参数即可。
#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 //在我们理解任务切换概念时，首先说说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的指向）。
2019-2020 《信息安全系统设计》20175212童皓桢 ucosii-2
标签：inf 应该 gpio 独立 sch 调度 形参 目录 window
原文地址：https://www.cnblogs.com/thz666/p/12114522.html
