Discussion :

[Caxton]

Je crois que je commence à comprendre.

J'avais pour mauvaise habitude de travailler avec du Char et du String... C'est pas propre j'en convient totalement.

Super exemple, ça prends forme

Voilà ce que j'ai fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define RX_PIN 5
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;
 
RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600); //Liaison série pour le Débug
  driver.init();  //Initialisation de RH_ASK
}
 
void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer
 
  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {
    //Nous imprimons les 8 adresses
      for(uint8_t i = 0; i < 8; i++) {
      Serial.print(F("data.addr["));
      Serial.print(i);
      Serial.print(F("] = 0x"));
      Serial.println(data.addr[i], HEX);
    }
 
    //Nous imprimons le message contextuel
    Serial.print(F("Message: "));
    Serial.println((char*) data.dataRecv);
 
    //Fabriquer l'adresse
    char tblAddrASCII[40]; //Tableau "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx" -> 39 chars + '\0'
    sprintf(tblAddrASCII, "%04X:%04X:%04X:%04X:%04X:%04X:%04X:%04X", data.addr[0], data.addr[1], data.addr[2], data.addr[3], data.addr[4], data.addr[5], data.addr[6], data.addr[7]);
    //http://www.cplusplus.com/reference/cstdio/sprintf/
 
    Serial.print(F("Adresse en ASCII: "));
    Serial.println(tblAddrASCII);
 
    if(strcmp(tblAddrASCII, "00AB:CF2A:153D:2ABC:2384:A23D:F2FF:CA2D") == 0) {
      Serial.print(F("Addresse OK -> Traitement"));
      Serial.println();
    }
  }
}

Et si je met une autre adresse, le if n'est pas exécuté (logique puisque je teste l'adresse). Je me suis servi du site que tu m'a donné et qui permet de visualiser les possibilités du langage.

Je vais faire ensuite la partie traitement du message afin d'afficher sur le LCD. Il faudra que je bosse sur de nouvelles procédures aussi. Donc réviser ma classe Disp !

Zou, je continue le développement. Merci c'est super cool d'être aider. J'y serais pas arrivé sinon. Et en plus j'apprends des choses sympa. Y a fort à parier pour que je traine dans le coin plus souvent

[Jay M]

Bravo

Notez que pour comparer l’adresse il n’y a pas besoin de fabriquer la chaîne de caractère et comparer en ascii, vous pouvez juste comparer les 8 éléments 2 à 2 ou en étant un peu smart puisque les octets sont contigus dans la structure avec un memcmp()

[Caxton]

J'avoue qu'au départ, je n'avez pas songé à cette solution

Mais du coup, ça m'a donné une idée. Pourquoi ne pas travailler sur un token. Ben oui, come ça on ne teste plus qu'un booléen pour effectuer l'affichage. C'est beaucoup plus rapide et ça évite de se perdre. Du coup, j'ai mis en place une technique qui fait qu'au premier groupe de caractère faux ça break !

Voilà donc ce que ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define RX_PIN 5
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;
 
uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D};
boolean tokenValid = false;
 
RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600); //Liaison série pour le Débug
  driver.init();  //Initialisation de RH_ASK
}
 
void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer
 
  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {
    //Nous imprimons les 8 adresses
    for(uint8_t i = 0; i < 8; i++) {
      Serial.print(F("data.addr["));
      Serial.print(i);
      Serial.print(F("] = 0x"));
      Serial.println(data.addr[i], HEX);
    }
 
    //Nous imprimons le message contextuel
    Serial.print(F("Message: "));
    Serial.println((char*) data.dataRecv);
 
    //Lister au travers de la mémoire chaque valeur de l'adresse
    for(uint8_t i = 0; i < 8; i++) {
 
      //Comparaison par emplacement mémoire
      if(memcmp(tblAddr[i], data.addr[i], sizeof(tblAddr)) == 0) {
        tokenValid = true;
      }
      else {
        tokenValid = false;
        break; // Forcer la sortie de la recherche d'adresse car c'est pas la bonne
      }
    }
 
    if(tokenValid) {
      Serial.print(F("Addresse OK -> Traitement"));
      Serial.println();
    }
  }
}

