¿Cuál es la diferencia entre un sistema integrado basado en Linux y un sistema integrado basado en microcontrolador? ¿Cuáles son algunos ejemplos del mundo real para ambos?

En lugar de solo comparar un sistema basado en uC versus un sistema embebido basado en Linux, hagamos un análisis más profundo.

Programar un uC (microcontrolador) desde cero es similar a escribir su propio sistema operativo y luego escribir la aplicación en ese sistema operativo. Esto se convierte en una tarea gigantesca, especialmente si la aplicación es compleja y tiene muchas partes móviles, un juego de palabras destinado en casos como robots. Pero si su aplicación es bastante simple, comienza a tener mucho sentido, ya que no necesitará algunas de las funcionalidades de un sistema operativo, como la programación de hilos, el manejo de mensajes, etc. Por ejemplo, si todo lo que necesita es controlar, tal vez solo un motor paso a paso en una forma de avance, no necesita muchas campanas y silbatos.

Ahora, tenga en cuenta que los uC son dispositivos muy simples, tiene memoria limitada, una tonelada de periféricos integrados, tal vez tenga DMA y, definitivamente, un solo núcleo (aunque hay algunos uC con múltiples núcleos asimétricos y simétricos) , y definitivamente no MMU, ya que toda su memoria está en el chip y no necesita la complejidad adicional.

Pero puede haber un caso en el que su aplicación sea lo suficientemente grande como para garantizar el uso de un sistema operativo, algo que proporciona algún tipo de programación de subprocesos, E / S y manejo de interrupciones, manejo de mensajes o protección de datos, etc. Ingrese, sistemas operativos mínimos como FreeRTOS, Estos son básicamente núcleos “nano”, que le proporcionan las necesidades mínimas básicas. Su “aplicación”, en tales sistemas, está integrada hasta cierto punto con el núcleo.

Entonces, supongamos que tiene una aplicación, donde requiere esencialmente un sistema operativo totalmente operativo, pero no desea invertir en hardware adicional. Tiene opciones de hardware para estos sistemas, como MCU de doble núcleo LPC ARM Cortex-M0 y M4F | NXP donde tiene periféricos y memoria integrados, y puede agregar memoria y periféricos adicionales. En un sistema de este tipo, puede tener múltiples programas de aplicación que deben cargarse y luego ejecutarse, elementos de interacción humana mucho más complejos, como quizás una GUI en una pantalla táctil LCD +, una consola de terminal, etc. El beneficio de estos sistemas es que el diseño del hardware es más simple, ya que tiene memoria RAM y memoria de programa a bordo del chip, y puede agregar memoria adicional con interfaces mucho más simples que en un procesador completo. Para tales sistemas, definitivamente querría un sistema operativo. Pero como su elemento de procesamiento no es un procesador normal con MMU, necesita una versión reducida del sistema operativo. Entra, uCLinux.

Finalmente, desea un sistema informático completamente desarrollado, con un procesador con MMU, implementado para una tarea específica, es decir, un sistema integrado. Ahí es donde puedes usar Linux o un sabor de BSD.

Ahora hay un problema. La mayoría de los sistemas integrados, incluso si tienen elementos complejos de interacción humana como la pantalla táctil, se implementan para aplicaciones en tiempo real, como el control de máquinas. Linux tradicional es una mala elección en esas aplicaciones, ya que el kernel no es un kernel preventivo en tiempo real. Puede usar RTLinux o RTAI si solo se siente cómodo con un entorno de trabajo Linux, o puede usar un RTOS como QNX Neutrino.

Los sistemas operativos en tiempo real proporcionan un límite superior al tiempo que lleva completar una tarea de aplicación. Hard Real-Time Systems utiliza elementos de hardware como temporizadores Watchdog o incluso temporizadores normales para proporcionar dicha funcionalidad. Sus controladores de interrupción también se escriben teniendo en cuenta dicha funcionalidad. Entonces, esta es una diferencia crítica que un sistema Linux puro tendría contra varios sistemas en tiempo real.

Primero, los ejemplos del mundo real: un enrutador basado en Linux frente a un control remoto de TV basado en un microcontrolador de metal desnudo. Uno podría ser factible con un Beaglebone y el otro con un pequeño Arduino.

