Diminuer emprunte mémoire d'un sketch

International Français
1

Bonjour,

Je suis en train de développer un programme, en pièce-jointe, un peu lourd en mettant bout à bout différents morceaux de programme que j'ai utilisé/développé jusque là et j'ai quelques problème de gestion de la mémoire. Pour le moment, ça m'arrive avec la fonction FichierSuivant.

Jusque là, j'utilise la librairie MemoryFree (Arduino Playground - AvailableMemory) pour savoir l'espace mémoire qu'il me reste et "otpimiser" mon programme, mais les résultats ne m'aident plus : j'ai soit disant 390 octets de libres, mais je rencontre un bogue que je n'ai pas quand j'en ai 395 de libres.

Voilà le morceau de code que j'utilise pour faire varier l'espace occupé en mémoire (ligne 183) :

  //~ pour débogue : test remplissage mémoire
  char *varmem;
  varmem="abb";
  Serial.println(varmem);
  
  //~ pour débogue
  Serial.println("memoire libre avant fichier suivant : ");
  Serial.println(freeMemory());

J'ai aussi fait des tests pour ce qui prend le plus de mémoire et j'arrive aux impacts mémoire suivants (en octets):

  • fonction FichierSuivant : 125
  • type File : 31
  • type MesurePulse : près de 110
  • librairies, chargement uniquement, aucune délcaration d'instance :
  • SD : 606
  • Time : 0

Du coup, quelques questions :

  • Pour FreeMemory, le résultat est faux, ou je n'utilise pas la fonction au bon moment ? Je ne comprend pas.
  • Pour la librairie SD : ça prend énormément de place !!! On peut pas diminuer ?
  • Ensuite, est-ce qu'il y a des "trucs" évident pour un programmeur chevronné qui sont efficaces pour gagner de l'espace mémoire et qui mériterait d'être fait pour mon programme
  • J'ai lu 2-3 trucs sur PROGMEM, pour gagner 1000 octects (j'utilise un Uno), mais est-ce que ça ne ralenti pas trop le programme d'utiliser cet espace mémoire pour des variables amenées à changer

Tests.ino (13.3 KB)

2

MemoryFree indique la mémoire libre au moment de son invocation donc elle ne voit pas tout il faudrait lancer périodiquement la fonction pour suivre l'évolution de l'utilisation de la mémoire. Qu'est-ce qui te parait faux?

La librairie SD prend de la place en RAM car elle utilise des buffer pour tamponner les accès à la mémoire, maintenir des pointeurs sur des structures de fichiers, ..... L'accès à la mémoire se fait par blocs donc les buffers sont nécessaires.
La librairie SD prend aussi beaucoup de place en flash car cette librairie contient beaucoup de code. Il y a des versions "dégradées" qui sont moins volumineuses mais je n'ai pas trop d'expérience là-dedans.

Pour économiser la mémoire privilégier les variables locales aux variables globales.

PROGMEM n'a d'intérêt que pour des constantes puisque les valeurs sont stockées dans la flash programme. Les accès sont un peu ralenti car au moment de leur utilisation ces variables doivent être ramenées dans l'espace de données. C'est intéressant pour stocker des chaînes de caractères ou des tableaux un peu volumineux pour autant qu'ils ne soient pas utilisés de manière intensive.

Maintenant tout ça c'est peut être aussi le signe que la carte cible n'est pas adaptée au besoin et qu'il faudrait passer à un processeur un peu plus musclé en mémoire.

3

fdufnews:
MemoryFree indique la mémoire libre au moment de son invocation donc elle ne voit pas tout il faudrait lancer périodiquement la fonction pour suivre l'évolution de l'utilisation de la mémoire. Qu'est-ce qui te parait faux?

En fait je dis que le résultat de MemoryFree est faux parce que j'ai justement essayé de faire appel à cette fonction à différents endroits dans la fonction FichierSuivant (cf ci-dessous) pour trouver l'endroit prenant le plus de mémoire.
Une fois trouvé, j'ai eu le bogue évoqué dans mon premier message alors que MemoryFree indiquait qu'il y avait 289 octects de libres. Ça me semble assez important pour que le "if" que je fais suite à MemoryFree puisse passer, mais je me trompe pt-être.

void FichierSuivant (char* Base, char* Extension, char* NomFichier){
/*
fonction trouvant le nom de fichier "suivant" à partir de la base du nom (Base) et 
de l'extension (Extension). Une fois le nom trouvé, le fichier est créé.

Le nom de fichier est de la forme BasexxxExtension où xxx est le premier entier
pour lequel un fichier similaire n'existe pas en partant de 0.

Utilise 125 octets de mémoire

*/
  int j = 0;
  File Fichier;
  char buffer[12+1];
  while (true) {
    char temp[10];
    memset(buffer,'\0',sizeof(buffer));
    strcat(buffer, Base);
    strcat(buffer,itoa(j,temp,10));
    strcat(buffer, Extension);
    if (!SD.exists(buffer)) {
      //le fichier n'existe pas : on garde ce nom
      break;
    }
    j++;
  }
  //création du fichier
  Fichier = SD.open(buffer, FILE_WRITE);
  
//~ pour débogue
Serial.println("memoire libre pendant fichier suivant : ");
Serial.println(freeMemory());

  if (!Fichier){
    //erreur à l'ouverture du fichier
    Serial.print ("Erreur de création du fichier : ");
    Serial.println (buffer);
  }
  else {
    //fihier ouvert correctement
    //écriture du nom de fichier dans la variable NomFichier
    strcpy(NomFichier,buffer);
  }
  Fichier.close();
}

Toujour dans la fonction FichierSuivant, j'ai essayé de diminuer la chaine de caractères de débogue pour voir

//
Serial.println("memoire libre pendant fichier suivant : ");
Serial.println(freeMemory());

ou

Serial.println("memoire pendant : ");
Serial.println(freeMemory());

Et là, surprise (pour moi en tout cas), la mémoire prise par la fonction FichierSuivant reste à 125 octets (cf message précédent) alors que la mémoire libre avant l'appel de la fonction FichierSuivant a, elle, diminué !!! J'en conclus que les chaines de caractères inclus dans mes fonctions ont un impact mémoire global. Ça me surprend, j'ai dû rater une étape, non ?

fdufnews:
La librairie SD prend de la place en RAM car elle utilise des buffer pour tamponner les accès à la mémoire, maintenir des pointeurs sur des structures de fichiers, ..... L'accès à la mémoire se fait par blocs donc les buffers sont nécessaires.
La librairie SD prend aussi beaucoup de place en flash car cette librairie contient beaucoup de code. Il y a des versions "dégradées" qui sont moins volumineuses mais je n'ai pas trop d'expérience là-dedans.

Est-ce que quelqu'un d'autre a un retour d'expérience avec des librairies moins gourmandes ?

4

Pas de réponses à mon message précédent. Personne ne peut m'aider ?