El video atómico puntual P24-P28 tiene una combinación de código fuente real para el análisis. Lo que estoy aquí se basa principalmente en el análisis de la guía autorizada Cortex-M3 y la guía autorizada ARM Cortex-M3 y Cortex-M4.

1. El concepto y el proceso de cambio de tareas

Paso 1: es necesario suspender la ejecución de la tarea A y guardar los registros de la tarea A en la pila de tareas en este momento.Este proceso se llama guardar la escena ;

Paso 2: Restaurar los valores de registro de la tarea B (almacenados en la pila de tareas) a los registros de la CPU.Este proceso se llama restaurar la escena ;

Guarde la escena para la tarea A y restaure la escena para la tarea B. Este proceso general se llama: cambio de contexto

La esencia de la conmutación de tareas: es la conmutación de registros de la CPU.

El proceso de cambio de tarea se completa en la función de servicio de interrupción de PendSV .

2. La relación entre el cambio de tareas y la excepción PendSV

2.1 ¿Qué es PendSV?

Antes de comprender PendSV (llamada al sistema suspendible), debe tener un concepto básico de SVC (llamada al servicio del sistema, también conocida como llamada al sistema).

SVC se utiliza para generar solicitudes de llamadas de funciones del sistema. Por ejemplo, el sistema operativo no permite que el programa de usuario acceda directamente al hardware, pero proporciona algunas funciones de servicio del sistema, y el programa de usuario usa SVC para emitir una solicitud de llamada a la función de servicio del sistema, y los llama de esta manera para indirectamente acceder al hardware. Por lo tanto, cuando el programa del usuario quiera controlar un hardware específico, generará una excepción SVC y luego se ejecutará la rutina de servicio de excepción SVC proporcionada por el sistema operativo, que luego llama a la función del sistema operativo relevante, que completa lo solicitado por el usuario. programa Servir. Las excepciones de SVC deben responderse de inmediato (si la prioridad no es mayor que la que se está procesando actualmente, u otras razones hacen que no sea posible responder de inmediato, la petición se convertirá en un fallo grave).Cuando la aplicación ejecuta SVC, espera obtener la solicitud requerida respuesta inmediata.

PendSV (llamada al sistema suspendible), que se utiliza junto con SVC. PendSV es diferente de SVC en que se puede suspender como una interrupción normal (a diferencia de la petición de SVC) . El sistema operativo puede aprovechar esto para "suspender la ejecución" de una excepción, es decir, no realizar acciones hasta que se hayan completado otras tareas importantes . El método para suspender PendSV es: escribir manualmente 1 en el registro de suspensión de PendSV de NVIC. Después de la suspensión, si la prioridad no es lo suficientemente alta, se pospondrá para esperar la ejecución. P endSV es una excepción suspendible, si lo configuramos con la prioridad más baja, entonces si se disparan varias excepciones al mismo tiempo, se ejecutará después de que se ejecuten otras excepciones, y cualquier excepción puede interrumpirlo.

2.2 Razones para usar PendSV para cambiar de contexto

Un caso de uso típico para PendSV es durante el cambio de contexto (cambio entre diferentes tareas). Por ejemplo, si hay dos tareas listas en un sistema, la ocasión en la que se activa el cambio de contexto puede ser:
1. Ejecutar una llamada al sistema.
En términos generales, esto es para ejecutar la función api del sistema.
2. El temporizador de marca del sistema ( SYSTICK) interrupción, (se requiere programación por turnos)
En la función de servicio de interrupción del temporizador del sistema, la prioridad de la tarea que se está ejecutando actualmente se compara con otras tareas prioritarias en la lista lista, y se juzga si hay una tarea con una prioridad más alta que la tarea en la lista lista o hay Si hay tareas de la misma prioridad, se requiere el cambio de tarea.

Entonces, ¿por qué el contexto cambia a través de excepciones y no en otro lugar?

Primero resolvamos la primera pregunta, ¿ por qué usar excepciones para cambiar de contexto?

El uso de excepciones para el cambio de contexto es una práctica común en los sistemas operativos en tiempo real por varias razones:

