đť•‚onekoMar 7
En programmation #Rust , je me suis rendu compte d’un point intĂ©ressant.
L’utilisation de fonctions async a la fâcheuse tendance à faire exploser la demande en mémoire RAM et Flash. C’est d’autant plus vrai lorsqu’une fonction asynchrone en appelle une autre, qui en appelle une troisième, et ainsi de suite. Ça pause un vrai problème dans le contexte contraint du développement de firmware. A priori, la meilleure solution est de se limiter en nombre de .await. J’ai vu ailleurs qu’on conseille également de Boxer les Futures, mais je n’ai pas trop compris pourquoi.
Show threadđť•‚oneko

En tout état de cause, ça rend la programmation embarquée asynchrone en Rust bien moins intéressante que je l’espérais.

Autre point à noter : les fonctions asynchrones n’apparaissent pas dans le mapping des symboles du binaire final. Il ne reste que les implémentation anonymes de Future::poll() dont la taille démesurée correspond au code d’une énorme machine d’état.

Mar 7 at 1:17pmWeb
Show threadđť•‚onekoMar 7

Je me suis amusé à rendre une représentation graphique de l’évolution de la taille de mon firmware.

Deux observations :

  • Les paramètres de compilation ont un rĂ´le prĂ©pondĂ©rant dans la maĂ®trise du poids. C’est la première chose Ă  faire.
  • L’introduction de la communication I²C entre la partie gauche et droite du clavier constitue la plus grosse pĂ©nalitĂ©.