Bien sûr, c'est bien mieux ainsi. Qu'en pensez vous ?
Si c'est bon, la prochaine étape sera donc d'extraire le message, de prévoir une pile (on en parlera ensuite)

[Jay M]

y'a de l'idée mais c'est pas tout à fait cela !!


si vous voulez comparer deux à deux avec votre boucle for, on peut simplement comparer avec == entre deux entiers

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
const uint16_t tblAddr[8] = {0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D}; // mettez le en const, c'est mieux
...
bool tokenValid = true;
for(uint8_t i = 0; i < 8; i++) {
  if (tblAddr[i] != data.addr[i]) {
    tokenValid = false;
    break; // Forcer la sortie de la recherche d'adresse car c'est pas la bonne
  }
}

if (tokenValid) {
  // bonne adresse
} else {
  // mauvaise adresse
}

Cependant la fonction memcmp() est assez intelligente pour arrêter de comparer dès qu'un octet ne correspond pas, donc elle fait l'équivalent de votre break. donc si vous utilisez memcmp() c'est sur tout le buffer d'un coup qu'il faut le faire, pas besoin de la boucle for.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
const uint16_t tblAddr[8] = {0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D}; // mettez le en const, c'est mieux
...

if (!memcmp(data.addr, tblAddr, sizeMaxData)) {
  // bonne adresse
} else {
  // mauvaise adresse
}

--> c'est encore plus compact

[Caxton]

En effet, c'est plus compact, mais... je ne suis pas arrivé à le faire fonctionné

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;
 
const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D};
 
RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600); //Liaison série pour le Débug
  driver.init();  //Initialisation de RH_ASK
}
 
void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer
 
  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {
    //Nous imprimons les 8 adresses
    for(uint8_t i = 0; i < 8; i++) {
      Serial.print(F("data.addr["));
      Serial.print(i);
      Serial.print(F("] = 0x"));
      Serial.println(data.addr[i], HEX);
    }
 
    //Nous imprimons le message contextuel
    Serial.print(F("Message: "));
    Serial.println((char*) data.dataRecv);
 
    if(!memcmp(data.addr, tblAddr, sizeMaxData)) {
      Serial.print(F("Addresse OK -> Traitement"));
      Serial.println();
    }
    else {
      Serial.print(F("Addresse NOK !!!"));
      Serial.println();
    }
  }
}

J'ai essayé et j'ai peut-être raté quelque-chose. Remarque c'est peut-être moi qui n'ai pas tout compris...

[Jay M]

J’avais laissé un petit piège

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 if(!memcmp(data.addr, tblAddr, sizeMaxData)) {

Combien d’octets souhaitez vous comparer avec memcmp() ?

[Caxton]

C'est mieux avec ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if(!memcmp(data.addr, tblAddr, sizeof(data.addr))) {

puisque c'est la taille de la chaîne reçue

Ça fonctionne !

Donc, oui, beaucoup plus court que ce que j'avais fait !

Du coup, je dois m'attaquer à la gestion du message et au LCD. Après, j'ai d'autres modifications à faire car je vais ajouter une notion de pile. Nous en reparlerons plus loin

Merci en tout cas pour la patience et pour les infos. C'est toujours aussi cool de progresser un peu.

[Jay M]

Bravo

[Caxton]

Bonjour,

Je viens de continuer à programmer un peu. J'ai légèrement modifier l'exemple qui avait été donné plus haut. J'espérais passé par un tableau, plus facile pour moi pour l'intégrer avec la librairie Display que j'ai construite y a pas mal de temps. Nous y reviendrons plus tard

Voilà donc le bout de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define RX_PIN 5
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;
 
const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D};
//const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA5D};
 
RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600); //Liaison série pour le Débug
  driver.init();  //Initialisation de RH_ASK
}
 