Soporte de hardware: muchos procesadores y microcontroladores proporcionan mecanismos especiales para la programación de tareas y el cambio de contexto, como tablas de vectores de interrupción y mecanismos de manejo de excepciones. Mediante el uso de estos soportes de hardware, se puede lograr un cambio de contexto eficiente y confiable.
Capacidad de respuesta: el manejo de excepciones tiene prioridad y un tiempo de respuesta fijo . Cuando se activa una excepción, el procesador saltará inmediatamente al controlador de excepciones correspondiente y, una vez que el controlador termine de ejecutarse, puede volver rápidamente al contexto original. Esto puede garantizar que las tareas en tiempo real puedan responder a tiempo y cumplir con los requisitos en tiempo real del sistema .
Aislamiento: se puede lograr un aislamiento estricto entre tareas mediante el uso de excepciones para el cambio de contexto . Cada tarea tiene su propio contexto, incluida la pila, los registros, etc., y los controladores de excepciones también tienen contextos independientes. Esto evita la interacción y los conflictos de datos entre tareas.
Confiabilidad: el kernel del sistema operativo o los controladores de bajo nivel generalmente proporcionan el manejo de excepciones, y estos códigos se diseñan y prueban cuidadosamente para garantizar su corrección y estabilidad. Mediante el uso de excepciones para el cambio de contexto, estos códigos confiables se pueden usar para administrar la programación de tareas y el cambio de contexto, mejorando la confiabilidad y solidez del sistema.

¿Por qué no haces el cambio de contexto en otro lugar?

Los cambios de contexto en otros lugares pueden causar los siguientes problemas:

Imprevisibilidad: si el cambio de contexto se realiza en cualquier posición del código, el momento del cambio de tarea será incontrolable, lo que puede provocar que no se cumplan los requisitos en tiempo real. En un sistema en tiempo real, la programación y el cambio de tareas deben ser predecibles y deterministas para garantizar que las tareas se puedan ejecutar dentro del tiempo especificado.
Problemas de seguridad: el cambio de contexto implica la conservación y restauración del estado de las tareas, incluidos datos clave como registros y pilas. Si se realiza un cambio de contexto en cualquier momento, los datos pueden perderse o corromperse, afectando la correcta ejecución de la tarea. Al usar el mecanismo de manejo de excepciones, puede asegurarse de que el cambio de contexto ocurra en una ubicación predefinida y segura , evitando así problemas de inconsistencia de datos.
Complejidad y mantenibilidad: centralizar el cambio de contexto en el mecanismo de manejo de excepciones mejora la legibilidad, el mantenimiento y la escalabilidad del código. Los controladores de excepciones generalmente los proporciona el kernel del sistema operativo o los controladores de bajo nivel, un código que ha sido cuidadosamente diseñado y probado para proporcionar un mecanismo de cambio de contexto consistente y confiable. Si el cambio de contexto se realiza en otro lugar, el código puede dispersarse y la lógica puede confundirse, lo que no es propicio para el mantenimiento y la depuración del sistema.

En resumen, el cambio de contexto a través de excepciones es cumplir con los requisitos de los sistemas en tiempo real, incluida la previsibilidad, la seguridad y la capacidad de mantenimiento. El mecanismo de gestión de excepciones proporciona una forma fiable y unificada de gestionar la programación de tareas y el cambio de contexto, y puede combinarse estrechamente con soporte de hardware para lograr un cambio de tareas eficiente y controlable.

¿Y por qué usar PendSV para cambiar de contexto en lugar de otras excepciones?

Pongamos un ejemplo sencillo para facilitar la comprensión. Supongamos que existe un sistema de este tipo, que tiene dos tareas listas, y una excepción SysTick inicia un cambio de contexto. Pero si se está atendiendo una interrupción cuando se genera la excepción SysTick, la excepción SysTick se adelantará a su ISR. En este caso, el sistema operativo no puede realizar el cambio de contexto; de lo contrario, la solicitud de interrupción se retrasará , y el tiempo de retraso en los sistemas reales suele ser impredecible: cualquier sistema con un poco de requisitos de tiempo real nunca puede tolerar este tipo de cosas . Por lo tanto, en CM3 también está estrictamente prohibido no discutir: si el sistema operativo intenta cambiar al modo subproceso mientras una interrupción está activa, violará la excepción de falla de uso.

