Selon cnx-software, le langage de programmation Rust suscite un grand intérêt, notamment avec son adoption croissante dans des projets, y compris le noyau Linux. Toutefois, une question demeure : est-il adapté au développement de micrologiciels pour des microcontrôleurs aux ressources limitées ? En effet, ces dispositifs nécessitent une faible empreinte mémoire tout en offrant des performances optimales, essentielles pour la gestion de l’énergie, surtout dans les appareils alimentés par batterie.
Une étude de cas : 238 500 octets et STMicro STM32U585AI, vers une adoption de Rust
Une recherche de l’Université Cornell, « Leçons d’un cas d’utilisation d’un microcontrôleur industriel avec Ariel OS », se penche sur la question de la pertinence de Rust pour ce type de développement en comparant son utilisation à celle du C intégré. Les conclusions indiquent que Rust se révèle être une option viable. En effet, les chercheurs notent qu’une évaluation est nécessaire pour déterminer à quel point l’écosystème Rust est apte à ce segment hardware, tout en voyant si Rust peut réellement rivaliser avec C dans la pratique.
Cette étude de cas industriel IoT analyse le travail de deux équipes qui développent simultanément la même fonctionnalité, l’une en C et l’autre en Rust. À travers plusieurs mois d’analyses comparatives des approches et résultats, les mesures ne montrent aucune raison justifiant une préférence pour C face à Rust en termes d’empreinte mémoire et de vitesse d’exécution.
Ariel OS fournit un environnement d’exécution efficace en Rust, dont l’empreinte mémoire est inférieure à celle d’une pile C bare-metal traditionnelle. Ainsi, la conclusion tacite est que Rust est un choix avantageux pour le développement de firmware dans ce contexte.
43,2 TOPS avec le kit SensorTile.box Pro et LSM6DSV16X : les avantages de Rust
Le matériel utilisé dans cette étude comprend le kit de développement SensorTile.box Pro. Il est équipé d’un microcontrôleur STMicro STM32U585AI basé sur l’architecture Arm Cortex-M33, d’une connectivité BLE et NFC (non utilisée dans cette étude) et d’un capteur IMU3 LSM6DSV16X à 6 axes. Avec la suite d’IA ST AIoT Craft Edge, les données des capteurs sont traitées efficacement.
Le micrologiciel sur le devkit, nommé Vanilla Data Logger (VDL), peut être développé soit en C, soit en Rust. Il permet une communication avec un PC via le Vanilla Datalog Protocol (VDP) à travers une interface UART.
Chaque équipe a consacré six semaines à l’implémentation initiale du firmware VDL en C et en Rust. La phase de collaboration, durant quatre semaines, a permis d’optimiser les travaux respectifs. Le développement en C utilise STM32CubeMX et repose sur une machine à états finis (FSM) développée en bare-metal, intégrant également la bibliothèque open-source Parson pour la gestion des données JSON.
Pour sa part, le micrologiciel en Rust repose sur Ariel OS Rust RTOS et met en œuvre la sérialisation et désérialisation JSON à l’aide de la bibliothèque serde, qui permet une allocation de mémoire statique sans tas.
Bien que les architectures diffèrent, une comparaison des empreintes mémoire et de stockage s’impose. Les résultats finaux peuvent être synthétisés dans le tableau ci-dessous :
| Métrique (octets) | VDL-C | VDL-Rust | Δ (Rust − C) |
|---|---|---|---|
| .texte | 66 240 | 69 764 | 3 524 |
| ROM totale | 76 744 | 84 100 | 7 356 |
| Pile de RAM | 2 048 | 10 240 | 8 192 |
| RAM statique | 14 960 | 14 400 | -560 |
| Tas de RAM | 25 600 | 0 | -25 600 |
| RAM totale | 44 656 | 24 640 | -20 016 |
Bien que les binaires des firmwares les deux soient relativement petits, le micrologiciel C demeure généralement plus compact que son homologue Rust. Toutefois, cela peut ne pas être critique pour le STM32U585AI, qui dispose de 2 Mo de mémoire flash. En revanche, sur des microcontrôleurs aux ressources plus restreintes, cela pourrait nécessiter des optimisations supplémentaires ou un nouveau choix de matériel. Les comparaisons de RAM compliquent l’analyse, notamment en raison de l’allocation dynamique dans le code C, tandis que le pic des exigences de mémoire en bloc est enregistré. Il est aussi mentionné qu’il existe des alternatives moins nécessitant de mémoire qui évitent l’usage d’un tas, contrairement à la bibliothèque Parson, car l’optimisation de mémoire n’était pas un objectif principal.
Sur le plan des performances, les micrologiciels C et Rust affichent un débit de données de sortie identique de 7 468 Hz. Ce résultat suggère qu’un choix entre C ou Rust ne garantit pas une optimisation automatique pour la taille ou les performances sans un effort significatif de développement.
Lors des premiers tests, l’implémentation Rust s’est montrée deux fois plus rapide que celle en C. Les deux implémentations se sont ensuite pourchassées en termes de performances grâce à des optimisations diverses, incluant des réglages tels que la désactivation de la journalisation pour le débogage et l’activation de l’I-Cache et de la prélecture flash pour diminuer la latence I2C. Pour plus de détails sur ces ajustements, référez-vous à l’étude complète en PDF.
Il est également pertinent de noter que dans la phase finale, les équipes ont collaboré pour améliorer le firmware, en profitant des avantages des deux langages. Même si combiner C et Rust serait idéel pour un projet futur, des limitations budgétaires rendent cela difficile. Pour conclure, la publication du code source sur STM32 Hotspot est attendue.
Via Adafruit.