Toda la verdad sobre RTOS. Artículo # 6. Otros servicios RTOS

En artículos anteriores, discutimos la funcionalidad del núcleo en términos de las tareas realizadas y la interacción entre ellas. En este artículo, observamos qué más puede hacer el núcleo, que se manifiesta en gran medida en una serie de otras llamadas API disponibles. También responderemos a la pregunta, ¿qué convierte el núcleo en un sistema operativo?

Artículos anteriores de la serie:
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.

Gestión de tareas

Además de la programación de tareas y la interacción entre ellos, el RTOS incluirá la funcionalidad (llamadas a la API) para administrar tareas de varias maneras. Consideremos algunas posibilidades.

Crear y eliminar tareas

En el RTOS "dinámico" hay llamadas a funciones que le permiten crear tareas (y otros objetos RTOS) cuando se requieren. Dichas llamadas incluyen una amplia gama de parámetros que definen la tarea, por ejemplo, punto de entrada, tamaño de pila y prioridad. La llamada a la API de eliminación de tareas correspondiente le permite liberar recursos después de completar la tarea.

En el RTOS "estático", los parámetros de definición de la tarea se configuran en una especie de archivo de configuración durante el ensamblaje.

Pausa y reanuda una tarea

Como vimos, la mayoría de los RTOS tienen el concepto de un estado de tareas "suspendido". Esto se puede lograr de varias maneras. Una de ellas es una llamada explícita a la función API Suspender tarea. Puede ser causado por sí mismo o por otra tarea. La correspondiente llamada "Reanudar tarea" permite que la tarea vuelva a ponerse en cola para la planificación.

Tarea estado de suspensión

Para un sistema en tiempo real, el control del tiempo es un requisito importante y puede adoptar diversas formas. Una vista simple es la capacidad de la tarea de "quedarse dormido", es decir, la tarea se suspende por un cierto período de tiempo. Cuando se agota el tiempo, la tarea "se despierta" y nuevamente se pone en cola para su planificación. Una llamada API generalmente estará disponible para este propósito. Por supuesto, esta funcionalidad depende de la disponibilidad del temporizador.

Exención

Cuando se usa el programador Round Robin ("carrusel"), una tarea puede negarse a controlar el procesador para la siguiente tarea en la cadena. Para hacer esto, la función API "Liberar tarea" estará disponible. La tarea no se suspende, estará disponible para la planificación cuando llegue su turno. Cuando se utiliza el planificador de segmentos de tiempo, es posible que una tarea pueda liberar parte de su intervalo de tiempo si no tiene un trabajo importante que hacer de inmediato. Liberar una tarea no tiene un significado lógico cuando se ejecuta Ejecutar hasta la finalización o Programadores prioritarios.

Tarea completada

En un artículo anterior, encontramos que, además de los estados "Listo" o "Suspendido", el RTOS puede admitir otros estados de tareas. La tarea puede ser "Finalizada", lo que significa que su función principal acaba de salir: no se requiere una llamada API especial. Una tarea puede ser "Terminada", lo que significa que no está disponible para la planificación y debe reiniciarse para que esté disponible para su lanzamiento nuevamente, consulte "Restablecer una tarea" a continuación. Esto requiere una llamada API especial. La disponibilidad de estos estados de tareas adicionales, la terminología utilizada y sus definiciones exactas diferirán según el RTOS.

Restablecer tarea

Muchos RTOS ofrecen una llamada a la función API "Restablecer tarea", que le permite devolver la tarea a su estado original. Puede estar en estado suspendido y requerir que se ejecute la función "Reanudar tarea" para hacer cola para la planificación.

Tareas prioritarias, etc.

En un RTOS "dinámico", las llamadas API pueden estar disponibles para configurar varios parámetros de tareas en tiempo de ejecución. Los ejemplos incluyen la prioridad y la duración del intervalo de tiempo.

Información del sistema