void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer
 
  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {
 
    //Si l'adresse correspond à celle de l'équipement
    if(!memcmp(data.addr, tblAddr, sizeof(data.addr))) {
      //Extraire le message, l'affichage sur le LCD
 
      /* A tester */
      char tblMessage[sizeof(data.dataRecv)];
      uint8_t cmpt = 0;
      char * ptrText;
      ptrText = strtok(data.dataRecv, ",");
 
      //Boucler tant que tous les éléments ne sont pas extrait
      while(ptrText) {
        char* starText;
 
        //Si nous avons un espace au début, sauter
        if(*ptrText == ' ') {
          starText = ptrText + 1;
        }
        else {
          starText = ptrText;
        }
 
        tblMessage[cmpt] = starText;
        cmpt++;
        ptrText = strtok(NULL, ";"); //Tocken suivant
      }
 
      Serial.print(F("Type message [ "));
      Serial.print(tblMessage[0]);
      Serial.println(F(" ]"));
 
      Serial.print(F("ligne [ "));
      Serial.print(tblMessage[1]);
      Serial.println(F(" ]"));
 
      Serial.print(F("colonne [ "));
      Serial.print(tblMessage[2]);
      Serial.println(F(" ]"));
 
      Serial.print(F("Message [ "));
      Serial.print(tblMessage[3]);
      Serial.println(F(" ]"));
      /* Fin du test */
    }
  }
}

J'ai gardé la partie adresse qui fonctionne bien entendu. Et maintenant, je me concentre sur l'affichage.

Voyons le résultat :


Je m'attendais à pire que ça. Genre que ça compile pas ou que j'ai outrepassé les possibilitées de la compilation. Mais non, ça a bien compilé.

Donc voilà, j'ai pas su m'y retrouver dans le parsing sous strtok. J'avoue, je ne suis pas très doué avec cette méthode. Peut-êtres est-ce par ce que j'ai eu beaucoup fait de PHP et que là règle de l'explode...

Enfin, bon, donc j'aimerais comprendre ce qui se passe avec mon code, ou est-ce que j'ai pu faire des erreurs et comment je puis les réparer.

[Jay M]

vous mélangez un peu les pointeurs et les données. quand vous parcourez les tokens vous avez des pointeurs dans la chaîne reçue et les caractères séparateurs sont remplacés par des caractère marquant une fin de chaîne. Si on se souvient donc de ces pointeurs on pourra donc effectivement imprimer les données. Attention ce sont des pointeurs dans le buffer principal, pas une copie, donc à la prochaine réception ils ne seront plus valides.

essayez ce code (en passant votre console série à 115200 bauds car 9600 c'est vraiment lent)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
#include <RH_ASK.h>
#define speedTR 1000
#define RX_PIN 5

const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer

struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;

const uint16_t tblAddr[8] {0x00AB, 0xCF2A, 0x153D, 0x2ABC, 0x2384, 0xA23D, 0xF2FF, 0xCA2D};
//const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA5D};

RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead

void setup()
{
  Serial.begin(115200); // utilisez 115200, c'est mieux car les messages debug vous ralentiront moins
  driver.init();  //Initialisation de RH_ASK
}

void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer

  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {

    //Si l'adresse correspond à celle de l'équipement
    if (!memcmp(data.addr, tblAddr, sizeof(data.addr))) {
      //Extraire le message, l'affichage sur le LCD

      /* A tester */
      const uint8_t maxPointeurs = 10;
      char* tblMessage[maxPointeurs]; // on va conserver des pointeurs dans la structure reçue, donc des char*
      uint8_t cmpt = 0;
      char * ptrText;
      ptrText = strtok(data.dataRecv, ",");

      //Boucler tant que tous les éléments ne sont pas extrait
      while (ptrText) {
        char* starText;

        //Si nous avons un espace au début, sauter
        if (*ptrText == ' ') starText = ptrText + 1;
        else starText = ptrText;

        if (cmpt < maxPointeurs)                  // S'il reste de la place dans le buffer on garde le pointeur
          tblMessage[cmpt++] = starText;
        else break; // pas la peine de continuer on ne peut pas mémoriser les suivants

        ptrText = strtok(NULL, ";"); //Tocken suivant
      }

      Serial.print(F("Type message [ "));
      Serial.print(tblMessage[0]);
      Serial.println(F(" ]"));

      Serial.print(F("ligne [ "));
      Serial.print(tblMessage[1]);
      Serial.println(F(" ]"));

      Serial.print(F("colonne [ "));
      Serial.print(tblMessage[2]);
      Serial.println(F(" ]"));

      Serial.print(F("Message [ "));
      Serial.print(tblMessage[3]);
      Serial.println(F(" ]"));
      /* Fin du test */
    }
  }
}

