994 réponses à ce sujet

[Oliver17]

C'est pire, les données sont à la limite de bloquer, puis dans la lib RS232 il place le 100ms pour que la réception et l'envoi soient syncro si je puis dire ^^

 

Après je me plante surement mais vu les tests que l'on avait fais avec les gars...

 

RS232 : https://www.teuniz.net/RS-232/

[Sandro]

Tu entends quoi par "les données sont à la limite de bloquer"?

 

Il est vrai que la doc de la bibliothèque conseille de faire du polling avec un écart d'environ 100 ms. Le problème est que tu essaye de lire exactement la taille d'une lecture des capteurs avec un écart d'un peu plus de 100 ms, du coup, ça peut pas marcher (tu ne lis pas assez vite).

 

Plusieurs bidouilles sont possibles :

1) tu remplaces le 100 ms par 90ms : tu vas ainsi lire un poil plus vite, ce qui devrait permettre de suivre le rythme. De temps à autre tu ne lira rien car il n'y aura pas encore de nouvelles données

2) dans comPI.cpp, tu ne lis pas que la taille de u_buf mais (beaucoup) plus, potentiellement jusqu'à la taille du buffer interne (4096 octets), et tu traite les données que tu as. Attention, rien ne garantit que tu as un nombre entier de paquets, ni même que le début du buffer est le début d'un paquet.

3) Tu utilise une autre bibliothèque pour le RS232 qui soit permet de faire du polling aussi souvent que tu veux, soit te permet d'avoir une interruption quand des données arrivent.

 

 

A noter que ton code de comPI.cpp est probablement faux :

tu pars du principe que dans piReceive(), tu reçois forcément soit rien soit sizeof (u_buf.cast_esp) octets. Mais tu peux très bien recevoir quelque chose entre les deux ( 0<n<sizeof (u_buf.cast_esp) ). Si tel est le cas, les derniers octets de u_buf seront du "n'importe quoi" (probablement la valeur qu'il y avait au coup d'avant, mais il faudrait aller creuser dans le code pour vérifier, à priori ça pourrait être n'importe quoi).

Un second problème est que rien ne permet d'affirmer a-priori qu'au moment où tu commence à recevoir, il n'y a pas un envois en cours (ou qu'un octet se perde) : il est donc possible qu'à un moment tu reçoive le bon nombre d'octets, mais qu'il s’agisse en fait de la fin d'un paquet suivit du début du suivant, ce que tu interprétera donc de manière erronée.

 

 

Si tu es pressé, essaye de réduire le sleep à 90ms, il est bien possible que ça marche 99.9% du temps (mais garde en tête que si un jour tu obtiens une valeur bizarre ou qu'il manque une mesure, c'est bien possible que ça vienne de là).

Si tu veux faire les choses proprement, alors il faut gérer la transmission en considérant que tu as une suite de bytes ininterrompue, dont tu lis toujours tout ce qui est disponible, et que c'est à toi de détecter le début de chaque paquet. Ce que je fais en général, c'est d'ajouter au début de chaque paquet un octet constant (par exemple 42), et à la fin du paquet une checksum (par exemple le xor de tous les octets du paquet) : de cette manière, si le premier octet n'est pas 42, je sais qu'il y a un problème et je vire tous les octets jusqu'à trouver un 42. Une fois que j'ai un 42, je récupère le paquet, et je vérifie la checksum pour m'assurer qu'il n'y a pas eut de problèmes de communication.

[Oliver17]

 punaise ça devient pénible tout ça, oui j'aimerais faire les choses proprement, je me doutais bien que mon code n'a rien de parfait loin de là mais j'essaye de me démerder comme je peux (smiley qui pleure, ps : rajouter un smiley qui pleure dans la liste snif ).

 

J'essaye de comprendre la fin de ton post, du moins comment mettre ça en place, pfffiiuuuuu c'est vraiment pénible. 

 

 

Sérieux, Glenn n'est pas près de voir le jour à se rythme la, misère.

[Sandro]

En pseudo code "haut niveau":

Je suppose que tu envois 40 octets de donnée utile, précédé de l'entier 11, et suivits par le xor des 41 octets (ie le 111 et les 40 octets de donnée). Nb : dans cet exemple, j'utilise le 111, au lieu du 42 évoqué dans le post précédent,  pour éviter de confondre avec le fait qu'on envois 42 octets au total.

 

Dans l'initialisation:

