Toda la verdad sobre RTOS. Artículo # 8. Nucleus SE: diseño interno y despliegue



Este artículo continúa la revisión de Nucleus SE.

Servicios


Nucleus SE proporciona un conjunto de herramientas que se pueden esperar de cualquier RTOS.
En primer lugar, Nucleus SE contiene un programador bastante simple, sin embargo, gracias a las cuatro opciones disponibles, proporciona flexibilidad. El planificador admite los algoritmos Ejecutar hasta la finalización, Round Robin, Carrusel, Time Slice y Priority.

La API de Nucleus SE incluye alrededor de 50 llamadas de servicios públicos que brindan a los desarrolladores acceso a la administración de tareas, secciones de memoria, señales, grupos de indicadores de eventos, semáforos, buzones, colas, tuberías, hora del sistema, temporizadores de aplicaciones y diagnósticos.

Además de la simple programación de tareas, Nucleus SE (opcional) admite la pausa de tareas. Esta función puede ser "limpia" (por ejemplo, como resultado de una llamada a la API del servicio de suspensión establecida explícitamente), puede ser una función de "suspensión" (cuando una tarea se suspende por un cierto período de tiempo), o puede ser el resultado de otra llamada a la API en la que la tarea está bloqueada (la llamada suspensión "condicional"), esperando el acceso al recurso del núcleo. A diferencia de Nucleus RTOS, Nucleus SE no admite tiempos de espera al bloquear llamadas API.

La variedad de mecanismos presentados le permite elegir entre una jerarquía de medios de sincronización y comunicación entre tareas: desde semáforos hasta señales, banderas de eventos, buzones y colas / tuberías.

Artículos anteriores de la serie:
Artículo # 7. Núcleo SE: Introducción
Artículo # 6. Otros servicios RTOS
Artículo # 5. Interacción de tareas y sincronización
Artículo # 4. Tareas, cambio de contexto e interrupciones
Artículo # 3. Tareas y planificación
Artículo # 2. RTOS: estructura y modo en tiempo real
Artículo # 1. RTOS: introducción.

Verificación de parámetros


Al elegir la configuración NUSE_API_PARAMETER_CHECKING , el código para verificar los parámetros se incluye en todas las funciones de la API: comprobación de punteros nulos, índices de objetos, etc. Dado que se trata de un código adicional que requiere memoria adicional, sería aconsejable habilitar esta función durante la depuración, pero desactívela en el conjunto de liberación.

Configuracion


Nucleus SE tiene una estructura flexible, que nos da dos puntos positivos. Por un lado, el núcleo puede tener una configuración detallada que satisfaga las tareas de una aplicación particular debido a la configuración simple de la funcionalidad disponible y la administración simple del uso de la memoria. Por otro lado, el código Nucleus SE es fácilmente portátil entre ambas herramientas y entre procesadores.

Convenciones de nomenclatura


Dado que la claridad y la facilidad de comprensión eran importantes al desarrollar Nucleus SE, las convenciones de nomenclatura fueron cuidadosamente pensadas. Cada carácter en el código tiene el prefijo NUSE_. Todo lo que sigue a este prefijo obedece a un conjunto de reglas simples.

Llamadas a la API


Cada función de llamada API en Nucleus SE comienza con NUSE_, que casi siempre va seguida de un tipo de objeto, seguido de una operación de mayúsculas y minúsculas, separadas por guiones bajos. Un ejemplo es la función NUSE_Queue_Send () , que pone en cola los mensajes.

Otras funciones y variables


El resto de las funciones y variables (globales) en el código de Nucleus SE también usan el prefijo NUSE_, pero el resto del nombre no siempre tiene una "estructura". Esto no es importante para el usuario promedio del núcleo, ya que tendrá suficientes funciones API.

Símbolos de configuración


Dado que Nucleus SE está configurado con caracteres #define, también obedecen las convenciones de nomenclatura. Están escritos solo en mayúsculas. Los nombres de los activadores de las llamadas a la API son los mismos que los nombres de las funciones y también están escritos en mayúsculas, por ejemplo, NUSE_QUEUE_SEND.

Otros #definir personajes


Cualquier otro carácter #define (por ejemplo, parámetros de llamada API y valores de estado de retorno) que pueda usar el código de la aplicación obedece a las mismas reglas, comienzan con NUSE_ y se escriben en mayúsculas. Por ejemplo, NUSE_SUCCESS.

Estructuras de datos


Todos los RTOS tienen un conjunto de estructuras de datos que describen los objetos del núcleo. En la mayoría de las implementaciones, son estructuras de datos en C que forman listas vinculadas, a menudo con comunicación bidireccional e incluso circular. Esto es lógico, ya que los datos importantes se encapsulan convenientemente, y los elementos de la lista se pueden agregar o eliminar a medida que se crean y eliminan los objetos.