¿Por qué el sistema operativo no puede realizar un cambio de contexto cuando la excepción se adelanta a la interrupción ?

En los sistemas en tiempo real, las rutinas de servicio de interrupción (ISR) generalmente están diseñadas para responder a eventos de emergencia y tienen una prioridad relativamente alta. Cuando llega una solicitud de interrupción, la CPU saltará inmediatamente al ISR correspondiente para su ejecución. Durante la ejecución de la ISR, se considera que la solicitud de interrupción está en estado de procesamiento de interrupción y, por lo general, se enmascara para garantizar el tiempo real y la consistencia de la respuesta.

Sin embargo, si se activa un cambio de contexto durante el manejo de excepciones, es decir, cambiar a la ejecución de otra tarea, la solicitud de interrupción se retrasará. Esto se debe a que, al realizar el cambio de contexto, el sistema operativo necesita guardar el contexto de la tarea actual (incluidos los valores de registro, la información de la pila, etc.) y luego cargar el contexto de la siguiente tarea. Esto implica la modificación y operación del estado del sistema, lo que consume una cierta cantidad de tiempo y recursos de cómputo. Por lo tanto, durante el cambio de contexto, la CPU no puede responder inmediatamente a la nueva solicitud de interrupción , lo que provoca que se retrase el procesamiento de la interrupción. De esta manera, si el tiempo de cambio de tareas es demasiado largo, el sistema operativo en tiempo real se convertirá en el hazmerreír.

Para resolver este problema, la mayoría de los primeros sistemas operativos detectarán si hay una interrupción actualmente activa y solo realizarán un cambio de contexto cuando no haya ninguna interrupción a la que deba responderse (no se puede responder a las interrupciones durante el cambio). Sin embargo, la desventaja de este método es que puede retrasar la acción de cambio de tarea durante mucho tiempo ( porque si se reemplaza la IRQ, el SysTick actual no se puede cambiar de contexto después de la ejecución, y solo puede esperar la próxima excepción de SysTick ), especialmente cuando una interrupción Cuando la frecuencia de la fuente está cerca de la frecuencia de la excepción SysTick, se producirá una "resonancia", lo que retrasará el cambio de contexto. Pues bien, PendSV ha venido a resolver perfectamente este problema. La excepción PendSV retrasará automáticamente la solicitud de cambio de contexto hasta que todos los demás ISR hayan completado el procesamiento. Para implementar este mecanismo, PendSV debe programarse como la excepción de prioridad más baja. Si el sistema operativo detecta que una IRQ está activa y está siendo reemplazada por un SysTick, generará una excepción PendSV para diferir la ejecución del cambio de contexto.

2.3 ¿Cómo se activa la excepción PendSV?

1. Marque la llamada de interrupción del temporizador

2. Ejecute las funciones de API relacionadas proporcionadas por FreeRTOS : portYIELD ()

La siguiente tabla está tomada de la página 131 de " La guía definitiva de Cortex M3 ( chino )" .

Esencia: la interrupción de PendSV se inicia escribiendo 1 en el bit 28 del control de interrupción y el registro de estado ICSR para suspender PendSV

2.4 Cómo PendSV controla el cambio de contexto

La excepción PendSV retrasa automáticamente la solicitud de cambio de contexto hasta que todos los demás ISR hayan terminado de procesarse. Para implementar este mecanismo, PendSV debe programarse como la excepción de prioridad más baja. Si el sistema operativo detecta que una IRQ está activa y está siendo reemplazada por un SysTick, generará una excepción PendSV para suspender la ejecución del cambio de contexto. Como se muestra en la Figura 7.17

Los registros diarios de los eventos son los siguientes:

1. La tarea A llama al SVC para solicitar un cambio de tarea (por ejemplo, para esperar a que se complete algún trabajo)

2. El sistema operativo recibe la solicitud, se prepara para el cambio de contexto y agrega una excepción PendSV.

