Toda la verdad sobre RTOS. Artículo # 32. Nucleus SE Migration: características no realizadas y compatibilidad

El principal requisito para el desarrollo de Nucleus SE fue un alto grado de compatibilidad con el producto principal de Mentor RTOS: Nucleus RTOS. Nucleus SE admite una cierta parte de la funcionalidad de Nucleus RTOS, que se ha discutido muchas veces en artículos anteriores, pero en este artículo intentaré recopilar todas las diferencias clave en un solo lugar. Este artículo fue pensado como una referencia rápida para todos los que van a cambiar de un núcleo a otro, o están en el proceso de elegir un núcleo para un proyecto específico.



Además de la funcionalidad limitada o simplificada, en comparación con Nucleus RTOS, Nucleus SE también se ha diseñado con el énfasis en maximizar la utilización de la memoria con amplias opciones de personalización. Una parte importante de este enfoque es la escalabilidad. Muchas características de la funcionalidad del núcleo se pueden activar o desactivar según sea necesario. Obviamente, deshabilitar la funcionalidad en una implementación particular aumenta su incompatibilidad con Nucleus RTOS.

En Nucleus RTOS, se puede crear un sistema con un número indeterminado de objetos del núcleo; la única limitación aquí es la cantidad de recursos disponibles (es decir, memoria). Nucleus SE tiene un límite de dieciséis objetos de cada tipo; el sistema puede tener de una a dieciséis tareas y de cero a dieciséis objetos de cada tipo (buzones, colas, etc.). A pesar de que se puede aumentar este límite, se requerirá un esfuerzo considerable, ya que Nucleus SE hace un uso extensivo de la capacidad de almacenar el índice de un objeto en un mordisco (cuatro bits). Además, con más de dieciséis tareas, es probable que el Programador prioritario se vuelva muy ineficiente. Una aplicación cuya funcionalidad adolece de estas limitaciones no es adecuada para Nucleus SE, en este caso Nucleus RTOS es una opción mucho más adecuada.

Planificador

Al igual que todos los núcleos modernos en tiempo real, Nucleus RTOS tiene un programador muy flexible que proporciona varios niveles de prioridad (con un número indeterminado de tareas en cada nivel de prioridad), así como la capacidad de seleccionar el programador Round Robin y Time Slice. Nucleus SE es mucho más simple y ofrece cuatro programadores que deben seleccionarse en el momento de la compilación: Run to Completion, Round Robin, Time Slice y Priority. Es imposible combinar diferentes planificadores (es decir, no hay un planificador compuesto). Por ejemplo, no puede seleccionar una combinación de planificadores Time Slice y Priority. Además, el planificador prioritario le permite asignar solo una tarea a cada nivel de prioridad, es decir, hay tantos niveles de prioridad como tareas. La prioridad de la tarea se establece durante la compilación y ya no cambia (como el intervalo de tiempo si se selecciona el planificador Time Slice).

Llamadas a la API

Interfaz de programación de aplicaciones (API): la "cara" visible del sistema operativo. No es sorprendente que aquí es donde las diferencias entre Nucleus RTOS y Nucleus SE son más obvias.

