AQUABOUN'S /// GESTION D'AQUARIUM RECIFAL

OK !

vous pourriez mettre les objets valeursd0... valeursd17 dans un tableau et éviter le gros switch case en faisanttableauValeursd[ligneNextion-1].setText(donneeLueSurSD);

Pour booster un peu la navigation, il faudrait se souvenir de là où vous vous êtes arrêté dans le fichier ('position') et faire un 'seek' à l'octet d'après la prochaine fois que vous venez (une variable static dans la fonction qui s'en souvient et vous mettez un paramètre bool optionnel à la fonction qui dit si vous voulez commencer au début du log ou là où vous vous êtes arrêté la fois d'avant

void afficher18Lignes(bool commenceAuDebut = true)
{
  static uint32_t teteDeLecture = 0; // 0 début du fichier
  if (commenceAuDebut) {
    teteDeLecture = 0;
  } 

  myFile = SD.open(nomDuFichierTxt, O_READ); // ouvre le fichier 
  if (myFile) {
    myFile.seekSet(teteDeLecture); // seekSet pour la bibliothèque SDFat
  
   ... ici le code pour lire 

   if (on est arrivé en fin de fichier) teteDeLecture = 0; // si on a atteint la fin du fichier lors du parcours
   else teteDeLecture = myFile.curPosition()+1; // sinon l'octet suivant 

   myFile.close(); // ferme le fichier
 }
 ...
}

j'avais pensé au seek le problème c'est que si je me replace a l'endroit X, pour aller en avant, ok, mais pour retour en arrière ? vu que je compte en nombre de ligne et pas en octet vu que chaque ligne a un nombre diffèrent de caractère.

https://www.youtube.com/watch?v=_5F8M0iIcM4

et pour le tableau j'avais déjà tenter avec d'autre mais j'ai coincé surement a cause des declaration : ex :

NexText valeursd17 = NexText(13, 20, "t17");

Salut Il y a plusieurs techniques pour résoudre cela

La première et la plus simple c’est d’optimiser la lecture dans Un sens avec le seek car c’est l’usage principal sans doute et tant pis pour l’autre sens ( si j’étais vous je commencerais par afficher la Fin du LOG puisque c’est sans doute ce qu’on veut voir en premier si on le regarde et optimiser la marche arrière)

La seconde option c’est conserver une liste de positions. Quand vous êtes sur cette page d’affichage du log vous ouvrez le fichier, le lisez et bâtissez un tableau avec N positions en mémoire, par exemple exemple les 10 dernières pages. Si vous restez dans ces pages alors ça va vite sinon vous retombez sur une lecture séquentielle - donc c’est un peu comme le premier cas sauf que vous avez N positions au lieu d’une seule

Une autre option est ce qu’on appelle le pre-fetch. Vous affichez une page et pendant que l’utilisateur lit au lieu d’attendre sans rien faire un click vous allez déjà chercher les autres positions pour aller dans l’autre sens. Comme ça lors du click vous avez déjà fait un bout du boulot. Le challenge sur un arduino c’est que ça peut bloquer la loop d’attente d’évènements assez longtemps

Une autre approche est d’optimiser le fichier pour cela. Comme il y a de l’espace sur la carte SD, mettre que des lignes de X caractères en replissant avec des espaces si besoin. Comme ça on peut faire des maths pour calculer la position.

il y a la possibilité de réserver un bloc en binaire au début du fichier log pour 1000 positions par exemple (4000 octets) plus le premier octet vous dit combien de postions sont Occupées. Vous écrivez en binaire les positions quand vous générez le log. L’inconvénient c’est que le fichier n’est plus tout en ASCII

Une Variante est d’avoir un fichier ami qui contient ces positions. Vous le gênerez au moment de l’écriture du LOG. Ce fichier sera petit et si vous stockez en binaire dedans les positions (4 octets) c’est facile de faire un seek pour trouver quelle est la position De la page P. En gros c’est un fichier d’index.

Si la fonction log est importante C’est cette dernière approche qui sera la plus efficace sans doute.

djbouns: et pour le tableau j'avais déjà tenter avec d'autre mais j'ai coincé surement a cause des declaration : ex :

NexText valeursd17 = NexText(13, 20, "t17");

Oui mais une fois qu’ils sont tous déclarés vous pourriez faire un

 NexText* tableau[] = {&valeursd0, &valeursd1, ...};

ca mange 18 pointeurs de sram mais ça permet d’optimiser plein de code plus tard sans doute.

commencer par la fin du fichier j'ai fait des recherches et j'ai pas trouvé. j'ai essayer d'écrire dans le fichier en faisant "a la ligne" puis revenir a 0 pour écrire mais sa ne fonctionne pas.(de façon a faire descendre se qui était précédemment écrit et d'écrire sur la nouvelle première ligne vierge)

Cette fonction n'est pas essentiel mais peut être pratique. Ce qui me semble le plus simple est de fixer un nombre de caractère par ligne et après faire des math.

J-M-L: Oui mais une fois qu’ils sont tous déclarés vous pourriez faire un

 NexText* tableau[] = {&valeursd0, &valeursd1, ...};

ca mange 18 pointeurs de sram mais ça permet d’optimiser plein de code plus tard sans doute.

Ok je vais tenter ca

j'ai fait

NexText*tableauLigneAffichageSd[] = {&valeursd00,&valeursd01,&valeursd02,&valeursd03,&valeursd04,&valeursd05,&valeursd06,&valeursd07,
&valeursd08,&valeursd09,&valeursd10,&valeursd11,&valeursd12,&valeursd13,&valeursd14,&valeursd15,&valeursd16,&valeursd17};

puis

tableauLigneAffichageSd[ligneNextion-1].setText(donneeLueSurSD);

et j'ai

request for member 'setText' in 'tableauLigneAffichageSd[(((int)ligneNextion) + -1)]', which is of pointer type 'NexText*' (maybe you meant to use '->' ?)

on a mis des pointeurs dans le tableau pas les objets directement, donc il faut mettre

tableauLigneAffichageSd[ligneNextion-1][color=red]->[/color]setText(donneeLueSurSD);

YEs, merci

et pour le ficher sd, comment faire soit pour lire a l'envers soit pour ecrir en haut a chaque ajout ?

et pour le ficher sd, comment faire soit pour lire a l’envers soit pour ecrir en haut a chaque ajout ?

On ne peut pas écrire en haut à chaque ajout, on écrit toujours à la fin.

Tenez voici un bout de code de démo qui prend la technique du fichier d’index pour lire à l’envers.

(.ino attaché en PJ)

Il y a des constantes importantes pour la gestion des Index ou de l’affichage

const uint8_t nombreDeLignesAffichage = 10; // le nombre de ligne dans une page d'affichage
const uint8_t tailleMaxLigne = 80; // le nombre max de caractère dans une ligne de la page

L’idée est un affichage du fichier de log par ‘pages’ donc il faut connaître la taille d’une page. ici je dis qu’une page c’est 10 lignes.
Ensuite j’ai décidé de forcer un buffer de taille fixe par ligne pour l’affichage (pas forcément dans le log) est ici c’est 80.

Au début dans le setup il faut appeler prepareFichiersLog("bla bla bla en tête", booléen).
Si le booléen est vrai, on détruit les fichiers de logs s’ils existaient. (donc attention !)
Si le booléen est faux et que les 2 fichiers existent déjà, on ne fait rien, mais si un des deux fichier n’est pas là alors on détruit celui qui existe (attention donc!) et on prépare un fichier d’index avec juste 0x00000000 dedans puisque que ce sera le début de la première page du fichier de log et enfin on écrit l’en tête du fichier de log avec “bla bla bla en tête”

Une fois cela fait, il y a une fonction logMessage("ce que l'on veut mettre dans le log") qui écrit dans le fichier de log et qui se charge de maintenir le fichier d’index pour vous. c’est ce qu’il faut utiliser dans le programme à chaque log. Attention il ne faut pas de saut de ligne au sein du message (il faut donc avoir bâti dans un cString ce que l’on veut écrire).

Dans ce fichier d’exemple, j’ai rajouté à la fin de prepareFichiersLog() un petit bout de code pour remplir mon fichier de log avec plus de 2000 lignes pour la démo

 // ici on triche et on pré-rempli le fichier, à enlever bien sûr
  char message[100]; // un buffer assez grand pour notre message
  for (int i = 1; i < 2023; i++) { // 24 pages de 10, la dernière n'ayant que 7 lignes (ligne d'en tête dans le fichier de log)
    sprintf(message, "%03d\tles valeurs sont A0=%d et A1=%d\t{%ld}", i, analogRead(A0), analogRead(A1), random(-32000, 32000));
    logMessage(message);
  }
  Serial.println("Fichier de log de démo créé avec 2023 lignes");

cette création prend un peu de temps bien sûr car je voulais un fichier de log assez important.

Voilà. La loop est toute simple, elle attend un caractère sur la console série à 115200 bauds. tapez ‘d’ pour lire la page de début, ‘f’ pour lire la page de fin, ‘+’ ou ‘s’ pour lire la page suivante et ‘-’ ou ‘p’ pour lire la page précédente.

Le fichier de log s’appelle “log.txt” et celui d’index associé est “_log.txt”

je vous laisse essayer (ne prenez pas votre carte SD de votre système, je ne veux pas être responsable de son effacement :slight_smile: )

Vous verrez que c’est assez rapide d’accéder à la dernière page (‘f’) et de remonter (’-’) malgré le fait que l’on ait plus de 2000 lignes dans le fichier

essayez de faire ‘f----++±—’ par exemple et vous verrez que ça speed pas mal :slight_smile:

On pourrait envisager facilement un petit bout de code à exécuter une fois séparément qui lit votre fichier de log existant et construit l’index de façon à ce que vous puissiez intégrer la nouvelle fonctionnalité sans avoir à détruire le log existant.

SD_LogAndScroll.ino (8.86 KB)

bonjour,

je retravaille depuis peu sur le projet. Je reprend donc la partie affichage des erreur. J'ai voulu faire par moi même :stuck_out_tongue:

tout les messages écrit avait la même taille (100 caractères) je me plaçait au dernier caractere du fichier je remontait de 100 pour lire une ligne et l’afficher puis remontait de 100 ect ...

La première page (18 lignes) etait ok mais des que je voulait changer de page rien n'allait alors que j'utilisait toujours le même principe. De plus, avec cette méthode aucune vérification pour savoir si l'emplacement était ok par exemple si l'arduino reboot au milieu d'une écriture tout la lecture est ensuite décalé ...

Je me suis donc mis sur le code joint par JML Le principe est compris mais le code est un peu dur a déchiffrer et donc a l'adapter ...

J'aurais besoin de quelque info pour être sur :

chaque ligne écrit doit être précéder de chiffre ? Pour écrire le message je lance la fonction avec mon char* >>> logMessage(bufferTexte);, j'ai bon ? Le fichier index ne s'enrichi que lorsque ont a atteint le nombre de ligne indiquer ? >>> si oui, je pense que mon problème vient de la puisque J'ecrit ligne par ligne cela veut dire que temps que je n'ai pas écrit assez de ligne elle ne sont pas indexer ?

J'aurais besoin de quelque info pour être sur :

chaque ligne écrit doit être précéder de chiffre ? Pour écrire le message je lance la fonction avec mon char* >>> logMessage(bufferTexte);, j'ai bon ? Le fichier index ne s'enrichi que lorsque ont a atteint le nombre de ligne indiquer ? >>> si oui, je pense que mon problème vient de la puisque J'ecrit ligne par ligne cela veut dire que temps que je n'ai pas écrit assez de ligne elle ne sont pas indexer ?

Je suis sur mon portable donc je ne peux pas voir mon ancien code

De mémoire cependant le fichier de log est non contraint au niveau contenu, l’analyse se fonde sur les saut de ligne: une ligne = un Élément de message

Comme expliqué plus haut il y a une fonction logMessage qui se charge d’écrire dans le fichier log et de maintenir le fichier d’index. Cependant pour que cela fonctionne il faut avoir crée correctement le fichier d’index, donc cf ce qu’il y a dans mon setup()

Le fichier d’index est un fichier binaire qui contient les positions des débuts de lignes du fichier de log: Sur les octets 0 à 3 on a 0x00000000 puisque la première ligne est à l’octet 0. Sur les octets 4 à 7 on a la position du début de deuxième ligne. Sur les octets de 8 à 11 la position du début de la troisième ligne Etc. Donc de manière générale comme Chaque position est codée sur 4 octets si on veut savoir où commence la Nème ligne, il suffit d’aller lire un unsigned long dans le fichier d’index à la position 4*(N-1) (ou 4*N si on considère que la première ligne est la ligne 0)

Est-ce plus clair ?

J'ai verifier et tout est bien dans le setup Le comptenu (donc l'ecriture) du fichier erreur est bon aussi L'index semble egalement bon car plus le temps passe et plus il y a de ligne. Le problème vient donc de la lecture car j'ai des ligne blanche :

'index de la page 0 est 0
PAGE: 0
Ligne 0 
Ligne 1 
Ligne 2 
Ligne 3 
Ligne 4 
Ligne 5 
Ligne 6 
Ligne 7 
Ligne 8 
Ligne 9 
Ligne 10    
Ligne 11    
Ligne 12    
Ligne 13    
Ligne 14    
Ligne 15    
Ligne 16    
Ligne 17    
Demande lecture page 1
L'index de la page 1 est 1203
PAGE: 1
Ligne 0 
Ligne 1 
Ligne 2 
Ligne 3 
Ligne 4 
Ligne 5 
Ligne 6 
Ligne 7 
Ligne 8 
Ligne 9 
Ligne 10    
Ligne 11    
Ligne 12    
Ligne 13    
Ligne 14    
Ligne 15    
Ligne 16    
Ligne 17

Pourtant j'ai bien vérifier et rien n'as été modifié.

Bonsoir,

J'ai passer la journée sur l'affichage. il a fallu adapter beaucoup de chose mais je partait sur de bonne base (merci jml) Le code de base lit de haut en bas (donc du plus ancien au plus récent) un certain nombre de ligne correspondant a une page. En retournant l'ordre de lecture ( le plus récent afficher en haut) je me suis retrouver avec pas mal de problème a contourner. Au final tout cela est régler et la seul trace visible est que lorsque on change de page pour revenir l'écriture se fait de bas en haut ... https://www.youtube.com/watch?v=SFF3snY8Q2U

Bravo !!

J-M-L: Bravo !!

Oula ... merci mais cette félicitation veux dire que le "bug" que je traine depuis un bon moment n'as pas été vu :stuck_out_tongue: regarder bien le début des lignes température :) Encore un problème avec l'écriture d'un char ... mais j'ai trouvé, je faisait un strncpy_P au lieu de strcat

Donc ce qui me reste avant de partager cette nouvelle version :

vérifier la fiabilité du nouveau module de mesure PH (attente du nouveau PCB pour ca) vérifier la fiabilité du nouveau module de mesure ORP (attente du nouveau PCB pour ca) écriture de tout la partie étalonnage du module ORP écriture de toute la gestion, affichage et calibration du module de mesure de la densité check de l'intégralité du code / mise en page / commentaire ...

Mais avant cela je voulait terminer la partie "configuration" et le dernier point qui a poser problème alors que j'ai fait comme pour tout le reste est le choix des PIN, je m'explique : J'ai crée 3 fichier "pin" définissant chacun des PIN diffèrent en fonction des branchement de chacun PinUtilisateur.h PinPCBouns15.h PinPCBouns20.h Dans la configuration.h j'ai fait

//#define PinPCBouns15
//#define PinPCBouns20
//#define PinUtilisateur

ou l'utilisateur doit décommenter la ligne correspondant a sa configuration. puis dans chaque Pin*.h j'ai fait un #ifdef pin** et #endif

Mais lors de la compilation j'ai un mess d'erreur que les pin ne sont pas définis. peut importe qu'elle configuration est choisie

Il y a une exception pour la définition des pin ?

Oula ... merci mais cette félicitation veux dire que le "bug" que je traine depuis un bon moment n'as pas été vu :stuck_out_tongue: regarder bien le début des lignes température :)

un peu petit sur mon smartphone.... j'avais juste vu que ça affichait des trucs ! c'est quoi le souci, la T° à Zéro degré ?

strncpy_P() c'est pour ce qui se trouve en PROGMEM. attention sur une MEGA quand on commence à avoir bcp de texte, on peut se retrouver dans les segments 'far' et ça fiche un peu le bazar...

je n'ai pas bien compris comment vous gérez vos 3 fichiers.

Vous pourriez faire comme cela:

Vous définissez vos 3 fichiers de PINS

``` PinUtilisateur.h ```

#ifndef PinUtilisateur_h
#define PinUtilisateur_h
const byte pinToto = 3;
const byte pinTutu = 5;
#endif

``` PinPCBouns15.h ```

#ifndef PinPCBouns15_h
#define PinPCBouns15_h
const byte pinToto = 7;
const byte pinTutu = 4;
#endif

``` PinPCBouns20.h ```

#ifndef PinPCBouns20_h
#define PinPCBouns20_h
const byte pinToto = 22;
const byte pinTutu = 25;
#endif

et dans ``` configuration.h ``` vous pourriez avoir une inclusion conditionnelle du bon fichier .h

#ifndef configuration_h
#define configuration_h

// CHOISIR LA CONFIGURATION DES PINS SOUHAITÉE EN ENLEVANT LE COMMENTAIRE  
//#define PinUtilisateur
//#define PinPCBouns15
//#define PinPCBouns20


#if defined(PinUtilisateur)
  #include "PinUtilisateur.h"
#elif defined(PinPCBouns15)
  #include "PinPCBouns15.h"
#elif defined(PinPCBouns20)
  #include "PinPCBouns20.h"
#endif

#endif

Le souci avec le mess température était qu'il manquait le début et a la place il y avait un caractere. j'ai effectivement pas mal de texte en PROGMEM ( une centaine) mais il ne font entre 10 et 40 caractères chacun. Je n'ai pas vu de bug a se niveau la (sauf ceux dont j'était responsable lol)

pour ma gestion des PIn*.h

Dans mon configue.h j'avais

#ifndef  _config_h_
#define _config_h_
// Choix de la configuration des PIN de l'arduino
/*choisir le type de configuration des pin correspondant a votre montage */ // ne choisir qu'une configuration
//#define PinUtilisateur
//#define PinPCBouns15
#define PinPCBouns20
#endif

puis dans chaque pin***.h

#ifdef PinPCBouns15

const uint8_t pinInCoupureCourant = A4; // entree presence tension d'alimentation
const uint8_t pinInBatterie = A5; // entree niveau batterie
const uint8_t pinInPhBac = A6; // entree sonde PH BAC
.......
....
#endif

et j'avais un message que xxx PIN n'était pas défini…

J'ai modifier pour concorder a ton dernier message. et j'ai la même chose

'pinOutRelaisElectovanneRac' was not declared in this scope

correspondant a une ligne du setup

  pinMode(pinOutRelaisElectovanneRac, OUTPUT); // Définit la broche comme sortie