Bonjour à tous,
Question bête et méchante, comment arriver à mesurer l'intervalle de temps entre 2 bytes arrivant sur un port série d'une nano, sachant que l'interbyte moyen est de 32µs, que l'inter frame moyen est de 980µs et que l'inter stream moyen est de 120ms?
Je sèche!!!!
Merci d'un petit coup de pouce
voilà le sketch:
// UART------------------------
// Tx - Pin 9 - D6
// Rx - pin 10 - D7
// USB------------------------
// Tx - pin 1 - D1
// Rx - pin 2 - D0
// BIBLIOTHEQUES EXTERNES-----
#include <SoftwareSerial.h>
// VARIABLES--------------
byte InByte; // variable de stockage temporaire pour bytes
SoftwareSerial UART(7, 6); // Porte série K-Line (RX,TX)
long Time = 0; // stockage temporaire de temps
long TP = 0; // stockage valeur temps inter-bytes
void setup()
{
Serial.begin(115200); // initialisation port usb à 115200 bauds
while (!Serial) {
; // Attente pour connection port serie usb
}
Serial.println("Carte ok"); // Texte de confirmation carte prête
UART.begin(10375); // initialisation port UART à 10375 bauds
Time = micros();
}
void loop()
{
if (UART.available())
{
TP = micros() - Time;
InByte = UART.read();
Serial.print(InByte, HEX);
if (TP < 35 )
{
Serial.print(":");
Time = micros();
}
if (TP > 980 && TP < 1500)
{
Serial.print(";");
Serial.print("#");
Serial.print(TP);
Serial.print(";");
Time = micros();
}
if (TP > 2500)
{
Serial.print(";");
Serial.print("#");
Serial.print(TP);
Serial.println(";");
Time = micros();
}
}
}
pernowel:
Bonjour à tous,
Question bête et méchante, comment arriver à mesurer l'intervalle de temps entre 2 bytes arrivant sur un port série d'une nano, sachant que l'interbyte moyen est de 32µs, que l'inter frame moyen est de 980µs et que l'inter stream moyen est de 120ms?Je sèche!!!!
Merci d'un petit coup de pouce
bonsoir
Je n'ai pas bien compris ce que tu cherche à mesurer/verifier exactement.
mais si tu veux analyser des chronogrammes , un petit analyseur logique à qq € fera parfaitement l'affaire
Effectivement la demande d'explication n'est pas très clair.
Préalablement j'ai effectué une capture au saleae pour déterminer la fréquence du bus, voir le nombre de bit et donc par là même déjà décortiquer les bytes transitants. Comme je sniffe en paralèle, je n'ai pas la vision de qui envoi quoi sauf que le tester effectue le premier sa requete.
Une capture avec 3 degré de zoom
Après analyse des flux, je me suis aperçu que la seul façon de dissocier pour savoir ce qui est de l'ordre de la requête et de l'ordre de la réponse était d'établir une règle de temps pour fractionner. Avec un renvoi sur le moniteur série et avec un formatage type CSV, j'ai d'abord fait ce sketch avec le formatage en sortie: BYTE N; Temps BYTE N-1 - BYTE N (TP); (et avoir des colonnes pour tri sur excel).
// UART------------------------
// Tx - Pin 9 - D6
// Rx - pin 10 - D7
// USB------------------------
// Tx - pin 1 - D1
// Rx - pin 2 - D0
// BIBLIOTHEQUES EXTERNES-----
#include <SoftwareSerial.h>
// VARIABLES--------------
byte InByte; // variable de stockage temporaire pour bytes
SoftwareSerial UART(7, 6); // Porte série K-Line (RX,TX)
long Time = 0; // stockage temporaire de temps
long TP = 0; // stockage valeur temps inter-bytes
void setup()
{
Serial.begin(115200); // initialisation port usb à 115200 bauds
while (!Serial) {
; // Attente pour connection port serie usb
}
Serial.println("Carte ok"); // Texte de confirmation carte prête
UART.begin(10375); // initialisation port UART à 10375 bauds
Time = micros();
}
void loop()
{
if (UART.available())
{
TP = micros() - Time;
InByte = UART.read();
Serial.print(InByte, HEX);
Serial.print(";");
Serial.print("#");
Serial.println(TP);
Time = micros();
}
/*if (TP > 980 && TP < 1500)
{
Serial.print(";");
Serial.print("#");
Serial.print(TP);
Serial.print(";");
Time = micros();
}
if (TP > 2500)
{
Serial.print(";");
Serial.print("#");
Serial.print(TP);
Serial.println(";");
Time = micros();
}*/
}
Des flux j'ai extrait ceci
Carte ok
0;#22667124
81;#145084
13;#32
F7;#20
81;#24
C;#20
3;#4760
C1;#932
57;#24
8F;#20
AA;#36
2;#113072
10;#28
A0;#24
B2;#20
1;#7716
50;#20
51;#20
2;#113588
27;#28
1;#20
2A;#28
4;#9548
.......
En comparant logg saleae et csv, j'ai eu donc ma réponse:
la fonction .availlabe() monopolise le microcontroleur et donc le temps retourné est celui entre 2 bytes et non celui entre les 2 premiers bits.
Les temps son cohérents sauf quelques fois ou au lieu d'avoir 20 à 36 µs entre bytes, j'ai entre 924 et 1272 qui eux correspondent réellement au temps entre les 1er bits des Bytes entre requete et réponse mais décalé d'un byte.... (vous suivez?)
Donc en complément de ma demande sur l'analyse du code, y a t il un moyen de "sécuriser" le code pour ne pas avoir ses incohérences sporadiques?
Si ce n'est pas possible, j'ai toujours la possibilité d'édicter une regle de temps pour filter aussi ces valeurs car elles sont dans une fourchette assez restrainte.
L'étape suivante sera de fractionner le flux comme suivant:
si 19<TP<37 séparateur ":"
si 900<TP<1300 séparateur ":"
Si TP> 1300 séparateur ";"
pour avoir comme fichier csv en sortie:
B1:B2:B3:Bn:.....; TP;
A1;A2;A3;An:.....; TP;
......
pernowel:
(vous suivez?)
Bonjour,
Personnellement non, je ne suis pas du tout. Je n'ai rien compris à ce que tu veux faire.
j'ai 2 appareils qui communiquent entre eux sur un bus unifilaire à 10375 bauds moyen (UART)
la seule règle que je connaisse pour déterminer quel est le flux, c'est qu'un appareil communique avant l'autre d'ou: requête puis réponse.
Les requêtes ne font pas toutes 4, 5 ou 6 bytes, les réponses ont une longueur variable donc je ne peut pas compter les bytes pour déterminer quel est le sens du flux.
La seule règle intangible est d'effectuer une mesure de temps entre bytes et après traitement, définir un assemblage pour traitement par lot sous excel.
Ca c'est la phase 1
La phase 2
A partir des chaines de bytes, c'est de les décoder pour établir la localisation les données qui transitent (bytes variants).
Est-ce plus clair?
La je comprend mieux.
Et tu ne peux pas utiliser le protocole pour savoir combien d'octets sont émis dans chaque sens? car par exemple lors d'une requête le récepteur doit bien déterminer s'il doit recevoir 4, 5 ou 6 octets avant de répondre.
La je comprend mieux
Bonjour,
trop fort Kamil !
perso je n'ai toujours pas compris, dommage car j'ai certainement la solution
pernowel, je pense d'ailleurs que si exposait le pb de façon claire, tu finiras par comprendre et trouver la solution toi-même ...
pernowel:
j'ai 2 appareils qui communiquent entre eux sur un bus unifilaire à 10375 bauds moyen (UART)
la seule règle que je connaisse pour déterminer quel est le flux, c'est qu'un appareil communique avant l'autre d'ou: requête puis réponse.Les requêtes ne font pas toutes 4, 5 ou 6 bytes, les réponses ont une longueur variable donc je ne peut pas compter les bytes pour déterminer quel est le sens du flux.
La seule règle intangible est d'effectuer une mesure de temps entre bytes et après traitement, définir un assemblage pour traitement par lot sous excel.
Ca c'est la phase 1
La phase 2
A partir des chaines de bytes, c'est de les décoder pour établir la localisation les données qui transitent (bytes variants).Est-ce plus clair?
poste un fichier capture saleae (.logicdata)
on fait comment pour poster un fichier?
pernowel:
on fait comment pour poster un fichier?
perso , je n'utilise pas le gestionnaire de fichiers du forum
je passe plutôt par cjoint
un premier test avec wakeup patern