tu crée un buffer vide BUFFER_RECEPTION

 

à chaque execution de piReceive() :

1) tu lis tous les octets disponibles et tu les stocke dans le tableau T_NOUVEAUX_OCTETS

2) tu ajoute les octets de T_NOUVEAUX_OCTETS après ceux déjà présents dans BUFFER_RECEPTION

3) tant que dans BUFFER_RECEPTION il y a au moins 42 octets

   3.1) si le premier octet n'est pas 111, l'enlever et retourner au 3)

   3.2) si le xor des 41 premiers octets n'est pas égal au 42ième octet, enlever le premier octet et retourner au 3). Nb : une version plus agressive est d'enlever les 42 octets : c'est plus rapide mais tu prends un petit risque de perdre le paquet suivant qui était valide si le 111 que tu avais rencontré n'était pas un début de paquet mais juste une valeur 111 présente par hasard.

   3.3) tu récupère et traite les 40 octets qui t'intéressent

   3.4) tu retourne au 3)

4) fin de la fonction piReceiver (nb : il faut faire attention qu'il reste potentiellement jusqu'à 41 octets dans BUFFER_RECEPTION, qu'il faut garder jusqu'à l'appel suivant de la fonction piReceiver)

 

 

Pour implémenter BUFFER_RECEPTION, tu as plusieurs solutions : une file d'attente contenant les octets, un buffer circulaire, un buffer unique de 4096+41 octets et dans l'étape 4) tu copie les données restantes vers le début du buffer, ...

 

Si tu veux plus de précisions, n'hésite pas à demander

[Oliver17]

Bon ben maintenant faut que j'arrive à comprendre tout ça, c'est pas gagné.
Je savais bien qu'une sécurité serait utile pour la communication, mais bon, ceci dis cela résoudra t'il mon problème de latence ??
Car du coup on passe à un autre sujet ^^

[Sandro]

oui, ça devrait résoudre le problème de latence, car tu ne récupère plus seulement 40 octets mais tout ce qu'il y a : du coup, même si récupère les données un petit peu moins fréquement que tu ne les envois, tu te retrouvera juste à traiter deux paquets d'un coup de temps à autre (si tout vas bien, ta latence devrait être inférieure à 150 ms à vue de nez).

Si vraiment tu veux une latence très faible, il te faudra probablement changer de bibliothèque pour en utiliser une qui supporte a soit du polling sans delay entre, soit encore mieux qui fournit des intéruptions quand des données arrivent.

[Oliver17]

