El mundo diverso de los sistemas embebidos y el lugar de Embox en él.

El proyecto Embox ya cumplió 9 años, pero muchos no entienden qué es y con qué se come y por qué es necesario. Algunos de los que han escuchado sobre el proyecto y saben que este es un sistema operativo, creen que Embox es un "sistema operativo doméstico". De hecho, Embox fue concebido como un intento de hacer "su" sistema operativo con "blackjack y barcos", pero lo principal es "blackjack y barcos". Es decir, ciertas características o su combinación, que faltaban en otros proyectos, se pusieron a la vanguardia.

Por supuesto, nadie iba a escribir un sistema operativo universal, incluso con algunos chips. El lema Embox - "Caja de herramientas esencial para el desarrollo integrado" - implica que el proyecto está dirigido a sistemas integrados. Sin embargo, este concepto es muy amplio e incluye: Internet de las cosas (IoT) y robots, varias frambuesas (RaPi) y sistemas a bordo, arduinki y ASU-TP, ... La lista, como saben, puede continuar durante mucho tiempo, hay lugares donde Linux vive muy bien, y hay lugares donde Linux es redundante y se usan varios RTOS pequeños. En este artículo, me gustaría hablar sobre el mundo incrustado en toda su diversidad, y también sobre el lugar de Embox en él.

Computadoras de placa única

Computadoras industriales

Comencemos con las computadoras de una sola placa. Muchos de ellos están hechos en diseño industrial. La mayoría se basa en procesadores con arquitecturas ARM y x86. Mucha gente piensa que los procesadores x86 no se utilizan en este segmento, y todo se limita a frambuesas , beagleboards , plátanos , etc. Pero mucho antes de RaPi, había otras máquinas de placa única destinadas al segmento de PC industrial, el llamado factor de forma PC / 104 . Eran inferiores en rendimiento a los escritorios convencionales, porque estaban destinados a tareas en las que la fiabilidad prevalece sobre la funcionalidad. Por la misma razón, Linux no se usaba a menudo como sistema operativo para estas plataformas de hardware; había varios sistemas operativos propietarios con propiedades en tiempo real ( VxWorks , QNX , LynxOS, etc. ). No escribí "RTOS" (en el que incluyo estos tres sistemas operativos) por las razones que con frecuencia Windows CE y su desarrollo de Windows Embedded se ubicaron en estas plataformas de hardware. Y no me vuelvo loco para atribuir todo este zoológico al RTOS.

Pagadores individuales del consumidor

Malinki estableció una tendencia completamente diferente. De hecho, no están dirigidos a sistemas industriales en tiempo real, sino al segmento de consumidores, en el que se valora la relación precio / funcionalidad, y las frambuesas (y análogos) están significativamente por delante de sus competidores en este parámetro. Después de todo, cuando compra por $ 30-50 condicionales, obtiene una unidad de sistema completa, con la que puede hacer fácilmente un dispositivo con una funcionalidad bastante complicada utilizando herramientas de Linux. Esto es muy útil para la creación de prototipos o bricolaje. Además, por supuesto, la frambuesa se puede usar como una PC o un servidor pequeño. Por lo tanto, las distribuciones Linux listas para usar a menudo se usan como sistema operativo, en primer lugar, por supuesto, Raspbian - Debian para Raspberry Pi, o una distribución con un nombre divertido para los hablantes de ruso Pidora - Fedora para RaspberryPi. Para otras plataformas similares, también hay distribuciones preparadas proporcionadas por los fabricantes de equipos y las comunidades de SO (fabricantes). De acuerdo, cuando necesite hacer un prototipo, la forma más fácil es tomar paquetes listos para usar, instruir paquetes, escribir funcionalidad en python. Como resultado, obtenga rápidamente un prototipo que funcione. Un ejemplo es un robot que reconoce una línea usando OpenCV .

Linux en dispositivos integrados

