Ejecute el software "de escritorio" en el microcontrolador

Embox participó en el festival TechTrain IT. Como la primera vez, trajimos los pedazos de hierro y mostramos nuestros logros en vivo. Ya escribimos sobre algunos en el Habré, pero nunca se sabe quién :). Se mostraron teléfonos VoIP , Qt y OpenCV , todos basados ​​en STM32F7-Discovery. Además del stand, hicimos tres informes. Ya describí ideas del primero sobre el proyecto abierto en un habr En este artículo quiero contar las ideas de otro de nuestro informe, que se llamó "Lanzamiento de software" de escritorio "en microcontroladores" . Bueno, aprovechando esta oportunidad, te contaré un poco sobre mis sentimientos sobre el festival.

TechTrain

Primero, déjame contarte un poco sobre el festival en sí. Quien no esté interesado puede retroceder inmediatamente a la sección "Iniciar el software" Desktop "en el microcontrolador"

Lo primero que me llamó la atención en el festival fue mucha gente. Estamos cansados ​​de estar en el stand, hablar, realizar una búsqueda y comunicarnos. Por otro lado, fue muy divertido e interesante, y lo más importante, tuvimos muchas emociones positivas, por ejemplo, varias personas nos dijeron que tenemos un buen blog en el centro :). Los participantes del festival provenían de diversos campos de actividad, y ni siquiera eran de TI, porque el eslogan del festival es "un gran festival para desarrolladores, ingenieros y simpatizantes". Había muchos niños, un niño al final del festival sacó una máquina robot del stand y jugó con ella. Ni el niño ni el robot resultaron heridos.

Para hacer más comprensible la amplitud de la audiencia, lo ilustraré de manera diferente. Se realizaron muchas actividades en el festival, una de ellas fue una búsqueda. Los participantes de la búsqueda tuvieron que subir a las gradas, completar las tareas inventadas y obtener una impresión. Para esto, alguien incluso obtuvo un quadrocopter completo. Pero ahora no se trata de eso. También fuimos uno de los lugares donde se podía obtener un sello. Habíamos preparado tareas, incluidas preguntas. Las preguntas eran simples, en relación con el software de código abierto y los sistemas integrados. Pero el contingente era tan diferente que algunos resentían la simplicidad de la pregunta, mientras que otros entraban en un estupor. Lo último que naturalmente ayudamos, le dijimos (o sugerimos a google) sobre cosas como: "quiénes son los creadores del lenguaje C", "lo que es famoso por Linus Torvalds", "cuál es la diferencia entre un microprocesador y un microcontrolador" o "qué es un compilador cruzado". Como resultado, nadie se fue sin imprimir. Por cierto, fue un poco extraño, pero sospechosamente muchos descifraron fácilmente "GNU - GNU no es Unix". Probablemente preparado para Stallman. :)

El segundo se sigue del primero. Hubo entretenimiento para un público muy amplio. Por ejemplo, Habr trajo una caja de arena. Es cierto que no se trataba de una caja de arena local donde se podía obtener una invitación para un artículo, pero era posible revolcarse en la fama. Sobre las invitaciones en la caja de arena, no pensé en preguntar, tal vez dieron como en una caja de arena real. Había un club de computadoras viejas , se podía jugar en ellas, lo que muchos hicieron. Había máquinas tragamonedas del Museo de máquinas tragamonedas soviéticas . Sberbank, ofreció un área de relajación, también era posible jugar en ella ya en la estación de juegos. Hubo sí pateadores tradicionales de TI y muchos otros entretenimientos. Desafortunadamente, tuvimos que trabajar, así que solo estoy hablando de lo que era visible desde nuestro stand.

El tercero y probablemente lo principal fue que los organizadores lograron reunir representantes de prácticamente todas sus áreas, desde el desarrollo web y los sistemas distribuidos hasta los integrados. Desde desarrolladores y otros técnicos, hasta recursos humanos y simplemente interesados ​​en ello, por ejemplo, jugadores (después de todo, era posible hackear al propio Romero ) o entusiastas del bricolaje. Hubo QA de COMAQA hubo líderes de equipo de Burning Lead . Había comunidades de diferentes ciudades (Rostov, Tver, Krasnodar). Como resultado, los informes y los stands fueron muy diferentes en el tema. Por ejemplo, nuestro stand estaba ubicado entre la comunidad de líderes de equipo Burning Lead y el stand del Club de Directores de TI de San Petersburgo .