El sistema basado en Linux proporcionará todo tipo de acceso de alto nivel al hardware, así como una serie de instalaciones como redes, sistemas de archivos, multitarea, gestión y protección de memoria, etc. El precio a pagar por todo esto es ese acceso a El hardware a un nivel lo suficientemente bajo como para cumplir los requisitos puede ser difícil o incluso imposible. La sincronización del acceso sensible a GPIO sería un ejemplo común. Las herramientas para desarrollar software en Linux son abundantes, gratuitas, consistentes en todas las plataformas y, en general, están bien soportadas y se comprenden. Las bibliotecas de código gratuito y compatible también son abundantes.

El sistema basado en microcontrolador le permitirá un acceso sin restricciones a todo el hardware y un control sencillo de todos los recursos del sistema, como memoria, periféricos y temporización. El precio a pagar por eso es que tienes que rodar el tuyo para casi todo. Es menos probable que las herramientas que utiliza sean tan compatibles como las herramientas basadas en Linux, posiblemente propietarias y posiblemente no gratuitas en ningún sentido. El código que escriba será menos portátil por definición, aunque creo que la portabilidad en los sistemas integrados está algo sobrevalorada.

A menudo, los sistemas basados ​​en microcontroladores están muy limitados en recursos, aunque los sistemas basados ​​en Linux también pueden estarlo. Por lo general, el sistema basado en Linux será más poderoso en general, pero el sistema operativo consume una buena parte de eso. Los sistemas basados ​​en microcontroladores probablemente sean los más adecuados para aplicaciones que requieren conservación de energía, aunque esto no es una verdad universal. Es casi seguro que su microcontrolador requiera un lenguaje de programación compilado como C, C ++ o ensamblador. El sistema basado en Linux puede permitirle usar lenguajes de nivel superior como Python o Java.

La respuesta tendría que comenzar desde la definición de un sistema integrado de pequeña escala y un sistema integrado de mediana / gran escala. Un sistema integrado generalmente se define como “un sistema informático con una función dedicada dentro de un sistema mecánico o eléctrico más grande”. Para algunas de las tareas más simples, como una máquina expendedora (que no tiene una función de reconocimiento de voz / facial incorporada en 😉), el conteo de productos en la cadena de suministro, un pequeño LED, etc., son ejemplos de sistemas que no necesitan un sistema operativo y la funcionalidad se puede lograr fácilmente mediante una combinación simple de un microcontrolador, algunas partes mecánicas, periféricos y S / w (firmware típico) escrito en la parte superior del controlador. Por otro lado, un sistema embebido basado en Linux tendría los recursos de memoria / energía básicamente para asumir tareas más complejas y darle respuestas. Suponga que un STB de Linux, un Sniffer, controladores en automóviles / aviones o una multitud de dispositivos electrónicos de consumo tienen Linux como la plataforma principal y lo personalizan según sus necesidades. El siguiente enlace sería útil si solo está mirando con los sistemas integrados.

https://hsc.com/Blog/Embedded-Sy

Si su sistema embebido está destinado a realizar una sola tarea o un pequeño conjunto de tareas repetidamente, es probable que utilice un microcontrolador para ello. Digamos, en una industria, usted tiene un robot que tiene que moverse siguiendo una línea y llevar herramientas al trabajador. Como la ruta del robot está pre-mapeada, solo tiene que decirle al robot en qué nodo debe detenerse. Usar un microcontrolador es suficiente en ese caso.
Pero, si está construyendo un robot de seguridad más inteligente, que patrulla un área determinada de una industria y envía una señal cada vez que la cámara detecta una figura humana (que requiere mucha potencia de procesamiento y memoria), no solo necesita un sistema con más poder procesador, desea que el sistema tenga una plataforma de programación más robusta que admita una biblioteca avanzada de terceros para Inteligencia Artificial, Visión por Computadora, Redes, etc. Aquí es donde entra en juego el sistema embebido basado en Linux u otro sistema operativo.

La más importante es que el sistema Linux tendrá mucha más energía y no usará la batería. Esto también puede requerir enfriamiento activo, o al menos una cocina pasiva diseñada con mucho cuidado.

También es más complejo y, como resultado, es mucho más propenso a fallas que una MCU bien programada, ya que Linux es mucho más complejo que el código Bare metal o un RTOS incorporado. También estará mucho menos integrado: necesita RAM y chips flash separados, interfaces periféricas, ADC, DIO, WiFi, BLE, etc., lo que lo hace más caro, más grande y más propenso a fallas. La CPU de Linux probablemente será mucho más potente.