[Caxton]

En effet, j'avais pas pensé au coup de dépasser un nombre de pointeurs.

Il y a eu du mieux, Mais...


J'ai du me gourationner quelque part !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define RX_PIN 5
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;
 
const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D};
//const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA5D};
 
RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600); //Liaison série pour le Débug
  driver.init();  //Initialisation de RH_ASK
}
 
void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer
 
  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {
 
    //Si l'adresse correspond à celle de l'équipement
    if(!memcmp(data.addr, tblAddr, sizeof(data.addr))) {
      //Extraire le message, l'affichage sur le LCD
 
      /* A tester */
      const uint8_t maxPtr = 10;
      uint8_t cmpt = 0;
      char* tblMessage[sizeof(data.dataRecv)];
      char * ptrText;
 
      ptrText = strtok(data.dataRecv, ",");
 
      //Boucler tant que tous les éléments ne sont pas extrait
      while(ptrText) {
        char* starText;
 
        //Si nous avons un espace au début, sauter
        if(*ptrText == ' ') {
          starText = ptrText + 1;
        }
        else {
          starText = ptrText;
        }
 
        //S'il reste de la place dans le buffer, nous gardons le pointeur
        if(cmpt < maxPtr) {
          tblMessage[cmpt++] = starText;
        }
        else {
          break; //stop !!! Oust... Dehors ! On a pas assez de place pour mémoriser les suivants
        }
        ptrText = strtok(NULL, ";"); //Tocken suivant
      }
 
      Serial.print(F("Type message [ "));
      Serial.print(tblMessage[0]);
      Serial.println(F(" ]"));
 
      Serial.print(F("ligne [ "));
      Serial.print(tblMessage[1]);
      Serial.println(F(" ]"));
 
      Serial.print(F("colonne [ "));
      Serial.print(tblMessage[2]);
      Serial.println(F(" ]"));
 
      Serial.print(F("Message [ "));
      Serial.print(tblMessage[3]);
      Serial.println(F(" ]"));
      /* Fin du test */
    }
  }
}

Alors, pour la vitesse Serial. Je reste volontairement sur une rapidité basse, de toute façon, j'ai qu'un message toutes les secondes environs pendant les essais. Ce mode dégradé me sert pour bien vérifier mon fonctionnement avant de remonter la vitesse de transfert. Il en va de même pour le signal radio qui est pas si rapide, afin de gagner sur la distance. C'est une histoire de compromis connu du monde radioamateur. Mais ça je ne peux plus en parler car je suis loin d'avoir tout fini.

Pour le moment, j'en suis là. C'est déjà pas si mal quand je vois mes essais au début !

[Jay M]

En effet, j'avais pas pensé au coup de dépasser un nombre de pointeurs.

vous aviez surtout un tableau de caractères (char) pas de pointeurs (char*)

si vous regardez ce qui est imprimé, Ligne a pris tout le message et donc il n'y pas eu de décodage et comme vous imprimez les 4 éléments sans vraiment tester si vous avez bien lu 4 tokens...

Je n'avais pas fait attention et j'avais repris juste le code concernant les pointeurs, mais vous n'utilisez pas le bon séparateur dans la boucle. Au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        ptrText = strtok(NULL, ";"); //Tocken suivant

il faut mettre une virgule au lieu du point virgule...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

        ptrText = strtok(NULL, ","); //Tocken suivant

Alors, pour la vitesse Serial. Je reste volontairement sur une rapidité basse, de toute façon, j'ai qu'un message toutes les secondes environs pendant les essais. Ce mode dégradé me sert pour bien vérifier mon fonctionnement avant de remonter la vitesse de transfert. Il en va de même pour le signal radio qui est pas si rapide, afin de gagner sur la distance. C'est une histoire de compromis connu du monde radioamateur. Mais ça je ne peux plus en parler car je suis loin d'avoir tout fini.

