¿Cuándo necesitamos un sistema operativo en el diseño de sistemas integrados?

Mi regla general es que debe considerar un sistema operativo si el producto requiere uno o más de los siguientes: una pila TCP/IP (u otra pila de red compleja), una GUI compleja (quizás una con objetos GUI como ventanas y eventos ), o un sistema de archivos.

Si ha realizado algo de codificación bare metal, entonces probablemente esté familiarizado con la arquitectura del programa super-loop . Si los requisitos de firmware del producto son lo suficientemente simples como para implementarse con un superbucle que se pueda mantener (y, con suerte, algo extensible), entonces probablemente no necesite un sistema operativo.

A medida que aumentan los requisitos de software, el superbucle se vuelve más complejo. Cuando los requisitos de software son tantos que el superbucle se vuelve demasiado complejo o no puede cumplir con los requisitos de tiempo real del sistema, entonces es hora de considerar otra arquitectura.

Una arquitectura RTOS le permite dividir los requisitos de software en tareas. Si se hace correctamente, esto simplifica la implementación de cada tarea. Y con la priorización de tareas, un RTOS puede facilitar el cumplimiento de los requisitos en tiempo real. Sin embargo, un RTOS no es una panacea. Un RTOS aumenta la complejidad general del sistema y lo abre a nuevos tipos de errores (como interbloqueos). Como alternativa al RTOS, puede considerar una arquitectura de máquina de estado basada en eventos (como QP ).

Si su producto tiene redes, una GUI compleja y un sistema de archivos, entonces podría estar en el punto en el que debería considerar sistemas operativos con todas las funciones, como VxWorks, Windows o Linux. Los sistemas operativos completos incluirán controladores para los detalles de bajo nivel y le permitirán concentrarse en su aplicación.

Realmente depende de su definición de un 'sistema integrado'. Puede haber algunos que afirmen que si no es una programación completa, no está integrada (lo que excluye su pregunta), pero no estoy de acuerdo con eso; diría que cualquier sistema diseñado para realizar solo una función, es decir, para ejecutar solo una 'aplicación' específica, podría llamarse un sistema integrado.

Dicho esto, debería ser bastante fácil imaginar situaciones que se beneficiarían de los servicios de un sistema operativo completo. Por ejemplo, donde trabajo, es bastante común encontrar personas que construyen equipos de prueba sobre un conjunto de diseño de instrumentación que se ejecuta sobre ventanas. Estos sistemas están configurados para iniciarse en la configuración de la estación de prueba y bloquear el uso general (para evitar la corrupción de la estación) y, por lo tanto, podría decirse que son sistemas integrados.

Sin embargo, comprar módulos de E/S disponibles en el mercado, conectarlos a una PC de montaje en bastidor y preparar una configuración en una GUI puede no calificar como diseño de sistema integrado para algunos. Para una situación un poco menos estándar, considere un controlador de proceso personalizado con un FPGA, para el cual desea realizar un registro de datos sofisticado. Puede incorporar un sistema de procesador de núcleo suave (con un BSP existente) y ejecutar un Linux en tiempo real para ejecutar una pila de red (para su registro y NTP, etc.) y hacer todo lo demás en lógica.

Mi regla general (muy vaga) es que si necesita más de un hilo de control (digamos al menos un dispositivo que involucre un protocolo o una máquina de estado más algo más que hacer), entonces algún software OSish le facilitará la vida.

Una vieja pregunta, pero voy a comentar de todos modos.

Incluso si no tiene pilas de red o similares, en el punto en que necesita un programador de tareas ya que tiene suficientes procesos en su aplicación integrada, podría considerar un RTOS. Escribir un programador multitarea cooperativo basado en un temporizador simple no es tan difícil, pero asegurarse de que un proceso atascado no bloquee el resto de la aplicación y puede llevar un tiempo hacerlo bien. Debe implementar un sistema de prioridad con algún tipo de disposición para reducir los procesos en la cola si no se han completado.

RTOS también le brinda cosas como protección de memoria y similares, lo que hace que sea mucho más fácil rastrear algunos errores comunes en el código C, pero es posible que los microcontroladores simples simplemente no puedan manejar la protección de memoria compleja. Por ejemplo, MSP430 le permite separar el código y los datos en un nivel alto, pero no hay un control de acceso a la memoria detallado.

Un sistema operativo en realidad cierra la brecha entre el hardware y el software de la aplicación (a través del controlador del dispositivo). En otras palabras, proporciona una plataforma de nivel relativamente alto para el programador que, en última instancia, reduce la complejidad del código. Y además, el sistema operativo proporciona una plataforma sólida y flexible para la ejecución de la aplicación.