Ca ne démontre pas du tout que le programme arduino est affecté par la vitesse de transmission, ni que le problème soit du coté arduino.
Ok bidouilleelec; 
Peut tu me démontrer le contraire ?
Ma petites expérience précédente et mon expérience d'utilisation me disent le contraire.
Je recherche des infos concrètes à ce sujet.
Salutations.
Bonsoir manumanu,
manumanu:
Ok bidouilleelec;Peut tu me démontrer le contraire ?
Ma petites expérience précédente et mon expérience d'utilisation me disent le contraire.Je recherche des infos concrètes à ce sujet.
Salutations.
Après moultes essais, avec plusieurs afficheurs sur PC ( dont le mien , très rapide ???), je dois reconnaitre que j'ai plus que des doutes sur la possibilité (fiable) de l'Arduino Uno à transmettre à plus que 1000000 bauds.
Surtout avec des chaines de caractères.
Grosso modo : je pense que les soucis à 2000000 viennent de l'arduino.
Il y a quelques fils sur le web, en américain international, sur le sujet:
pas tout à fait simple à digérer.
Je vous prie d'excuser mes propos un peu rudes.
Quelque chose me trouble : en compilant votre programme (ou d'autres programmes ressemblants) avec l'option -O0, votre programme fonctionne sans curiosité d'affichage, à 20000000.
Mes meilleurs voeux
Cordialement,
bidouilleelec
bidouilleelec:
Bonjour bengloo59J'ai fait des essais avec ce programme (et une montre pour mesurer ) :
/*
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
pinMode(10, OUTPUT);
digitalWrite(10, LOW);
}
void loop() {
unsigned long i = 0;
delay(3000); // délai pour trouver la montre
digitalWrite(10, HIGH); // feu
time0 = micros();
while ( i < c_nboucle) {
i++;
Serial.println(i);
}
delta = micros() - time0;
digitalWrite(10, LOW);
Serial.println(i);
Serial.println("");
Serial.print(" delta = ");
Serial.print(delta / 1000);
while(1);
}
Avec ou sans moniteur série , que l'arduino (UNO) soit alimenté par USB ou le jack en 12v, et si l'Arduino est alimenté par le jack, que le cable USB soit connecté entre le PC et l'arduino ou non (ouf) : le temps d'exécution est strictement le même. Cordialement, bidouilleelec
oui, mais exécutez le même en supprimant le serial.println de la boucle while, et l'exécution sera plus rapide. c'est le sens de la question initiale, ou du moins telle que je la comprends
manumanu:
Ok bidouilleelec;Peut tu me démontrer le contraire ?
Ma petites expérience précédente et mon expérience d'utilisation me disent le contraire.Je recherche des infos concrètes à ce sujet.
Salutations.
C'est pas compliqué.
Coté arduino lorsque le buffer de transmission est plein. La fonction print est bloquée jusqu'à qu'il y ait de la place dans le buffer pour continuer l'émission. Donc au pire si tu as trop d'informations à émettre l'exécution de ton application sera ralentie mais les données sortiront toujours dans l'ordre.
Coté PC, si les données arrivent trop vite, il y a débordement du buffer de réception SUR LE PC. L'affichage est alors complètement incohérent.
Lorsque tu fais ça:
Serial.println("XXXXXXXXXXXXXXX");
delay(1);
Serial.println("XXXXXXXXXXXXXXX");
delay(1);
Serial.println("XXXXXXXXXXXXXXX");
delay(1);
Tu ralentis le flux de données qui arrivent au PC et donc tu limites (voir supprimes) l'engorgement du buffer de réception du PC.
Bonjour tous;
Je vous prie d'excuser mes propos un peu rudes.
Il n'y a pas de problème "bidouilleelec". Je n'y ai vu aucune "rudesse".
Merci de t'être penché sur la question et de ta réponse.
Cela relance ma curiosité.
si les données arrivent trop vite, il y a débordement du buffer de réception SUR LE PC. L'affichage est alors complètement incohérent.
Lorsque j'ai un débordement cela n'affiche rien ou parfois des petits carrées. J’obtiens cela en paramétrant le moniteur a une vitesse différente de l'Arduino.
Excusez moi j'ai encore du mal à comprendre...-suis têtu me faut du A+B -
Une transmission série s’effectue suivant un cadencement (en bauds/sec) configurable d'un éléments vers l'autre. Les deux équipements doivent avoirs la même vitesse de transmission réception.
Si en réception j'ai des données hasardeuses par débordement du buffer c'est que ma vitesse de traitement de données n'est pas compatible en réception. il y à donc une collision de données en réception. (peut y avoir aussi un problème de câbles connu en milieux industrie - longueurs.qualité de pose)
Dans ce cas les données entrant en "collisions" sont perdu et non placé en "buffer" et elle laisse sa place à la suivante si elle trouve un espace libre en buffer.
En toute logique les données arrivent dans l'ordre de traitement programme.
Donc si j'envoie "azertyuiop" et que le cas de collision est vrais sur quelques millisecondes j'aurais un truc du genre "azert__op" ou " - "azertop".
Or dans notre cas l'affichage des données est clair mais hasardeuse.
J'ai donc fait cette expérience sur la base de ChristopheFr à 2000000 bauds.
J'ai intégré des temps intermédiaire après chaque instructions de "Serial".
J'ai également numéroté chaque lignes et ajouté une ligne d'instruction "Serial+ Z" dans le "setup()".
void setup() {
Serial.begin(2000000);
Serial.println("MONITEUR PRET");
Serial.println("ZZZZZZZZZZZZZZ");
}
void loop() {
Serial.println("XXXXXXXXXXXXXXXXXXX1");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX2");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX3");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX4");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX5");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX6");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX7");
//delay(1);
Serial.println("XXXXXXXXXXXXXXXXXXX8");
//delay(1);
while (1);
}
Voici ce que j'obtiens sans delay().
MONITEUR P5
XXXXXXXXXXXXXXXXXXX6
XXXXXXXXXXXXXXXXXXX7
XXXXXXXXXXXXXXXXXXX8
XXXXXXXXXXXXXXX3
XXXXXXXXXXXXXXXXXXX4
XXXXXXXXXXXXXXXXXXX5
XXXXXXXXXXXXXXXXXXX6
XXXXXXXXXXXXXXXXXXX7
XXXXXXXXXXXXXXXXXXX8
Je constate ci dessus que dans le "setup()" la première ligne n'est pas complète.
La seconde "ZZ" n'est pas affiché.
Pour l'exécution du loop() la ligne "X1" et "X2" n'apparaissent pas, on commence par la ligne "X6" pour finir sur la "X8" en réinscrivant les lignes "X3" à "X8".
Si mon programme s'exécute dans le bon ordre pourquoi ce désordre ??? 
Surtout qu'après avoir exécuté la ligne "X8" il est sensé se bloquer dans while(1).
J'ai donc tour à tour lignes après lignes et l'un après l'autre activé delay(1). (pas tous en même temps)
Le résultat est bluffant. En activant le delay() à la 3 em ligne la lectures est bonne. Alors que sur les autres lignes c'est le KO.
Mais il est à noter que par moment cela ne marche pas si l'on ré-téléverse.(1fois/10)
L’insertion d'un delay() même "très petit" en temps permet un transfert gérable -si on peut dire stable-mais faut le placer au bon endroit.
Ce que je ne comprends pas c'est...
Si vous me dite que le programme s’exécute normalement pourquoi ne s’arrête t'il pas dans "while()" à la lecture de la ligne "X8" déjà transmise.
Alors j'ai baladé while(1) sous chaque lignes. J'ai mis un delay(10000) 1sec dans le setup().
Le résultat:
Jusqu'à la 6em ligne tout vas bien. Mais arrivé à la 7em !! Patatra !! rien en vas plus et de plus il commence par la ligne 7 et ne s'arrête pas dans while(1).
Ce que j'en déduis. C'est que les données envoyés envoyées à haute vitesse crée une "collision" au buffer qui exclu les 1er données reçu en surplus puis repasse par loop() pour finir l'exécution du programme et finir dans while(1).
J'ai validé cela en plaçant "Serial.begin(2000000);" dans loop().
Cela nous apprends t'il que les instructions comme while() -ou if()- ne sont pas activent tant que Serial() n'est pas exécuté sans faute ? Si le buffer est saturé on réactive la boucle "loop()". ?
Une chose est sur et je rejoint "bidouilleelec" sur ce point. Avec <=1000000 bauds tout vas bien !
En même temps qui travail a ces vitesse !!
En gros à ces vitesse il faut placer des "delay()" au bon intervalle pour avoir un affichage correcte de ses données.
Salutations.