Oui pour ce qui concerne la partie Radio. Mais pour la liaison série il n'y a aucun intérêt. si on a un arduino ‘récent’ (quelques années), il n'y a aucune raison valable pour que la liaison série soit à 9600 bauds. L'habitude vient de ce que l'on voit dans les tutos, qui datent des débuts d'Arduino, et où le module série n'était pas capable de supporter des vitesses plus rapide. ce n'est plus le cas et ce qu'il peut se passer c'est que l'usage de 9600 bauds pour votre debug viennent empiéter sur le performance de l'application (print devient bloquant s'il y a plus de 64 octets à un moment donné à imprimer) et que vous ratiez des trames radio ou d'autres événements ...

[Caxton]

Oh mon dieu
Je n'avais pas creusé jusqu'au ";". Mais oui, ça fonctionne parfaitement

Ok pour le côté bloquant de la fonction. Mais a terme, c'est pus la liaison série qui doit être employé sur le récepteur mais le LCD.

Je viens d'implémenter mon affichage... devinez ? .... quoi vous n'avez pas deviné ? Bon, ok je vous le dit : ça fonctionne

Du coup :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
#include <LcdMidas.h>
#include "Disp.h"
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define RX_PIN 5
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataRecv[sizeMaxData];  //Nombre d'octets en réception
} data;
 
const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA2D};
//const uint16_t tblAddr[8]{0x00AB,0xCF2A,0x153D,0x2ABC,0x2384,0xA23D,0xF2FF,0xCA5D};
 
Disp *p_Disp; //Global Pointer
RH_ASK driver(speedTR, RX_PIN); //Librairie RadioHead
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600); //Liaison série pour le Débug
 
  p_Disp = new Disp();              //Constructor
  p_Disp->dispInit();               //Initalize Hardware
  delete p_Disp;                     //Delete pointer in Destructor
 
  delay("1000");
 
  driver.init();  //Initialisation de RH_ASK
}
 
void loop() {
  // put your main code here, to run repeatedly:
  uint8_t buflen = sizeof(data);  //Longueur du buffer
 
  //Si des datas sont reçues au tarvers de RH_ASK
  if (driver.recv((uint8_t*) &data, &buflen)) {
 
    //Si l'adresse correspond à celle de l'équipement
    if(!memcmp(data.addr, tblAddr, sizeof(data.addr))) {
      //Extraire le message, l'affichage sur le LCD
 
      //Analyse et affiche les infos
      analyseMSG(data.dataRecv);
    }
  }
}

Bon, pour la bibliothèque, remplacez par liquidChristalI2C et pour Disp, c'est une petite simplification en passant par une classe perso

Maintenant, je m'interroge sur quelque-chose. Peut-on séparer l'analyse de l'affichage ? C'est à dire en pseudo code :

Init()
Loop()
-> attendre message
--> Message reçu, c'est la bonne adresse
---> tableau = analyse message()
---> Message complet ?
---->afficher message
Void analyse()
-> Analyser
-> Mettre dans un tableau

J'ai essayer de synthétiser ou je veux en venir. Mais n'étant pas assez calé avec les pointeurs, je me demande si c'est réalisable sans trop de retouche.

Ce qui m'amène à une ultime question. Oui, je suis pénible avec mes question, mais c'est pour comprendre et faire évoluer mon code aussi. Que se passe-t-il si par exemple, un jour, nous désirons améliorer le message en ajoutant de nouvelles données tel que :

- LCD, 0, 0, Data 1
- TEMP, 100
- OPT1, DATA1, DATA2, DATA3, DATA4, DATA5

Je n'envoie pas tous les message à la fois. Par exemple :

0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D
LCD, 0, 0, Data 1
0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D
OPT1, DATA1, DATA2, DATA3, DATA4, DATA5
0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xC021
LCD, 0, 0, Data 23
0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xC021
OPT1, DATA1, DATA2, DATA3, DATA4, DATA5