3. Cuando la CPU sale de SVC, ingresa inmediatamente a PendSV, realizando así un cambio de contexto.

4. Una vez completada la ejecución de PendSV, volverá a la tarea B e ingresará al modo subproceso al mismo tiempo.

5. Ocurre una interrupción y la rutina de servicio de interrupción comienza a ejecutarse

6. Durante la ejecución de ISR, se produce una excepción de SysTick y se adelanta el ISR.

7. El sistema operativo realiza las operaciones necesarias, luego pend genera la excepción PendSV en preparación para el cambio de contexto.

8. Cuando SysTick sale, regrese al ISR previamente ocupado y el ISR continúa ejecutándose

9. Una vez que ISR termina de ejecutarse y sale, la rutina de servicio PendSV comienza a ejecutarse y el cambio de contexto se realiza dentro

10. Una vez completada la ejecución de PendSV, regrese a la tarea A y el sistema ingresa nuevamente al modo de subprocesos.

3. Modo de trabajo Cortex-M3/4 durante la programación de tareas

Referencia: (1 mensaje) Artículos de la serie RTOS (6): Cortex-M3/4 SP, MSP, PSP, modo Thread, modo controlador, modo kernel, modo usuario_psp msp_Pig Brother-Embedded Blog-CSDN blog

¿Por qué el kernel CM3 tiene un modo de hilo y un modo de controlador?

En el núcleo ARM Cortex-M3, se introduce el diseño del modo de subproceso (modo de subproceso) y el modo de procesador (modo de controlador), principalmente para proporcionar soporte para multitarea y sistema operativo en tiempo real (RTOS) .

Modo de subproceso (modo de subproceso) : el modo de subproceso es un modo especial del procesador Cortex-M3 para admitir la multitarea. En el modo de subprocesos, el procesador puede ejecutar múltiples subprocesos, cada subproceso tiene su propia pila y contexto, y puede cambiar entre diferentes subprocesos a través del mecanismo de cambio de tareas. Esta capacidad multitarea permite que el núcleo Cortex-M3 admita el funcionamiento de un sistema operativo en tiempo real (RTOS), lo que permite la ejecución y la programación de tareas simultáneas.
Modo de procesador (modo de controlador ): el modo de procesador es el modo predeterminado del núcleo Cortex-M3, también conocido como el modo privilegiado. En el modo de procesador, el procesador puede ejecutar controladores de excepciones (como rutinas de servicio de interrupción, controladores de excepciones, etc.). El modo de procesador proporciona un nivel de privilegio de mayor prioridad, que puede manejar varias condiciones anormales que ocurren en el sistema y tiene acceso a registros privilegiados e instrucciones privilegiadas.

Al distinguir entre el modo de subproceso y el modo de procesador, el núcleo Cortex-M3 puede admitir de manera efectiva las necesidades de los sistemas operativos multitarea y en tiempo real. El modo de subprocesos se utiliza para realizar el cambio de tareas y la programación de varios subprocesos de usuario para lograr la ejecución simultánea de tareas, mientras que el modo de procesador se utiliza para realizar el manejo de excepciones de alta prioridad y tareas a nivel del sistema para garantizar el funcionamiento correcto del sistema y el manejo de excepciones.

Cabe señalar que el núcleo Cortex-M3 no es compatible directamente con las funciones del sistema operativo, pero proporciona algunos mecanismos y modos de hardware específicos para lograr la compatibilidad con multitarea y RTOS. El sistema operativo específico debe desarrollarse e implementarse sobre la base de estos mecanismos.

¿Por qué el kernel CM3 necesita una clasificación de privilegios?

El diseño del nivel de privilegio introducido en el núcleo ARM Cortex-M3 es para lograr la seguridad y confiabilidad del sistema.

La clasificación de privilegios permite que diferentes módulos de software se ejecuten en diferentes niveles de privilegios. Este mecanismo de separación de privilegios tiene los siguientes propósitos principales:

