Zephyr RTOS

[Gustavo F. Paredes Delaloye - LU2JGP]

Interesante RTOS promovido por la Linux Foundation.

https://events.linuxfoundation.org/zephyr-developer-summit/

Saludos.

Gustavo

--

"Per Aspera ad Astra"
Gustavo F. Paredes Delaloye

--

My LinkedIn

[Pablo A. Llanos]

Interesante? Zephyr RTOS es el equivalente del lightsaber Jedi para los desarrolladores de firmware! Es la solución a los dolores de cabeza de la dependencia entre el firmware y el hardware!

Cualquier desarrollador de firmware sabe que independientemente de que siga todas las buenas prácticas que existen, desarrollar en capas sobre una HAL, encapsulamiento, etc, si tiene que cambiar de hardware tendrá que cambiar el firmware. Hoy existen herramientas muy interesantes para facilitar la creación de una HAL, mapeo de pines y seteo de periféricos, la mayoría de los fabricantes de MCU proveen estas herramientas y, si bien podemos abstraer gran parte del código del hardware, aún hay una dependencia muy fuerte entre firmware y hardware. Zephyr RTOS cambió eso al utilizar el mismo concepto que en Linux: el Device Tree Model.

Un programador no necesita compilar una aplicación para la PC de Jorgito, otra para la PC de Marcos y otra para la Notebook de Paola, hay un sistema operativo que se encarga de ser el "intermediario" entre el hardware y la aplicación. En el mundo de los embebidos no teníamos esa ventaja, necesitabamos crear una aplicación para cada microcontrolador, o incluso si utilizamos el mismo MCU en dos placas diferentes pero con pines mapeados distintos, requerirá que compilemos un binario para cada placa!

Hoy existen cientos de empresas que aún utilizan microcontroladores del paleolítico para no tener que migrar su código que les llevó años perfeccionar y prefieren continuar usando (o hasta hacer "atrocidades ingenieriles") para no tener que comenzar desde cero con un nuevo MCU. Zephyr es la solución a eso, gracias al DTS podemos utilizar la misma aplicación sin tener que cambiar una sóla línea de código aún si, por ejemplo, cambiamos de un micro de ST a otro de NXP. Sólo tendríamos que cambiar el dts. Si tenemos dos placas similares con el mismo procesador, podemos crear un DTSI para lo que es común a ambas placas y un DTS para lo que es diferente en cada placa pero no necesitaremos tocar ni una sóla línea del código de la aplicación.

Otras ventajas de Zephyr RTOS:

- Utiliza una arquitectura común con Linux, los subsistemas, los mecanismos de sincronización, kernel y user space, device drivers, etc. Para un programador de Linux será súmamente fácil comenzar a programar con Zephyr y para los que aún no incursionaron con los RTOS, después de aprender Zephyr tendrán muchos conceptos que les permitirán entender más fácilmente como funciona Linux (Kernel).

- Soporta todas las arquitecturas más usadas y miles de placas de desarrollo, placas de aprendizaje (como Arduino), ESP32, etc. Además, es más fácil portar una nueva placa si no está soportada.

- Está basado en una licencia Apache y no GPL, lo que permite desarrollar aplicaciones comerciales sin costos de licencias y sin cláusula de copyleft (obligación de distribuir el código fuente de las modificaciones).

- Es modular.

- Soporte nativo de TCP, IPv4, IPv6, UDP, DNS, ICMP, Bluetooth 5, LoRa, MQTT, CANBus, USB, etc, lo que implica NO más dependencia de librerías externas o de implementaciones propias de cada fabricante.

- Altísima calidad de código y soporte a largo plazo.

- Hay mucho material de aprendizaje disponible (en inglés), ejemplos y tutoriales

Merece que lo prueben, y la mejor prueba que pueden hacer es, por ejemplo, desarrollar una aplicación para Arduino Nano y luego probar la misma aplicación en un STM32 Blue Pill o un ESP32, verán que la misma aplicación puede correr en las tres plataformas sólo instanciando el DTS correspondiente.