Pero el mundo integrado es mucho más amplio que las tarjetas ARM estándar de una sola placa. Además, constituyen una parte relativamente pequeña de los dispositivos, y su principal contribución es la popularización y simplificación de la entrada en el desarrollo de dispositivos de esta clase. Los dispositivos en serie se crean sobre la base de los mismos procesadores (sistemas en un chip) o similares, pero las placas están diseñadas para la tarea (proyecto, dispositivo). En consecuencia, las distribuciones estándar son al menos redundantes, ya que a menudo utilizan algún tipo de administrador de paquetes, y puede entregar fácilmente muchas cosas interesantes (pero innecesarias para resolver una tarea específica). Los dispositivos integrados generalmente vienen con una funcionalidad completa, e incluso se llama firmware. Hay otra clase de distribuciones de Linux para crear firmware. Dichas distribuciones le permiten "instalar" los paquetes necesarios de forma estática, ensamblándolos en el sistema de archivos raíz, y no dinámicamente, utilizando el administrador de paquetes del repositorio. Típicamente, estas distribuciones pueden construirse no solo aplicaciones de aplicaciones y bibliotecas, sino también el núcleo en una configuración dada. Y a menudo también es un compilador cruzado, porque compilar en el dispositivo en sí no es efectivo.

Proyecto Yocto

Hasta la fecha, el proyecto Yocto es la distribución más famosa (un proyecto para crear distribuciones). A su vez, se basa en otro conocido proyecto OpenEmbedded , que es un tipo de sistema de compilación para distribuciones de Linux. Si desea utilizar la Raspberry Pi no como un sistema pequeño listo para usar, sino como un dispositivo personalizado con Linux, entonces Yocto o sus análogos serán una gran opción. Personalmente, no veo grandes ventajas en el uso de distribuciones de Linux no estándar con piezas de hierro estándar, pero si planea desarrollar dispositivos similares o desea aprender las tecnologías, entonces este enfoque parece el más prometedor. Después de todo, mientras se desarrolla una pieza de hardware especializada, los programadores pueden desarrollar y depurar sus partes del sistema (algoritmos, controladores, bibliotecas, ...). Lo que reduce en gran medida el tiempo de desarrollo y, por lo tanto, el notorio TTM (tiempo de comercialización).

Openwrt

Otro famoso proyecto de firmware basado en Linux es OpenWRT . Estoy seguro de que aquellos que se divierten personalizando enrutadores han oído hablar de él. Basado en este proyecto, el firmware está hecho para varios enrutadores, que son un binario, incluidos el núcleo y el sistema de archivos raíz. El uso de firmware (en lugar de distribuciones universales) en sistemas integrados está conectado con la idea de que la funcionalidad del sistema final se conoce en el momento de su desarrollo, es decir, incluso si se actualiza la versión del enrutador, el firmware cambia completamente con toda la funcionalidad (o parte de este firmware se reemplaza de una manera especial ) Instalar, por ejemplo, suites de oficina, generalmente no es necesario, y a menudo generalmente está prohibido, ya que esto puede introducir su propia incertidumbre. Este enfoque permite, entre otras cosas, ahorrar significativamente en hardware. Los mismos enrutadores, por ejemplo, tienen un procesador mucho menos potente y mucha menos memoria que las glándulas universales.

Sistemas en tiempo real

Volviendo al tema de las calculadoras industriales, es necesario discutir el término "sistema en tiempo real". Mucha gente piensa que los sistemas en tiempo real son más rápidos. Esto es una falacia. Probablemente, está conectado con premisas históricas. Después de todo, el término en sí surgió cuando los automóviles eran lentos. Y el usuario notó que la reacción del sistema puede retrasarse con respecto a sus acciones. El término "tiempo real" significaba que el sistema tenía que responder a cualquier influencia, incluidas las acciones del operador. Pero en las computadoras modernas, es poco probable que el usuario (operador) note la inhibición. En la gran mayoría de los casos, cuando hace clic en el menú, icono, botón, veremos inmediatamente un redibujo de la pantalla, a menos que, por supuesto, todo esté en orden (Internet está allí, el proceso no se bloquea, etc.). Pero si sucedió algo inesperado, por ejemplo, se pierde la conexión, veremos cómo los sistemas en tiempo real difieren (deberían diferir). Simplemente reiniciaremos el teléfono inteligente normal. Pero si este sistema controla la planta de energía, entonces usted mismo comprende que esto no siempre es posible. De esto concluimos que el sistema en tiempo real debería responder de manera predecible y no rápida a cualquier evento o conjunto de eventos, independientemente de su estado y entorno.

Linux en sistemas en tiempo real

