基于Cortex-M的RTOS上下文切换详解及FreeRTOS实例

已于 2024-03-27 10:26:15 修改
阅读量2.6k 收藏 12
点赞数 4
分类专栏： ARM 文章标签： arm
于 2022-12-06 17:21:43 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tilblackout/article/details/128135347
版权

文章目录


    在实时操作系统中，上下文切换指的是从一个任务切换到另一个任务，与此同时需要保存任务的上下文，以确保在下一次被切换的任务重新调度时能恢复原有的任务状态。
    本文将从硬件上来探讨在ARM Cortex-M的MCU上的上下文切换是如何进行的，然后分析FreeRTOS中是如何实现上下文切换的。

1 Cortex-M MCU特性

在了解上下文切换之前，肯定需要先了解MCU的架构才能知道如何实现上下文切换的功能，这里以Cortex-M为例进行分析。

1.1 操作模式

    当MCU运行于异常处理回调函数，如ISR中时，MCU处于Handler Mode；其它时候MCU都处于Thread Mode。
    系统内核可以在特权/非特权模式下运行，有一些特定的指令和操作只能在特权模式下运行。比如在非特权模式下，用户无法访问NVIC寄存器，而在Handler Mode下，内核总是处于特权模式；而在Thread Mode下，程序可以在特权/非特权模式下切换。只有当程序处于Handler Mode时，才能将Thread Mode中的非特权模式切换为特权模式。

1.2 寄存器

1.2.1 核心寄存器

AAPCS(ARM Architecture Procedure Calling Standard)定义的寄存器如下：

寄存器别名描述
r15PCProgram Counter(Current Instruction)
r14LRLink Register(Return Address)
r13SPStack Pointer
r12IPIntra-Procedure-call scratch register
r11v8Variable-register 8
r10v7Variable-register 7
r9v6,SB,TRVariable-register 6 or Platform Register
r8~r4v5~v1Variable-register 5 ~ Variable-register 1
r3~r0a4~a1Argument/scratch register 4 ~ Argument/scratch register 1
  • 大部分的编译器都能识别上面的别名，比如下面两个语句都可以将r0寄存器置0：mov r0, #0和mov a1, #0
  • 在AAPCS specification中提到对于有固定作用的寄存器需要使用大小描述，比如程序计数器是PC而不是pc

(1) r12(Intra-Procedure-call Scratch Register)
该寄存器有32位，对于汇编中的跳转指令bl，它并不能跳转到整个程序的地址空间，因为指令中的前几位是对指令进行编码的，所以无法跳转到整个32位的地址。所以如果要跳转到一个在地址空间中很大的地址，就需要传递一个由编译器产生的shim函数，r12是唯一的一个可以用在这个传递过程中的寄存器且计算机不需要保存原来的状态。

(2)r9(Platform Register)
在绝大多数应用中，r9也同样在一个函数运行的过程中作为一个Variable-register，但是在下面两种情况下，r9寄存器需要在函数调用的过程中被保存。
①r9用作thread register：该寄存器保存当前线程局部存储的上下文指针。
②r9用作static base：通常情况下，当编译代码时，代码依赖于它运行的位置。但是，对于某些应用程序，我们可能希望能够从任意位置运行代码。比如，我们想把一个函数从flash加载到RAM中执行。这就需要编写位置无关代码，在这个过程中就需要查找全局和静态数据的地址，这些地址都存储在一个全局偏移表中(Global Offset Table)，而这个表的基地址就保存在r9寄存器中。

  • 使用这个特性需要在编译过程中添加编译选项-fpic和-msingle-pic-base

1.2.2 浮点寄存器(Floating Point registers)

    在Cortex M4、Cortex M7和Cortex M33中支持添加一个可选的浮点扩展单元来支持MCU的浮点运算。Cortex-M设备可以实现两种浮点扩展FPv4-SP和FPv5，这里不对这两种扩展进行详细描述，但这两种扩展都为FPU操作提供相同的寄存器集。

  • 使能不同的浮点扩展，需要在编译时添加相关的浮点编译选项：GCC浮点编译选项

他们可以通过两种方式被寻址：

  1. 作为32位(单字)寄存器(s0 - s31)
  2. 作为16位(双字)寄存器(d0 - d16)
  • 其中s(x)和s(x+1)组成d(x/2)寄存器，如s2和s3组成了d1寄存器