Linux tampoco es un verdadero RTOS (ni siquiera un “Linux en tiempo real”), por lo que implementar tiempos precisos para varios protocolos e interfaces puede ser difícil o un poco inestable. Obviamente, otras interfaces, como Ethernet o TCP / IP o una GUI, son mucho más fáciles de hacer en Linux, ya que ya están allí.

Por último, pero no menos importante, es mucho más fácil programar la caja de Linux: puede ejecutar Python, Ruby, Perl. Las cosas de bajo nivel son un poco difíciles en Linux, aunque ha mejorado mucho en los últimos núcleos.

Entonces, para decidir cuál usar, piense en el costo objetivo, la potencia de procesamiento necesaria, los requisitos de potencia, el tamaño permitido, los periféricos necesarios, si necesita una GUI o una pila de red completa, qué tan crítico es el tiempo y si tiene un desarrollador que puede programar cosas incrustadas profundas.

Creo que se puede hacer una distinción por la disponibilidad de una Unidad de administración de memoria (MMU), ya que es necesaria para la administración de memoria virtual. Si se cumplen otras restricciones, puede portar un linux incrustado en él. (por ejemplo, SoC basados ​​en ARM A8 en Beaglebone de TI)
Algunos controladores solo pueden tener la Unidad de Protección de Memoria (MPU) donde el espacio de memoria virtual podría no crearse pero las aplicaciones de espacio de usuario aún pueden ejecutarse. Un RTOS es más apropiado en este caso. Cuando no tenga ambos, tendrá que manejar con códigos simples de metal desnudo (por ejemplo, microcontroladores de la serie ARM Cortex M en SoC NXP)
[Después de editar la pregunta, también agrego lo siguiente]
La parte anterior fue cuando ya tienes un hardware, pero en la situación en la que debes diseñar el sistema embebido, creo que hay demasiados parámetros involucrados.
Pero hasta donde yo sé, una regla general es evitar un sistema operativo completo tanto como puedas. Si el número de tareas que debe realizar el sistema integrado es determinista y no hay demasiadas entradas involucradas, realmente no necesita un sistema operativo en absoluto.
Incluso si necesita una pila de red o una interfaz USB con su sistema, aún puede usar un RTOS, esto le costará mucho + ahorro de energía + espacio y seguirá haciendo el trabajo.

Cuanto más necesites, más deberías tener. Un sistema embebido basado en Linux, no se dice sistema operativo en tiempo real o no, tiene su propio programador, mientras que la mayoría de los microcontroladores no lo tienen.

El planificador es lo que desea si tiene grandes procesos de uso de CPU. En el sistema basado en microcontrolador, solo tiene interrupciones y estas deben determinarse realmente, quiero decir REALMENTE con cuidado. Pero en los sistemas basados ​​en Linux no es necesario determinar estas interrupciones y problemas de tiempo. ¡Solo dale prioridades de proceso y boom! Pero si desea manejar solo un periférico y las interrupciones del usuario, no necesita tener un sistema operativo enorme como los basados ​​en Linux.

Se trata de compensaciones entre complejidad, consumo de energía y costo. Un sistema Linux implica al menos un núcleo de 32 bits con MMU, 64 MB de RAM y cantidades similares de almacenamiento de persistencia. Esto abarcará múltiples chips y costará más en todos los aspectos: más potencia, más complejidad, mayores COG. Lo que obtienes a cambio es más capacidad, en todo. Si eres un aficionado, piensa en Raspberry Pi o BeagleBone.

Un diseño de microcontrolador es mucho más simple y pequeño. Por lo general, el procesador, RAM, flash, periféricos de todo tipo están integrados en un solo chip. Piensa en el Arduino, pero no en la base Uno. La realidad es que el quid de todo ese proyecto se puede colapsar en un solo chip Atmega328p, con las únicas adiciones en la PCB que son algunos componentes pasivos.

Piense en esto en términos de una pregunta diferente: ¿Cuál es la diferencia entre un elefante y un gato?

El elefante puede llevar mucho peso pero requiere muchos recursos para mantenerse con vida. Un gato es muy rápido y dinámico y requiere muchos menos recursos para mantenerse con vida. Sin embargo, ambos animales son interesantes para lidiar con un determinado entorno. (Descargo de responsabilidad: esta analogía proviene de una charla sobre mRuby IoT con Ruby / mruby – RubyWorld Conference 2015)