- Ce sujet est vide.
-
Messages
-
Attention la fonction flush censée vider le buffer du port série a changé depuis l’IDE 1.0. http://arduino.cc/en/Serial/Flushhttp://arduino.cc/en/Serial/Flush” class=”bbcode_url”> Afin de vider le buffer en entrée, vous pouvez remplacer vos appels à
Serial.flush()
par :
while (Serial.read() != -1);
Bonjour, En passant sur le site du ZERO, ils ont un forum et meme des cours sur l’arduino uno et autre
a voir cela pourra peut etre aider
De mon cote, je ne connais pas l’arduino, je pense que ce week end, je vais me pencher dessus (il annonce du mauvais temps et faire la feria sous la pluie c’est pas top)
A premiere vue, c’est du language c ou ca y ressemble, donc d’abord voir comment cela ce code et apres direction les manips
bon a plus tard, je dois me preparer pour aller au taf (la pluie est revenue, va faloir rouler avec prudence)
A bientôt
JASON64
Ce sont des données qui te sont destinées : pourquoi veux-tu les effacer ? Au pire, tu n’en tiens pas compte, mais dans ce cas celui qui te les envoie fait du boulot pour rien et cause dans le vide. Ou alors la problématique est plus complexe et il va falloir commencer à imaginer l’ajout d’un protocole (début de trame, fin de trame, éventuel CRC, …) dans le tuyau 
Je ne sais pas ce que tu faisais avec flush()… personellement je n’ai jamais utilisé cette fonction… mais as-tu essayé de gérer tes données entrantes avec serial.available() ?
Ca te permet de savoir combien il y a de données dans le buffer
et donc de les traiter à “ton rythme” avec par exemple:
int DonneeReception = 0; // Variable servant à réceptionner les données
void setup() {
Serial.begin(9600); // ouverture du port et initialisation à 9600 bauds
}
void loop () {
if (Serial.available() > 0) { // si des données entrantes sont présentes dans le buffer
// On lit les données réceptionnées:
DonneeReception = Serial.read(); // Ici on lit un entier à chaque cycle, si tu veux en lire plus d’un coup… libre à toi de gérer avec des boucles
}
}
Personnellement, j’ai fait l’équivalent de ce flush sur un client ethernet pour envoyer des données sur Cosm à partir d’une arduino et j’avais utilisé la boucle suivante pour “vider” ce que Cosm m’envoyait et le lire sur le terminal (but = débuggage); c’était de l’ethernet mais c’est exactement le même principe (remplacer “client” par “serial”):
while (client.available()) { //si il y a des données entrantes
char c = client.read(); // les lire
Serial.print(c); // les renvoyer vers le terminal
}
le JEDI receiver envoie en permanence toutes les 20ms 36 octets correspondants aux 6 voies du récepteur de la radio. donc soit on traite en permanence ces données (ça peut etre un peu stressant pour l’arduino, quoique je n’en sois pas certain)
soit on les traite à intervalles plus grands (par exemple 60ms ou plus, ou moins comme on le sent, à tester)
or le buffer de l’arduino a une taille limitée (64 octets dans la doc anglaise et 128 dans la française, trop forts
😡 )toute donnée arrivant une fois le buffer plein est ignorée
l’idée est donc à intervalles réguliers de vider le buffer pour lire les données les plus récentes qui arrivent
le problème de faire une boucle infinie de ce style
Code:if (Serial.available() > 0) { // si des données entrantes sont présentes dans le buffer
// On lit les données réceptionnées:
DonneeReception = Serial.read(); // Ici on lit un entier à chaque cycle, si tu veux en lire plus d’un coup… libre à toi de gérer avec des boucles
}étant que si le buffer n’est pas vidé avant les 20ms nécessaires à l’envoi de nouvelles données, on entre dans une boucle infinie
ce cas ne devrait pas se produire, mais tout ce qui est douteux est interdit dans mon code
après il y a bien entendu la possibilité de gérer un time out ou autre, mais au final j’ai peur que le code ne se retrouve plus lourd que dans le cas initial où on traite la totalité des données reçues.
Tout ça pour dire que c’est quand même scandaleux que le comportement d’une fonction soit redéfini sans renommage de cette dernière.
Une nouvelle fonction aurait dû être créée et la fonction flush conservée.
C’est ce qui est pénible dans ce genre de produits un peu open source à l’arrache, c’est qu’à chaque nouvelle version, il y a intérêt à faire des tests poussés de non régression sous peine de surprises…
Cela illustre tout à fait pourquoi je me refuse à confier le pilotage de mon droide par de telles cartes.
Le dome OK, mais les drives trop dangereux.
Je pense que j’attendrai donc une nouvelle release de l’IDE réintroduisant le flush.
Scott Gray doit également faire évoluer son protocole sur la carte JEDI receiver et les données envoyées seront plus light (divisées par deux de mémoire), je traiterai donc tout, cela reste le plus sûr.
Voici de quoi te satisfaire 
Code:
Dans le dossier : arduino-1.0/hardware/arduino/cores/arduinoFichier : HardwareSerial.h , ajouter cette définition
virtual void iflush(void);Fichier : HardwareSerial.cpp , ajouter cette fonction
void HardwareSerial::iflush()
{
_rx_buffer->head = _rx_buffer->tail;
}
Et maintenant tu as une belle instruction : Serial.iflush() qui fait exactement comme avant.Ah, et le buffer fait bien 64. Voir le fichier HardwareSerial.cpp ligne 59
Code:#define SERIAL_BUFFER_SIZE 64
Merci donc pour ces infos, je vais tester ça !
- Vous devez être connecté pour répondre à ce sujet.