Seguridad del sistema: la clasificación de privilegios puede garantizar la seguridad del sistema y evitar el acceso no autorizado a recursos y funciones con niveles de privilegios altos por parte de software con niveles de privilegios bajos. Al restringir los permisos del software de bajo nivel de privilegios, puede proteger eficazmente el sistema contra malware o código erróneo.
Confiabilidad del sistema: la clasificación de privilegios ayuda a mejorar la confiabilidad y estabilidad del sistema . El software altamente privilegiado puede acceder a más recursos de hardware y ejecutar instrucciones privilegiadas, lo que permite el procesamiento de misión crítica y las operaciones a nivel del sistema. El software con privilegios bajos está restringido en un entorno controlado y no tiene acceso directo a partes críticas del sistema, lo que evita el riesgo de fallas en el sistema o corrupción de datos causada por algunos errores o excepciones potenciales.
Capacidad de mantenimiento del software: la clasificación de privilegios hace que el desarrollo, el mantenimiento y la depuración de software sean más convenientes . Al dividir el código de diferentes funciones en diferentes niveles de privilegio, se puede realizar el diseño modular y jerárquico del código y se reduce la complejidad del código. Además, durante la depuración, aislar código con diferentes niveles de privilegio ayuda a localizar y resolver problemas.

Modo de trabajo principal de Cortex-M3, clasificación de privilegios

modo de trabajo del núcleo

Modo subproceso: el modo en el que se ejecutan los programas de aplicación normales.Las aplicaciones incluyen aplicaciones escritas por programadores y algunos programas del sistema operativo.
Modo controlador: modo de trabajo cuando se producen excepciones e interrupciones.

Clasificación de privilegios La
clasificación de privilegios del kernel de Cortex-M3/M4 tiene dos tipos, a saber, privilegiado (privilegiado) y no privilegiado (sin privilegios), muchos libros dividirán estos dos tipos de privilegios en estado del kernel y estado del usuario.

Hay algunas conexiones entre el modo privilegiado, el modo sin privilegios y el modo de subprocesos, el modo controlador, pero son conceptos diferentes.

El modo privilegiado y el modo sin privilegios se relacionan principalmente con el nivel de privilegio del procesador y el acceso a los recursos del sistema. El modo privilegiado tiene un nivel de privilegio más alto, puede ejecutar instrucciones privilegiadas, acceder a recursos confidenciales del sistema y es adecuado para ejecutar tareas clave y ejecutar el kernel del sistema operativo; el modo sin privilegios tiene un nivel de privilegio más bajo y está sujeto a ciertas restricciones. para el funcionamiento normal de la aplicación.

El modo de subprocesos es el modo del procesador cuando se ejecutan programas de aplicación normales, incluidas las aplicaciones escritas por programadores de aplicaciones y partes de algunos sistemas operativos. El modo de subprocesos puede ejecutarse en modo privilegiado o no privilegiado, según la implementación y configuración del sistema operativo. En el modo de subprocesos, el procesador cambia entre diferentes subprocesos para realizar tareas.

El patrón Handler es un patrón que funciona cuando ocurre una excepción o interrupción. Cuando ocurre un evento de excepción o interrupción, el procesador cambiará automáticamente al modo Controlador y ejecutará el controlador de excepción o interrupción correspondiente, que generalmente se ejecuta en un modo privilegiado. El modo Manejador permite el manejo especial de excepciones e interrupciones, como guardar contexto, responder a solicitudes de interrupción, realizar operaciones privilegiadas, etc.

Por lo tanto, el procesador puede estar en un modo de hilo privilegiado o no privilegiado mientras se ejecutan los programas de aplicación normales. Cuando ocurre una excepción o interrupción, el procesador cambiará al modo Manejador y ejecutará el manejador de excepción o interrupción correspondiente. El modo privilegiado y el modo sin privilegios forman parte del modo subproceso, y el modo controlador es el modo de trabajo en caso de excepción o interrupción. Están relacionados, pero no son idénticos.

4. Punteros de doble pila MSP y PSP

¿Por qué el núcleo CM3 necesita dos SP (MSP y PSP)?

