Go Down

Topic: AQUABOUN'S /// GESTION D'AQUARIUM RECIFAL (Read 106206 times) previous topic - next topic

J-M-L

#1185
Sep 20, 2020, 10:18 am Last Edit: Sep 20, 2020, 10:19 am by J-M-L
Quote
Oula ... merci mais cette félicitation veux dire que le "bug" que je traine depuis un bon moment n'as pas été vu  :smiley-razz: 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
Code: [Select]
#ifndef PinUtilisateur_h
#define PinUtilisateur_h
const byte pinToto = 3;
const byte pinTutu = 5;
#endif


PinPCBouns15.h
Code: [Select]
#ifndef PinPCBouns15_h
#define PinPCBouns15_h
const byte pinToto = 7;
const byte pinTutu = 4;
#endif


PinPCBouns20.h
Code: [Select]
#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
Code: [Select]
#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


Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

djbouns

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
Code: [Select]
#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
Code: [Select]
#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
Code: [Select]
'pinOutRelaisElectovanneRac' was not declared in this scope

correspondant a une ligne du setup
Code: [Select]
  pinMode(pinOutRelaisElectovanneRac, OUTPUT); // Définit la broche comme sortie






J-M-L

#1187
Sep 20, 2020, 12:06 pm Last Edit: Sep 20, 2020, 12:25 pm by J-M-L
quand et où importiez vous les  pin***.h dans votre approche ?

avec mon approche vous avez bien noté qu'il y a un _h dans le define du ifdef du ficher ? (ce n'est pas le même que le #define PinUtilisateur du fichier de config, sinon ça importera pas)
Code: [Select]
#ifndef PinUtilisateur_h
#define PinUtilisateur_h // ATTENTION CE N'EST PAS LE MEME QUE #define PinUtilisateur



Je mets en PJ un projet avec plusieurs fichiers à fins de démonstration

si dans le fichier de configuration vous mettez
Code: [Select]
// CHOISIR LA CONFIGURATION DES PINS SOUHAITÉE EN ENLEVANT LE COMMENTAIRE  
#define PinUtilisateur
//#define PinPCBouns15
//#define PinPCBouns20

alors quand vous le faites exécuter vous verrez dans la console
pinToto = 3
pinTutu= 5


mais si vous mettez
Code: [Select]
//#define PinUtilisateur
#define PinPCBouns15
//#define PinPCBouns20

alors quand vous le faites exécuter vous verrez dans la console
pinToto = 7
pinTutu= 4



enfin si vous mettez
Code: [Select]
//#define PinUtilisateur
//#define PinPCBouns15
#define PinPCBouns20

alors quand vous le faites exécuter vous verrez dans la console
pinToto = 22
pinTutu= 25




donc ça fonctionne bien
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

djbouns

j'avais bien vu le _h

J'ai eu beau chercher d'où venait le problème, faire des retours en arrière, je n'ai pas trouvé d'où venait le problème alors que tout semblait concorder ...
bref sa fonctionne bien a présent, merci

J'ai constater une anomalie aléatoire entre les échanges ecran > arduino.
Dans la page paramétrage de l'ecran, l'arduino envoie les variables actuels.
On modifie ces variables a partir de l'ecran et lorsque tout est ok, on click sauvegarder.
a se moment la l'arduino demande au nextion la valeur d'un champ, nextion lui envoie et l'arduino le copie dans la variable correspondante et ainsi de suite jusque a avoir récupérer toute les variable de l'ecran.
Lorsque toute les variable modifier a l'ecran on été récupérer elle sont sauvegarder.

de manière aléatoire, il arrive régulièrement que la première valeur récupérer reste identique le temp de 3 ou 4 autre demandes et du coup puis la 5eme va faire de même 3 ou 4 fois ect ...


exemple
a l'ecran on a:
Code: [Select]
A = 1
B = 2
C = 3
D = 4
E = 5
F=  6


sauvegarder dans l'arduino il y auras si "bug"
Code: [Select]
A = 1
B = 1
C = 1
D = 1
E = 5
F=  5
ect ...


Apres avoir un peu chercher,
utiliser le debug,
J'en arrive a la conclusion que l'arduino va trop vite / nextion trop lent
Comme si le nextion renvoyait la valeur précèdent pars qu'il n'avait pas eu le temps de lire car par exemple il suffit que je rajout un ligne debug entre chaque demande/réception pour que le problème disparaisse.
La solution serait donc de mettre un petit délais entre chaque mais je ne veux pas mettre un pansement si cela n'est pas normal.