La API de Nucleus SE es diferente de la API de Nucleus RTOS. Sin embargo, la API Nucleus SE ha sido cuidadosamente diseñada para que pueda transferirse al fragmento API Nucleus RTOS. Los titulares de Nucleus RTOS con licencia pueden obtener un "shell" (un archivo de encabezado que contiene #define macros) que realizará la transferencia casi directamente.

Por el hecho de que la API Nucleus SE puede llamarse un "subconjunto" de la API Nucleus RTOS, se deduce que faltan algunas llamadas API. Esto es cierto y es un resultado inevitable de los criterios de desarrollo de Nucleus SE. Algunas llamadas a la API simplemente no tienen sentido, ya que están asociadas con una funcionalidad inexistente; otras llamadas fueron excluidas para simplificar la implementación de algunos objetos del núcleo. Todo esto se describe en detalle en las siguientes secciones de este artículo.

Funciones API comunes

Nucleus RTOS tiene funciones API que son comunes a varios tipos diferentes de objetos del núcleo, o incluso a todos los tipos de objetos. Algunos de ellos también se implementaron en Nucleus SE, un buen ejemplo de dicha función se restablece. Otras funciones no son aplicables a la implementación de objetos del núcleo en Nucleus SE.

Crea y elimina

En Nucleus RTOS, todos los objetos del núcleo son dinámicos; se crean y eliminan según sea necesario. Por lo tanto, hay llamadas de API para esto. En Nucleus SE, todos los objetos son estáticos (se crean durante el ensamblaje), por lo que estas llamadas a la API no son necesarias.

Devolver punteros a objetos

El identificador principal (descriptor) de los objetos del núcleo en Nucleus RTOS es un puntero al bloque de control del objeto, que se asigna cuando se crea el objeto. Por lo tanto, también hay un conjunto de llamadas API que devuelven una lista de punteros a objetos de cada tipo. Dado que Nucleus SE usa un índice simple para identificar objetos del núcleo, tales llamadas no son necesarias. Un programa puede sondear el kernel para averiguar cuántas instancias de objetos de un tipo particular están configurados (usando una llamada como NUSE_Mailbox_Count () ); si este valor es n , los índices de objetos de este tipo tendrán valores de cero a n-1 .

Transmisión de datos

Para algunos tipos de objetos de núcleo Nucleus RTOS (como buzones, colas y tuberías), se proporciona una sobrecarga de API para traducir los datos. Esto le permite enviar datos a todas las tareas que esperan datos del objeto. Esta posibilidad se excluyó de Nucleus SE para simplificar, ya que el acceso a los datos de dichos objetos siempre se realiza en el contexto de una tarea específica, que luego libera el objeto. Por lo tanto, para implementar la traducción, se requeriría un mecanismo de bandera adicional.

Características únicas de los objetos API

Muchos objetos del núcleo tienen llamadas API que son exclusivas de un tipo particular de objeto y difieren en Nucleus RTOS y Nucleus SE.

Las tareas

Dado que Nucleus RTOS Scheduler es significativamente más complejo que Nucleus SE, algunas funciones API no son necesarias:

• Cambiar la posición de una interrupción de tarea: no se admite en Nucleus SE.
• Cambiar prioridad de tarea: en Nucleus SE, la prioridad de tarea se asigna durante la configuración y no se puede cambiar.
• Cambio del intervalo de tiempo de la tarea: en Nucleus SE, el valor del intervalo de tiempo es común a todas las tareas y se establece durante la configuración.
• Finalización de tarea: Nucleus SE no admite el estado de tarea "completado".

Memoria dinámica

Como todo se crea estáticamente en Nucleus SE, la memoria dinámica no es compatible (y no es necesaria). Por lo tanto, las funciones API asociadas también son innecesarias.

Señales

Nucleus RTOS admite manejadores de señales, programas que se ejecutan (como manejadores de interrupciones) cuando cambian las señales de tareas. Esta característica se excluyó de Nucleus SE, por lo tanto, no se requieren llamadas API para administrar las señales y crear un controlador de señales.

Interrupciones

Nucleus SE utiliza el enfoque de interrupciones sin interrupción, simplemente proporcionando la capacidad de hacer algunas llamadas API desde el controlador de interrupciones. Por lo tanto, algunas llamadas a la API Nucleus RTOS que especifican cómo debe manejar las interrupciones el núcleo no son compatibles.

Diagnósticos

Nucleus SE tiene servicios de diagnóstico muy modestos, siguiendo su estilo de desarrollo "restringido", limitándose a la verificación de parámetros (opcional) y enviando el código de versión del producto. Por lo tanto, las llamadas a la API Nucleus RTOS relacionadas con el registro del historial y la confirmación de errores no son compatibles.

Conductores

Nucleus RTOS tiene una estructura de controlador formal bien definida y varias funciones API relacionadas con la gestión de controladores. Nucleus SE no tiene esta estructura; por lo tanto, las llamadas API correspondientes no son necesarias.

Funcionalidad de llamada API

Algunos aspectos de la funcionalidad de Nucleus SE, que se implementan de forma simplificada, generan diferencias con respecto a Nucleus RTOS. Algunos de ellos afectan cómo se usan las llamadas a la API y los servicios disponibles.

Tiempos de espera

Cuando se usa Nucleus RTOS, a menudo hay situaciones en las que una llamada API puede pausar una tarea en espera de acceder a un recurso: la tarea está bloqueada. Dicha suspensión de una tarea puede ser implícita (es decir, hasta que el recurso esté disponible) o se puede especificar un valor de tiempo de espera. Nucleus SE proporciona el bloqueo mediante llamadas API como una opción, sin embargo, solo se puede usar la suspensión implícita (es decir, una llamada solo puede usar NUSE_SUSPEND o NUSE_NO_SUSPEND , no un valor de tiempo de espera). Esta característica es bastante simple de agregar a Nucleus SE.

Procedimiento de suspensión

Cuando se crean múltiples tipos de objetos en Nucleus RTOS, se puede asignar una orden de suspensión. Esta es una secuencia en la que varias tareas bloqueadas se reanudarán a medida que los recursos estén disponibles. Hay dos opciones disponibles: FIFO, primero en entrar, primero en salir (primero en entrar, primero en salir), en el que las tareas se reanudan en el mismo orden en que se bloquean; o por prioridad, en la que la tarea con la prioridad más alta siempre se reanuda primero. Nucleus SE no ofrece tal opción. Implementa solo el orden de prioridad. De hecho, es más correcto decir el orden por el índice de tareas, ya que el orden de suspensión se puede aplicar no solo cuando se usa el planificador Prioritario, sino también cuando se usan los planificadores Round Robin y Time Slice.

Funcionalidad única

En algunos casos, los cambios funcionales relacionados con ciertos tipos de objetos eran necesarios.

Manejadores de señal
Como se mencionó anteriormente, la implementación de la señal en Nucleus SE no admite procedimientos de procesamiento de señal.

Configuración del temporizador de aplicación
El temporizador tiene una duración inicial / duración inicial de operación y una duración de reinicio y, opcionalmente, puede realizar una función definida por el usuario al finalizar. Esta funcionalidad es compatible con Nucleus RTOS y Nucleus SE. Sin embargo, Nucleus SE, a diferencia de Nucleus RTOS, no permite cambiar los parámetros descritos anteriormente cuando se llama a la función API para restablecer. Además, en Nucleus SE, todo el soporte para los procedimientos de finalización del temporizador es opcional.

Banderas de eventos
Nucleus RTOS tiene una opción para "absorber" las banderas de eventos. Esto significa que los indicadores que coinciden con los criterios establecidos por la tarea se restablecen. Dicha funcionalidad no es compatible con Nucleus SE, ya que la capacidad de buscar los criterios de varias tareas aumenta significativamente la complejidad del sistema.

Tamaños de datos

Dos criterios de desarrollo para Nucleus SE: mantener la simplicidad y minimizar el uso de memoria, han llevado a ciertas diferencias en el tamaño de los elementos de datos en comparación con Nucleus RTOS. Vale la pena señalar que Nucleus RTOS generalmente usa datos sin firmar , que probablemente sean de 32 bits. mientras que Nucleus SE utiliza tipos de datos simplificados como U32 , U16 , U8 , etc. ( Nota del traductor: en mi opinión, el autor tiene razón para los sistemas de 8 bits. En los sistemas modernos, los registros siguen siendo de 32 bits, por lo que cortar la parte anterior consume memoria para el código y los ciclos de reloj para su ejecución, y todos los datos son iguales a 32 bits cuando se almacenan en memoria, de lo contrario, el rendimiento del sistema disminuirá, por lo que este enfoque no proporciona una ganancia para los sistemas modernos, y una pérdida debido a las instrucciones agregadas por el compilador que cortan la parte anterior puede muy bien ).

Buzones

En Nucleus RTOS, un buzón almacena un mensaje que consta de cuatro elementos de datos sin firmar. En Nucleus SE, un buzón almacena un elemento de datos ADDR . En mi opinión, los buzones se usan a menudo para transferir una dirección (que indica datos específicos) de una tarea a otra.

Colas

En Nucleus RTOS, una cola procesa mensajes de uno o más elementos de datos sin firmar . La cola también se puede configurar para manejar mensajes de longitud variable. En Nucleus SE, una cola procesa mensajes que consisten en un solo elemento de datos ADDR . En mi opinión, las colas se usan de manera similar con los buzones. Además, en Nucleus RTOS, el tamaño total de la cola (es decir, el número total de elementos sin signo que se pueden colocar en la cola) se especifica como un valor sin signo. En Nucleus SE, este valor es de tipo U8 . Por lo tanto, una cola puede contener menos datos.

Canales de datos

En Nucleus RTOS, un canal procesa mensajes de uno o más bytes; El canal también se puede configurar para manejar mensajes de longitud variable. En Nucleus SE, un canal procesa mensajes que consisten en uno o más elementos de datos del tipo U8 . El tamaño del mensaje se establece durante la configuración de cada canal. Además, en Nucleus RTOS, el tamaño total del canal (es decir, el número total de bytes que se pueden colocar en un canal) se especifica como un valor sin señal . En Nucleus SE, este valor es del tipo U8 y representa el número de mensajes (en la llamada API NUSE_Pipe_Information () ). En consecuencia, un canal puede contener menos datos.

Grupos de banderas de eventos

En Nucleus RTOS, un grupo de banderas de eventos contiene 32 banderas; en Nucleus SE, su número se reduce a ocho. Se ha elegido este tamaño ya que los procesadores Nucleus SE de destino probable pueden procesar datos de 8 bits de manera eficiente. Al mismo tiempo, cambiar el número de banderas en los grupos de banderas de eventos procesados ​​por Nucleus SE no será difícil.

Señales

En Nucleus RTOS, cada tarea tiene un conjunto de 32 indicadores de señal. En Nucleus SE, las señales son opcionales y cada tarea tiene un conjunto de 8 banderas. Se ha elegido este tamaño porque los procesadores Nucleus SE de destino probable pueden procesar datos de 8 bits de manera eficiente. Al mismo tiempo, cambiar el número de banderas en los conjuntos de señales procesadas por Nucleus SE no será difícil.

Secciones de memoria

En Nucleus RTOS, el número y el tamaño de las particiones no tienen signo . En Nucleus SE, el número de particiones es un parámetro del tipo U8 y el tamaño de la partición es U16 . Esto lleva a algunas restricciones de partición y tamaño de grupo.

Temporizadores

En Nucleus RTOS, los temporizadores (tanto los temporizadores de aplicación como los de inactividad de tareas) funcionan con valores sin signo . En Nucleus SE, son del tipo U16 . Se eligió este tipo porque los procesadores Nucleus SE de destino probable pueden procesar datos de 16 bits de manera eficiente (y ocho bits claramente no son suficientes para usar un temporizador). Al mismo tiempo, cambiar el tamaño de los temporizadores en Nucleus SE no será difícil.

El siguiente artículo examinará cómo se puede usar Nucleus SE en un proyecto de software integrado.

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. Blog profesional de Colin , correo electrónico: colin_walls@mentor.com.