目录
1、vTaskStartScheduler
2、xPortStartScheduler
3、vPortSetupTimerInterrupt
4、prvStartFirstTask
5、vPortSVCHandler
在使用 FreeRTOS 的时候，一般的，先创建若干任务，但此刻任务并没有被调度起来，仅仅是创建了，如果想要真正的跑起来，那么还需要调用让调度器跑起来的函数：
vTaskStartScheduler
典型的用法是：
现在就来看看 vTaskStartScheduler 具体做了些什么；
vTaskStartScheduler 的实现在 task.c 中：
在 vTaskStartScheduler 函数中，首先通过 xTaskCreate 创建了一个 Idle 任务，优先级为最低 0；（关于 Idle 任务，后面专门来讲）；
调用 portDISABLE_INTERRUPTS(); 关闭全局中断，因为后面要初始化 TICK 中断；
接着初始化了全局变量：
下一个未阻塞的任务时间为 0xFFFF_FFFF；调度器启动的标志位为 TRUE，代表调度器已经初始化，Tick 的计数器为 0；
接着调用 xPortStartScheduler 来配置和体系结构相关调度，这里主要是一些和处理器相关的寄存器（比如 SYSTICK 等）；这里还是以 Cortex-M3 作为例子，xPortStartScheduler 实现在 port.c 文件：
首先，如果定义 configASSERT_DEFINED 了的话，那么先：
volatile uint8_t * const pucFirstUserPriorityRegister = ( uint8_t * ) (portNVIC_IP_REGISTERS_OFFSET_16 +portFIRST_USER_INTERRUPT_NUMBER );
根据 Cortex-M3 的数据手册可以知道，这个地方获取到的是：NVIC 中断优先级寄存器的基地址，Cortex-M3 的 NVIC 中断优先级寄存器定义如下：
| Name | Access | Base Address | Reset Value | Description |
| PRI_0 | R/W | 0xE000_E400 | 0 (8 bits) | 外中断 #0 的优先级 |
| PRI_1 | R/W | 0xE000_E401 | 0 (8 bits) | 外中断 #1 的优先级 |
| ..... | R/W | ..... | 0 (8 bits) | ..... |
| PRI_239 | R/W | 0xE000_E4EF | 0 (8 bits) | 外中断 #239 的优先级 |
这里注意一下，每个优先级 8 bit；
这里，首先将中断 0 优先级读出来，放置到 ulOriginalPriority；
在往这个 PRI_0 优先级寄存器中写全 1，也就是 0xFF；
再将这个寄存器读出来读到 ucMaxPriorityValue 中；
这样做的目的是为了判断这个中断优先级寄存器哪些 bit 是可写（可配置）的；这个和处理器对这方面的定义相关；
在 Cortex-M3 处理器上，NVIC 中断控制器支持中断优选级配置，它分为了组优先级和组内优先级概念，虽然看起来每个优先级使用 8 bits 来表示，看似最大配置到 0xFF，也就是 255，其实不然，因为引入了组优先级和组内优先级的概念，让这个 8 bits 配置得有点玄机；
优先级组也叫抢占优先级，组内优先级也叫子优先级；抢占优先级高的中断可以嵌套抢占优先级低的，同样抢占优先级的中断，则比较的是子优先级；
Cortex-M3 只是处理器的架构，实际上，芯片公司在利用这种架构实现芯片设计的时候，优先级组和组内优先级，并不是这 8 个 bit 都用到了，因为大量的优先级会增加 NVIC 的复杂度；所以，一般的，具体芯片，PRI_0 的 8 bit 只会用到一部分的 bit，其中中用几个 bit 来表示抢占优先级，用几个 bit 来表示子优先级，这个是可以配置的；具体一点的话，比如：
一款 Cortex-M3 内核做的处理器，它在设计的时候，就定义了 PRI_x 优先级的 8 bit，只有高 3 bit 有效：
一款 Cortex-M3 内核做的处理器，它在设计的时候，就定义了 PRI_x 优先级的 8 bit，只有高 4 bit 有效：
比如ST的STM32F1xx和F4xx只使用了这个8位中的高4位[7:4]，低四位取零，这样2^4=16，只能表示16级中断嵌套。
那么用高 4 bit 表示优先级，那么这 4 个 bit 哪几个 bit 代表抢占优先级？哪几个 bit 代表子优先级呢？
这个由另一个寄存器的值说了算，SCB->AIRCR[10:8]（0xE000_ED00） 寄存器的 PRIGROUP 的值说了算；
| Group | AIRCR[10:8] Value | PRI_x bit[7:4] 分配情况 | 分配结果 |
| 0 | 3‘b111 | 0:4 | 0位抢占优先级，4位响应优先级 |
| 1 | 3‘b110 | 1:3 | 1位抢占优先级，3位响应优先级 |
| 2 | 3‘b101 | 2:2 | 2位抢占优先级，2位响应优先级 |
| 3 | 3‘b100 | 3:1 | 3位抢占优先级，1位响应优先级 |
| 4 | 3‘b011 | 4:0 | 4位抢占优先级，0位响应优先 |
Cortex-M3 中断优先级数值越大，表示优先级越低。而 FreeRTOS 的任务优先级则与之相反：优先级数值越大的任务，优先级越高。
好了，言归正传，这里应该说清楚为何要写进去 0xF，在读出来，就是因为这 8bit 并不是全部都用了，这样便可以得到最大支持的优先级个数 ucMaxPriorityValue；
接着计算最大优先级组的值，从读出来有效的 PRI_0 的最高位开始判断（因为）优先级组和子优先级是从最高位开始；
接着配置 PendSV 和 SysTick 的优先级为最低：
调用 vPortSetupTimerInterrupt 配置 SysTick，这个是操作系统的心跳，和体系架构相关：
STM32 的 SysTick 是一个向下计数的计数器，可以配置产生 Tick 中断；
configSYSTICK_CLOCK_HZ 定义了 CPU 的时钟频率，需要和处理器同步；
configTICK_RATE_HZ 定义了 Tick 来的频率，比如：
configTICK_RATE_HZ为100，则系统节拍时钟周期为10ms，设置宏configTICK_RATE_HZ为1000，则系统节拍时钟周期为1ms
太频繁的 Tick 中断会导致过频繁的上下文切换，增加系统负担，过于长的上下文切换，会导致任务响应不及时；
典型的，STM32 的 configTICK_RATE_HZ 为 1000，也就是 1ms 一次 Tick 中断；
然后配置寄存器，使能了 SysTick，使能了 SysTick 中断；
接着初始化了嵌套深度：
uxCriticalNesting = 0;
最后调用了 prvStartFirstTask(); 启动第一个任务，它的实现使用汇编写的：
PRESERVE8 用于 8 字节对齐；
从 0xE000ED08 获取向量表的偏移，为啥要获得向量表呢？因为向量表的第一个是 MSP 指针！
取 MSP 的初始值的思路是先根据向量表的位置寄存器 VTOR (0xE000ED08) 来获取向量表存储的地址；
在根据向量表存储的地址，来访问第一个元素，也就是初始的 MSP；
此刻呢，将初始的 MSP 存入到了 R0 中，通过 MSR 指令，写到 MSP 中：
打个比方，Cortex-M3 处理器，上电默认进入线程的特权模式，使用 MSP 作为堆栈指针，从上电跑到这里，经过一系列的函数调用，出栈，入栈，MSP 自然已经不是最开始的初始化的位置，这里通过 MSR 重新复制了 MSP，岂不是堆栈都没了么？是的，因为这是一条不归路，代码跑到这里，首先不会返回，之前压栈的内容再也不会用到，所以破坏之前的堆栈也没关系；其次既然不会用到，那么岂不是之前的压栈空间都废了，如果把 MSP 重新初始化到头，就 OK 了嘛，大不了就是破坏了堆栈，反正再也回不去啦；
OK，堆栈指针 MSP 刷完，赋予了新的生命，此刻开中断，开异常，刷流水线；
调用 svc 并传入系统调用号为 0 手动拉 SVC 中断；
手动拉了 SVC 中断，而且开启了中断，那么就会进入它的 ISR：vPortSVCHandler，它的实现也是和处理器体系结构相关，在 port.c 中实现：
首先还是 PRESERVE8 的 8字节对齐操作；
还记得吗，pxCurrentTCB 指向的是最高优先级的 Ready 状态的任务指针；
根据 pxCurrentTCB 获取到对应 TCB 的地址；然后获取第一个成员变量，也就是当前栈顶地址 pxTopOfStack；这个值在任务分配的时候，就已经计算好，并且模拟的 Cortex-M3 的异常入栈顺序，手动入栈了；
使用 LDMIA 指令，以 pxTopOfStack 开始顺序出栈，先出 R4~R11（在创建任务的时候，最后入栈的就是这些个），同时 R0 递增；
将此刻的 R0 赋值给 PSP（因为弹栈的时候，处理器会按照入栈的顺序去取 xPSR、PC、LR、R12、R3、R2、R1、R0，而这些寄存器在我们创建任务的时候已经手动压栈）；
ISB 指令屏障，刷流水线；
将 BASEPRI 寄存器赋值为 0，也就是允许任何中断；
ORR 指令时按位或，所以 ORR R14, #0xd 相当于 R14 |= 0xd；这个操作也和体系架构相关，R14 是链接寄存器 LR，在 ISR 中（此刻我们在 SVC 的 ISR 中），它记录了异常返回值 EXC_RETURN（更多细节参考《Cortex-M3 处理器窥探》Chapter 7.4）；
因为当前在 ISR 中还是使用的 MSP，启动任务后，我们期望在任务执行过程中，处于线程模式，并使用 PSP（前面几行已经给 PSP 赋值了），所以我们需要将 LR 设计成为 0xFFFF_FFFD，让处理器知道返回的时候呢，使用线程模式+PSP堆栈；
最后执行 bx R14，告诉处理器 ISR 完成，需要返回，此刻处理器便会使用 PSP 做为堆栈指针，进行出栈操作，将xPSR、PC、LR、R12、R3~R0 出栈，初始化的时候，PC 被我们赋值成为了执行任务的函数的入口，所以呢，就正常跳入到了优先级最高的 Ready 状态的第一个任务的入口函数了；
处理器相关的部分，可以参考《Cortex-M3 处理器窥探》，创建任务的部分参考《FreeRTOS --（8）任务管理之创建任务》
大致的流程如下：
紫色部分，是和体系架构相关的，黑色的是开关中断的地方，蓝色的是 FreeRTOS 的代码；