Qu'en penser vous ?

pour info : Les échange arduino nextion sont en 115200 baud







J-M-L

#1189
Sep 20, 2020, 03:20 pm Last Edit: Sep 20, 2020, 03:27 pm by J-M-L
Quote
J'en arrive a la conclusion que l'arduino va trop vite / nextion trop lent
ils vont à la même vitesse au niveau communication mais il se peut que le logiciel de l'écran créée un liste de tâches à effectuer en fonction des commandes arrivant sur son port série (en faisant le parsing plus tard pour vider le buffer d'entrée) et s'il donne la priorité aux requêtes d'information (qui sont synchrone je crois) plutôt qu'à celles de mises à jour de valeurs alors ça vous donne le comportement que vous voyez....

est-ce qu'il y a moyen d'attendre un accusé de réception d'une commande de mise à jour de l'écran ?
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

djbouns

#1190
Sep 20, 2020, 03:50 pm Last Edit: Sep 20, 2020, 03:54 pm by djbouns
mais connaissance ne me permette pas d'être affirmatif.
Mais meme si c'est le cas, rien du coté de l'aquabouns pour gerer en cas d'erreur ...

J'ai regarder dans la bibliothèque et ci dessous l'extrait de se que je pense utiliser comme fonction lorsque je fait une demande :


Code: [Select]
bool NexNumber::getValue(uint32_t *number)
{
    String cmd = String("get ");
    cmd += getObjName();
    cmd += ".val";
    sendCommand(cmd.c_str());
    return recvRetNumber(number);
}

Code: [Select]
bool recvRetNumber(uint32_t *number, uint32_t timeout)
{
    bool ret = false;
    uint8_t temp[8] = {0};

    if (!number)
    {
        goto __return;
    }
   
    nexSerial.setTimeout(timeout);
    if (sizeof(temp) != nexSerial.readBytes((char *)temp, sizeof(temp)))
    {
        goto __return;
    }

    if (temp[0] == NEX_RET_NUMBER_HEAD
        && temp[5] == 0xFF
        && temp[6] == 0xFF
        && temp[7] == 0xFF
        )
    {
        *number = ((uint32_t)temp[4] << 24) | ((uint32_t)temp[3] << 16) | (temp[2] << 8) | (temp[1]);
        ret = true;
    }

__return:

    if (ret)
    {
        dbSerialPrint("recvRetNumber :");
        dbSerialPrintln(*number);
    }
    else
    {
        dbSerialPrintln("recvRetNumber err");
    }
   
    return ret;
}



J-M-L

ils semble qu'il y ait des soucis à en lire les bugs ouverts... (par exemple ceci)

j'utilise pas nextion car c'est limité au PC et les commentaires de ceux de la communauté Arduino qui ont essayé de travailler avec eux pour améliorer la bibliothèque ont été édifiants...
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

djbouns

 :o

il parle d'une bibliothèque "NeoNextion" qui serait mieux ...
Mais cela voudrait dire tout revoir  :smiley-confuse:  :smiley-roll-sweat:

J-M-L

Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

djbouns

oui.... pour la V5 :)
:smiley-sweat:  :smiley-sweat:  :smiley-sweat:  oui j'aurais du temp a la retraite  :smiley-lol:  :smiley-lol:  :smiley-lol:

pour "solutionner" le bug j'ai ajouter un délais.
Apres diffèrent essaie, a partir de 250ms je n'ai plus le bug.
C'est assez long !!! surtout quand il y a 22 champs a récupérer ...
Mais, visuellement, quand on click enregistrer j'avais une barre de progression qui se remplissait en ~2sec et elle n'était la que visuellement pour que l'utilisateur visualise bien que la sauvegarde était en cours (sans cela on revenais d'un coup a la page précédente et cela pouvait nous faire douter je trouvais)
J'ai donc allonger la progression de cette barre ~5sec comme cela visuellement la barre de progression bouge et en même temps l'arduino fait ces demande/delay.
Pour l'utilisateur, les delays sont donc invisible :)

J-M-L

#1195
Sep 24, 2020, 07:30 pm Last Edit: Sep 24, 2020, 07:30 pm by J-M-L
Quote
J'ai donc allongé la progression de cette barre ~5sec comme cela visuellement la barre de progression bouge et en même temps l'arduino fait ces demandes/delay.
malin :)
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

Go Up