Éxitos!

PD: @Gustavo F. Paredes Delaloye excelente share!

Pablo Llanos Clariá

Embedded Linux Expert

UNITED CODERS

+7 981 954-65-99

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAFOkcww7sFQc5%2BQzhjwTLxMKzJ2HZiAadMvdqR%3DdvMYpPNprqQ%40mail.gmail.com.

[Luciano Vittori]

Pablo, muy interesante tu apreciación sobre este OS. Me surge preguntar cómo se compara con FreeRTOS para microcontroladores.
Saludos

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAFvB5gP7%2BYecRSLRhkoSw%3DdA_o4cTU-X%2B7iYAQqh-gwmqmV1SQ%40mail.gmail.com.

[Pablo A. Llanos]

FreeRTOS se ha convertido en el sistema operativo real-time standard de facto para microcontroladores. Tiene un footprint bajo y los Middleware ayudan a abstraer la aplicación del hardware. Es muy robusto, maduro, casi todos los fabricantes proveen ports de FreeRTOS para una buena parte de los MCUs que comercializan.

A FreeRTOS le falta esa independencia del hardware, hoy dependen de los ports que hacen los fabricantes y, a pesar que puedes abstraerte bastante del MCU, la aplicación siempre será dependiente de la plataforma que estés utilizando. Es decir, si cambias de MCU (dentro del mismo fabricante) deberás hacer cambios en el código de la aplicación. Si cambias de familia o si optas por un MCU de otro fabricante, lo más probable es que sólo puedas utilizar una porción de tu código, la que utiliza los Middleware o librerías externas pero el resto tendrá que ser descartado y reescrito para la nueva plataforma.

Zephyr RTOS no sólo tiene el DTS para abstraerte del MCU, también tiene un modelo basado en drivers/subsistemas como lo tiene Linux y eso te permite reutilizar el 100% del código.

Un ejemplo, supongamos que necesitas utilizar un RTC externo, en FreeRTOS o en tu código "bare metal" tendrás que generar el código para comunicarte con el RTC externo vía SPI, I2C o el puerto que utilice. Si te tomas el trabajo de generar una HAL para usar el SPI o el I2C del MCU, aún así tu código dependerá del RTC que estés usando (por ejemplo un DS3231). En tu código vas a colocar las direcciones de los registros del DS3231, timmings, callbacks, todo estará relacionado al DS3231. Si cambias el DS3231 por otro RTC, deberás cambiar tu aplicación porque no te va a coincidir todo tu código con otro RTC. Ahora, qué sucedería si el sistema operativo tiene un subsistema para los RTC, cada RTC tiene su driver y tu aplicación simplemente utiliza la API del OS? En ese caso aún si cambias de RTC, sólo activas el driver del RTC que necesites, como tu aplicación utiliza la API del OS no deberías modificar ni una línea de tu aplicación. Así es como funciona Linux, Windows, iOS, etc y es precisamente como Zephyr RTOS funciona!

Conclusión: FreeRTOS es genial pero en mi opinión Zephyr RTOS lo ha superado ampliamente.

Seguramente alguien se estará preguntando porqué no todo el mundo automáticamente lanzó a FreeRTOS por la ventana (o a cualquier otro OS real-time) y comenzó a utilizar Zephyr RTOS? Porque la modularidad, los subsistemas, device tree, etc. lo hacen un sistema complejo, es el mismo problema Windows-Linux, porqué no todos utilizan Linux si es más estable, gratuito, libre, utiliza menos recursos y no convierte tu PC en una cafetera con monitor? Porque es más difícil de utilizar.

Ahora si no le tienes miedo al desafío, se puede convertir en la mejor herramienta para tí y para tu empresa.

Éxitos!

Pablo Llanos Clariá

Embedded Linux Expert

UNITED CODERS

+7 981 954-65-99

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CACURg-gqjSATrZVtdOpkP9FR1h%2BsDDnjzU7-W7nE-T-9WVyisQ%40mail.gmail.com.