¿Por qué un desarrollador bare-metal se mudó a sistemas operativos

Mirando hacia atrás en la 'Edad del Bare-Metal'

La primera vez que supe sobre el software integrado fue en 2008, estaba en el segundo año y comencé a aprender sobre programación en un chip 51. Desde que me especialicé en informática, la mayoría de mis programas se ejecutaron en PC. Fue una experiencia completamente diferente ver programas ejecutándose en una placa de metal desnudo, y todavía puedo recordar la emoción cuando mi primer programa de lámpara de ciclismo se ejecutó con éxito. Sin embargo, mientras más programas bare-metal escribía, más problemas encontré. Los resumo de la siguiente manera:

Simultaneidad

Para los programas bare-metal, inevitablemente hay un gran bucle "while (1)", que contiene casi toda la lógica de transacción de todo el proyecto. Cada transacción invoca una o más funciones de retardo y se ejecutan en serie cuando la CPU está ejecutando una función de retardo, el resto de las transacciones tienen que esperar. De esta manera, gran parte del tiempo de la CPU se pierde en bucles vacíos, lo que provoca una simultaneidad bastante baja.

Modularidad

Desde la perspectiva del proyecto de software, el principio de alta cohesión y bajo acoplamiento siempre se enfatiza durante el proceso de desarrollo. Sin embargo, los módulos en un software bare-metal generalmente dependen entre sí en gran medida, no es conveniente diseñar software con bajo acoplamiento, lo que dificulta el desarrollo de grandes proyectos en placas bare-metal. Por ejemplo:

• Como se mencionó anteriormente, la mayoría de las funciones se recopilan en un bucle enorme "while (1)" y son difíciles de dividir en módulos.
• Como otro ejemplo, los desarrolladores deben tener cuidado al usar las funciones de retardo cuando el temporizador de vigilancia está involucrado. Si el tiempo de retardo es demasiado largo, la función principal no tiene la oportunidad de restablecer el perro guardián, entonces el perro guardián se activará durante la ejecución. Entonces, para el desarrollo bare-metal, hay demasiadas cosas a considerar incluso cuando se invoca una función de retardo. Cuanto más complejo sea el proyecto, más cuidado se debe tener.

Ecosistema

Muchos componentes de software avanzados deben depender de la implementación del sistema operativo de nivel inferior. Por ejemplo:

• He desarrollado un proyecto de código abierto basado en 'FreeModbus' que había planeado trasplantar a varias plataformas, incluso se consideraron las placas de metal puro. Pero en comparación con la conveniencia de adaptarlo a diferentes sistemas operativos, algunas funciones son demasiado complejas para implementarlas en todas las placas completas. Por otro lado, muchas implementaciones deben diseñarse desde cero en diferentes plataformas de hardware debido a la falta de elementos comunes, que es una tarea aburrida y que requiere mucho tiempo. Por ahora, mi implementación de la pila Modbus todavía no se puede ejecutar en placas completas.
• Muchos kits de desarrollo de software (SDK) WiFi proporcionados por grandes empresas como Realteck, TI y MediaTek solo se pueden ejecutar en el sistema operativo. No publican el código fuente del firmware para que el usuario lo modifique, por lo que no puede usarlos dentro del entorno bare-metal.

En tiempo real

La capacidad en tiempo real es necesaria para algunos campos de aplicación. En esta situación, algunos pasos críticos del software deben activarse en un momento específico. Para el control de la industria, los dispositivos mecánicos deben completar acciones en un orden y tiempo predeterminados. Si no se puede garantizar la capacidad en tiempo real, se producirán fallos de funcionamiento que pueden poner en peligro la vida de los trabajadores. En plataformas completas, cuando todas las funciones están agrupadas en un gran bucle "while (1)", es imposible mantener las capacidades en tiempo real.

Reutilización

La reutilización depende directamente de la modularidad. Creo que a nadie le gustaría hacer el mismo trabajo una y otra vez, especialmente al escribir código. Pero en varias plataformas de hardware con diferentes chips, la misma función debe adaptarse a diferentes hardware, cuyas implementaciones dependen en gran medida del hardware de bajo nivel. Es inevitable reconstruir las ruedas.

La ventaja de los sistemas operativos

Fue alrededor de 2010 cuando utilicé por primera vez el sistema operativo. La serie de MCU STM32 comenzaba a ser popular. Con características poderosas, muchas personas ejecutaron sistemas operativos en ellas. Entonces estaba usando el sistema operativo RT-Thread para el cual hay muchos componentes disponibles listos para usar. En comparación con otros sistemas operativos, me siento más cómodo y lo he estado desarrollando durante 10 años.

Según mi comprensión, me gustaría hablar sobre las ventajas de los sistemas operativos:

Modularidad

Con el sistema operativo, todo el software podría dividirse en varias tareas (conocidas como subprocesos), cada subproceso tiene su propio espacio de ejecución independiente. Son independientes entre sí, lo que mejora la modularidad.

Simultaneidad

Cuando un subproceso invoca la función de retardo, cederá automáticamente la CPU a otros subprocesos que lo necesiten, lo que mejora la utilización de toda la CPU y, en última instancia, la concurrencia.

En tiempo real

Un RTOS está diseñado con capacidades en tiempo real. A cada hilo se le asigna una prioridad específica. Los subprocesos más importantes se establecen en una prioridad más alta, los subprocesos menos importantes se establecen en los inferiores. De esta forma, se garantiza el rendimiento en tiempo real de todo el software.

Eficiencia de desarrollo

El sistema operativo proporciona una capa unificada de interfaces abstractas, lo que facilita la acumulación de componentes reutilizables y mejora la eficiencia del desarrollo.

El sistema operativo es producto de la sabiduría de un grupo de expertos en software. Muchas funciones de software comunes, como semáforo, notificación de eventos, buzón de correo, búfer de anillo, lista de cadena unidireccional / lista bidireccional, etc., están encapsuladas y resumidas para que estas funciones estén listas para su uso.

Los sistemas operativos como Linux y RT-Thread implementan un conjunto estándar de interfaces de hardware para hardware fragmentado, conocido como marco de controlador de dispositivo. Por lo tanto, los ingenieros de software solo necesitan enfocarse en el desarrollo y ya no necesitan preocuparse por el hardware subyacente o reconstruir las ruedas.

Ecosistema de software

La riqueza del ecosistema lleva el proceso de cambios cuantitativos a los cualitativos.

La mejora de la modularidad y la reutilización con los sistemas operativos nos permite encapsular componentes reutilizables integrados y amigables basados ​​en el sistema operativo, que no solo se pueden usar en nuestros proyectos, sino que también se pueden compartir con más desarrolladores integrados que lo necesiten, maximizando el valor de la software.

Soy un geek de código abierto y he creado software integrado en GitHub. Antes de crear software de código abierto, rara vez hablaba con otras personas sobre mis proyectos porque consideraba que debido a que la gente usa diferentes chips o plataformas de hardware, mi código difícilmente podría ejecutarse en su hardware. Con los sistemas operativos, la reutilización del software se mejora enormemente, muchos expertos pueden comunicarse entre sí sobre el mismo proyecto. Incluso son de diferentes países. Esto está animando a más y más personas a compartir y hablar sobre sus proyectos.