Como resultado, personas con antecedentes muy diferentes se acercaron a nuestro stand, hubo desarrolladores web y mejillas dotnet, hubo JS y más. Alguien recordó que estaba haciendo algo en el AVR mientras aún estaba en la universidad, alguien decía que se estaba divirtiendo con RaPi o Arduino. Había muchos pollitos DotNet, muchos se preguntaban si teníamos un .NET Micro Framework . Incluso pensamos mucho en no arrastrarlo hacia nosotros. Se esperaba que hubiera muchas preguntas sobre Rust. En resumen, en mi opinión, los organizadores lograron implementar bastante bien la idea del festival "¡Descubre lo que viven los demás!". Después de todo, como en cualquier festival, lo principal aquí es ver a los demás y mostrarse :).

Sí, las fotos no se dan aquí. Se pueden ver algunas fotos , incluso con un niño en vivo, Volodya, en nuestro grupo. Bueno, por supuesto, en el grupo techtrain, un montón de fotos de alta calidad, prometieron publicar más.

Inicie el software de escritorio en un microcontrolador

Mi informe fue una especie de resumen de los resultados de varios de nuestros trabajos en el lanzamiento de software de escritorio ( Qt , OpenCV , pjsip ). El informe está dirigido al público en general. Para un habr, intentaré reducir muchos detalles, y para las cosas necesarias, daré el enlace o las palabras clave para la búsqueda.

Para empezar, daré una especie de agenda. De hecho, habrá 3 partes. En primer lugar, explicaré las dificultades de transferir software de escritorio a microcontroladores, y en el camino explicaré la diferencia entre el microcontrolador y el microprocesador. También responderé una pregunta clave, por ejemplo, cabra bayan , por qué ejecutar software de escritorio en un microcontrolador, y finalmente, le diré cómo pudimos reducir en gran medida el costo de transferir este software de "escritorio" a microcontroladores.

¿Cuál es la diferencia entre microcontroladores y microprocesadores?

Entonces, una de nuestras preguntas sobre la búsqueda sonó y tal vez bajo la influencia de esto apareció un artículo sobre un programador típico que explicaba en qué se diferencian. Estoy de acuerdo con todo en el artículo, pero trataremos de explicarlo con nuestras propias palabras y hacer otros acentos.

¿Qué es una unidad de microcontrolador (MCU)? Si mira Wikipedia , puede comprender que un microcontrolador es un sistema en un chip, es decir, un procesador y periféricos están ubicados en un chip.

El término system-on-a-chip (System-on-a-Chip, SoC) es un concepto más amplio que un microcontrolador. Este es un circuito electrónico integrado en un solo chip, que contiene un microprocesador (CPU) y periféricos. En cualquier teléfono móvil hay un chip en el que, además de varios núcleos de procesador, hay un montón de periféricos. Incluso los procesadores x86 ahora incluyen puentes e incluso gpu. Pero quiero centrarme no en una clasificación clara, sino en las características. Todos saben que los sistemas en un chip:

• Consume menos
• Son mas baratos
• Menos productivo

No todos saben que son aún más confiables al reducir la cantidad de contactos y pueden tener un rango de temperatura mayor.

El microcontrolador tiene una integración aún mayor y también incluye memoria (RAM y ROM), que también se refiere a la periferia. En consecuencia, las propiedades se conservan, consumen menos, cuestan menos, son menos productivas, incluso más confiables.

Quiero hablar sobre "aún menos productivo" con más detalle. El hecho es que, por un lado, es cierto, tome cualquier CPU o SoC moderna de uso general y vea un rendimiento significativamente mayor en el llamado DMIPS . Pero si piensas por qué tal actuación? Como ejemplo, daré los juegos Quake y Doom (el creador de los cuales fue John Romero en el festival), funcionaron muy bien en el Pentium MMX. Pero el rendimiento de los sistemas basados ​​en esta CPU ya está bloqueado por los microcontroladores de gama alta. Me refiero a STM32F7 o incluso STM32H7 . Es decir, en base a estos MCU, es bastante posible ejecutar aplicaciones de nivel Doom y Quake, lo que usted acepta no es malo en absoluto.

