¿Cuándo necesitamos un sistema operativo en el diseño del sistema integrado?

Mi regla de oro 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 (tal vez una con objetos GUI como Windows y eventos), o un sistema de archivos.

Si has hecho un poco de codificación completa, probablemente estés familiarizado con el programa super-loop arquitectura. Si los requisitos de firmware del producto son lo suficientemente simples como para ser implementados con un súper bucle que se puede mantener (y es de esperar que sea algo extensible), entonces probablemente no necesite un sistema operativo.

A medida que aumentan los requisitos del software, el super-bucle se vuelve más complejo. Cuando los requisitos de software son tantos que el súper bucle se vuelve demasiado complejo o no puede cumplir los requisitos en tiempo real del sistema, 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 una red, una GUI compleja y un sistema de archivos, es posible que esté en el punto en el que debería considerar 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 'sistema integrado'. Puede haber algunos que afirmen que si no es una programación simple, 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, se podría llamar 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, son sistemas integrados.

Sin embargo, solo comprando módulos de E / S disponibles en el mercado, enchufándolos a una PC de montaje en rack y activando una configuración en una GUI puede que no califique como diseño del sistema incorporado para algunos . Para una situación un poco menos comercial, considere un controlador de proceso personalizado con un FPGA, para el cual desea realizar un registro de datos sofisticado. Puede integrar 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 de oro (muy vaga) es si necesita más de un hilo de control (por ejemplo, al menos un dispositivo que involucre un protocolo o una máquina de estado más algo más que hacer), entonces algunos de los programas de OSish harán que su vida mas facil

Una vieja pregunta pero voy a comentar de todos modos.

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

RTOS también le ofrece funciones como la protección de memoria y similares, lo que facilita mucho el seguimiento de algunos errores comunes en código C, pero los microcontroladores simples simplemente no pueden manejar una protección de memoria compleja. P.ej. MSP430 le permite separar código y datos en alto nivel, pero no hay un control de acceso de memoria de grano fino.

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 alto nivel 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.