当使能FP扩展时，还会用到一个特殊的寄存器FPSCR，它允许配置和控制浮点操作的选项。默认情况下，即使MCU实现了FP扩展，当设备复位时，该功能是禁用的。要启用它，必须往0xE000ED88地址处的协处理器访问控制寄存器(CPACR)的相关位进行配置。
在这里插入图片描述
其中，CP10和CP11用于控制使能浮点运算。这两个字段都是2位，定义如下：

bit1bit0描述
00FPU Disabled (default). Any access generates a UsageFault.
01Privileged access only. Any unprivileged access generates a UsageFault.
10Reserved
11Privileged and unprivileged access allowed.

其中CP10和CP11字段的内容必须相同：
在这里插入图片描述

1.2.3 特殊寄存器(Special Registers)

特殊寄存器的访问需要使用汇编指令MSR来写，MRS来读。这里不对特殊据存器进行深入讨论，ARMv7 Architecture Reference Manual中有对特殊寄存器的相关描述：
Special Register
有一些关于读写特殊寄存器的Privilege需要注意：
(1)MRS(手册B5.2.2)
在这里插入图片描述

  • 如果非特权模式的代码尝试读取任何堆栈指针、优先级掩码或IPSR寄存器，都将返回0。

(2)MSR(手册5.2.3)
在这里插入图片描述

  • 处理器会忽略非特权线程模式下对所有的堆栈指针的写操作，包括EPSR、IPSR、masks(即CONTROL)寄存器。如果在特权线程模式下向CONTROL寄存器的nPRIV位写1，处理器会切换到非特权线程模式执行，并忽略之后对Special Register的写入操作。

对于上下文切换，最重要的特殊寄存器之一就是CONTROL寄存器。在ARMv8-M架构中又对此寄存器的功能进行了增加，以ARMv8-M架构中的CONTROL寄存器进行说明：

在这里插入图片描述

  • SFPA：浮点安全选项，需要打开ARMv8-M Security Extension选项
  • FPCA：指示浮点上下文是否处于激活状态
  • SPSEL：控制正在使用的堆栈指针
  • nPriv：控制线程模式是作为特权还是非特权操作。1为非特权模式，0为特权模式

1.3 上下文堆栈指针

    Cortex-M架构实现了两个栈，分别是Main Stack(在MSP寄存器中查看)和Process Stack(在PSP寄存器中查看)。每次系统复位后，默认是采用MSP，它的初始值通过中断向量表中的第一个word来设置。访问r13(SP)寄存器将返回当前使能的堆栈指针。
    在Handler Mode下，总是使用MSP；在Thread Mode下，堆栈指针可以为上述二种之一：

  • 将CONTROL寄存器中的SPSEL位置1，上下文堆栈将从MSP切换为PSP
  • 如果发生exception错误，相关返回值EXC_RETURN 将保存在LR寄存器中

1.4 上下文状态堆栈

根据AAPCS，在被调用函数返回之前，需要将特定的寄存器集(r4-r8, r10,r11,SP，用作v6的r9)恢复到调用函数前的原始值，这些寄存器由被调函数保存，称为callee-saved register，也就是说如果被调函数中有使用到这些寄存器，则需要在函数入口处保存，在函数出口处恢复。
对于函数的调用者，即硬件上在进入异常程序之前，它会自动保存r0-r3,r12,LR(r14),PC(r15)和xPSR寄存器(按顺序从后往前压,即先压xPSR)，这些寄存器称为caller-saved register。

  • xPSR保存了最近使用汇编指令保存的状态，xPSR将APSR、IPSR和EPSR组合在一个32位寄存器中
  • 除此之外，如果还用到了FPU，则caller将保存s0-s15，而callee需要保存s16-s31

AAPCS还强制要求：堆栈必须双字对齐。对于“公共接口”，也就是说，当调用一个函数时，它的堆栈指针总是8字节对齐的。考虑到所有这些因素，又为了保证中断中执行的程序ABI(Application Binary Interface)兼容，ARM架构需要对齐堆栈并保存调用函数负责保存的寄存器状态。

  • 如果系统在使用PSP的线程模式下发生异常，数据将被压入PSP上；如果系统已经在处理另一个异常服务，并且被一个优先级更高的异常抢占，则数据将被压入MSP。

ARMv7 Architecture Reference Manual中描述了在异常处理的入口处自动保存上下文状态后堆栈的变化：
在这里插入图片描述
可以看到，如果原来的SP是四字节对齐的，将会保留一个字以满足字节对齐。

  • 在异常处理入口处，ARM硬件使用堆栈的xPSR的第9位来指示是否添加了4个字节的填充以使堆栈对齐到8字节边界上。