En Nucleus SE, todos los objetos son estáticos, por lo que organizar todas las estructuras de datos de estos objetos en una lista simple fue la solución obvia. Esto reduce el volumen y la complejidad de los punteros hacia adelante y hacia atrás. Sin embargo, decidí fortalecer la optimización del sistema y me negué a usar estructuras. En Nucleus SE, todos los datos de los objetos del núcleo están representados por varias matrices simples (también llamadas tablas) de varios tipos, uno o más para cada tipo de objeto. Hay varios argumentos a favor de esta decisión:

  • Nucleus SE fue diseñado teniendo en cuenta la compatibilidad con estructuras de 8 bits. La mayoría de las CPU pequeñas no tienen herramientas óptimas para implementar estructuras de datos en un compilador de C. Las matrices simples son mucho más eficientes.
  • Como el número máximo permitido de objetos de cada tipo es 16, y el acceso a los elementos de cada matriz requiere cuatro bits, a menudo se usa un byte. Esto es más eficiente que una dirección, que generalmente toma 16 o 32 bits.
  • Los datos de objetos permanentes deben almacenarse en la ROM y no copiarse a la RAM. Dado que la estructura no se puede dividir entre ROM y RAM (en C portátil tradicional), cada tipo de objeto puede tener dos estructuras, lo que es demasiado complejo. En Nucleus SE, las tablas de descripción de objetos se pueden encontrar tanto en ROM como en RAM, según sea necesario.
  • Debido a la alta capacidad de configuración de Nucleus SE ("escalabilidad ultra alta"), algunos datos de descripción de objetos pueden ser opcionales, dependiendo de las herramientas seleccionadas. Esto lleva al uso generalizado de la compilación condicional. Una definición estructural con directivas de compilación condicional incorporadas es muy difícil de entender. El control de la creación de instancias de matrices individuales utilizando este método es, a su vez, bastante fácil de entender.


Todas las tablas de datos de objetos están sujetas a la convención de nomenclatura jerárquica mencionada anteriormente. Por lo tanto, es bastante fácil entender qué tablas están relacionadas lógicamente.

Diferencias clave de Nucleus RTOS


Aunque Nucleus SE fue diseñado con un alto grado de compatibilidad con Nucleus RTOS, no se pudieron evitar algunas diferencias pequeñas y grandes. Se describirán en detalle en los artículos relevantes, y a continuación se ofrece una breve descripción.

Datos de objeto


En Nucleus RTOS, los objetos se crean y eliminan a pedido. En Nucleus SE, todos los objetos se crean de forma estática y se determinan durante el ensamblaje.

Numero de objetos


Nucleus RTOS admite un número indefinido de objetos de cada tipo. Nucleus SE admite un máximo de dieciséis objetos de cada tipo.

Nombres de objeto


Nucleus RTOS le permite asignar tipos de texto a algunos tipos de objetos que pueden usarse para la depuración. Nucleus SE no tiene esta característica.

Mecanismo de bloqueo de tareas


El mecanismo para bloquear tareas con una llamada API en Nucleus SE es bastante simple. Cuando se libera un recurso, todas las tareas pendientes se reanudan y compiten entre sí (utilizando el programador de tareas) por los recursos. Las tareas perdedoras son nuevamente suspendidas (bloqueadas). En Nucleus RTOS, el mecanismo es más complejo, solo continúan tareas importantes, lo que es más efectivo.

API Call Timeout


Al llamar a la API de bloqueo, Nucleus RTOS permite al desarrollador especificar un período de tiempo de espera después del cual la llamada se reanudará incluso si el recurso no se libera. Nucleus SE no tiene esta característica.

Programación de tareas


Nucleus RTOS Scheduler es flexible, eficiente y bien definido. Nucleus SE ofrece un conjunto de planificadores, cada uno de los cuales es lo suficientemente simple y efectivo para un número reducido de tareas compatibles: de 1 a 16.

Prioridades de la tarea


Un sistema que usa Nucleus RTOS puede tener un número arbitrario de tareas a las que se les puede asignar uno de los 256 niveles de prioridad, mientras que varias tareas pueden tener un nivel de prioridad. Los niveles de prioridad de la tarea también pueden cambiar en tiempo de ejecución. En Nucleus SE, si se selecciona un planificador de prioridad, cada tarea debe tener un nivel de prioridad único que no se pueda cambiar dinámicamente. Solo puede haber un nivel de prioridad por tarea.

Manejo de interrupción


Nucleus RTOS admite la arquitectura sofisticada de un controlador de interrupciones de dos niveles que permite la interoperabilidad eficiente de los servicios de kernel y del controlador de interrupciones. Nucleus SE utiliza un enfoque similar que admite manejadores de interrupciones simples que no son del núcleo (interrupciones no administradas) y manejadores de interrupciones totalmente conscientes del contexto que pueden usar llamadas API (interrupciones administradas).

Controladores de dispositivos


Nucleus RTOS tiene una arquitectura de controlador de dispositivo bien diseñada. Nucleus SE no tiene dicha arquitectura, lo que deja al desarrollador la tarea de distribuir el control del dispositivo entre las tareas y el código del controlador de interrupciones.

Distribución de Nucleus SE


Los códigos fuente de Nucleus SE se publicarán a medida que se desarrolle esta serie de artículos. Los archivos disponibles estarán disponibles a pedido por correo electrónico. Hacia el final de la serie de artículos, se creará un repositorio para descargar todos los archivos publicados.

Sobre el autor
Colin Walls ha trabajado en la industria electrónica durante más de treinta años, dedicando la mayor parte de su tiempo al firmware. Ahora es ingeniero de firmware en Mentor Embedded (una división de Mentor Graphics). Colin Walls a menudo habla en conferencias y seminarios, autor de numerosos artículos técnicos y dos libros sobre firmware. Vive en el Reino Unido. Correo electrónico del blog profesional de Colin

Source: https://habr.com/ru/post/es422617/


All Articles