Hablemos de otra característica de la MCU: la memoria interna. Ella, como dije, se encuentra directamente en el chip y, en consecuencia, es muy rápida. Pero ella, por supuesto, no es suficiente. ¿Pero qué poco? El microcontrolador STM32F769 contiene 2 mb flash (ROM) y 512 + 16 + 4 kB SRAM (RAM). Además, por ejemplo, la placa STM32F769i-disco también tiene memoria externa (128-Mbit SDRAM y 512-Mbit Quad-SPI Flash memory), que se dirige directamente. Ni siquiera estoy hablando de la capacidad de conectar una tarjeta SD o USB. Bueno, si recuerdas la famosa frase "640 kb debería ser suficiente para todos", entonces surge la pregunta razonable: ¿por qué el software de escritorio moderno es tan glotón? Por ejemplo, una calculadora en Windows 10 en modo inactivo consume hasta 16 MB de memoria.

Pasemos a la siguiente característica de MCU, la presencia de ROM. De hecho, los sistemas con una CPU también contienen una ROM; la ejecución comienza desde ella y el BIOS comienza, pero el resto del software se carga en la RAM y se ejecuta desde allí. En los sistemas embebidos, es costumbre ejecutar código directamente, que se llama eXecute-In-Place (XIP), Linux, por cierto, también es compatible con este modo, pero lo principal es cargar todo en la memoria principal e incluso ejecutarlo. La capacidad de ejecutar directamente desde la ROM es importante por dos razones: la primera es la arquitectura de Harvard, la separación del bus de comando y el bus de datos le permite aumentar la velocidad de ejecución del programa; el segundo, bueno, naturalmente, se desperdicia menos memoria, porque al menos un segmento de código no necesita copiarse en ningún otro lugar.

Otra característica clave de la MCU es la falta de un módulo como MMU , es decir, los microcontroladores no tienen soporte de hardware para la administración de memoria virtual . En MCU, incluso no todos tienen MPU , y el código se ejecuta en el mismo espacio de direcciones, por lo que es difícil organizar una bifurcación completa () . Pero fork () en sí, como escribimos en el artículo "fork () vs. vfork () ”es una llamada de sistema bastante pesada, y de acuerdo con su funcionalidad, en muchos casos, se puede reemplazar con vfork () o posix_spawn ().

En resumen, en qué se diferencian los microcontroladores de los microprocesadores, podemos decir lo siguiente:
En términos de hardware:

• Los microcontroladores tienen todos los periféricos necesarios, incluida la memoria
• Los microcontroladores tienen significativamente menos memoria
• Los microcontroladores no tienen una MMU de hardware
• Los microcontroladores tienen una velocidad de reloj más baja y pueden tener una arquitectura de procesador diferente (arquitectura de regalo)

En términos de propiedades de consumo:

• Los microcontroladores consumen menos energía, pueden funcionar con batería
• Los microcontroladores son más baratos.
• Los microcontroladores son más confiables
• Los microcontroladores son menos productivos.

¿Por qué ejecutar software de escritorio en un microcontrolador?

Por lo tanto, las MCU son menos productivas y originalmente estaban destinadas (y pensadas) para tareas de control. Entonces, ¿por qué ejecutar software diseñado para otra clase de sistemas en ellos? Bueno, incluso si su poder ya es suficiente para tales tareas, pero estas tareas pueden resolverse de la manera tradicional para microcontroladores. Es decir, usar varios RTOS pequeños o escribir código desde cero, lo que se llama metal desnudo. Hay una respuesta obvia, inicialmente las tareas de administración eran muy simples, ahora los requisitos de funcionalidad están creciendo rápidamente. Incluso de una bombilla de mala calidad que esperan control a través de Internet, no estoy hablando de la tetera, probablemente seleccionarán pronto la composición del té de acuerdo con el estado de ánimo del propietario y calentarán la cantidad óptima de agua a la temperatura óptima para mejorar la situación ambiental. :)

