Arduino Forum

International => Français => Topic started by: medeloualidi on Jun 24, 2016, 03:00 pm

Title: analyse de trame de 27 octets
Post by: medeloualidi on Jun 24, 2016, 03:00 pm
Bonjour ArduinoTeam

Je travail sur un projet de communication numérique,  et j'essaye d'envoyer 27 octets sur le port série  chaque 90 ms dont le 'entête est de valeur 255, avec un débit de 4800 baud.

de l'autre coté le récepteur est une carte arduino uno, je veux savoir comment je peux stocker les 27 octetsdans un tableau une fois je reçois le premier byte qui est de valeur 255,??

 quelqu'un a une idée svp ??!!!! :)
Title: Re: analyse de trame de 27 octets
Post by: -Standby on Jun 24, 2016, 03:41 pm
Il y a un peut un manque de motivation.

Ecrire une valeur dans un tableau n'est pas compliqué, incrémenter l'index d'un tableau non plus, comparé une valeur non plus.
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 24, 2016, 03:51 pm
Ah Non ne dis pas ça ... j'ai déjà essayé pas mal de solution mais je trouve toujours un décalage au niveau de la trame reçu, comme celui la par exemple

Code: [Select]

#include "TimerOne.h"

boolean readyToRead = false;

void setup() {
  Serial.begin(4800);// put your setup code here, to run once:
  //Serial.setTimeout(100);
}

