TinyGo - compilateur Go compact basé sur LLVM
(github.com/tinygo-org)- Utilisable sur des microcontrôleurs, avec WebAssembly (WASM/WASI) et pour des outils CLI
- Prend en charge la plupart des packages de la bibliothèque standard et peut compiler du code Go sans modification
- Utilise LLVM en interne pour produire un code compact et efficace
- Excellent support de CGo
4 commentaires
Quand j’ai essayé d’utiliser TinyGo sur des cartes Arduino Nano 33 (basées sur nrf52 ou Nano 33 IoT), les fonctions de base marchaient plutôt bien (à part le problème de l’appairage BLE...).
Je pense moi aussi que c’est difficile à utiliser en production, mais malgré tout les channels Go fonctionnaient mieux que je ne l’imaginais, donc c’était assez sympa pour bricoler un peu pour le plaisir.
Pour le firmware aujourd’hui, Zephyr RTOS (C/C++) me semble plutôt pas mal : il est soutenu par la Linux Foundation, utilisé sérieusement comme RTOS principal chez Nordic Semiconductor, et ses points forts sont la prise en charge de nombreux protocoles ainsi que son tooling.
Dans le cas de Rust, j’ai entendu dire qu’il faut souvent passer par
no_std, donc que ce n’est pas simple, mais comme je ne l’ai jamais réellement utilisé en pratique, ça m’intrigue aussi hahaLa prise en charge des MCU est un peu limitée, et le support des gammes STM, NXP ou TI, qui sont pourtant très largement utilisées, laisse un peu à désirer.
Pour l’Esp32, le Wi‑Fi et le Bluetooth ne fonctionnent pas, et cela semble encore un peu insuffisant pour parler d’un produit prêt pour la production.
Personnellement, parmi ce type de projets d’application des langages modernes aux MCU, c’est surtout
rust in embeddedqui m’enthousiasme le plus.Bonjour, le point que vous avez mentionné en passant m’a semblé intéressant, donc je me permets de vous poser une question.
Par le passé, j’ai étudié et écrit du firmware en C (stm, ti), mais comme cela ne me convenait pas, j’ai abandonné. Aujourd’hui, longtemps après, j’aimerais me replonger dans ce domaine de manière un peu plus moderne.
En firmware, est-ce que Rust est malgré tout plus proche de la tendance actuelle ?
On peut dire que, dans les firmwares, l’adoption de Rust n’est clairement pas encore production ready~~~. Mais la couverture des appareils pris en charge s’élargit très rapidement.
Une nouvelle intéressante est qu’il semble qu’il y ait récemment eu une réunion qui ressemblait à un travail préparatoire pour inscrire Rust dans la norme AutoSAR..
Dans le domaine du firmware, à cause d’environnements d’exécution particuliers, lorsqu’un bug lié à la mémoire non managée survient, les conséquences peuvent être critiques..
Du côté des MCU pour firmware,
software emulation in embedded,
perfect unit testing without boards
sont des thèmes souvent présentés dans les séminaires..
Comme sujet avancé, on peut peut-être citer onnx in mcu ??