¿En qué casos se necesitaría usar Linux incorporado o un kernel en un microcontrolador?

Ya escribí software bare metal y usé FreeRTOS en dispositivos integrados. Pero me gustaría entender por qué algunas personas eligen usar Linux integrado o un kernel en un dispositivo integrado. ¿En qué casos sería, por ejemplo, inevitable que necesite usar Linux integrado o un kernel en un dispositivo integrado? ¿Cómo llegaría uno a la conclusión de que necesita una de esas dos cosas?

Por ejemplo, cuando tiene que implementar una funcionalidad compleja que ya está implementada en Linux...
Porque a veces las personas no tienen ganas de reescribir el soporte avanzado del sistema de archivos, una pila TCP/IP completa, la pila USB, varios controladores de hardware, mutexes, subprocesos, gestión de procesos, un shell potente, un montón de bibliotecas que pueden hacer cualquier cosa, etc. .. Sí, la gente es perezosa, ¿no? Sin embargo, tenga en cuenta que nunca es inevitable usar eso. Es mucho más eficiente en una serie de situaciones.
También multiprocesamiento.
@dim, su descripción simplista no habla de (a) las desventajas de poner esa montaña de software que enumeró en un microcontrolador integrado o (b) cómo lo encajaría en un dispositivo con flash y RAM pequeños, ¿podría? equilibrar tu comentario? De lo contrario, es solo una lista de deseos.
@tonym por supuesto que hay desventajas. Mucho (requisito de hardware enorme, no controlas cómo se hacen las cosas, no es realmente adecuado para tiempo real, tiempo de arranque más lento, ...) Pero la pregunta era: "¿por qué querrías usar Linux en un entorno integrado?" , como si no tuviera sentido hacerlo. Así que no abordé la parte de "por qué no", ya que OP parecía tener razones de ese lado.
@dim, vi el bit 'sin sentido' en la publicación de OP, pero las dos respuestas publicadas hasta ahora responden bien, así que parece que lo leyeron como yo. ¿Has puesto Linux en pequeñas MCU integradas entonces, lo haces parecer fácil para los principiantes?
@TonyM De hecho, ambas respuestas se centran en MCU pequeños , pero integrado no significa necesariamente pequeño. LPC32xx, por ejemplo, se anuncia como una MCU y puede admitir un Linux completo. Un paquete de soporte de placa Linux está disponible en NXP, que admite la mayoría de los periféricos, si no todos. Pero tampoco dije que fuera fácil para los novatos, incluso si ciertamente es más fácil que volver a desarrollar todo, si necesita un equivalente . Sin embargo, realmente no llego a donde quieres llevarme. Y en cuanto a mi legitimidad para afirmar tales cosas, no la tengo. Solo estoy fingiendo estar bien informado, aquí.

Respuestas (2)

En general, no usaría un sistema operativo en algo que realiza tareas de microcontrolador reales. En tales casos, el sistema operativo interfiere más de lo que ayuda. Los sistemas operativos consisten en virtualizar recursos de hardware y proporcionar abstracciones como hilos y procesos. Estas cosas son de poca utilidad cuando el hardware que está manejando es fácil de controlar directamente, no hay problemas de portabilidad y, de todos modos, no es el tipo de cosas que los sistemas operativos virtualizan para usted. Los sistemas operativos de propósito general tampoco manejan bien los requisitos de tiempo real, o en absoluto, y eso es algo que suele ser importante en las aplicaciones de controlador verdadero.

La razón por la que a veces ves sistemas operativos en microcontroladores de gama alta es porque esos procesadores en realidad se usan como computadoras integradas, no como controladores. Cuando desee conectarse a un teclado estándar, un mouse, manejar una pantalla estándar, conectarse a una red, ser un host USB, almacenar archivos en una estructura de árbol arbitraria o hacer cualquier otra cosa con la que los sistemas operativos están destinados a ayudar, entonces un sistema operativo puede ser útil.

Quienquiera que votó negativamente esto, sería interesante saber a qué se opone.

¿Linux en microcontroladores? Solo usando versiones sin MMU (Memory Management Unit) - ej. uC Linux. Cortex-M (M - microcontrolador) tiene MPU (Unidad de protección de memoria). Cortex-A (A - aplicación) tiene MMU. Por lo general, los microprocesadores no incorporaban periféricos ordinarios que se encuentran en los microcontroladores comunes. Aunque es muy rápido, ejecuta tanto el sistema operativo como las aplicaciones del usuario. No manejan muy bien los pines de E/S y los protocolos que demandan baja latencia , pero son ideales para manejar imágenes, audio y transferencia de megabytes de datos en alto rendimiento .(USB, Ethernet, etc.). Una Raspberry-PI es buena para ver una película, pero no es adecuada para implementar el control FOC de un motor trifásico, por ejemplo. Por razones similares a las ya comentadas, no es raro encontrar soluciones que involucren una placa con dos procesadores: un Cortex-A ejecutando Linux y un Cortex-M encargado de tareas críticas (ejemplo placa UDOO). El BeagleBone es ligeramente diferente cuando se incluye en el mismo chip, control dedicado y periféricos de temporización.

Sus ejemplos están lo suficientemente separados como para ser claramente distintos, pero el mundo actual es un poco más borroso. Considere que puede encontrar enchufes inteligentes hechos al estilo de un microcontrolador con un ESP8266 y otros a precios competitivos basados ​​en SoC de enrutador wifi basados ​​en Linux económicos. Efectivamente, existe un conjunto de aplicaciones que es una superposición entre lo que puede construir un sistema "simple" para manejar, y lo que puede quitar uno "complejo" para que encaje.