MSP se usa en modo hilo + modo controlador.
En el modo Manejador, la CPU forzará el uso de MSP.
Puntero de pila principal (MSP): MSP es el puntero de pila predeterminado que se inicializa cuando se inicia el sistema y se usa para guardar variables globales, el contexto de la rutina de servicio de interrupción (ISR) y el marco de pila durante el manejo de excepciones. MSP generalmente se usa para guardar el contexto a nivel del sistema y se usa en el modo Controlador.

MSP se puede usar en modo subproceso y PSP también se puede usar.
Puntero de pila de proceso (PSP): PSP es un puntero de pila que se usa en modo hilo (Thread mode), que se usa para guardar el contexto del hilo, como variables locales, información de llamadas a funciones, etc. PSP generalmente se usa para guardar el contexto de nivel de subproceso y guardarlo y restaurarlo cuando se cambia la tarea.

Ejemplo: para programas completos, se ha utilizado MSP. Para programas con un sistema operativo, el núcleo del sistema operativo y las interrupciones usan el MSP, mientras que la tarea de la aplicación usa el PSP.

¿Cuál es el papel del puntero de doble pila?

La respuesta es aislar el sistema operativo y el programa de aplicación . La pila es indispensable para la ejecución del programa, porque nuestra CPU solo tiene una pequeña cantidad de registros de propósito general. Cuando usamos muchas variables temporales, necesitamos almacenar estas variables temporales en la pila y el empuje de la pila Tanto pop como pop se implementan a través de SP, por lo que el aislamiento del kernel del sistema operativo y las aplicaciones se pueden realizar a través de MSP y PSP.La tarea de la aplicación usa PSP y el sistema operativo usa MSP , que será muy seguro. Porque no importa cuánto arroje el programa de aplicación, solo arrojará su propia pila y no afectará el sistema operativo del kernel.

Normativamente hablando, es

Compatibilidad con multitarea : al usar la PSP, el Cortex-M3 puede admitir multitarea, lo que permite que varios subprocesos se ejecuten simultáneamente. Cada subproceso tiene su propio espacio de pila independiente.Al cambiar de PSP, se puede realizar el cambio de pila y la preservación del contexto entre diferentes subprocesos.
Manejo de excepciones: cuando ocurre una excepción, Cortex-M3 cambiará automáticamente al modo Controlador y usará MSP para guardar el contexto de excepción actual. Esto puede garantizar que la información de la pila del subproceso no se destruya durante el manejo de excepciones y, al mismo tiempo, mediante el uso de MSP, las excepciones se pueden administrar y manejar convenientemente.

A continuación, introduzca un pasaje del capítulo 10.2 de "La guía definitiva de ARM Cortex-M3/4" para explicar con más detalle el papel de SP, MSP y PSP:

En la mayoría de los casos, no es necesario utilizar la PSP si la aplicación no requiere un sistema operativo integrado. Muchas aplicaciones simples pueden confiar completamente en el MSP.
El PSP se usa normalmente cuando se trata de un sistema operativo incorporado, donde la pila para el kernel del sistema operativo y las tareas de la aplicación están separadas. El valor inicial de PSP no está definido y el valor inicial de MSP se toma de la primera palabra de la memoria durante la secuencia de reinicio

Traducido, hay la siguiente información clave:

MSP es el puntero de pila que se usa de forma predeterminada y puede funcionar en modo subproceso, mientras que el modo controlador debe usar MSP.
PSP solo se puede usar en modo subproceso.
Hay dos situaciones para cambiar entre MSP y PSP:
(1) Cuando ocurre una excepción o una interrupción, la CPU entra automáticamente en el modo Manejador y la CPU establece automáticamente el bit de CONTROL[1] en 0 para usar MSP.
(2) El sistema operativo o el programador establece el bit de CONTROL [1] en 1, luego ingresa al modo de subprocesos y luego usa PSP.
Bajo RTOS, el sistema operativo asigna espacio de pila para cada tarea. Cuando cada tarea se ejecuta, se usa PSP, mientras que bajo una interrupción anormal y el kernel del sistema operativo, se usa MSP.
Topología SP y MSP, PSP
Veamos primero la estructura interna del registro

Podemos refinarlo aún más, como se muestra en la siguiente figura:

