Lire (et trier !) sur le port série

International Français
1

Bonjour tout le monde :slight_smile:

Je débute avec l'utilisation du port série... et j'ai pris pas mal de paracétamol avant de venir vous soumettre mon souci ^^

D'un logiciel, je reçois des données sur le port série, j'arrive à les "observer" grâce à un logiciel de "port monitoring".
Capture du logiciel de port monitoring : colonne 3 = "Data" / colonne 4 = "Data (chars)" / colonne 5 = "Data length"

Je souhaite n'utiliser que les "paquets" (je ne sais pas si j'utilise le bon vocabulaire) avec une Data Length de 900.

  1. Du peu que j'ai compris jusqu'à présent, on ne peut lire que caractère par caractère avec Serial.read() , et je n'ai pas trouvé de fonction qui renvoie la "data length".

  2. Même si je bidouille des choses en lisant caractère par caractère, y a-t-il un moyen de distinguer une ligne de la suivante ? J'ai bien entendu parler de "stop bit" mais là il n'apparaissent pas sur ce logiciel de monitoring.

  3. Quand on utilise Serial.read(), on récupère de l'hexadécimal ? ou un char ?

Bref je suis preneur d'une stratégie pour récupérer mes petits paquets de données de 900 unités, bien séparés les uns des autres lol.
Merciii

2

1 - souvent on lit octet par octet, il existe d'autres fonctions de Serial qui lisent un int, ou bien "jusqu'à" trouver tel caractère ... voir la doc de Serial.

2 - les stopbits, c'est au niveau en dessous, c-à-d pour séparer les octets consécutifs.
En général, on appelle "trame" un paquet de données circulant sur une ligne série. L'émetteur envoie une trame, le recepteur la reçoit. Comment le récepteur sait-il que le trame - qu'il reçoit octet par octet - est finie ?
Ca s'appelle un protocole : c'est une entente, une convention entre l'émetteur et le récepteur.

Par exemple, l'émetteur peut respecter un silence minimum (par ex. 100 ms) entre la fin d'une trame et le début de la suivante (on parle de "Silence Ligne"). Le récepteur doit mesurer le temps qui s'écoule après réception d'un octet, si le temps dépasse le seuil, il sait que la trame est finie.

Ou alors, on convient que la trame se termine par 1 ou 2 octets particuliers, par exemple "\r\n". Quand le récepteur voit passer ces 2 là, il sait...

Au final, ça vient donc à toi de choisir le protocole ... lorsque tu écris le recepteur et l'émetteur. Si l'émetteur est fourni (semble être ton cas), il faut bien étudier ce qu'il fait (respecte-t-il un silence ligne ? finit-il ses trames par un caractère particulier ?) et t'adapter en conséquence.

3 - Ni l'un ni l'autre. Tu récupères des octets. Un octet est un octet. L'héxadécimal, le décimal, le binaire, ce ne sont que des façons d'écrire sa valeur.
Ensuite est-ce qu'il faut ranger ces octets dans des char, ou dans autre chose ? c'est encore à toi de savoir ce que représentent ces octets, pour en faire bon usage. Dans ton cas, il semble que la trame contient du texte lisible, ranger les octets entrants dans un tableau de char me semble une bonne idée.

3

Merci biggil pour ces premiers éléments :slight_smile:

Du coup, sur une trame qui commencerait du style ff 00 ff ff 00 00

Avec ce type de code,

int d1,d2,d3;
d1 = Serial.read();
d2 = Serial.read();
d3 = Serial.read();

J'aurais d1 = 255, d2 = 0 et d3 = 255 ?

4

oui ... si tu commences pas à lire alors que la trame est déjà commencée (= raté le début)
Il faut gérer ça aussi, savoir éliminer les 1er octets reçus si on prend la trame "en cours".

[Edit] comme tu as déclaré d1 et d3 comme des int (sous entendu signés), ils vont hériter du signe du byte renvoyé par Serial.read(), ainsi ils vaudront -1 (et non 255)