En RTOS, habrá una serie de llamadas API para proporcionar al sistema información sobre la tarea, que incluye:
Información sobre las tareas . Cuántas tareas hay en el sistema, su configuración y estados actuales.
Información sobre otros objetos del núcleo. Cuántos objetos de cada tipo hay en el sistema, su configuración e información sobre el estado actual. Por ejemplo:

• ¿Cuál es la capacidad actual de la cola? ¿Puedo agregar más mensajes?
• ¿Cuántas tareas están suspendidas en un buzón particular?

Información sobre la versión RTOS . Una llamada a la API puede proporcionar datos similares.

Asignación de memoria

En muchas aplicaciones, es importante que el programa pueda capturar dinámicamente algo de memoria cuando sea necesario y liberarlo cuando ya no sea necesario. Lo mismo sucede en el firmware. Sin embargo, los enfoques convencionales son propensos a problemas que son poco probables o inconvenientes en las aplicaciones de escritorio, pero pueden ser desastrosos para un sistema integrado. Sin embargo, hay formas de implementar dichos servicios, incluso en un RTOS estático.

Problemas con las funciones malloc () y free ()

En un programa de escritorio C, una función puede llamar a malloc () , indicando cuánta memoria se requiere, y recuperar un puntero al área de almacenamiento. Usando memoria, se puede liberar llamando a free () . La memoria se asigna desde un área llamada montón. El problema con este enfoque es que con una secuencia descoordinada de llamadas a estas funciones, el área de almacenamiento dinámico puede fragmentarse fácilmente, y luego la asignación de memoria fallará incluso si hay suficiente memoria disponible, porque Las áreas adyacentes no son lo suficientemente grandes. Algunos sistemas (como Java y Visual Basic) utilizan esquemas sofisticados de "recolección de basura" para desfragmentar. El problema es que estos esquemas pueden generar retrasos impredecibles significativos en el tiempo de ejecución y la necesidad de utilizar punteros indirectos (que no funcionan en C).

Si malloc () y free () se implementaron de forma reentrante (generalmente no) y se usaron en las tareas RTOS, la fragmentación ocurrirá muy rápidamente y una falla del sistema será casi inevitable. En C ++, hay operadores nuevos y de eliminación que generalmente realizan las mismas funciones que malloc () y free (). Están sujetos a las mismas limitaciones y problemas.

Secciones de memoria

Para proporcionar un sistema en tiempo real con memoria accesible dinámicamente, se puede utilizar un enfoque de bloque para la administración de memoria. Tales bloques se denominan comúnmente "particiones"; las particiones se pueden asignar desde el "grupo de particiones".

El grupo de particiones contiene un cierto número de bloques, cada uno de los cuales tiene el mismo tamaño. El número y el tamaño de los bloques en una partición se determinan cuando se crea el grupo de particiones. Esto puede ser dinámico si el sistema lo permite, o estáticamente durante el ensamblaje. Por lo general, una aplicación puede incluir varios grupos de particiones que ofrecen bloques de diferentes tamaños.

Si una tarea necesita memoria, llama a una API que solicita un bloque de un grupo específico. Si esta llamada tiene éxito, la tarea recibirá un puntero al bloque seleccionado. Si la llamada falla porque no hay particiones disponibles en el grupo indicado, la tarea puede recibir una respuesta de error. Alternativamente, la tarea puede bloquearse (suspenderse) hasta que otra tarea libere el bloqueo en la sección.

Típicamente, una tarea simplemente pasa un puntero a un bloque de memoria en cualquier código que use el bloque. Esto lleva a un problema cuando el bloque ya no es necesario. Si el código solo tiene un puntero a un bloque, ¿cómo puede decirle al RTOS a través de una llamada API, de qué grupo de partición desea liberar memoria? La respuesta es que la mayoría de los RTOS admiten datos adicionales en un bloque dedicado (generalmente un desplazamiento negativo del puntero) que proporcionan la información requerida. Por lo tanto, para llamar a la API para liberar un bloque, solo se requiere su dirección.

