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

He escrito un montón de código simple para procesadores PIC y x86. ¿Alguien puede decirme cómo y cuándo debería necesitar un sistema operativo? Por el contrario, ¿qué aplicación o situación se puede tratar con o sin un sistema operativo también?

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 una codificación básica, 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 súper bucle que se puede mantener (y con suerte algo extensible), entonces probablemente no necesite un sistema operativo.

A medida que aumentan los requisitos de software, el súper bucle se vuelve más complejo. Cuando los requisitos de software son tantos que el súper circuito se vuelve demasiado complejo o no puede cumplir con los requisitos en 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 puntos muertos). 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 los sistemas operativos con todas las funciones, como VxWorks, Windows o Linux. Los sistemas operativos con todas las funciones 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 se trata de programación básica, no está incrustada (lo que excluye su pregunta), pero no estaría de acuerdo con eso: argumentaría que cualquier sistema que esté diseñado para realizar una sola 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 construyendo equipos de prueba sobre una suite 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, son sistemas integrados.

Sin embargo, solo comprar módulos de E / S listos para usar, enchufarlos en una PC de montaje en bastidor y crear una configuración en una GUI puede no calificar como diseño de sistema integrado para algunos. Para un poco menos de la situación comercial, considere un controlador de proceso personalizado con un FPGA, para el que desea hacer un registro de datos sofisticado. Puede integrar un sistema de procesador de núcleo blando (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 (por ejemplo, al menos un dispositivo que implique un protocolo o una máquina de estado más algo más que hacer), entonces algo de software OSish le facilitará la vida

Una vieja pregunta pero comentaré de todos modos.

Incluso si no tiene pilas de red o similares, en el punto donde necesita un programador de tareas ya que tiene suficientes procesos en su aplicación integrada, puede considerar un RTOS. Escribir un simple programador multitarea cooperativo basado en temporizador no es tan difícil, pero asegurarse de que un proceso atascado no bloqueará el resto de la aplicación y puede llevar un tiempo hacerlo bien. Debe implementar un sistema de prioridad con algún tipo de provisió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 los microcontroladores simples simplemente no pueden manejar una 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 de memoria de grano fino.

Un sistema operativo realmente 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 fuerte y flexible para la ejecución de la aplicación.