void loop() {
 Serial.flush();
 
  //unsigned long duree = micros();
  int duree = micros();

  boolean bitArray[200];
  boolean datar[208]; 
  int i = 0;
  byte received;
  while (Serial.available() > 0 && !readyToRead)
  {
    byte b = Serial.read();
    delayMicroseconds(100);
    if (b == 255)
    {
      readyToRead = true;

    }
  }
  if (readyToRead)
  {
    while ( (Serial.available() > 0 ) && (i < 25))
    { // esayer avec 26
     
      received = Serial.read();
      delayMicroseconds(100);
     
      //Serial.print(received, HEX);
      //Serial.print(" ");

      for (int bit = 0; bit <= 7; bit++)
      {
        if (received & (1 << bit)) {
          bitArray[bit + i * 8] = 1; // add true to array
        }
        else {
          bitArray[bit + i * 8] = 0; // add alse to array
        }
        //Serial.print(bitArray[bit + i * 8]);
      }
      i++;

      if ( received == 144)
      {
        readyToRead = false;
        Serial.flush();

      }
    }
  }

Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 24, 2016, 03:55 pm
Bonjour,

Ton programme m'a l'air super compliqué
La méthode suivante devrait fonctionner
Code: [Select]
void loop() {
  static byte buffer[27];
  if (Serial.available())
  {
    Serial.find(255); // attend l'octet de début
    buffer[0]=255;    // range le premier octet
    Serial.readBytes(buffer+1, sizeof buffer - 1);  // lit les 26 octets suivants
  }
}
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 24, 2016, 04:30 pm
Oh! Merci  mais une question svp
Code: [Select]
Serial.readBytes(buffer+1, sizeof buffer - 1); qu'est ce qu'elle renvois  ???  et j'espère que
Code: [Select]
   for (int i = 0; i < sizeof(buffer); i++) {
      Serial.print(buffer[i]);
    }


print bien ce que je reçois dans le moniteur série
Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 24, 2016, 04:46 pm
Oui, ça doit afficher les octets que tu as reçu, mais tu ne dois pas voir grand chose si tu ne sépares pas tes octets à l'affichage.
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 24, 2016, 05:36 pm
j'ai essayé avec ça,  mais il affiche une sel fois des octets que je n'ai pas envoyé
Code: [Select]


void setup() {
  Serial.begin(4800);// put your setup code here, to run once:
  //Serial.setTimeout(100);
}

void loop() {
 
   byte buffer[26];
   
  if (Serial.available()>0)
  {
    Serial.find(255); // attend l'octet de début
    buffer[0] = 255;  // range le premier octet
    Serial.readBytes (buffer + 1, sizeof(buffer) - 1); // lit les 26 octets suivants
  }
   for (int i = 0; i < sizeof(buffer); i++) {
      Serial.print( buffer[i]);
      Serial.print(" ");     
    }
    Serial.print("\n");
  delay(1000);
 
}
Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 24, 2016, 05:48 pm
L'affichage doit être dans le if {} après la réception
Code: [Select]
void loop() {
  byte buffer[27];

  if (Serial.available() > 0)
  {
    Serial.find(255); // attend l'octet de début
    buffer[0] = 255;  // range le premier octet
    int nbOctets=Serial.readBytes (buffer + 1, sizeof(buffer) - 1); // lit les 26 octets suivants
   
    for (int i = 0; i < nbOctets+1; i++) {
      Serial.print( buffer[i]);
      Serial.print(" ");
    }
    Serial.print("\n");
  }
  delay(1000);
}


buffer doit avoir 27 octets et non 26
j'ai amélioré un peu le programme en testant le nombre d'octets reçus
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 24, 2016, 08:26 pm
Est ce que t'as jamais essayer ça ??!! parceque ça n'a pas marché pour moi :(
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 02:22 am
Il est important de comprendre que Serial.find(255) n'attend qu'une seconde par défaut - le timeout peut être réglé Dans le setup avec un appel à setTimeout() (https://www.arduino.cc/en/Reference/StreamSetTimeout)

donc il serait bien de faire

If (Serial.find(255)) {...}
Plutôt que de croire aveuglément qu'on a bien reçu 255 une fois que l'appel à la fonction retourne.

De même

Code: [Select]
Serial.readBytes (buffer + 1, sizeof(buffer) - 1);


Peut retourner avant d'avoir lu les 26 octets si timeout

Le mieux c'est vraiment d'avoir un index x (initialisé à 0), et un booléen de début de trame qui indiquera si on a reçu le premier 255 (initialisé  à faux)

créer  un boucle générale infinie qui contient:
  si une donnée est dispo sur la ligne série
     On lit 1 caractère (byte)
     Si on a déjà reçu 255 (test du booléen)
          rajouter le caractère au buffer en position x,
           passer à x+1,
           si x vaut 26 alors on a tout reçu on fait un break; pour sortir de la boucle infinie
      Sinon  on n'a pas encore reçu 255 alors
           on teste si le caractère reçu vaut 255 et  si oui
                  on met le booléen  vrai pour dire que c'est bon on a reçu 255,
                   on met x à 0
            et sinon on ne fait rien et on retourne à la boucle infinie en attente du prochain charactere


L'amélioration suivante de cet algorithme c'est de rajouter la gestion d'un temps d'attente max éventuellement au début de la boucle infinie et faire un break si le temps max est atteint avec bien sûr un booléen supplémentaire qui dira qu'on n'a pas tout reçu alors que si on a bien tout reçu on le met à vrai


Voilà - reste plus qu'à coder

Vous essayez?

Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 25, 2016, 09:29 am
Bonjour,

Apparement Serial.find() n'a pas l'air de fonctionner avec des caractères >127. Je te propose le code suivant en remplacement:
Code: [Select]
void loop() {
  static byte buffer[27];
 
  if (Serial.available() > 0)
  {
    byte octet=Serial.read();
    if (octet==255)
    {
      buffer[0] = 255;  // range le premier octet
      int nbOctets = Serial.readBytes(buffer + 1, sizeof buffer - 1); // lit les 26 octets suivants

      for (int i = 0; i < nbOctets+1; i++) {
        Serial.print(buffer[i]);
        Serial.print(" ");
      }
        Serial.print("\n");
    }
  }
}
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 10:37 am
Merci J-M-L, c'est presque le même algorithme que j'ai essayé avant de poster mon problème, mais l'idée de kamill   a l'aire qu'elle donne des bonnes résultats aussi sauf que dès fois je reçois une trame correcte dès fois non, pour moi je veux faire la transmission chaque 100 ms, voilà ce qu'il m'affiche

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 31 80 116 133 176 122 46 153 144 92 12 201 144 255 137 168 176 219 14 165 12 232 154 153 trame fausse
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 144 92 12 201 144 255 137 168 176 trame fausse
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 168 176 219 14 165 12
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 165 12 232 154 153 43 32
255 137 168 176 219 14 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 255 137 168 176
255 137 80 116 133 176 122 46 153 144 92 12 201 144 255 137 168 176 219 14 165 12 232 154 153 43
255 153 144 92 12 201 144 255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 255 137 168 176 219 14 165 12 232 154
255 137 168 176 219 14 165 12 232 154 153 43 32 31 255 137 168 176 219 14 165 12 232 154 153 43
255 137 168 176 219 14 165 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 43 32 31 80 116
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 80
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144

Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 10:50 am
Est ce que c'est un problème de synchronisation parce que j'envoie la même trameà chaque fois qui commence par 255 et finit par 144

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 10:53 am
les communications séries sont asynchrones par nature. utiliser Serial.readBytes comme le propose Kamill pour lire d'un coup les 26 octets arrivant ensuite est séduisante mais dépendante du timeout implicite de la fonction Serial.readBytes qui est de 1 seconde. Si pour une raison ou pour une autre les 26 chars n'arrivent pas en une seconde, votre trame sera incomplète. si en plus vous n'avez pas vidé le buffer et que vous l'imprimez en entier (pas ce que Kamill fait cependant, je ne sais pas si c'est le code que vous utilisez) alors vous allez imprimer des données que vous n'avez pas vraiment reçu. il faut donc penser à remettre le buffer à zéro.

je pense que gérer manuellement 1 par 1 les octets quand ils arrivent va vous donner plus de contrôle sur ce qu'il se passe.
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 11:01 am
à quelle vitesse envoyez vous la trame? est-ce que les 2 ports séries sont bien calés sur la même vitesse en BAUD? au début je vois que vous utiliser 4800 comme vitesse de communication

à 4800 bauds vous envoyez environ 480 characters par seconde donc en 100ms vous pouvez envoyer 48 octets environ. ça peut sembler suffisant puisque vous n'envoyez que 27 éléments mais ensuite votre programme imprime

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144

soit 95 caractères. c'est bufferisé et ça peut répondre vite comme ça peut attendre si le buffer d'entrée est plein - et comme vous lisez à 480 caractères par seconde mais écrivez ça 10 fois par seconde (puisque vous envoyez une trame toutes les 100ms) vous essayez de mettre dans le buffer 950 caractères par seconde... le Serial.print devient alors en fait bloquant et vous commencez à accumuler du retard pour revenir lire les 27 éléments suivants car le buffer d'entrée se remplit (et overflow possible) en attendant.


quel outil utilisez vous pour envoyer votre trame? pouvez vous passer à 115200 bauds la fois côté émetteur et récepteur juste pour voir ce que ça donne ou vérifiez les octets dans votre programme et n'imprimez que OK si c'est bien la bonne trame reçue pour ne pas surcharger le buffer
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 11:15 am
Exactement t'as raison J-M-L  lorsque je passe à un débit élevé je trouve la bonne trame à chaque fois

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144


c'est le code de kamill que j'ai utilisé

mais pour le cas de mon application je dois pas dépasser 4800 baud :/ est ce qu'il y a une solution ?
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 11:41 am
oui exactement lorsque j'augmente le debit je trouve des bonne résultat !

par contre mois j'envoie 26 octets à un debit de 4800 bit/s ce qui donne le temps de transmission est de 26x8/4800 =43,33 ms .

à l'émission
Code: [Select]


Serial.write((unsigned byte)255);

  for (int i = 0; i < 25; i++)
  {

  Serial.write((unsigned byte)pac[i]);
 
  }



sinon si je veux transmettre pendant ces 43 ms les 26 octets chaque 100 ms qu'est ce qu'il faut ajouter à ce programme ?
Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 25, 2016, 11:57 am
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
255 137 31 80 116 133 176 122 46 153 144 92 12 201 144 255 137 168 176 219 14 165 12 232 154 153 trame fausse
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 144 92 12 201 144 255 137 168 176 trame fausse
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144 trame correcte
Tu envoie toujours la même chose ?
Si c'est le cas, je pense que ce n'est pas un problème du programme de réception, mais plutot un problème de transmission (parasites, problème de niveau, problème de baudrate...)

C'est quoi l'émetteur?
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 12:07 pm
Tu envoie toujours la même chose ?
Si c'est le cas, je pense que ce n'est pas un problème du programme de réception, mais plutot un problème de transmission (parasites, problème de niveau, problème de baudrate...)

C'est quoi l'émetteur?
l'émetteur c'est un diode IR pilotée par une carte arduino et je ne dois pas dépasser 4800 baud sinon la diode va être grillée
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 12:13 pm
L'envoi d'un octet est toujours accompagné d'un bit de start et d'un bit de stop, ce qui fait 10 bits au total. Donc l'envoi de 26 octets prend au moins 10x26/4800 = 54,17 ms.

Le code que tu indiques mets les 26 octets dans le tampon. L'envoi de ces octets est ensuite réalisé pratiquement sans attente. La période d'envoi des trames de 100 ms ne dépend que du reste du programme.

Mais si la perte des octets persiste alors que les trames sont envoyées toutes les 100 ms, alors c'est à la réception que le problème doit être réglé.
pourquoi 10x26 .. t'as ajouté les 2 bits de RS232 c'est ça ?
Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 25, 2016, 12:14 pm
Bonjour _pepe_,

Je n'ai pas très bien compris ce que tu veux dire, mais quand tu parles d'émission, je me dis que c'est peut être effectivement l'émission (pour affichage de vérification) qui perturbe la réception. En effet on envoie entre 2 et 4 fois plus d'octets qu'on en reçoit et peut être que le temps d'émission fait que le buffer de réception finit par saturer.
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 12:43 pm
@medeloualidi

si vous enlevez les traces de debug - toute la partie qui imprime tous les code sur la console alors vous n'aurez sans doute plus de pb

à 4800 bauds vous envoyez 480 octets par seconde, comme vous voulez envoyez vos 27 octets 10 fois par seconde, ça veut dire que vous envoyez 270 octets par secondes et avez la capacité d'en lire 480. ça devrait tenir sans pb si le reste du code côté récepteur ne bloque pas trop longtemps (ce que vos print sur la console faisaient).

l'émetteur de vos 27 caractères va prendre disons 30ms en arrondissant puis va re-émettre 70ms plus tard (si le premier octet est envoyé toutes les 100ms).

Donc côté récepteur vous êtes bloqué pendant 50ms pour recevoir tous les octets et vous devez être prêt à recevoir de nouveaux octets 50ms plus tard. Donc en gros il faut que votre code côté récepteur gère tout ce qu'il doit faire en moins de 40ms après avoir reçu une trame par exemple comme ça vous avez 10ms d'avance pour attendre la trame suivante ce qui devrait être suffisant pour éviter tout pb.

la question est donc: que devez vous faire une fois que vous avez reçu cette trame et est-ce que c'est exécutable en 40ms?



Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 12:50 pm
@medeloualidi

si vous enlevez les traces de debug - toute la partie qui imprime tous les code sur la console alors vous n'aurez sans doute plus de pb

à 4800 bauds vous envoyez 480 octets par seconde, comme vous voulez envoyez vos 27 octets 10 fois par seconde, ça veut dire que vous envoyez 270 octets par secondes et avez la capacité d'en lire 480. ça devrait tenir sans pb si le reste du code côté récepteur ne bloque pas trop longtemps (ce que vos print sur la console faisaient).

Envoyer l'émetteur de vos 27 caractères va prendre disons 30ms en arrondissant puis va re-emetter 70ms plus tard (si le premier octet est envoyé toutes les 100ms).

Donc côté récepteur vous êtes bloqué pendant 30ms pour recevoir tous les octets et vous devez être prêt à recevoir de nouveaux octets 70ms plus tard. Donc en gros il faut que votre code côté récepteur gère tout ce qu'il doit faire en moins de 50ms après avoir reçu une trame par exemple comme ça vous avez 20ms d'avance pour attendre la trame suivante ce qui devrait être suffisant pour éviter tout pb.

la question est donc: que devez vous faire une fois que vous avez reçu cette trame et est-ce que c'est exécutable en 50ms?




une fois je reçois cette trame (qui est codé avant l'émission ) je fait le décodage .. je ne sais pas combien du temps prendre  l'exécution du code de décodage ... peut etre je dois faire ça pour mesurer le temps de decodage
Code: [Select]

duration = micros();
decodage();
duration = micros() - duration;
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 01:16 pm
@ J-M-L

Merci pour votre aides les amis, apparemment oui c'est exécutable en moins de 50 ms
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 01:20 pm
oui par exemple juste pour le debug - ça vous donnera une idée

vous pouvez utiliser milli() plutôt que micros(), pas besoin d'être précis à la microseconde près...

Code: [Select]
unsigned long duration;

....


duration = millis();
decodage();
duration = millis() - duration;
if (duration > 50) { // on a pris plus de 50ms
      Serial.print("Attention calcul trop long: ");
      Serial.print(duration);
      Serial.println(" ms"");
}



comme ça vous n'imprimez que si vous prenez plus de 50ms et sinon vous n'imprimez rien. bien sûr appeler millis() (soit 4 microsondes) deux fois faire une soustraction et un test prend un peu de temps en plus... mais pas trop juste quelque microsondes. ce qui serait pas bien c'est d'imprimer la duration à chaque fois

Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 01:26 pm
Petite correction effectivement à 4800 bauds il faut plutôt 50ms pour émettre les 27 octets donc il faut que votre code tourne en moins de 40ms pour avoir 10ms d'avance sur la prochaine trame. (en fait avoir 1ms d'avance serait suffisant, on joue la sécurité là avec 10ms)


donc changer les 50ms en 40ms ci dessus pour voir si vous êtes tranquille ou pas pour l'exécution de votre code
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 01:37 pm
ah! non haha il tourne en 47 ms si ma méthode de mesure est correcte.

Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 25, 2016, 03:38 pm
@ _pepe_ 

oui t'as raison , lorsque je fait un delay(200); à l'émission   je reçois la trame tel qu'elle est, par contre lorsque je fait un delay(150); je e reçois pas ce que je veux

En tout cas merci beaucoup pour vos réponses, j'ai bien compris le problème je vais penser à une autre solution pour coder mes donnée et réduire la taille de la trame à envoyer.

avez vous une idée sur le CRC-8 pour coder 5 nombre de type float ? (c'est mieux de créer un nouveau Topic :p)   
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 25, 2016, 04:52 pm
En tout cas merci beaucoup pour vos réponses, j'ai bien compris le problème je vais penser à une autre solution pour coder mes donnée et réduire la taille de la trame à envoyer.
la question est vraiment de savoir si vous avez besoin d'envoyer toutes les 90ms. c'est quoi comme émetteur (qu'est-ce que vous mesurez et est-ce que ça change si souvent que ça?)

Si une seule ou peu des 27 valeurs changent de temps en temps, il serait plus efficace d'envoyer une trame un peu plus compliquée mais qui aura l'avantage d'être plus rapide

vous envoyez FF
vous envoyez le nombre de valeur qui ont changé
Pour chaque valeur qui a changé vous envoyez sa position entre 0 et 25 puis la valeur

si vous avez 5 valeurs qui ont changé par exemple ça ne fait envoyer que

255 5 Pos1 Val1 Pos2 Val2 Pos3 Val3 Pos4 Val4 Pos5 Val5

soit 12 octets au lieu des 27

si plus de 12 valeurs on changé alors il vaut mieux renvoyer toute la trame

donc côté réception si le chiffre après 255 est 26 alors vous savez qu'il n'y a pas de positions et  que c'est toute la trame. (et c'est ce que vous faites lors de la première trame)

avez vous une idée sur le CRC-8 pour coder 5 nombre de type float ? (c'est mieux de créer un nouveau Topic :p)   
jetez un oeil ici (http://dvsoft.developpez.com/Articles/CRC/)
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 26, 2016, 02:01 pm
la question est vraiment de savoir si vous avez besoin d'envoyer toutes les 90ms. c'est quoi comme émetteur (qu'est-ce que vous mesurez et est-ce que ça change si souvent que ça?)

Si une seule ou peu des 27 valeurs changent de temps en temps, il serait plus efficace d'envoyer une trame un peu plus compliquée mais qui aura l'avantage d'être plus rapide

vous envoyez FF
vous envoyez le nombre de valeur qui ont changé
Pour chaque valeur qui a changé vous envoyez sa position entre 0 et 25 puis la valeur

si vous avez 5 valeurs qui ont changé par exemple ça ne fait envoyer que

255 5 Pos1 Val1 Pos2 Val2 Pos3 Val3 Pos4 Val4 Pos5 Val5

soit 12 octets au lieu des 27

si plus de 12 valeurs on changé alors il vaut mieux renvoyer toute la trame

donc côté réception si le chiffre après 255 est 26 alors vous savez qu'il n'y a pas de positions et  que c'est toute la trame. (et c'est ce que vous faites lors de la première trame)

Bonjour J-M-L ,

Oui c'est une très bonne idée mais la trame change à chaque fois car la charge utile sont des valeurs des différentes capteurs qui génèrent des valeurs float sur 4 octets, le débit c'est exigé par le récepteur (une diode IR + démodulateur+ filtre ), les 100 ms sont donné par le CDC

Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 29, 2016, 09:49 am
Bonjour J-M-L

J'ai une proposition pour le problème du temps de traitement du programme,

Si je change ma carte arduino uno(16 MHz) par une carte Arduino Zero (48MHz), est ce que ça résoudra le problème  ?!
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 30, 2016, 10:32 am
Si vous ne pouvez pas changer le débit de 4800 baud, alors si vous pouvez calculer plus vite votre analyse ça devrait marcher
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 30, 2016, 10:58 am
j'ai pu optimiser mon programme d'émission de tel façon que je reçois

255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
 
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
 
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
 
255 137 168 176 219 14 165 12 232 154 153 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116


Comment je peux vider ou réinitialiser le buffer  après 3 itérations ?!
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 30, 2016, 11:37 am
Est-ce que l'émetteur dispose aussi d'un récepteur?
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jun 30, 2016, 11:42 am
Non la transmission se fait dans un seul sens
Title: Re: analyse de trame de 27 octets
Post by: J-M-L on Jun 30, 2016, 05:08 pm
Que donne le calcul avec un processeur plus puissant?
Title: Re: analyse de trame de 27 octets
Post by: kamill on Jun 30, 2016, 05:22 pm
Bonjour,

Excusez moi, mais je ne comprend pas de quoi on parle.
Si on reçoit une trame toutes les 90ms, on a 90ms pour faire le calcul (moins les quelques dizaine de micros secondes consommée par l'interruption de réception de caractère)
Donc en admettant que le décodage prenne 47ms (ce qui parait énorme car en 47ms on a le temps d'en faire des calculs sur une uno), il n'y a pas de problème.

Depuis le début tout le monde te dis que le problème est l'affichage de debug. Comment as tu pu afficher ce que tu reçois ici?
Quote
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
 
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
 
255 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116 133 176 122 46 153 144 92 12 201 144
 
255 137 168 176 219 14 165 12 232 154 153 137 168 176 219 14 165 12 232 154 153 43 32 31 80 116
Title: Re: analyse de trame de 27 octets
Post by: medeloualidi on Jul 01, 2016, 03:11 am
Bonsoir tout le monde,

J'ai pas encore essayé avec un processeur plus perforement,

Je fait l'affichage sur le moniteur série (Serial.print ()) de latrame reçu.

Je pense que t'as raison Kamil. Maintenant j'ai trouvé une idée qui marche très bien c'est que une fois je reçois la trame et je la stocke (je fait l'affichage aussi) je vide le buffer de réception(l'initialise) pour qu'il soit prêt pour la trame suivante.

je fait un simple appel de cette fonction après Serial.readBytes()

Code: [Select]

void flushReceive() {
  while(Serial.available())
  Serial.read();
}