1.4.1 浮点扩展和上下文状态堆栈

当浮点(FP)扩展使能时，AAPCS规定子例程调用必须保存s16-s31，而不需要保存s0-s15。此外，与PSR寄存器类似，FPU的状态需要被保存，因此FPSCR也需要被存储。这意味着需要在进入异常时多压入17个寄存器(68字节)。对于某些工程来说，这可能会影响性能或内存问题，所以ARM就允许我们通过位于0xE000EF34的FPCCR(Floating Point Context Control Register)寄存器配置上下文如何保存。
在这里插入图片描述
对于上下文状态的堆栈信息，我们主要介绍以下几个字段：

  • ASPEN：默认为1，此时任何浮点指令的执行都会将CONTROL寄存器中的FPCA为置1
  • LSPEN：默认为1，此时会使能Lazy Context Save。这意味着在进入异常时，堆栈将为调用者保存的浮点寄存器(s0-s15和FPSCR)保留空间。但默认情况下数据实际上不会被压栈，当且仅当在异常中执行浮点指令时才会压入这些寄存器。这意味着只要在中断不使用FPU，就可以不用将68字节的浮点状态压入堆栈。

当FPU使能的时候(CONTROL中的FPCA为1)，扩展帧将会由硬件保存：
在这里插入图片描述

  • 如果启用了FPU但没有执行浮点指令或禁用了CONTROL寄存器中的ASPEN，则只保存基本帧。

1.4.2 异常返回

最后，为了让硬件知道退出异常时要恢复什么状态，需要将一个称为EXC_RETURN的特殊值加载到LR寄存器中。
在ARMv7 Architecture Reference Manual的B1.5.6 Exception entry behavior中，给出了下面的伪代码，它描述了当前正在使用的堆栈帧(扩展的/基本的)，以及在异常发生之前正在使用的堆栈指针是什么。
在这里插入图片描述
当从异常返回时，EXC_RETURN的可能值如下:

EXC_RETURNReturn ToReturn Stack
0xFFFFFFF1Handler ModeMSP
0xFFFFFFF9Thread ModeMSP
0xFFFFFFFDThread ModePSP
0xFFFFFFE1Handler Mode(FPU Extended Frame)MSP
0xFFFFFFE9Thread Mode(FPU Extended Frame)MSP
0xFFFFFFEDThread Mode(FPU Extended Frame)PSP

2 FreeRTOS的上下文切换

当RTOS调度程序决定运行一个与当前运行的任务不同的任务时，它将触发上下文切换。从一个任务切换到另一个任务时，需要以某种方式保留当前任务的状态，包括任务的执行状态(例如在互斥锁上阻塞，休眠等)和硬件寄存器的值等信息。接下来，将以FreeRTOS(v10.2.0)为例，来说明在Cortex-M内核的设备中是如何进行上下文切换的。

2.1 上下文切换代码分析

FreeRTOS调度器通过利用内置的SysTick和PendSV中断工作。SysTick被配置为定期触发，每次触发时，(xTaskIncrementTick函数)都会检查是否需要上下文切换。

void xPortSysTickHandler( void )
{
    /* The SysTick runs at the lowest interrupt priority, so when this interrupt
    executes all interrupts must be unmasked.  There is therefore no need to
    save and then restore the interrupt mask value as its value is already
    known. */
    portDISABLE_INTERRUPTS();
    {
        /* Increment the RTOS tick. */
        if( xTaskIncrementTick() != pdFALSE )
        {
            /* A context switch is required.  Context switching is performed in
            the PendSV interrupt.  Pend the PendSV interrupt. */
            portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;
        }
    }
    portENABLE_INTERRUPTS();
}

除此之外，上下文切换也会在任务放弃占用CPU时发生(portYIELD)。这两种上下文切换的方式最终都会触发PendSV异常。

现在来看一下PendSV异常处理程序的汇编代码：

