MemoryUsage

[Thierry]

Un problème récurrent, en tout cas dans mes sketchs, est la gestion de la mémoire. Chaque octet coûte cher, et les Arduino sont chiches en SRAM... Alors une nouvelle bibliothèque a été poussée sur Framasoft pour permettre d'afficher localement la taille de la mémoire disponible, et la taille maxi de la pile.

[DDEFF]

Salut Thierry,
Sketch d'autant plus utile que cette info est sujette à caution :

1°) Dans un UNO, avec ses pauvres 2ko, on en voit vite le bout.
Et quand on s'approche du remplissage, le fonctionnement n'est plus tout à fait garanti. J'en ai déjà fait l'expérience.

2°) A l'autre bout de la chaîne, sur un DUE, avec ses 64 ko+32ko, on est tellement au large que l'IDE ne donne plus aucune indication...
Je vais tester.

[savignyexpress]

Bonjour à tous,

Un des moyens d'économiser la mémoire est de passer à la programmation directe du microcontrôleur AVR qui équipe l'Arduino. Les impacts sur le développement sont les suivants:

• Utilisation d'un 2ème Arduino comme programmeur série du 1er Arduino.
• Suppression du bootloader en mémoire flash.
• Utilisation du compilateur C AVR Gcc et de la librairie libc.
• Remplacement des fonctions spécifiques Arduino telles que digitalWrite par le accès équivalents aux ports du microcontrôleur. C'est à peine plus compliqué, mais le reste de la logique du programme ne change pas.

Outre le gain en place mémoire, le remplacement des instructions digitalWrite par les accès aux ports occasionnera un gain de temps: l'accès direct étant environ 10 fois plus rapide que digitalWrite.

À titre d'exemple, j'ai réalisé un système pour gérer les itinéraires sur le réseau N d'un ami à l'aide d'un Atmega 8 dont la mémoire flash fait 8 KB. Le programme tient en 5 KB tout en comportant 3 tâches pseudo-parallèles, l'utilisation du convertisseur analogique-numérique pour la lecture des boutons poussoir. Un sketch Arduino aurait certainement été plus gros. Pour plus de détails, voir mon blog: https://savignyexpress.wordpress.com/.

Meilleures salutations.

[Thierry]

Une version V2 vient d'être poussée.
Elle simplifie la compréhension du problème en fournissant plus d'infos et en rationalisant les comportements. Une seconde méthode de mesure dite 'Paint' a été ajoutée, ainsi que le moyen d'afficher toutes les données chiffrées de la SRAM.
Le fichier MemoryUsage.h en particulier a été grandement documenté pour mieux s'y retrouver.

[Thierry]

Outre le gain en place mémoire, le remplacement des instructions digitalWrite par les accès aux ports occasionnera un gain de temps: l'accès direct étant environ 10 fois plus rapide que digitalWrite.

Le gain attendu ici est sur la SRAM qui n'est pas beaucoup impactée - voire pas du tout - par le bootloader...
Pour l'accès direct aux ports, que je trouve particulièrement imbuvable, j'utilise une variante personnelle d'un source que j'ai récupéré de CodeProject : Arduino2. Il me permet de bénéficier des avantages (la vitesse) sans les inconvénients (la relecture de code...). Il est disponible dans ma librairie UAD, mais je devrais peut être en faire une vraie bibliothèque.

[savignyexpress]

Bonjour à tous,

Un autre moyen permettant d'économiser la SRAM est de placer les tableaux de constantes en mémoire programme. Dans nos applications ferroviaires, il est courant de définir des tableaux reprenant des éléments du réseau et cette technique s'applique tout particulièrement.

J'ai pratiqué cette technique en C direct, mais c'est aussi documenté pour l'environnement Arduino: https://www.arduino.cc/en/Reference/PROGMEM.

Bonne journée et meilleures salutations.

Marc-Henri