Para facilitar la comprensión, simplemente podemos pensarlo de esta manera:

En la CPU, hay 3 registros de pila SP, a saber, SP, MSP y PSP.
SP es un registro para uso externo, o se considera que SP siempre apunta al puntero de pila utilizado en varios modos y escenarios, pero en modo OS o controlador, SP apunta primero a MSP, o SP copia el valor de MSP y puede ser directamente Acceder a la pila principal . En el modo de subprocesos, SP copia el valor de PSP y puede acceder directamente a la pila de subprocesos (tareas) .
Es decir, SP es el portavoz de MSP y PSP, es decir, SP es la dirección lógica de MSP y PSP. Para los programas completos, solo necesitamos saber SP. Para los sistemas operativos, especialmente cuando las interrupciones y el cambio de contexto de tareas son involucrado, necesitamos saber PSP y PSP.MSP, el sistema operativo subyacente se programará directamente para el PSP. Aquí, explicaremos en detalle cuando analicemos el principio de implementación de la programación de FreeRTOS.

Cambiar entre MSP y PSP antes y después de ingresar la interrupción

En el análisis anterior, sabemos que MSP se usa en modo hilo + modo Manejador, especialmente en modo Manejador, la CPU cambiará automáticamente a MSP, solo en el sistema operativo, la tarea tarea usará el PSP, es decir, el PSP está especialmente diseñado para el sistema operativo Diseñado para la ejecución de tareas.
Cuando ocurre una interrupción o excepción , la CPU necesita guardar automáticamente la mitad de los valores de registro de campo, R0~R3, R12, R13(SP), R14(LR), R15(PC) en la pila . Esta parte del trabajo es implementada por el hardware de la CPU. Luego ejecute la rutina de servicio de interrupción. En este proceso, cuando escribimos el ensamblador, solo nos importa el SP, pero internamente, especialmente cuando hay un sistema operativo, en realidad hay diferencias:

Cuando ocurre una interrupción, el hardware de la CPU necesita guardar automáticamente la escena. En este momento, SP apunta a MSP o PSP, dependiendo de la pila que se esté usando antes de que ocurra la interrupción, es decir, si el modo de subproceso se está ejecutando antes de que ocurra la interrupción . , y la tarea se está ejecutando, use PSP , y si se usó el MSP antes de ingresar la interrupción, el MSP se seguirá usando aquí.
Una vez que se ejecuta el programa de servicio de interrupción, es decir, el modo de controlador, se debe usar MSP , es decir, si hay un sistema operativo, cuando la tarea se está ejecutando, se produce una interrupción, la CPU primero usa el PSP para guardar automáticamente la escena. , y luego salta al servicio de interrupción Después del programa, cambie de PSP a MSP, y todas las variables temporales utilizadas por la rutina del servicio de interrupción se almacenan en MSP.
El diagrama esquemático del uso de MSP y PSP en los dos casos anteriores es el siguiente:
Programa completo, use siempre MSP

En el sistema operativo, conmutación MSP/PSP

En la figura anterior, el apilamiento es el proceso en el que la CPU guarda automáticamente la escena. Aquí, el PSP todavía se usa y el MSP solo se usará después de ingresar la interrupción.

Funcionamiento de los punteros de PSP y MSP durante el cambio de tareas

probablemente dar un ejemplo

El puntero de pila se usa para acceder a la pila, y las instrucciones PUSH y POP usan SP de forma predeterminada

Las operaciones PUSH y POP del registro siempre están alineadas en 4 bytes, por lo que agregar y eliminar también es una operación de cuatro bytes de cuatro bytes (el caso de mover cuatro bytes a la vez generalmente se debe a que el ancho del bus de datos del procesador es 32 bits (4 bytes))

Para STM32, la dirección de crecimiento de la pila crece de arriba hacia abajo, la parte inferior de la pila está en la dirección alta y la parte superior de la pila está en la dirección baja. La operación emergente es mover el puntero superior de la pila a una dirección superior, y la operación de pila es mover el puntero superior de la pila a una dirección inferior.

STM32 portando FreeRTOS serie trece: proceso de cambio de tareas en RTOS (resumen)