Naturalmente, ha habido (hay y habrá) intentos de hacer un sistema en tiempo real de Linux. El más famoso es RTLinux , originalmente era un parche para Linux, reemplazando el " programador completamente honesto " original, más precisamente, insertando el suyo, una de las tareas establecidas por el programador Linux. Este planificador trabajó en prioridades de tareas estáticas; en consecuencia, funcionó de manera mucho más predecible. Pero ya no era Linux, o más bien, la funcionalidad de Linux no estaba en tiempo real.

ARINC-653

Otro enfoque para proporcionar en tiempo real, algo similar al parche RT para Linux, es el enfoque requerido por el estándar ARINC653 o el llamado enfoque MILS . Este enfoque implica que el sistema está diseñado en capas, la capa inferior implica un hipervisor muy ligero, basado en qué tareas de diversos grados de criticidad se realizan en secciones estáticamente definidas. Llamé al hipervisor muy ligero porque implica que tiene la mayor criticidad y, por lo tanto, su código (algoritmos) debe verificarse lo más completamente posible (idealmente, la ausencia de situaciones no procesadas debe demostrarse matemáticamente). Por lo tanto, el código debe ser lo más pequeño posible. Bueno, y Linux, como probablemente entendiste, se encuentra en su propia sección.

uCLinux

Los intentos de usar Linux en sistemas embebidos comenzaron hace mucho tiempo. Uno de los primeros fue un intento de usar Linux en sistemas donde no hay soporte de hardware para memoria virtual (MMU). Este proyecto se llamó uCLinux y su contribución al kernel de Linux fue el modo NOMMU o MMU-less.

Linux en sistemas en tiempo real

Para resumir los intentos de usar Linux en sistemas en tiempo real, debe responder a la pregunta de por qué sucede esto. Es decir, por un lado, Linux no está particularmente adaptado (en este momento, y en su forma pura) para sistemas en tiempo real, y por otro lado, constantemente se hacen intentos para hacerlo. Y esto sucede debido a la introducción de restricciones (reemplazo del planificador, introducción de un hipervisor, restricciones en el uso de la memoria virtual, etc.). La respuesta, en mi opinión, radica en la presencia de Linux, una base de código gigantesco. Estos son controladores, estas son aplicaciones funcionales y bibliotecas. Obviamente, si desea crear un sistema confiable, debe usar las partes preparadas tanto como sea posible, porque el desarrollo de nuevas, ya sea lógica funcional o un controlador, siempre contiene la probabilidad de introducir un error. Y dado que los sistemas modernos en tiempo real tienen requisitos funcionales bastante altos, la reutilización de funcionalidades listas para usar de Linux se está volviendo cada vez más tentadora. En otras palabras, actualizar Linux a un sistema en tiempo real no parece tan costoso en comparación con el desarrollo de la funcionalidad, aunque basado en un sistema operativo en tiempo real, porque la confiabilidad de todo el sistema, y ​​no solo su parte en la forma del núcleo del sistema operativo, debe ser confiable.

Windows en dispositivos integrados

Quiero volver a Windows por un tiempo. Al comienzo de mi carrera, tuve una discusión con un desarrollador más experimentado acerca de que Windows no se puede usar en sistemas confiables. A lo que se opuso, si prueba un sistema ya completado con el software funcional necesario y prohíbe cualquier cambio: actualizaciones, instalación de software, etc., el sistema será lo suficientemente confiable para muchas tareas, incluida la que nosotros decidido Ahora no tengo dudas de que mi oponente tenía razón, no yo. Además, incluso el antiguo MS-DOS se ha utilizado en sistemas industriales durante mucho tiempo. El hecho es que la multitarea, que parece tan necesaria, introduce incertidumbre. Y si ejecuta un software que controla completamente todo el sistema, puede lograr un comportamiento mucho más determinista. En otras palabras, si un número indefinido de tareas gira en el sistema, entonces es poco probable que sea posible lograr certeza en el trabajo de todas las funciones del sistema. Por lo tanto, la forma más fácil de aumentar la previsibilidad del sistema es limitar su funcionalidad y, por lo tanto, el rechazo de la universalidad en tiempo de ejecución. Lo cual, de hecho, observamos en los ejemplos de uso de Linux en los sistemas de tiempo real mencionados anteriormente.

Microcontroladores