// portasm.S
xPortPendSVHandler:
	mrs r0, psp
	isb
	/* Get the location of the current TCB. */
	ldr	r3, =pxCurrentTCB
	ldr	r2, [r3]

	/* Is the task using the FPU context?  If so, push high vfp registers. */
	tst r14, #0x10
	it eq
	vstmdbeq r0!, {s16-s31}

	/* Save the core registers. */
	stmdb r0!, {r4-r11, r14}

	/* Save the new top of stack into the first member of the TCB. */
	str r0, [r2]

	stmdb sp!, {r0, r3}
	mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
	msr basepri, r0
	dsb
	isb
	bl vTaskSwitchContext
	mov r0, #0
	msr basepri, r0
	ldmia sp!, {r0, r3}

	/* The first item in pxCurrentTCB is the task top of stack. */
	ldr r1, [r3]
	ldr r0, [r1]

	/* Pop the core registers. */
	ldmia r0!, {r4-r11, r14}

	/* Is the task using the FPU context?  If so, pop the high vfp registers
	too. */
	tst r14, #0x10
	it eq
	vldmiaeq r0!, {s16-s31}

	msr psp, r0
	isb
	#ifdef WORKAROUND_PMU_CM001 /* XMC4000 specific errata */
		#if WORKAROUND_PMU_CM001 == 1
			push { r14 }
			pop { pc }
		#endif
	#endif

	bx r14

现在来分析一下上面的代码：

mrs r0, psp
isb

首先将psp(该栈在之前的异常入口用到)保存到r0中，然后紧跟着一个isb(Instruction Synchronization Barrier)，这是为了刷新指令流水线以保证后面的指令被重新获取。

ldr     r3, pxCurrentTCBConst
ldr     r2, [r3]

然后将task.c中定义的pxCurrentTCB变量赋值给r3，再将pxCurrentTCB的值加载到r2中。实际上pxCurrentTCB为一个TCB_t *的指针，它保存了当前正在运行的任务的TCB的地址，所以将这个TCB结构体的地址赋值给r2。

tst r14, #0x10
it eq
vstmdbeq r0!, {s16-s31}

这组指令检查FPU是否激活。之前有提到，在进入异常时，LR寄存器会保存EXC_RETURN，从EXC_RETURN 的值来看，第5位为0时表示FPU使能。下面对于上面的指令进行分析：
①tst(test)：在寄存器和立即数之间进行与操作，与操作的结果会保存在PSR寄存器中，如果结果为0，该寄存器的零标志位将会置位
②it(if then)：根据EPSR中的IT标志位有条件地执行进一步的指令，It eq就是判断最后一次比较的结果是零
③vstmdbeq r0!, {s16-s31}：将被调用者的浮点寄存器保存到r0(前面赋值为psp)中
在我的例子中，没有使能FPU，故结果不是零，所以这条指令应该被跳过。

/* Save the core registers. */
stmdb r0!, {r4-r11, r14}

/* Save the new top of stack into the first member of the TCB. */
str r0, [r2]

接着使用stmdb(Store Multiple Decrement Before stores multiple registers)指令将所有callee可能用到的寄存器压入psp，感叹号表示r0等于最终压栈之后的栈顶地址，stmdb的压栈顺序为后面的参数先压，即先压r14，再压r11…最后将r0的值写入pxCurrentTCB指针的第一个字中(栈顶地址)。

  • pxCurrentTCB的类型为tskTaskControlBlock，其第一个字段为volatile StackType_t *pxTopOfStack，其为指针，故大小为一个字
  • 进入异常后，硬件会自动将PSR、PC、LR、r12、r3~r0按顺序压栈，即保存进入PendSV异常之前的寄存器状态
  • r14即LR寄存器，稍后调用的C函数vTaskSwitchContext会修改LR为它的下一条指令的地址，调用完需要恢复，后面的bx r14会用到，故需要保存

现在我们已经保存了原始任务的所有寄存器状态，现在是时候将上下文切换到一个新任务了：

stmdb sp!, {r0, r3}
mov r0, #configMAX_SYSCALL_INTERRUPT_PRIORITY
msr basepri, r0
dsb
isb
bl vTaskSwitchContext

可以看到最后调用C函数vTaskSwitchContext来决定下一个执行的任务，所以前面的代码就是为调用这个函数做准备。首先将r0和r3这两个参数寄存器保存到正在使用的堆栈中(MSP或PSP)，然后设置basepri寄存器，该寄存器可以让优先级比设置值(这里是configMAX_SYSCALL_INTERRUPT_PRIORITY)低的中断被屏蔽，以保证vTaskSwitchContext 不会被其它中断打断。

  • 实际上调用vTaskSwitchContext后不止是r0和r3的值会改变，r1和r2等寄存器都有可能会因为vTaskSwitchContext的调用而改变。但是后面的汇编代码只用到了r0和r3，故这里保存这两个寄存器。
    • 实际上保存r3是因为它的值为pxCurrentTCB的地址，后面要用到。而对于r0来说，指向的是前一个任务的PSP，在后面的代码中也没有用到。所以这里实际上不压r0(后面的代码也不用出栈r0)也不会有错误。
  • 如果没有屏蔽其它中断，且在中断中有调用FreeRTOS的*_FromISR()函数，会修改原有的上下文数据结构，程序就可能会崩溃。