ici, nous voyons un échange avec 2 récepteurs, chacun son data à afficher et son option. Je compte gérer des validations avec la seconde trame par exemple ou d'autres comportements. Il va de sois que si je veux intégrer la seconde ligne, je dois ajouter une nouvelle igne LCD.

Mais déjà c'est cool je suis content d'avoir réussi à faire marché le bout de code.

Merci, encore une fois de cette patience.

[Jay M]

cool !

Peut-on séparer l'analyse de l'affichage ? C'est à dire en pseudo code :

On peut faire ce qu’on veut

La durée de vie de vos pointeurs est la durée de vie de la structure et de la fonction dans votre cas car déclarés localement, si vous recevez un nouveau message alors vous perdez l’info.

Si vous souhaitez la conserver, pas de magie, il faut la stocker ailleurs, dans un espace mémoire qui aura une durée de vie égale à celle du programme. Si ce n’est que pour le LCD, ce que vous envoyez est cumulatif si vous ne faites pas de clear, donc le LCD lui même peut servir de buffer.

Vous pourriez par exemple garder un tableau des 10 dernières structures (attention à la mémoire dispo) reçues et avec un index qui va de 0 à 9 et qui boucle. Il suffit alors de passer à la fonction de réception des données un pointeur sur la bonne structure dans le tableau. Comme l'analyse du contenu est assez rapide, pas la peine de conserver les pointeurs de décodage, vous pouvez les calculer quand vous en avez besoin.

[Caxton]

Bonjour,

Je suis désolé d'avoir eu autant d'absence depuis le dernier message. Le pro est passé avant

Mais entre deux coup de balais (c'est histoire de tenir le manche...), j'ai eu le temps de réfléchir un peu. J'ai essayé de codé l'émission de telle sorte que les datas passent depuis l'extérieur vers la carte émission avant d'arriver à la carte réception, et son affichage sur le LCD. Malheureusement, ça ne fonctionne pas très bien.

Voilà ce que j'ai essayé de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
#include <RH_ASK.h>
#include <SPI.h> // Not actually used but needed to compile
 
#define speedTR 1000
#define TX_PIN 4
 
const uint16_t sizeMaxData = 43;  //Taille max du data à envoyer
 
struct data_t {
  uint16_t addr[8];
  uint8_t dataSend[sizeMaxData];  //Nombre d'octets
} data;
 
RH_ASK driver(speedTR, "", TX_PIN);
 
void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  driver.init();
}
 
void loop() {
  // put your main code here, to run repeatedly:
  data.addr[0] = 0x00AB;
  data.addr[1] = 0xCF2A;
  data.addr[2] = 0x153D;
  data.addr[3] = 0x2ABC;
  data.addr[4] = 0x2384;
  data.addr[5] = 0xA23D;
  data.addr[6] = 0xF2FF;
  data.addr[7] = 0xCA2D;
 
 
  char MSG[16]; //16 caracteres +1
  int i = 0;
  if(Serial.available() > 0) {
    while(Serial.available() > 0) {
      MSG[i] = Serial.read();
      delay(3);
      i++;
    }
 
    strncpy(data.dataSend, MSG, sizeMaxData-1);
    data.dataSend[sizeMaxData-1] = '\0'; //Fin de chaine
 
    driver.send((uint8_t*)&data, sizeof(data));
    driver.waitPacketSent();
  }
}

Toujours pareil, je suis en bas débit volontairement. Il faudra dire aussi qu'il risque d'y avoir de l'éloignement entre le PC et la carte émission. Donc je limite pour le moment.

Donc ici, je n'envoie pas encore tous le message. D'ailleurs, depuis le PC, le Serial devrais recevoir ceci : "0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D;0;0;2345 52 D" soit la trame suivante "Adresse;Colonne;Ligne;Message". Message n’excède pas 16 caractères.