El siguiente artículo tendrá más información sobre particiones de memoria.

Tiempo

Es probable que la funcionalidad asociada con el uso y el control del tiempo esté disponible en el sistema operativo en tiempo real. Las oportunidades variarán según el RTOS, pero consideraremos las disponibles públicamente. En cualquier caso, el temporizador en tiempo real es un elemento indispensable para el funcionamiento de cualquiera de estos servicios.

Hora del sistema

La hora del sistema simple, o "temporizador de reloj", casi siempre está disponible. Esto es solo un contador (generalmente 32 bits), que se incrementa utilizando la rutina de servicio de interrupción en tiempo real y se puede configurar y leer a través de llamadas API.

Tiempos de espera de llamadas de servicio

Normalmente, un RTOS permite bloquear llamadas API, es decir, la tarea de llamada se suspende (bloquea) hasta que se proporciona el servicio solicitado. Por lo general, este bloqueo es vago, pero algunos RTOS ofrecen un tiempo de espera durante el cual la llamada regresa cuando expira el tiempo de espera si el servicio continúa sin estar disponible. Los tiempos de espera de llamadas de API no son compatibles con todos los RTOS.

Tarea estado de suspensión

Por lo general, las tareas tienen la capacidad de detenerse por un período fijo de tiempo. Esto se discutió anteriormente en la sección Gestión de tareas.

Temporizadores de software

Para que las tareas del programa realicen funciones de conteo de tiempo, la mayoría de los RTOS ofrecen objetos de temporizador. Estos son temporizadores independientes actualizados por el controlador de interrupción de temporizador en tiempo real, que puede controlarse mediante llamadas API. Tales llamadas configuran, monitorean y monitorean la operación del temporizador. Como regla, se pueden configurar para una sola actuación o reinicio automático. Por lo general, también se admite una rutina de caducidad, una función que se ejecuta cada vez que un temporizador completa un ciclo. El siguiente artículo proporcionará más información sobre temporizadores de software y una descripción de su implementación.

Interrupciones, controladores y E / S

La medida en que los RTOS están asociados con interrupciones y E / S es muy diferente. Del mismo modo, algunos RTOS tienen una estructura muy clara para los controladores de dispositivos, lo que puede agregar problemas al elegir un producto específico.

Interrupciones

Las interrupciones presentan un problema para RTOS por dos razones.

• Sin ninguna precaución, el controlador de interrupciones (ISR) "robará" el tiempo del procesador, interrumpiendo así el comportamiento RTOS en tiempo real.
• Si el ISR realiza llamadas a la API que afectan la programación de tareas, esto debería ser monitoreado y el RTOS debería poder ejecutar su algoritmo de programación.

Un ejemplo de una llamada API de este tipo es el procedimiento para activar una tarea con una prioridad más alta que la que se inició cuando se produjo la interrupción.

Algunos RTOS controlan completamente todas las interrupciones. Hay una serie de llamadas API disponibles para "registrar" los programas ISR. Este enfoque permite que el planificador identifique cuándo se habilitan las interrupciones y facilita el uso de la mayoría de las llamadas API desde el ISR.

Por ejemplo, Nucleus RTOS implementa el concepto de manejadores de interrupciones de "baja prioridad" y "alta prioridad", que proporciona una gestión de interrupciones confiable sin sobrecarga innecesaria (es decir, un aumento en el retraso de la interrupción).

Otros RTOS pueden usar el modo automático de "interrupción" para las interrupciones, que proporciona a los desarrolladores más opciones para garantizar que los manejadores de interrupciones funcionen correctamente. Como regla, se proporcionan prefijo ISR (prólogo) y sufijo (epílogo) adicionales para proteger las llamadas API realizadas en él.
Nucleus SE utiliza una rutina de interrupción ligera, que se describirá en un artículo futuro.

Conductores