当修改basepri寄存器降低有效执行级别时，需要执行isb指令以让新的优先级对未来的指令可见，否则还是有一定概率被嵌套。dsb指令在这并不是显式必须的。

  • dsb：等待存储器访问操作执行完毕
  • isb：刷新流水线的指令，保证都执行完毕

最后，进入到C函数vTaskSwitchContext中，当这个函数返回时，pxCurrentTCB 将指向切换后的新任务。

/*
 * THIS FUNCTION MUST NOT BE USED FROM APPLICATION CODE.  IT IS ONLY
 * INTENDED FOR USE WHEN IMPLEMENTING A PORT OF THE SCHEDULER AND IS
 * AN INTERFACE WHICH IS FOR THE EXCLUSIVE USE OF THE SCHEDULER.
 *
 * Sets the pointer to the current TCB to the TCB of the highest priority task
 * that is ready to run.
 */
portDONT_DISCARD void vTaskSwitchContext( void ) PRIVILEGED_FUNCTION;

从vTaskSwitchContext返回时，将basepri寄存器重置为0来恢复所有中断，并从堆栈中pop出参数寄存器到r0和r3来恢复函数调用之前的初始值。

mov r0,#0
msr basepri, r0
ldmia sp!, {r0, r3}
  • msr不需要同步指令，因为当执行优先级增加时，ARM内核实际上会为你处理这个问题

现在，是时候执行新的任务了，之前我们保存了原来人物的堆栈到pxTopOfStack中，现在需要切换为新任务的状态。我们首先需要加载pxCurrentTCB指向的新任务的TCB的内容。

/* The first item in pxCurrentTCB is the task top of stack. */
ldr r1, [r3]
ldr r0, [r1]

r0现在保存了一个新任务堆栈顶部的指针。首先，我们使用ldmia (Load Multiple Increment After)指令将callee保存的核心寄存器出栈，然后我们要检查LR(r14)寄存器的内容来判断是否之前有将FPU的寄存器压栈，若有则要出栈。现在r0指向程序堆栈的位置，此时的堆栈和我们进入异常入口处的时候一样。

	/* Pop the core registers. */
	ldmia r0!, {r4-r11, r14}

	/* Is the task using the FPU context?  If so, pop the high vfp registers
	too. */
	tst r14, #0x10
	it eq
	vldmiaeq r0!, {s16-s31}

最后，我们需要更改psp堆栈的位置为当前任务的堆栈指针的位置，并用我们刚刚用ldmia指令从新任务的任务栈中恢复的EXC_RETURN值填充到LR(r14)寄存器。前面1.4.2 异常返回中有介绍，这将告诉硬件如何返回线程模式并恢复上下文状态：

	msr psp, r0
	isb
	bx r14

bx r14后，即整个函数执行完毕，硬件自动将寄存器r0-r3,r12,LR(r14),PC(r15)和xPSR出栈，此时优先级最高任务的PC会出栈到系统的PC中并开始执行。

2.2 上下文切换总结

最后从FreeRTOS的角度来总结一下整个FreeRTOS上下文切换的过程，FreeRTOS的TCB_t中有几个关于堆栈的变量：

  • pxStack：任务栈的基地址
  • pxEndOfStack：任务栈的结束地址
  • pxTopOfStack：任务栈指针的位置

在Cortex-M中，堆栈是向下生长的，所以栈是从pxEndOfStack往下存数据的。而对于pxEndOfStack来说，在任务运行的过程中它并不会修改，理论上它是和SP同步的，但是不可能系统每次操作这个堆栈就更新到pxTopOfStack中，所以仅仅是在每次任务切换的时候更新这个值。所以再来回顾一下前面的汇编代码(删除部分)：

mrs r0, psp
ldr	r3, =pxCurrentTCB
ldr	r2, [r3]
stmdb r0!, {r4-r11, r14}
str r0, [r2]

