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