Embassy vs FreeRTOS: una batalla de RTOS en Rust y C
Embedded Rust RTOS vs. C RTOS

En este artículo, Tweede Golf compara Embassy (async Rust) con FreeRTOS (C) en un STM32F446, ejecutando la misma aplicación con tres tareas: parpadeo de LED, lectura de botón y comunicación por cola de mensajes. Miden latencia de interrupción, tamaño de programa, uso de RAM y facilidad de programación. Los resultados muestran que Embassy tiene menor uso de RAM y código más compacto, mientras que FreeRTOS destaca en latencia de interrupción. El artículo también explica los fundamentos de async/await y RTOS, y proporciona código de ejemplo para ambos.
En el mundo web, async/await ya ha ganado a los hilos, así que probablemente también sea el caso aquí.
- Animats
Eso es bajo una carga de CPU muy ligera. Así que un enfoque asíncrono, sin preferencia, puede funcionar. Si hay algún cómputo significativo en curso, no funcionará tan bien.
Un número útil para medir en un osciloscopio es la latencia de interrupción en el peor caso. Esto es lo que importa si hay una restricción de tiempo real estricta. Midieron la desviación estándar, pero no el peor caso. La configuración de prueba habitual es que una señal de entrada (típicamente una onda cuadrada) va a un pin de entrada, ocurre una interrupción si las interrupciones no están bloqueadas, la tarea comienza, y la tarea activa un pin de salida. Observas el retardo de entrada a salida en un osciloscopio y buscas valores atípicos.
Si ejecutas todo de principio a fin, los valores atípicos están determinados por la tarea de cómputo más larga. Esto es un problema si hay una tarea de cómputo.
Históricamente, aquí es donde QNX brilla. La interrupción se procesa y programa un hilo. Casi todo lo que ocurre a nivel de interrupción es la activación del hilo. El hilo activa el pin de salida. Puedes buscar en un osciloscopio valores atípicos de programación. La latencia en el mejor caso es mayor que hacer el trabajo a nivel de interrupción, pero la latencia en el peor caso es constante, incluso si los hilos de menor prioridad están limitados por cómputo.
Esta es la diferencia entre programación en tiempo real y "casi tiempo real".
- CupricTea
El título debería cambiarse. Async Rust != RTOS. Los RTOS son de múltiples hilos con preferencia, mientras que async se hace cooperativamente con puntos de rendición.
Quizás "Async Rust embebido vs. RTOS en C"
- joshchngs
Este artículo tiene casi 5 años, lo que lo hace bastante antiguo en términos de Rust embebido. Creo que el panorama general no ha cambiado mucho, pero sería cauteloso a la hora de confiar en cualquier detalle del mismo.