首先将在Thread mode下使用的PSP加载进来，即当前任务使用的堆栈指针所在的位置。进入PendSV异常处理程序时，硬件已经把r0-r3,r12,LR,PC和xPSR压入PSP中了，还需要保存r4~r11这些寄存器(再次保存r14即LR是为了后续调用C函数返回使用)，所以继续在PSP的基础上压栈，这样就保存了当前任务的所有寄存器的值。然后把压栈后的PSP值保存到当前任务的pxTopOfStack中。

当前任务的上下文保存完了，就可以进行上下文切换了：

stmdb sp!, {r0, r3}
bl vTaskSwitchContext

因为调用vTaskSwitchContext后我们还将用到r0和r3寄存器，所以这里暂时用一下当前任务的堆栈来保存这两个寄存器。而在vTaskSwitchContext函数中，如果去掉那些统计和溢出检测的代码，实际上就两行：

taskSELECT_HIGHEST_PRIORITY_TASK();
/* 该函数实际上用于Segger JLink调试数据的发送(如果使能的话),可忽略 */
traceTASK_SWITCHED_IN();

其中taskSELECT_HIGHEST_PRIORITY_TASK就是在pxReadyTasksLists中从任务优先级最高往最低寻找就绪的任务的TCB，然后赋值给pxCurrentTCB。

  • pxReadyTasksLists中任务加入的时机：Systick中断中判断vTaskDelay超时的任务、信号量/事件位等释放完后正在等待这些信号量/事件的任务等

好了现在系统将要运行的下一个任务已经保存在pxCurrentTCB中了，再来看看后面的汇编：

ldmia sp!, {r0, r3}
ldr r1, [r3]
ldr r0, [r1]
ldmia r0!, {r4-r11, r14}
msr psp, r0
bx r14

首先将前面保存的r0和r3出栈，其中r3即pxCurrentTCB的地址，然后将该地址里面的*pxCurrentTCB的内容(前四字节)加载到r1中，即r1 = &(*pxTopOfStack)。然后再把*pxTopOfStack，即待运行任务的堆栈指针加载到r0中，再将待运行任务的上下文r4~r11和r14从栈顶指针r0出栈到系统对应的寄存器中，再将出栈后的堆栈指针pxTopOfStack(r0)保存到psp中。最后调用bx r14切换回Thread mode，退出PendSV异常。最后别忘了，由caller保存的r0-r3,r12,LR,PC和xPSR也将由硬件出栈，硬件并不知道我们已经修改psp到新的任务中了，它就是从psp位置处依次将这些寄存器出栈，所以新任务堆栈中的r0-r3,r12,LR,PC和xPSR将出栈到这些寄存器中，最后任务切换成功。

  • 所以前面进入异常时硬件的压栈和stmdb r0!, {r4-r11, r14}压的是原任务的上下文；而ldmia r0!, {r4-r11, r14}的出栈和退出异常时出的是新任务的上下文

2.3 任务调度

    现在还有一个问题，如果PendSV异常被触发，但系统刚刚启动，没有当前运行的任务，会发生什么？
    有几种不同的策略，但在创建新任务时，RTOS将遵循的一个常见的模式是初始化任务堆栈，使其看起来像已被调度器上下文切换过了一样。然后通过使用SVC指令触发SVC异常来启动调度程序本身。这种启动线程的方式与将上下文切换到线程几乎相同。

  • SVC异常仅在系统刚上电后触发一次，用于运行第一个任务

第一个任务创建的具体流程和分析，参考：FreeRTOS第一个任务的创建和调度详解(SVC异常)

查看初始化代码，还会发现一些配置的设置，例如：

  • 配置任务是在特权还是非特权模式下运行
  • FP扩展配置，如是否使能、使用什么上下文堆栈方式

对于本例中，FPU的配置如下：

vPortEnableVFP:
	/* The FPU enable bits are in the CPACR. */
	ldr.w r0, =0xE000ED88
	ldr	r1, [r0]

	/* Enable CP10 and CP11 coprocessors, then save back. */
	orr	r1, r1, #( 0xf << 20 )
	str r1, [r0]
	bx	r14


BaseType_t xPortStartScheduler( void )
{
...
    /* Ensure the VFP is enabled - it should be anyway. */
    vPortEnableVFP();

    /* Lazy save always. */
    *( portFPCCR ) |= portASPEN_AND_LSPEN_BITS;
...
}

开启任务调度需要调用vTaskStartScheduler，如果想要深入了解任务调度的逻辑，建议详细理解port.c中的pxPortInitialiseStack、xPortStartScheduler和vPortSVCHandler函数。