El ejemplo de MS-DOS como sistema operativo base para sistemas industriales en tiempo real nos lleva a la idea de que si usa solo su propio software, puede lograr un comportamiento predecible de todo el sistema. ¡Y realmente lo es! Es cierto que debe hacer una reserva de que esto es posible solo si la funcionalidad del sistema es pequeña y está claramente fijada. Si toda la funcionalidad del sistema consiste en controlar el motor usando el GPIO y recibir (transmitir) un conjunto limitado de comandos a través de la interfaz UART, entonces no es necesario usar el sistema operativo, puede crear firmware (lo que se llama metal). Este enfoque se usa a menudo en microcontroladores. Pero como los microcontroladores se hicieron grandes (ARM de 32 bits con varios KB de RAM versus AVR-ok de 8 bits con cien bytes de RAM), las solicitudes de funcionalidad aumentaron. Ahora, cuando desarrollan firmware, usan al menos software de fabricantes, lo que le permite usar algunos ejemplos listos para trabajar con un microcontrolador, por ejemplo, STM32Cube .

RTOSes

Pero dado que los requisitos de funcionalidad están en constante crecimiento, el firmware para microcontroladores se está haciendo cada vez más sobre la base del llamado RTOS. A diferencia de los grandes sistemas operativos en tiempo real, estos son proyectos de código abierto relativamente pequeños que proporcionan acceso completo a todo el código del sistema. Es decir, hay una combinación de conceptos: por un lado, se usa código listo para usar, y por otro lado, el desarrollador tiene acceso completo a todo en el sistema, puede decir firmware sin formato.

Hay bastantes RTOS para microcontroladores. Por lo tanto, es imposible hablar de todos ellos. En mi opinión, destacaré solo algunos proyectos interesantes y hablaré brevemente sobre sus características.

FreeRTOS

Probablemente uno de los proyectos RTOS más populares ahora es FreeRTOS . Algunos dicen que este no es un sistema operativo completo, sino solo un programador. Pero si tiene en cuenta la discusión anterior sobre el metal desnudo, la gran cantidad de microcontroladores compatibles y el hecho de que una gran cantidad de software de aplicación está escrito e integrado, entonces la pequeña funcionalidad parece más una virtud que una desventaja. Esto nos permitió convertirnos en un estándar de facto para microcontroladores, tal como está escrito en el sitio web del proyecto.

Contiki

Contiki : RTOS desarrollado por Adam Dunkels , creador de pilas TCP / IP tan conocidas como lwIP y uIP. Diría que todo el sistema operativo está construido alrededor de la pila de red. La presencia de soporte de IPv6 y los requisitos de recursos pequeños hacen que este proyecto sea interesante para crear varios tipos de dispositivos inalámbricos.

RTEMS

RTEMS Ejecutivo en tiempo real para sistemas multiprocesador. Originalmente desarrollado para el ejército, el acrónimo significa Ejecutivo en tiempo real para sistemas de misiles, y luego Ejecutivo en tiempo real para sistemas militares. Proyecto de código abierto bastante antiguo pero todavía animado. Brillante representante del enfoque libOS. Cuando el software desarrollado está vinculado con un sistema operativo ya ensamblado, que no es solo el núcleo, sino también todos los servicios disponibles. Se compila y se entrega como una biblioteca al compilador, lo cual es bastante conveniente en las primeras etapas de desarrollo.

eCos

Sistema operativo configurable integrado eCos . También es un proyecto bastante antiguo, anteriormente muy popular. La idea principal es crear un sistema operativo muy configurable, es decir, incluir en el núcleo solo lo que necesita.

Otras RTOSes

La lista continúa por bastante tiempo. Mencionaré otro proyecto de NuttX a continuación. Y para aquellos que estén interesados ​​en una lista más detallada, les aconsejo que vean Wikipedia . Para los microcontroladores, también mencionaría ChibiOS / RT , MicroC / OS (µC / OS) , Nut / OS , RIOT . Pero, por supuesto, todo depende de la tarea.

Arduino

Creo que hablar sobre embebido estaría incompleto sin mencionar a Arduino. Después de todo, como RaPi, son muy comunes y contribuyeron en gran medida a la popularización de los microcontroladores. Yo mismo soy bastante escéptico sobre el tema arduino, por lo que omitiré las críticas de los fanáticos de esta tecnología. Pero sobre el hecho de que esta es una tecnología muy interesante, puedo dar un ejemplo de una máquina de pan, descrita en un centro Muy buena solución. Bueno, o el ejemplo ya citado con un robot que reconoce una línea por openCV , pero arduino también se usa allí.

Microkernel