Pour l'heure, sans toucher au RX, le message issue de Serial n'arrive pas. L'écran reste vide (au clear quoi). Donc je me dis, si le code suivant fonctionne avec le récepteur, c'est qu'une erreur est glissé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
//Type, Colonne, Ligne, Message
  strncpy(data.dataSend, "LCD, 0, 0, Hello World!!!!!!!", sizeMaxData-1);
  data.dataSend[sizeMaxData-1] = '\0'; //Fin de chaine
 
  driver.send((uint8_t*)&data, sizeof(data));
  driver.waitPacketSent();
  delay(1000);
 
  //Type, Colonne, Ligne, Message
  strncpy(data.dataSend, "LCD, 0, 0, ABCD", sizeMaxData-1);
  data.dataSend[sizeMaxData-1] = '\0'; //Fin de chaine
 
  driver.send((uint8_t*)&data, sizeof(data));
  driver.waitPacketSent();
  delay(1000);

Pour le moment, voilà ou j'en suis.

[Jay M]

Salut

Ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 char MSG[16]; //16 caracteres +1
  int i = 0;
  if(Serial.available() > 0) {
    while(Serial.available() > 0) {
      MSG[i] = Serial.read();
      delay(3);
      i++;
    }

n’est pas top à plein d’égards:
D’abord vous n’avez que 16 caractères alors que le commentaire appellerait à en mettre 17
Ensuite la lecture d’un port asynchrone ne doit pas se faire en jouant avec delay... pour bien lire le port série le plus simple c’est de définir un caractère de fin de ligne et de lire dans le buffer jusqu’à réception. Ici si vous envoyez le texte depuis la console la fin de ligne pourrait être ‘\n’ (newline). Donc votre boucle ne doit pas se faire tant qu’il y a des data dans le buffer série (Vous ne savez pas à quelle vitesse elles vont arriver et vous risquer de le vider trop rapidement), mais tant que vous n’avez pas reçu la fin de ligne, vous lisez et stockez (s’il y a de la place dans le tableau attention au débordement) et passez au caractère suivant.
Attention une cString doit se terminer par un caractère nul ‘\0’ donc quand vous recevez le ‘\n’, mettez bien ce caractère nul dans le tableau pour marquer la fin de chaîne.

Avec ça votre écoute du port série sera un peu plus solide, et ça devrait marcher. Vous essayez ?

[Caxton]

Du coup, je viens de revérifier un peu. En effet, 17 caractères. Mais du coup, je me suis dit est-ce que je sais détecté la fin de la chaine. Et oui, mais non !
Là, je détecte un vide (et donc pas la fin de chaine). Petit exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
char MSG[17]; //16 caracteres +1
  int i = 0;
  if(Serial.available() > 0) {
    while(Serial.available() > 0) {
      char lu = Serial.read();
      if(lu != '\n') {
        Serial.print(i);
        Serial.print(F(" - "));
        Serial.println(lu);
      }
      else {
        Serial.print(i);
        Serial.print(F(" - "));
        Serial.println("FIN");
      }
      //MSG[i] = lu;
      i++;
    }

Résultat pour la chaine "0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D;0;0;2345 52 D" :

0 - 0
0 - x
1 - 0
2 - 0
3 - A
4 - B
5 - :
6 - 0
7 - x
8 - C
9 - F
10 - 2
11 - A
12 - :
13 - 0
14 - x
15 - 1
16 - 5
17 - 3
18 - D
19 - :
20 - 0
21 - x
22 - 2
23 - A
24 - B
25 - C
26 - :
27 - 0
28 - x
29 - 2
30 - 3
31 - 8
32 - 4
33 - :
34 - 0
35 - x
36 - A
37 - 2
38 - 3
39 - D
40 - :
41 - 0
42 - x
43 - F
44 - 2
45 - F
46 - F
47 - :
48 - 0
49 - x
50 - C
51 - A
52 - 2
53 - D
54 - ;
55 - 0
56 - ;
57 - 0
58 - ;
59 - 2
60 - 3
61 - 4
62 - 5

Et nous voyons bien que ça s'arrête avant. L'espace, du coup, fait stopper net le contenu. Donc il faut que je trouve pourquoi c'est ainsi. J'ai pas vraiment de piste à ce stade.

[Jay M]

C’est ce que je vous disais à mon avis - vous lisez le buffer plus rapidement que les données n’arrivent et le buffer fait 64 caractères...

Le while doit être sur la réception de la fin de ligne ou faire un while(true) et faire un break à la réception de la fin de ligne (ou pour être robuste et pas rester coincé au bout de x secondes)

Vous n’êtes pas loin !!

[Caxton]

Et le problème s'avéra plus complexe que prévus.
Je sais ce qui se passe. Je dépasse ce que le buffer peut accepter. En d'autres termes, il me faut envoyer moins de données à la fois. Ce n'est pas l'espace qui jette la suite du message mais sa longueur.

Je propose une solution, et je cherche la meilleure méthode pour y arrivé. Au départ, se voulant simple, j'ai accolé les messages avec un caractère de séparation, le ";". Et ça semblais être Ok entre les deux cartes. Mais c’était sans compter sur Serial qui a un buffer trop court... Le vilain

Bon, réfléchissons un peu ! Si je coupe en 3 messages l'envoie d'un message, je peux alors envoyer ceci:

Adresse -> Ack de la carte TX
Instruction LCD -> Ack de la carte TX
Message -> Ack de la carte TX + diffusion

Ceci devrais donner cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Pc "0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D" -> USB -> adresse enregistré
TX -> Renvoie le caractère "1"
Pc "0;0" -> USB -> Colonne et Ligne enregistré
TX -> Renvoie le caractère "1"
Pc "2345 52 D" -> USB -> Message enregistré
Tx -> Renvoie a la carte RX
TX -> Renvoie le caractère "1"

Sauf que, comment faire pour que la carte ne se mélange pas les pédales à la réception des datas ? Est-ce que nous pouvons prendre en compte une stratégie d'abandon, exemple si deux messages partent trop tôt... Par ce que bon, je ne suis pas à l'abri que le soft qui sera derrière envoie du lourd et du super rapide. Mais ça je ne peux que le vérifier avec des tests et des discussions ici.

Donc, ceci m'amène à penser à une autre stratégie. Si le Pc a de la mémoire, il peut donc logicielement faire office de tampon tant que le TX n'a pas reçu son instruction complète. En plus je pense que nous pouvons identifier les éléments envoyées tel que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Pc -> "Addr;0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D"
Tx -> Tbl[0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D][][]
Tx -> Serial : Addr;Ok
Pc -> "Lcd;0;0"
Tx -> Tbl[0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D][0;0][]
Tx -> Serial : Lcd;Ok
Pc -> "Mess;2345 52 D"
Tx -> Tbl[0x00AB:0xCF2A:0x153D:0x2ABC:0x2384:0xA23D:0xF2FF:0xCA2D][0;0][2345 52 D]
Tx -> Serial : Mess;Ok

Dans ce cas, je pense que je sécurise les choses, car si je fixe le début de trame avec un identifiant tel que Addr; ou Lcd; ou Mess; on peut imaginer de pouvoir traiter plus d'informations et sans dépasser le buffer. Du coup, je gagne en lisibilité et en simplicité. Qu'en pensez-vous ? Est-ce que ce sera réalisable sans trop de modification ?

[Jay M]

A l'origine vous vouliez une Communication radio mono directionnelle. Synchroniser les 2 cartes sur la base d'un protocole asynchrone n'est pas simple. outre le rajout de matériel il faudra développer une machine à état des deux côtés, et un mécanisme robuste de reprise en cas d'erreur. Si vous voulez explorer cette voie, le RH_ASK n'est pas le bon hardware, vaudrait mieux passer sur du nRF24L01+ qui est multicanal et bi-directionnel.

en restant sur l'architecture actuelle, à mon avis vous pouvez vous en sortir avec l'émetteur qui envoie plusieurs trames, charge au receveur de bien gérer ces différents éléments. Si quelque chose ne va pas, il aura raté un message complet et se remet en attente du prochain message complet

chaque message aura un en-tête pour dire quelle partie du message complet il représente, et éventuellement numérotez le message pour s'assurer qu'on reçoit bien un élément du message en cours.