Por lo tanto, no es sorprendente que constantemente se hagan intentos para usar el software ya desarrollado en microcontroladores. Por ejemplo, uno de los primeros y ampliamente conocidos intentos de ejecutar Linux en plataformas pequeñas es ucLinux, ahora es el modo NOMMU principalmente Linux. La idea era ejecutar Linux en plataformas de hardware sin una MMU, pero descubrimos que esta es una de las diferencias clave entre la CPU y la MCU.

Brevemente, las ventajas de usar software listo para usar:

• Reduce los costos de desarrollo
• Menor tiempo de comercialización
• Reducción de errores en el código. El software listo para usar es más confiable.

Cómo lo hacemos en Embox

Aquí entiendes, puedes hablar durante mucho tiempo, pero nuevamente intentaré esbozar los puntos principales en una tesis y de una manera accesible.

El primero Embox utiliza el sistema de compilación Mybuild con su propio lenguaje para describir módulos y sistemas, escribimos sobre ello en el artículo "Mybuild: un sistema de compilación para aplicaciones modulares" . Este sistema de compilación le permite no incluir nada superfluo en la imagen, o más bien incluir solo lo que se requiere. Realmente puede ajustar las características del sistema, por ejemplo, para ejecutar PJSIP en STM32F7, limitamos la cantidad de paquetes de Ethernet a 16 simplemente escribiendo una línea en el archivo de configuración del sistema

include embox.net.skbuff(amount_skb=16) 

Mybuild analiza las dependencias y genera varios artefactos, incluidos los archivos de encabezado, los scripts del enlazador y los Makefiles. Todo esto permite reducir significativamente la cantidad de memoria requerida y no incluir aquellas partes que no se utilizan en absoluto.

El segundo Obviamente, Embox debe ser compatible con POSIX y es compatible. Además, hemos implementado nuestra propia biblioteca estándar, porque también debe reconstruirse según la configuración del sistema.

El tercero Enlace estático. Para evitar problemas con un solo espacio de direcciones, reducir el tamaño de la imagen e incluir solo las partes requeridas, utilizamos un enlace estático. En diferentes etapas, se ensamblan diferentes partes del sistema, pero finalmente todo (el núcleo, todos los subsistemas, bibliotecas y aplicaciones) se vincula en una sola imagen. Tiene toda la información sobre todos los personajes de la imagen. Y aunque a primera vista tenemos muchas aplicaciones con puntos de entrada int main (..) estándar, pero en la imagen resultante, estos serán caracteres diferentes que estarán disponibles en el sistema desde la línea de comandos.

Cuarto. Tuvimos que implementar un tiempo de ejecución para C ++, ya que muchas aplicaciones y bibliotecas populares tienen ventajas.

Quinta. Agregamos la capacidad de usar el sistema de compilación

  ./configure; make; make install 

Después de descargar la fuente desde algún lugar y aplicar los parches necesarios.

Conclusión

Hoy en día, los requisitos funcionales para los sistemas que se hicieron previamente en microcontroladores han crecido significativamente. Se espera que los sistemas de control sean compatibles con los sistemas universales. Las características de los microcontroladores también han crecido significativamente, lo que le permite ejecutar software en ellos con la funcionalidad correspondiente. Históricamente, el software para microcontroladores con fines de optimización se escribió para una tarea específica, pero con un aumento en los requisitos funcionales, es necesario aplicar enfoques del mundo de los sistemas universales que pueden aumentar en gran medida la confiabilidad del software, es decir, la reutilización de módulos, el desarrollo distribuido. El software universal, aunque no tiene en cuenta las características de los sistemas integrados, tiene una funcionalidad significativamente mayor y que funciona bien. Por lo tanto, el uso de software de escritorio en microcontroladores da una ganancia. De hecho, por un lado, puede utilizar una plataforma de hardware más barata, más confiable y que consuma menos, y por otro lado, el costo de desarrollar dichos sistemas se reduce significativamente.