版权声明：本文为CSDN博主「tilblackout」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/tilblackout/article/details/128135347

tilblackout
关注
  • 4
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
专栏目录
RTOS内核技术研究：任务上下文切换
坚韧与专注
07-07 1402
前言 任务或线程，可以理解为一个个功能函数，RTOS内核的作用，就是管理这些功能函数，并且，根据某些策略，如任务优先级、时间片，进行切换。 切换任务，不单单是PC指针的跳转，还需要保存各个任务的现场，各个任务的现场，称之为：任务上下文，context。 就像裸机系统，中断来了，CPU会自动保存现场，如一些必要的CPU寄存器的值，当前的PC指针放到LR寄存器，中断处理完回来，执行LR，恢复CPU寄存器的值，程序继续正常的接着上次被中断的地方跑，而不是重新跑...
1268_FreeRTOS任务上下文切换的实现
小灰笔记
06-12 737
全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)继续前面调度器启动最后面没有分析完的几个接口，现在还剩下一个任务上下文切换还有一个错误处理。这一次，分析一下上下文切换的实现。其实，从这部分注释看，这个接口在这里应该是运行不到的。在这里增加了一下也不过是防御性的编程设计而已。那么，接下来看看这个上下文切换的接口在整个OS中的使用情况。从调度方面看，第一个头文件其实可以不去分析了。另外需要看的还有两个文件，先看po
FreeRTOS任务调度（任务上下文切换）详解
最新发布
weixin_46461874的博客
04-18 1945
在文章中对实时操作系统RTOS进行了移植。移植完成后由于PendSV_Handler、SVC_Handler、SysTick_Handler三个中断的影响使程序进入了硬件错误中断，。
RTOS任务调度过程（上下文切换）
weixin_67271870的博客
12-06 1446
RTOS任务调度过程（上下文切换）解析：RTOS任务调度的机制是基于内核异常机制的，即每产生一次调度就会产生一次内核异常，那么，要了解RTOS的任务调度机制需要先明白内核的中断系统。RTOS使用其中三个特殊的异常：systick的中断、SVC异常以及PendSV异常。这三个异常是任务能跑起来的根本原因。Systick中断就是我们常说的滴答定时器中断，Freertos 调度器依靠滴答定时器中断不断地运行，假设每过1ms滴答定时器就会中断一次，调度器就会随着systick的中断1ms运行一次。除了滴答定时器中断
Freertos Cortex-M3上下文切换
denghuajing的博客
11-20 3872
上下文切换是操作系统实现虚拟化的核心功能，操作系统对任务的管理通过上下文切换完成。 Freertos 在STM32F103上的上下文切换是本文介绍的内容。STM32F103 采用 Cortex-M3 内核 。 上下文切换的本质是对现场的保护和恢复现场，切换 CPU的运行环境。 上下文切换的触发来源于调度器，调度器根据复杂智能的调度算法来判断，是否要进行上下文切换。这换意味着一个任务被‘暂停’，任务中所做的事情都会被暂停。 1.调度器的优先级 Freertos 调度器本身的周期性运行是靠一个时间定时器syst
Cortex-M中断机制在FreeRTOS中的体现
10-09
- 例如，在Cortex-M处理器上，一个定时器中断可能被用来周期性地唤醒RTOS，执行任务调度。定时器中断服务程序会更新RTOS的时间基，并可能使用信号量通知任务处理新的数据或事件。 - 另一个例子是，当串口接收到...
cortex-m：低级访问Cortex-M处理器
02-05
10. **RTOS (实时操作系统)**：虽然“no-std”强调了不使用标准库，但在某些复杂应用中，可能需要引入RTOS，如FreeRTOS或Zephyr，来实现多任务调度和资源管理。 通过深入学习和实践这些知识点，开发者能够充分利用...
Cortex-M编程手册（英文）
08-12
4. **实时操作系统（RTOS）**：介绍如何在Cortex-M上集成和使用RTOS，如FreeRTOS或CMSIS-RTOS，以及如何进行任务调度、信号量、互斥锁等并发控制。 5. **硬件接口编程**：熟悉Cortex-M处理器与外设之间的通信，包括...
新塘M2351单片机cortex-m23内核UCOS移植工程模板
06-28
新塘M2351单片机是一款基于Cortex-M23内核的微控制器，其在嵌入式系统设计中扮演着重要角色。Cortex-M23是ARM公司推出的一种超低功耗、高性能的处理器核心，适用于物联网(IoT)、传感器节点和其他资源受限的设备。该...
FreeRTOS任务切换流程说明
07-06
FreeRTOS的核心就是任务管理，而任务管理的核心就是如何进行任务切换。
ARMv6-M 架构参考手册(Cortex-M0_M _M1内核架构).zip
04-21
Cortex-M0、Cortex-M1是基于此架构的微控制器内核，广泛应用于物联网(IoT)设备、传感器节点和消费电子等领域。下面将详细介绍ARMv6-M架构及其相关的Cortex-M0和Cortex-M1内核。 1. **ARMv6-M架构**： - **指令集**...
RTOS内功修炼记（十） | 深度解析RTOS内核上下文切换机制
Mculover666的博客（嵌入式）
07-21 945
一、风平浪静的程序世界 芯片上电的那一刻，犹如小船撑起了帆，开始远航。 这艘小船上，PC寄存器负责航行路线，按照路线图（可执行固件）告诉船长（CPU）接下来该往走哪个方向，船长在走的时候，还要依赖R0-R12这些通用寄存器来完成一些基本的计算。 这一路上，还会遇到很多的港口，船长有点不太安分想进港玩玩，但这个时候PC指针不干了： “船长，我自己只能无脑的向前冲，现在我们要偏离路线进港的话，有可能会回不来了”！ 船长一听，这问题不大啊，喊过来LR寄存器： “你记一下现在的位置，我们待会进港玩完了要回来这里，一
FreeRTOS任务上下文切换与任务状态切换的区别及联系
qq_40823714的博客
02-17 446
FreeRTOS任务上下文切换与任务状态切换的区别及联系
Freertos 任务（二）调度器设计和上下文切换
denghuajing的博客
11-22 499
Freertos 调度器的设定和处理器的架构联系非常紧密 所以这部分的内容属于移植层，以ARM cortex-M3为例 FreeRTOS-Kernel-10.4.6\portable\GCC\ARM_CM3 调度器设计的功能有两个，围绕调度 1：调度，完成调度这个动作，也就上下文切换 2：调度策略， 该怎么调度好 调度器本身也是一段在处理器上的代码，为了让它保持对处理器的控制权，只要控制了CPU才能对CPU上的任务进行调度。简单说就是 这个CPU我说的算。设计嵌入式系统根据需求，实时性有时是摆在第一位的，所
FreeRTOS：在ARM Cortex-M内核上运行RTOS
lf9335的专栏
02-17 2813
注意：以下关于中断嵌套的信息适用于Cortex-M3、Cortex-M4、Cortex-M4F和Cortex-M7，不适用于Cortex-M0或者Cortex-M+等不包括BASEPRI寄存器的内核。 介绍 数以千计的应用在ARM Cortex-M内核上运行FreeRTOS。令人吃惊的是，很少有关于这个RTOS和ARM Cortex内核组合的技术支持请求。但是，确实存在大量由于不正确设置中断优...
FreeRTOS中的　’上下文切换‘　含义
linzs.online
02-28 9805
最近在重新回顾底层的相关知识在FreeRTOS中遇到了一个词’上下文切换‘，我在网上找到份比较好的解释： 上下文切换（有时也称做进程切换或任务切换）是指 CPU 从一个进程或线程切换到另一个进程或线程。 进程（有时候也称做任务）是指一个程序运行的实例。在 Linux 系统中，线程就是能并行运行并且与他们的父进程（创建他们的进程）共享同一地址空间（一段内存区域）和其他资源的轻量级的进程。 上下文是...
【无标题】FreeRTOS中断中执行上下文切换方法
Dsircheck的博客
11-27 573
/* 定时器 ISR */ void vTimerISR( voidvoid * pvParameters ) { static unsigned char ucLocalTickCount = 0; static signed BaseType_txHigherPriorityTaskWoken; /*定时器中断发生 */ ...执行其它代码 /*需要vATask() 运行吗? */ xHigherPriorityTaskWoken = pdFALSE; ucLocalTickCo
LED照明
汽车以太网和SOA
02-15 4151
LED照明
CMSIS-RTOS在Cortex-M微控制器上的实战教程
教程详细介绍了如何在基于Cortex-M的微控制器上使用一个小巧的实时操作系统（RTOS），特别是遵循‘Cortex微控制器软件接口标准’（CMSIS）RTOS规范的系统。CMSIS-RTOS规范定义了一个用于Cortex-M微控制器的标准RTOS ...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

tilblackout

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值