[RESOLU] Formatage fichier XML

bienvenue dans le monde du C.

Effectivement, changer une ligne en C, consiste à réécrire tout le fichier, avec la ligne modifiée, ou, sans cette ligne si on veut la supprimer.

Sur le serveur, il n'y aura aucun problème à identifier les données, puisqu'elles restent dans le même ordre pour chaque ligne. Ca sous entend évidement, que si une valeur d'une ligne devait être omise, il doit quand même apparaître une valeur vide dans le CSV, soit 2 virgules qui se suivent. Si non, il y aura un décalage lors de la lecture.

Etant donné la nature des données stockées dans ton CSV, le XML ne t'apporterait rien à par des cheveux blancs en créant les fonction sur l'Arduino.
Faire un petit script sur le serveur (coté PC) qui te le passe en XML te posera nettement moins de soucis.

Bonjour,

+1 pour l'avis général, le format CSV est bien mieux.

Surtout que même côté serveur le format CSV est plus simple à gérer que du XML.
Pour parser du CSV il faut faire un découpage de chaine de caractère ligne par ligne, c'est 3x rien à coder.
Pour parser du XML il faut prendre en compte l'architecture du fichier, l'encodage, ...

Pour ce qui est du renvoi des données "offline" c'est pas compliqué, comme elles sont toute dans un ordre chronologique il te suffit d'envoyer toutes les données du fichiers en une seule fois.
Le problème c'est que tu ne peut pas enlever une ligne bien précise dans un fichier sans tout lire / réécrire.
Donc si l'envoi du fichier complet échoue tu auras des problèmes pour gérer la situation.

Le mieux serait de faire un dossier avec un fichier par trame à émettre, numéro dans un ordre croissant, une sorte de file d'attente d'envoi avec des fichiers.
Tu envois fichier par fichier dans l'ordre, si ça marche tu supprime le fichier, si ça plante tu laisse le fichier en place pour la prochaine fois.

du coup, s'il fait un fichier par ligne... et qu'il supprime les fichiers qui ont étés envoyés, il n'y a plus de problème :o

Je vais partir dans ce sens yapluka comme on dit :slight_smile:
par contre qu'elle est la limite du nombre de fichier sur la carte SD ?

en fat 16:
65 524 fichier sur la partition, et apparement 512 fichier à la racine (en ne dépassant pas le nomage en 8.3) par contre, je ne sais pas de ce qu'il en est dans un autre dossier...

Je ne sais pas s'il est possible de lire la fat32 (qui est bien moins limitative) avec la librairie sd

D'après la page de la bilbiothèque SD, elle gère le FAT32 :slight_smile:

C'est bien 512 fichiers ou répertoires pour le répertoire racine car la FAT pour le répertoire racine est de taille fixe
Cette limite saute pour les sous répertoires qui peuvent être étendus dynamiquement sur plusieurs clusters

... en théorie

Car effectivement il faudrait vérifier que l'implémentation Arduino permette de gérer le cas général.
A la place de l'auteur, je ne me serais pas embarrassé d'une implémentation complète pour un micro 8 bit.

j'essaie déjà de former le nom du fichier me permettant de créer le fichier sur la carte SD.
voila une partie du code mais cela ne créé pas le fichier avec le nom espéré ... lol
la nuit porte conseil comme ondit

nbrefichier = nbrefichier + 1;
    nomfichier = nbrefichier + ".txt";
    char charBuf[nomfichier.length()+1];
    nomfichier.toCharArray(charBuf, nomfichier.length()+1);
    
    Serial.println(nomfichier);
    //---- crée fichier en écriture --- 
    file = SD.open(charBuf, FILE_WRITE); // ouvre le fichier en écriture

pourquoi ne pas coder le nom du fichier en C plutot qu'en C++ ?

Euh j'ai fait ca moi ? :astonished:

Ca veut dire "Pourquoi utiliser la classe String plutot que rester avec des char[] ?"

La classe String est attirante parce qu'elle propose un certain nombre de fonctions utiles mais :

  • les fonctions ne sont pas exhaustives et c'est compliqué si tu veux l'étendre
  • le classe string est basé sur de la gestion de mémoire dynamique ce qui peut rapidement devenir problématique sur un micro avec peu de mémoire

De plus il semble que le compilo fournit avec Arduino (WinAVR 2009) comporte pas mal de bug concernant la gestion de mémoire dynamique.

Donc il est préférable de se passer autant que possible de la classe String.

char charBuf[13]; // 8+'.'+3+'\0' = 13
nbrefichier = nbrefichier + 1;
sprintf("%08d.txt", charBuff, nbrefichier );
Serial.println(charBuff);
//---- crée fichier en écriture --- 
file = SD.open(charBuf, FILE_WRITE); // ouvre le fichier en écriture

attention barbudor, sprintf ne s'utilise pas comme ça.
c'est sprintf(charDest, "ma tambouille avec le formatage %d %s", les, variables)

sprintf(charBuff, "%08d.txt", nbrefichier );

exact, j'ai inversé les 2 premiers paramètres
veuillez pardonner cette erreur due à mon grand age XD

Merci à tous
voici le code qui fonctionne en fonction de ce que vous m'avez dit

Je vais taguer le poste comme résolu ! :slight_smile:

// Mise en forme du nom du fichier .txt  
char datafile[13];
int jour=day();
int mois = month();
int heure= hour();
int minut= minute();

sprintf(datafile,"%02d%02d%02d%02d.txt",mois,jour,heure,minut);  //  %d pour un int 
 
     //----- initialisation de la carte SD ----- 
    Serial.println( (__FlashStringHelper *)PSTR("Initialisation de la SD card..."));

    SD.begin(brocheSDCardSelect); // initialisation de la carte SD avec broche 4 en tant que CS - renvoie true/false
    
   
    
    Serial.println(datafile);
    //---- crée fichier en écriture --- 
    file = SD.open(datafile, FILE_WRITE); // ouvre le fichier en écriture

Question juste comme ça, pourquoi :

Serial.println( (__FlashStringHelper *)PSTR("Initialisation de la SD card..."));

Et non tout simplement :

Serial.println(F("Initialisation de la SD card..."));

Je crois que je suis le fautif :drooling_face:
Je connaissais PSTR et _FlashStringHelper mais pas F() que j'ai trouvé récemment
J'ai donc orienté PITP2 la dessus....

La question est est ce que cela fait que l'on gagne un peu d'espace mémoire supplémentaire ?

barbudor:
Je crois que je suis le fautif :drooling_face:
Je connaissais PSTR et _FlashStringHelper mais pas F() que j'ai trouvé récemment
J'ai donc orienté PITP2 la dessus....

F() c'est juste le cast tout fait :

#define F(string_literal) (reinterpret_cast<__FlashStringHelper *>(PSTR(string_literal)))

PITP2:
La question est est ce que cela fait que l'on gagne un peu d'espace mémoire supplémentaire ?

Non mais ça fait des caractères en moins à écrire et ça fait plus propre :grin: