Go Down

Topic: analyse de trame de 27 octets  (Read 4991 times) previous topic - next topic

medeloualidi

#30
Jun 29, 2016, 09:49 am Last Edit: Jun 29, 2016, 11:42 am by medeloualidi
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  ?!

J-M-L

Si vous ne pouvez pas changer le débit de 4800 baud, alors si vous pouvez calculer plus vite votre analyse ça devrait marcher
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

medeloualidi

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 ?!

J-M-L

Est-ce que l'émetteur dispose aussi d'un récepteur?
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

medeloualidi

Non la transmission se fait dans un seul sens

J-M-L

Que donne le calcul avec un processeur plus puissant?
Hello - Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums.
Bonjour Pas de messages privés SVP, postez dans le forum directement pour que ça profite à tous

kamill

#36
Jun 30, 2016, 05:22 pm Last Edit: Jun 30, 2016, 05:27 pm by kamill
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

medeloualidi

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();
}



Go Up