Ouais mais pour trouver une lib en C++ (ouais j'y tiens en C++) j'ai galéré, après si tu a mieux que la RS232 faut voir.

Mais il est fort possible que j'utilise mal la lib actuelle.

[Sandro]

Ta librarie m'a l'air d'être une librairie C plutôt que C++ (mais sauf rares exceptions une librarie C marchera sans le moindre problème en C++, éventuellemement en devant préciser " extern "C" "). Je dois avouer ne pas avoir fait de réception coté "ordinateur" pour de l'UART depuis très longtemps (quand je communique avec un raspberry Pi le plus souvent j'utilise l'I2C).

En C++, tu as par exemple la librairie de boost (https://www.boost.or...al_ports.html),après installer boost juste pour ça est un peu overkill (et je ne l'ai pas testé).

 

C'est quoi la latence maximale acceptable et la latence au dessous de laquelle tu considère que ça ne sert plus à rien de passer du temps pour essayer de la réduire?

 

Sinon, une question "bête" : est-ce que tu utilise les valeurs de tes capteurs I2C dans l'ESP? Car dans le cas contraire, autant les connecter directement à l'I2C du Raspi

[Oliver17]

Oui enfin je dis C++ mais C aussi ^^

J'étais tombé sur Boost mais ça me semble une usine à gaz, et comme tu le dis, juste pour ça, bof bof.

 

Ben pour moi, il ne devrait y avoir aucune latence.

 

Ben j'y ai pensé justement, mais on m'avait conseillé d'utiliser un arduino (ou autre) de mettre mes capteurs dessus et d'envoyer les informations à la PI, mais au final le micro contrôleur ne va plus servir à grand chose, ou alors juste pour les led's, car même l'écran ne servira plus vraiment, quoi que comme ça je pourrais remettre mes ventilos lol

 

Mais faire tourner l'imu 9250 et le VL53lx0 sur la PI en C/C++ va falloir encore faire des recherches, perso je voulais que la Pi serve juste pour les calculs, au final tout va se retrouver dessus, lol

 

Je crois que j'ai perdu énormément de temps avec ça...

[Sandro]

Si tu veux aucune latence (ou alors une latence minimale, car une communication instantanée, ça n'existe pas), alors il faut partir sur du polling en continu ou des interruptions : autrement dit, si le delai de 100ms est bien indispensable pour ta librairie, alors elle ne fera pas l'affaire (il y en a plein d'autres, mais je n'ai aucun retours dessus).

 

Si tu peux tout faire directement sur la Pi, alors je pense que tu as tout à y gagner (surtout si tu te préoccupe de la latence : un intermédiaire ne peut que l'augmenter).

 

En général, je dirais qu'avoir un arduino en plus d'une Pi peut être utile dans 3 situations :

- tu as besoins d'entrées/sorties qui ne sont pas disponibles sur la Pi ou pas en nombre suffisent (par exemple des entrées analogiques, ou plus que 1 PWM)

- tu veux faire un contrôle en temps réel strict : sur l'arduino, tu peux maitriser très précisément tes timings et être très répétable, alors que sur la Pi tu as un OS qui n'est pas conçu pour du temps réel, du coup tu peux avoir de petits décalages/délais (quand le thread de ton programme est mis en attente pendant qu'un autre programme tourne)

- tu veux utiliser des shields arduinos

 

Un 4ième cas, peut éventuellement être que tu veux utiliser un bibliothèque écrite pour arduino, ce qui est peut-être le cas ici (pour faire l'interface avec l'IMU par exemple). Mais tu peux en général assez facilement aller voir le code de la librairie arduino et l'adapter pour le raspberry pi. Dans le cas de l'IMU, tout ce que tu dois envoyer et recevoir via I2C est déjà écrit dans la bibliothèque arduino, du coup tu ne devrais pas avoir beaucoup plus à faire que recopier.

 

A noter que la Pi a aussi des portes d'entrée-sortie numérique, du coup tu peux sans problème l'utiliser pour allumer tes LEDs (par contre tu n'as que du 3.3V).

 

Pour l'écran, tu communiquais comment avec lui? si c'est par i2c, alors tu peux facilement continuer. Si c'est par des pins numériques "brutes", alors tu peux aussi, il faudra juste implémenter le protocol (si elles marchent en 3.3V, sinon il faut un level shifter)

[Thot]

Les capteurs VL ont souvent des soucis de bloquage ou de latences de ouf. Perso, j'utilise la version VL53L1X avec la librairie Arduino VL53L1X.h, il me semble que l'equivalent 0X existe.

Tu utilises quelle librarie pour le VL sur l'ESP ?

 

Perso, pour avoir testé le VL53L0X et le VL53L1X, le deuxième est beaucoup plus satisfaisant et plus fiable pour un coût equivalent, notamment en extérieur.

 

Voici un de mes codes qui utilisent quatre VL53L1X sur une Arduino Mega qui communique avec une Raspberry Pi. Je vais bientôt documenter "à quoi ça sert".

https://github.com/T...MVCA2/MVCA2.ino

[Oliver17]

Ben ce que je ne pige pas c'est que sur l'écran oled il n'y a aucune latence, et lorsque je compare en direct avec les données reçu sur la pi au bout d'un certains temps j'ai un gros décalage de plusieurs secondes (sur la pi).

 

J'utilise la lib d'adafruit car les autres ne fonctionnent pas sur l'esp. 

#include "Adafruit_VL53L0X.h"

 

Honnêtement cela devient pénible de tourner en rond, tout ça va finir dans un carton et je vais passer à autre chose (mode déçu).

 

Bref...

[Thot]

Ok, ce qui semble se passer, c'est que ton ESP envoie les données au Raspberry Pi plus vite que la Raspberry Pi ne les lit. Du coup, les données se mettent en buffer dans ta Raspberry Pi et cela entraine un décalage qui augmente dans le temps.

Il faut voir combien de fois par secondes tu envoies avec ton ESP et combien de fois par seconde tu lis le port Série sur la Raspberry. Mieux vaut trop lire le Port Série sur la Raspberry quitte à attendre un peu.

Le mieux est quand la Raspberry envoie un signal à l'ESP pour une demande de lecture. L'ESP renvoie ses données du moment.

En espérant que ça t'aide.

[Sandro]

Tu as essayé de réduire le délai du raspi à 80 ou 90 ms au lieu de 100?

[Mike118]

Ben ce que je ne pige pas c'est que sur l'écran oled il n'y a aucune latence, et lorsque je compare en direct avec les données reçu sur la pi au bout d'un certains temps j'ai un gros décalage de plusieurs secondes (sur la pi).

 

J'utilise la lib d'adafruit car les autres ne fonctionnent pas sur l'esp. 

#include "Adafruit_VL53L0X.h"

 

Honnêtement cela devient pénible de tourner en rond, tout ça va finir dans un carton et je vais passer à autre chose (mode déçu).

 

Bref...

 

 

C'est exactement pour ce genre de chose que je recommande de faire des projets petit à petit de plus en plus grand ... Faire un gros projet comme le tient en étant tout seul c'est difficile ... très difficile... Mais c'est pas impossible ... ça demande beaucoup de temps et de motivation ... Et surtout pour y arriver il faut être " méthodique" dans les étapes qu'on se fixe. Sinon il est facile de se démotiver et d'abandonner ... 

Exemple précis dans ton cas si j'ai bien compris, tu as plusieurs capteurs  et un écran qui sont reliés à un ESP32. 
Et l'ESP32 communique avec la raspberry pi. 

Une première étape est de savoir parfaitement faire fonctionner chacun des capteurs indépendamment sur l'ESP32. 
Une seconde étape est de savoir faire fonctionner les capteurs ensembles sur l'ESP32 ( Parfois tu peux avoir des incompatibilités entre les élément à causes d'adresses identiques sur un bus I2C par exemple ) . 
Une troisième étape est de savoir faire communiquer des info lambda avec la pi et ce sans latence. Pour tester cela tu peux faire en sorte d'envoyer des timestamp avec l'esp32 et les renvoyer par la pi et regarder si tu as du décalage temporel. 
La dernière étape une fois que tu as les trois que la seconde et la troisième fonctionnent parfaitement est de fuisonner le tout =) . 

Est ce que tu maîtrises pleinement les premières étapes ?


Après un autre trucs est d'éventuellement commencer par des trucs plus facile sur le robot, genre la tête qui bouge et la connecter de sorte à la faire parler voir mesurer des distances etc ...

[Oliver17]

Et bien déjà chacun en vous lisant à ça façon de voir les choses, certes très intéressant mais il est facile de se noyer avec ces informations, car dans quelle direction allez.

 

Ce qui serait intéressant c'est de montrer des exemples, quelque chose de concret similaire tout simplement à un échange de données entre PI et ESP (ou Arduino). (et sans utiliser Python, Path tu sors --> lol)
En vous lisant j'ai pu constater trois façons de faire, montrez moi concrètement en vous rappelant bien que je suis un amateur.

 

1 - Sandro : qui est d'ajouter au début de chaque paquet un octet constant (par exemple 42 ou autre), et à la fin du paquet une checksum (par exemple le xor de tous les octets du paquet), histoire que l'information arrive bien, le hic ça ne résoudra peut être pas ma latence, mais j'aime beaucoup l'idée de vérification.

 

2 - Thot : Que la Raspberry envoie un signal à l'ESP pour une demande de lecture. L'ESP renvoie ses données du moment.
Si j'ai bien compris, la PI interroge l'ESP pour une demande de lecture et si une nouvelle information est disponible l'ESP renvoie les données en cours...pourquoi pas, c'est une idée.

 

3 - Mike : en fait j'ai suivi les conseils de Mike que je ne remercierai jamais assez (ainsi que tous les membres qui participe de loin comme de prés), et j'ai appris aussi à associer une structure avec une union faisant office de buffer pour tout envoyer en un seul paquet toutes les informations voulu, si je ne dis pas de bêtise via la lib RS232, pourtant je trouve que ça fonctionne bien, juste cette latence, et donc je ne remet aucunement en cause la lib, ni même vos conseils, c'est juste moi qui patauge sans réussir à trouver du coup.
Et surtout sans trouver la bonne façon de faire.

 

Je reste tout de même super content car j'ai énormément progressé grâce aux membres du forum, j'y vais étape par étape etc etc, je sais que le projet peut sembler énorme mais c'est la seule façon pour moi d'apprendre, me donner de gros challenge, ceci dis (et là je rie tout seul lol) je ne cherche aucunement créer le super humanoïde de la mort qui tue, mais juste me faire plaisir avec ce p'tit robot, sinon j'aurai économisé pour acheter un NAO mais il aurait vite fini au placard (me connaissant), car je n'aurais pas réussi à exploiter comme il faut NAO.
 

@Mike : 

 

C'est exactement ce que je fais, j'essaye toujours de faire comme tu me l'a toujours dis, étape par étape

 

1 déjà fais avec tous les capteurs, écran ou autre led's.

 

2 c'est fais tout fonctionnent ensemble sur l'esp.

 

3 c'est là qu'il me faudrait quelque chose de concret, pour l'instant j'ai avancé avec l'aide que vous m'avez apporté sur l'utilisation de la lib RS232 je trouve que je m'en suis pas trop mal sorti pour un noob (sans prétention) grâce à vos conseils...je bloque surtout sur cette latence avec l'échange entre la Pi et l'ESP, car l'info en elle même lorsqu'elle apparaît sur l'écran oled brancher sur l'ESP je n'ai pas de latence, du moins c'est plutôt rapide.
Mais pour le test du timestamp je ne sais pas faire.
 

J'ai déjà fais plusieurs tests pour avoir un bon "échange" entre les deux cartes, ça me semblait pas mal...mais par la suite dans le temps et oui j'ai cette latence flagrante avec le VL par contre ce n'est pas flagrant sur l'IMU, le truc c'est qu'il faut respecter se temps entres les deux cartes de 100ms, donc si je place 90ms d'un coté et que de l'autre j'ai 100ms sans avoir testé, c'est clair que ça va merdouiller, je vous invites à lire les exemples ou à voir la lib si vous avez le temps.

 

Tout est déjà "fusionné", je ne sais pas si c'est bien ce que j'ai fais, mais bon, j'essaye aussi de me débrouiller tout seul pour éviter de poser une question tout les 4 matin en sachant qu'il faut juste réfléchir par moment un p'tit peu pour avoir la réponse, alors quitte à passer plusieurs jours pour une broutille la plus part je trouve la solution, même si ce n'est peut être pas la meilleur

 

Le seul truc que je test pour l'instant c'est via cet échange, je joue juste avec le capteur de distance je met la main devant et j’enlève, et c'est comme ça qu'au bout d'un moment je peux observer cette latence, alors jouer avec la tête et les servos j'y suis pas encore, tant que pour moi je n'aurai pas un échange comme il se doit

 

Après si vous voulez que je vous balances tout le code (zippé) pas de soucis, mais je pense que vous allez saigner des yeux en essayent de comprend le pourquoi du comment, ceci dis ce n'est pas non plus un code difficile à comprendre

Mais avant d'en arriver là, je pense qu'il doit y avoir une solution pour cet échange...

Merci ^^

[Sandro]

1 - Sandro : qui est d'ajouter au début de chaque paquet un octet constant (par exemple 42 ou autre), et à la fin du paquet une checksum (par exemple le xor de tous les octets du paquet), histoire que l'information arrive bien, le hic ça ne résoudra peut être pas ma latence, mais j'aime beaucoup l'idée de vérification.

En effet, la vérification seule n'apporte rien au problème de latence. La solution que je te suggérais était d'essayer de lire tout ce qu'il y a dans le buffer (ie jusqu'à 4096 octets), au lieu de juste la taille d'un paquet (ie 40 octets). ÇA, ça devrait résoudre le problème de latence (et avec cette technique, la vérification est nécessaire car sinon si tu commences dans un paquet tu prends le risque que toutes les données suivantes sont corrompues car tu garde l'offset).

Je veux bien te faire un code (avec arduino, j'ai pas ESP), mais ça devra malheureusement attendre la fin de la semaine prochaine (j'ai un ami qui arrive d'ici quelques minutes et qui reste jusqu'à jeudi, donc j'aurais probablement pas le temps).

 

 

J'ai déjà fais plusieurs tests pour avoir un bon "échange" entre les deux cartes, ça me semblait pas mal...mais par la suite dans le temps et oui j'ai cette latence flagrante avec le VL par contre ce n'est pas flagrant sur l'IMU, le truc c'est qu'il faut respecter se temps entres les deux cartes de 100ms, donc si je place 90ms d'un coté et que de l'autre j'ai 100ms sans avoir testé, c'est clair que ça va merdouiller, je vous invites à lire les exemples ou à voir la lib si vous avez le temps.

Une synchronisation entre 2 processeurs/controleurs basés sur un timing exact des deux cotés ne marchera jamais bien, car la mesure du temps n'est pas "exacte" (il y a toujours une petite erreur, et une bien plus grande sur le raspi, car le système d'exploitation n'est pas temps réel). Deux évènements prévus pour se dérouler au même instant ne se passeront jamais exactement au même instant (un instant étant infiniment court).

 

Pour rappel, coté arduino tu as un timer, donc tu as assez précisément 100ms entre 2 évènements. Sur le raspi, un cycle te prends le temps d'exécuter ton code (au pif 1ms) + le temps du sleep (100ms), soit 101 ms : tu n'est donc de toute façon pas synchronisé. A la limite, si tu utilisais un timer coté rapsi pour avoir "exactement" 100ms, alors je pense que tu garderas quelques centaines de millisecondes de latences mais que celle ci n'augmentera pas.

 

Si tu mets 90ms, je pense que ça vas marcher : tu auras alors 2 cas de figure :

- une nouvelle donnée est prête : dans ce cas tu vas la lire et la traiter

- pas de nouvelle donnée prête : tu sera dans le cas n=0, ou tu te contente de ne rien faire (tu lira la nouvelle donnée la fois d'après)

 

Donc s'il te plait, essaye avant de dire que ça ne marche pas. Je ne peux as garantir que ça marchera, mais je suis à 95% sur qu'en gardant les délais actuelles (et en ne lisant qu'un paquet à la fois) tu ne parviendra pas à faire marcher le code.

 

Une chose importante à savoir est que sur le raspi, tu as un buffer : du coup, rien ne t'oblige à lire les données au moment où elles arrivent, il suffit de les lire à un moment quelconque après qu'elles soit arrivées (il faut juste les lire avant d'avoir rempli le buffer, ie d'avoir accumulé 4096 octets non lus, sinon tu vas perdre les plus anciennes)

 

 

Bon, sur ce, je dois te laisser

[Thot]

Si tu mets 90ms, je pense que ça vas marcher : tu auras alors 2 cas de figure :

- une nouvelle donnée est prête : dans ce cas tu vas la lire et la traiter

- pas de nouvelle donnée prête : tu sera dans le cas n=0, ou tu te contente de ne rien faire (tu lira la nouvelle donnée la fois d'après)

 

Oui, juste ça, ce que ça donne, ça va aider.

[Mike118]

Je suis d'accord avec sandro et thot =)  et je pense que même si tu as bien avancé sur l'étape 3 elle n'était pas pleinement finie avant de passer à la fusion. 

Au risque de répéter ce qu'ils ont dit tous les deux : 

Le timing entre deux machine n'étant pas parfait tu ne peux pas dire : 

Ok une machine envoit une trame  de 100 octets toutes les  100ms donc je vais lire 100 octects toutes les 100 ms avec la machine qui va recevoir. 

En général tu as deux principales méthodes pour les envois de trames : 

La façon décrites pas thot : 
 

 

Thot : Que la Raspberry envoie un signal à l'ESP pour une demande de lecture. L'ESP renvoie ses données du moment.

Si j'ai bien compris, la PI interroge l'ESP pour une demande de lecture et si une nouvelle information est disponible l'ESP renvoie les données en cours...pourquoi pas, c'est une idée.

 

 

 

C'est aussi ce qui se fait en I2C, le maitre demande une info, l'esclave répond aussitôt juste ce qu'il y a de demandé. Dans ce cas tu peux chercher à lire que ce qui a été demandé.
C'est une méthode simple et efficace pour de la communication asynchrone. 

 

L'autre méthode : 

Le slave envoit ses données aussi vite qu'il le peut ( comme ce que fait un GPS par exemple ) Le master vient lire ce qui l'intéresse quand ça l'intéresse. Il faut donc qu'il soit capable de lire une trame dont le début peut être au milieu d'un flux de données. (d'ou l'usage d'un octet de start ) avec vigibot c'est exactement ce qu'on fait . 

Par contre dans ce cas là tu peux avoir beaucoup plus de données qu'une seule trame dans ton buffer. Il faut donc lire tout ton buffer pour le vider et pas juste la quantité d'octet que tu penses avoir besoin ...  

[Oliver17]

Ok, bon ben suis pas rendu avec tout ça