Nunca he mencionado el concepto de un microkernel que, como mucha gente sabe, hace que el sistema sea confiable y predecible. Por un lado, esto es cierto, pero por el otro, como siempre, no del todo. Más precisamente, por supuesto que es cierto, pero la creencia de que este concepto (arquitectura) convertirá inmediatamente su sistema en un sistema duro en tiempo real es una ilusión. Es más bien un eslogan de marketing: "somos un sistema en tiempo real porque estamos basados ​​en el principio de un micronúcleo". Pero el principio de un microkernel simplemente hace posible simplificar el desarrollo de software, ya que la mayoría de las partes se llevan a cabo en el espacio del usuario. Pero, ¿qué pasa si tiene un servidor roto, que es necesario para el trabajo? Lo reinicias, pero lleva tiempo, ¿y si no lo tienes? Además, la arquitectura clásica de microkernel tiene sus inconvenientes. Por ejemplo, es lento porque hay muchas llamadas al sistema (transferencias de mensajes entre servidores y software de aplicación). De lo contrario, todos habrían cambiado a una arquitectura de microkernel puro hace mucho tiempo, y quienes, por ejemplo, vieron proyectos en L4 , pero lo están. Bueno, y por supuesto, muchos recuerdan la discusión de Linus Torvalds con Andrew Tanenbaum .

Es decir, el concepto de micronúcleo no es una bala de plata. Pero como una muy buena idea, se aplica en un grado u otro en la mayoría de los sistemas operativos modernos. Y la creación de un sistema confiable al final todavía depende del desarrollador final y de las capacidades que el sistema operativo proporciona para su construcción.

El lugar de Embox en el mundo de los sistemas embebidos

Ya hablé bastante sobre varios aspectos del mundo incrustado, pero nunca llegué al lugar de Embox en él. Bueno, puedo decir que en los ejemplos descritos anteriormente, puede que no sea necesario usar Embox. Además, generalmente preguntamos a los usuarios por qué necesitan Embox? Si el uso de Embox no ofrece ninguna ventaja, recomendamos probar algo de la lista anterior u otra cosa (por ejemplo, Android). Pero hay varios casos en los que el uso de Embox proporciona una ganancia tangible.

Sistema de desarrollo de equipos

Comenzaré con el primer uso de Embox. Entonces ni siquiera era un Embox, sino que era una especie de código C y ensamblador, que le permitía comenzar muy rápidamente y ejecutar código utilitario. En ese momento, era un proyecto para ayudar a los ingenieros a depurar equipos desarrollados en FPGA.Sabía cómo correr muy rápido, mucho más rápido que un código similar escrito usando los RTEMS ya mencionados. Esto es importante porque también se usó en la etapa de simulación de lapso de tiempo. Además, comenzaron a usarlo en un hardware real, para esto se escribió un pequeño intérprete que podía llamar a los comandos del usuario. Más tarde, se desarrolló esta dirección, y el intérprete del lenguaje TCL fue portado, ya que es familiar para los desarrolladores de FPGA. Y dado que en una determinada configuración los equipos tienen acceso directo al equipo (a todo el espacio de direcciones), los desarrolladores pudieron realizar pruebas bastante complejas.

Certificado por Linux

. , , : (UDP), , . Linux. x86 ARM. . , , . Linux, 500 . , #ifdef . , , . Embox , . Mybuild, , . , ( ) , .

Linux Linux

. Linux, - . Embox Linux. , Qt (embedded-) SIP- . , Embox , .

POSIX- — NuttX . - Embox, - — . Qt SIP-, , NuttX . .

, RTOS POSIX. , FreeRTOS RTEMS, POSIX Profile 52, « , , » . RTEMS Qt

Linux

RTOS, , , , . , Linux , - ( , , .). , , , , , . . , , - , , , , . , , , . , .

Linux

Linux . , . , OpenCV . , , OpenCV RaPi, Arduino. : — , — , , Linux . , Embox Linux. OpenCV , .

, Linux . — , -, . , .

Internet of Things

Embox, RTOS , . stm32vl-discovery. Embox 16- MSP-430 c 512 . , , , , POSIX-, (light threads). , , , . “” IoT. . - . Embox, , , , . -, , , , . -, , .

CodeFreeze .

Conclusión

embedded . , , , -. , “” embedded. , , , - ! .

PS , Embox “embedded”, “ opensource ”. , !