La mayoría de los RTOS determinan la estructura del controlador del dispositivo. Los detalles pueden variar según el RTOS, pero el controlador generalmente consta de dos componentes interactivos: código incrustado (llamadas API) e ISR. Por lo general, otras llamadas API estarán disponibles para administrar y registrar controladores.

Entrada / salida

Actualmente, la mayoría de los RTOS en el mercado no se preocupan por la entrada / salida de nivel superior, pero algunos definen un flujo de entrada / salida, que básicamente establece una conexión entre los controladores de dispositivo correspondientes y las funciones estándar del lenguaje C, como printf ().
Históricamente, el RTOS a menudo soportaba la "consola", la interfaz de usuario para el RTOS a través de un canal en serie. Esto se usó principalmente para diagnósticos y depuración. El uso de depuradores modernos que admiten aplicaciones de depuración con RTOS elimina la necesidad de tales objetos.

Diagnósticos

Por lo general, RTOS requiere un rendimiento máximo con una huella de memoria mínima. Por lo tanto, la verificación de integridad no es una alta prioridad. Con la ayuda de tecnologías modernas de depuración que tienen en cuenta las características del RTOS, la mayoría de las comprobaciones pueden realizarse fuera del RTOS.

Comprobación de parámetros de llamadas de API

Las llamadas a la API pueden tener muchos parámetros complejos. Esto puede causar errores. Muchos RTOS proporcionan una verificación de los parámetros de tiempo de ejecución con la devolución de un código de error en caso de un parámetro incorrecto. Dado que esto requiere un código adicional y las comprobaciones mismas afectan negativamente el rendimiento, es mejor verificar los parámetros durante el ensamblaje o la configuración.

Verificación de pila

Para la mayoría de los tipos de planificador (excepto Run to Completion), cada tarea tiene su propia pila, cuyo tamaño se determina individualmente. En algunos RTOS, el núcleo tiene una pila separada, en otros, la pila de tareas es "prestada" durante una llamada API. Obviamente, la integridad de la pila es importante para la confiabilidad general del sistema. Por lo tanto, los RTOS a menudo ofrecen herramientas para verificar la integridad de la pila en tiempo de ejecución. Hay varias opciones:

• Una llamada a la API que devuelve la cantidad de espacio de pila para la tarea actual o especificada.
• Los parámetros delimitadores de la pila. Se les asigna un valor único (generalmente impar y distinto de cero), que se verifica periódicamente para su reescritura.

Diagnóstico de la aplicación

A pesar de que esta función no se admite directamente en el RTOS, se puede asignar una tarea de aplicación para verificar la integridad de todo el sistema. Tal tarea puede ser responsable de restablecer el temporizador de vigilancia. Una tarea puede recibir datos de entrada periódicos (por ejemplo, parámetros de señal) de cada tarea crítica. El restablecimiento del temporizador de vigilancia (que evitará que el sistema se reinicie) se realizará solo después de que hayan llegado los datos de todas las tareas.

Servicios no kernel

El RTOS es más que solo el núcleo en el que nos hemos centrado hasta ahora. Este sistema operativo de escritorio es significativamente diferente del RTOS incorporado. Por lo general, en un sistema operativo de escritorio, todos los componentes adicionales están agrupados o pueden instalarse (todas las PC de escritorio tienen una interfaz gráfica de usuario, y solo algunas de ellas no tienen acceso a la red). La PC de escritorio no tiene límites de recursos reales: siempre hay memoria libre, espacio en el disco duro y recursos de CPU no utilizados. En un mundo de sistemas integrados con recursos limitados, pueden ser necesarios componentes adicionales como tarjetas de video, componentes de red y sistemas de archivos, pero deben ser desconectables y escalables para minimizar la huella de memoria.

Funciones de red

La mayoría de los sistemas integrados están relacionados de alguna manera con las redes. Por lo tanto, se espera que haya un interés significativo en las soluciones de red para sistemas integrados, debido a que hay una gran cantidad de productos en el mercado.

