J'ai remarqué une choses mais ça ne change pas le fonctionnement :
char value;
int a=0;
int b=0;
int c=0;
long time=0;
char t[15];
void setup() {
Serial.begin(38400);
}
void loop() {
while (Serial.available() > 0) {
value = Serial.read();
if (value =='T'){
a=0;
while (value !='U'){
value = Serial.read();
if (value !='U'){ // pourquoi mettre un if ? si le while est vrai le if aussi
t[a]=value;
Serial.print(value);
}
a++;
b=a;
c=a;
}
a=0;
while(a < c){
switch (b){
case 8:
time=+(t[a]*100000000);
case 7:
time=+(t[a]*10000000);
case 6:
time=+(t[a]*1000000);
case 5:
time=+(t[a]*100000);
case 4:
time=+(t[a]*10000);
case 3:
time=+(t[a]*1000);
case 2:
time=+(t[a]*100);
case 1:
time=+(t[a]*10);
case 0:
time=+(t[a]*1);
}
b--;
a++;
}
Serial.print(" time ");
Serial.print(time);
Serial.print(" time fin ");
Serial.println("stop");
time=0;
}
}
}
Par contre j'ai pas la longueur des long en tête mais est-ce que ça passe quand b = 8 ?
Sinon où est-ce que ça bloque plus précisément ?
Effectivement ça dépasse la capacité des long, mais normalement ça ne devrait jamais arriver jusqu'à la position 8.
J'ai un truc comme ça qui s'affiche en console :
ÿÿÿ538 time 50 time fin stop
ÿÿÿ555 time 50 time fin stop
ÿÿÿ571 time 50 time fin stop
ÿÿÿ587 time 50 time fin stop
ÿÿÿ604 time 50 time fin stop
ÿÿÿ620 time 50 time fin stop
ÿÿÿ636 time 50 time fin stop
ÿÿÿ653 time 50 time fin stop
ÿÿÿ669 time 50 time fin stop
ÿÿÿ685 time 50 time fin stop
ÿÿÿ701 time 50 time fin stop
Si je ne Reset pas la carte 1 la valeur time reste à 0.
Le if est nécessaire car entre le while et le if, la valeur a été changée par un nouveau read.
C'est normal que tu aies le yyy538 en début de ligne : comme tu écoutes "en espion" (j'ai oublié le terme exact) la ligne série, tu vois à la fois ce que la carte reçois et ce qu'elle envoie).
while (Serial.available() >= 3) {
if (Serial.read() == 0xff) { // le premier octet, équivalent à ton T
val = (Serial.read() << 8) | (Serial.read());
}
}
Je viens de faire un essai avec tes deux bouts de code....
Je me cassais les c....les pour pas grand chose...
J'ai pas tout compris ::), j'ai trouvé que << sert a décaler les bits, mais ça reste compliqué à comprendre pour moi.
Serait-il possible de commenter ce que ça fait (les deux séquences complètes), j'aimerais vraiment comprendre ça.
Est-ce possible de faire la même chose pour un long ?
Il faut juste me répondre par oui-non, car si c'est faisable j'aimerais trouver par moi-même si les premiers code me sont expliqués.
Si on doit envoyer par exemple 867, qui vaut en hexadecimal 0x0363
int val = 0x0363;
Serial.print(0xff, BYTE); // la valeur envoyée est 0xFF
Serial.print((val >> 8) & 0xFF, BYTE); // la valeur envoyée est 0x03
Serial.print(val & 0xFF, BYTE); // la valeur envoyée est 0x63
0x363 vaut en binaire 0000 0011 0110 0011
donc un décalage vers la droite (>>) de 4 va donner le binaire suivant : 0000 0011 0110 soit 0x036.
(Parenthèse, pour décoder une trame ASCII en nombre, plutôt que de passer par des multiplications par 1 000 000, il vaut mieux multiplier par 10. j'ai fait un petit exemple : Interface en ligne de commande - PoBot)
La première ligne, il a le même rôle que ton 'T', il est là pour identifier le début d'une trame (3 octets, le premier FF est non significatif).
Pour la présence du FF dans les deux lignes suivantes, je ne sais pas vraiment, c'est une habitude que j'ai vu.
EDIT : j'ai les réponses d'un des membres de Pobot
Serial.print( (val >> 8) & 0xff, BYTE);
Cela sert à être certain d'avoir un résultat après décalage sur un byte au cas où val ait été déclaré signé et que le bit de signe soit propagé par le shift.
Serial.print( val & 0xff, BYTE);
Cela sert à être certain d'avoir un résultat après décalage sur un byte.
En principe ça ne semble pas indispensable puisqu'on spécifie à print() que la donnée est sur un byte. Mais ça ne mange pas de pain au cas où on utilise autre chose comme fonction et qu'on oublie de forcer la taille de la donnée envoyée.
long val = 0x74CBB1;
Serial.print(0xff, BYTE); // la valeur envoyée est 0xFF
Serial.print((val >> 24) & 0xFF, BYTE); // la valeur envoyée est 0x0
Serial.print((val >> 16) & 0xFF, BYTE); // la valeur envoyée est 0x74
Serial.print((val >> 8) & 0xFF, BYTE); // la valeur envoyée est 0xCB
Serial.print(val & 0xFF, BYTE); // la valeur envoyée est 0xB1
Si je remplace BYTE par HEX, sur le moniteur série j'ai FF074CBB1, donc jusque là ça va.
Sur la carte Tx, je pensais qu'avec ce code j'arriverais à récupérer mes valeurs :
while (Serial.available() >= 5) { // 5 = 1 octet pour FF + 4 octets
if (Serial.read() == 0xff) { // le premier octet, équivalent à ton T
val = ((Serial.read() << 24) |(Serial.read() << 16))|((Serial.read() << 8) |(Serial.read()));
Serial.println(val,DEC);
mais cela ne fonctionne pas, la valeur retournée est -19969.
Pour voir ce que j'avais dans le flux, j'ai essayé de faire :
Serial.println(serial.read(),HEX)
Les 100 premières lignes j'ai :
FF
74
CB
B1
FF
74
CB
B1
FF
74
CB
Et ensuite je n'ai plus qu'une valeur qui est retournée :
Depuis la carte Rx j'envoie 987654321 et en lisant la carte Tx avec le moniteur la variable "valeur" affiche 987654321.
Si je fais "valeur+10" j'ai 987654331.
Par contre si quelqu'un a un tuyaux pour raccourcir tout ça ;).
Je viens de remarquer quelques chose, si j'envoie un nombre avec une série de F comme 7FAFFAF, la lecture n'est pas juste à chaque fois, je pense qu'il prend le FF du milieu comme balise de départ.
Oui, pas de problème. Normalement il n'y a pas de raison qu'il perde des caractères, mais si c'est le cas, il ne fera pas de distinction entre le FF du début et le FF en plein milieu.
Donc si j'ai bien compris, tu peux envoyer ceci :
FF 01 FF 32 1E
FF 04 23 60 AD
FF 03 C6 FF F3
mais si le premier octet n'est pas passé, il va jeter le 01 et tu vas te retrouver avec
FF 32 1E FF 04 --> faux
23 60 AD --> supprimé
FF 03 C6 FF F3 --> récupéré par chance
Il y a deux solutions :
allonger la chaine de reconnaissance et diminuer la probabilité de retrouver cette même séquence : soit FF FF, soit FA FA ou tout autre chaine selon les valeurs que tu envoie
utiliser un "CRC", une formule de vérification qui t'oblige à envoyer une valeur supplémentaire, et à faire un calcul sur les octets reçus puis comparer et ainsi vérifier que c'est toujours correct.