Cómo solucionar los puntos de portabilidad de FreeRTOS
El trasplante de FreeRTOS requiere principalmente reescribir los siguientes tres archivos.
1.portmacro.h
2.port.c
3.port.asm
Si está utilizando el compilador de C Permite la inserción de ensamblador en código C y admite la escritura de controladores de interrupciones en C, luego el contenido del archivo port.asm se puede fusionar en port.asm.
El siguiente es un ejemplo de cómo portar FreeRTOS a un microcontrolador con FreeScale 68HCS12 como núcleo. El entorno de desarrollo es CodeWarrior Development Studio V5.9.0
La razón por la que se utiliza FreeScale 68HCS12. el ejemplo de CPU es: Es porque previamente escribí instrucciones sobre cómo portar uC/OS-II al microcontrolador central FreeScale 68HCS12. Al utilizar la misma CPU y el mismo entorno de desarrollo, se pueden comparar fácilmente las similitudes y diferencias entre el código transferido para dos sistemas operativos en tiempo real diferentes. Además, FreeScale 68HCS12 es mucho más simple que ARM, MIPS y otras arquitecturas. La cantidad de código portado también es relativamente pequeña, lo que facilita el inicio.
portmacro.h
portmacro.h consta principalmente de dos partes. La primera parte define una serie de tipos de datos utilizados en el código del kernel. FreeRTOS, al igual que uC/OS-II, no utiliza directamente tipos locales como char e int, sino que los redefine como una serie de nuevos tipos que comienzan con port. En el código portado a uC/OS-II, los typedefs se usan a menudo para definir nuevos tipos, mientras que los autores de FreeRTOS parecen preferir definiciones de macro. A continuación se muestra el fragmento de código correspondiente.
portTickType se puede definir como un entero sin signo de 16 bits o un entero sin signo de 32 bits. La definición exacta depende de cómo se configura configUSE_16_BIT_TICKS en el archivo FreeRTOSConfig.h.
Luego hay algunas definiciones relacionadas con el hardware. Estas definiciones incluyen patrones de emparejamiento de datos, la dirección del crecimiento de la pila, tasas de ticks y macros de cambio de tareas.
portBYTE_ALIGNMENT no es necesario en uC/OS-II, el código FreeRTOS utiliza esta definición de macro al asignar espacio en la pila de tareas.
portSTACK_GROWTH se define como 1 para indicar crecimiento de la pila hacia adelante, -1 para indicar crecimiento inverso. Normalmente, la pila crece en la dirección opuesta y 68HCS12 no es una excepción, por lo que aquí se define como (-1).
Una cosa más a tener en cuenta es que en uC/OS-II, la macro correspondiente es OS_STK_GROWTH, donde 1 representa crecimiento inverso y 0 representa crecimiento hacia adelante.
portTICK_RATE_MS solo se puede utilizar en el código de la aplicación y representa el intervalo entre dos ticks.
portYIELD() implementa el cambio de tareas, que es equivalente a OS_TASK_SW() en uC/OS-II.
portNOP(), como su nombre indica, define una macro sin operación. No he notado que esta macro se use en el código FreeRTOS, pero estoy seguro de que se usa en alguna parte.
Luego, el código que maneja el área crítica:
Esta parte del código es bastante larga, pero en realidad proporciona dos definiciones macro para el modelo de memoria pequeña y el modelo de memoria bancaria:
p>
portRESTORE_CONTEXT()
portSAVE_CONTEXT()
El conjunto de definiciones de macros que se utiliza depende de si la macro BANKED_MODEL está definida. De hecho, el código oficial proporcionado en CodeWarrior Development Studio V5.9.0 proporciona un método de determinación más formal:
El código para guardar y restaurar el contexto de la tarea en FreeRTOS es básicamente el mismo que el código en uC/ OS-II Lo mismo, la única pequeña diferencia es que debes guardar el valor de uxCriticalNesting. Las razones son las mencionadas anteriormente.
La razón para usar estas dos macros es aprovechar ciertas extensiones del compilador de C para optimizar mejor la función de la tarea, pero CodeWarrior no proporciona estas extensiones, por lo que en este caso la tarea es solo una función normal.