TCP / IP es un protocolo estándar que se usa ampliamente y es la opción obvia para muchas aplicaciones. Normalmente, TCP / IP se usa para el protocolo Ethernet (IEEE802.3), que proporciona una velocidad promedio de 10 Mb / s. Hoy, 100 Mb / s son bastante comunes, y en el enfoque de 1 Gb / s. Además, TCP / IP se puede usar para otros protocolos. Por ejemplo, PPP (Protocolo punto a punto) es una implementación TCP / IP para transferencia de datos en serie que se ha adaptado para conexiones de Internet de banda ancha.

Hasta hace poco, se usaba la versión v4 del protocolo IP (IPv4). Sin embargo, se vuelve obsoleto a medida que se agotan las direcciones libres. La solución es IPv6, lo que aumenta significativamente el número de direcciones posibles y proporciona herramientas más eficientes para el mantenimiento y la seguridad. IPv6 está ampliamente disponible y se utiliza en equipos de muchos países, así como en sistemas militares de todo el mundo.
Una alternativa es el Protocolo de datagramas de usuario (UDP). Este protocolo se utiliza para obtener el máximo rendimiento. UDP no proporciona la misma confiabilidad y consistencia que TCP, pero es liviano y altamente eficiente.

USB es el bus serie universal, ampliamente utilizado en dispositivos para conectarse a computadoras de escritorio. Proporciona una interfaz plug-and-play muy fácil de usar que oculta software bastante sofisticado. , , USB-, . , USB ( ), «».

IEEE1394 – , (, ), FireWire i.Link.

Protocolos inalámbricos: la conveniencia y la prevalencia de diversas tecnologías inalámbricas entre los consumidores ha llevado a una gran demanda de capacidades inalámbricas en dispositivos integrados. Wi-Fi (conjunto de estándares IEEE802.11) proporciona un conjunto completo de capacidades de red, lo que le permite implementar topologías de pares e infraestructura a una distancia suficiente. El interés en la seguridad de datos en tales redes está creciendo, lo que significa que esto debería afectar el software. Otras tecnologías de radio, especialmente Bluetooth y ZigBee, proporcionan comunicaciones inalámbricas de punto a punto de corto alcance.

Verificación del protocolo

Dado que las oportunidades de creación de redes tienen una gran demanda, hay muchos proveedores que ofrecen sus soluciones. Los clientes enfrentan el desafío de verificar la calidad de los productos disponibles. A diferencia del kernel RTOS, una verificación completa de la funcionalidad y el rendimiento de la pila de protocolos no es una tarea fácil. Afortunadamente, hay kits de herramientas disponibles para verificar protocolos (aunque a un precio significativo), y un posible comprador puede averiguar del proveedor qué conjunto solía verificar.

Gráficos

Una interfaz gráfica se está volviendo más común entre los dispositivos integrados. Puede ser una LCD monocromática pequeña muy simple (como en teléfonos viejos, reproductores de MP3, alarmas, etc.). Por otro lado, un receptor de televisión digital puede tener su propia pantalla HDTV de alta resolución. Tal pantalla requiere soporte de software que está completamente integrado en el núcleo RTOS.
Dado que la pantalla generalmente tiene algún tipo de dispositivo de entrada, el soporte para dichos dispositivos a menudo se incluye en el paquete de gráficos. Dicho paquete puede admitir dispositivos señaladores (por ejemplo, un mouse), pantallas táctiles, teclados y teclados completos.
Los gráficos se pueden usar de varias maneras. Simplemente puede proporcionar información de salida (por ejemplo, como un marcador electrónico). O la pantalla puede ser parte de una interfaz gráfica de usuario junto con menús, ventanas, iconos y elementos similares. En cualquier caso, se requiere un conjunto de software bastante específico, y el paquete de gráficos suministrado con el RTOS debe proporcionar la flexibilidad necesaria sin aumentar significativamente la cantidad de memoria utilizada.

Sistemas de archivos

, , - . RAM, -, , (CD-ROM DVD-ROM). , . .

. , , MS-DOS, .