C'est qu'un exemple mais je pense que ça peut se faire, sinon, je part avec des valeurs fixes. Genre on envoie <00000000000000000000> On sait qu'on a une balise entrante, 20 caractères, balise fermante. Si on a une liaison défectueuse, à ce moment là, la uno aquite le défaut et passe en mode sécu. Vidage du ballast, mise en marche des feux d'erreurs.
Le code ci-dessus ne permet pas de se synchroniser en cas de perte de synchro.
Si les messages sont assez peu réguliers, le temps entre les messages peut suffir à se recaler.
Mais les messages arrivent à un rythme soutenu il faut d'abord chercher la synchro sur le marqueur de début.
Il est bien d'avoir un charactère de début et un différent pour la fin.
Que ce soit '[' et ']' comme ci-dessus ou par exemple '$' et '\n' dans les trames NMEA.
Comme dans beaucoup de cas, une solution propre et fiable passe par l'implémentation d'un automate simple.
Par exemple (code non testé car je suis en déplacement mais l'esprit y est):
// Variables globale
enum E_State { ATTENTE_SYNCHRO, LECTURE_MESSAGE } State = ATTENTE_SYNCHRO;
#define CHAR_DEBUT '['
#define CHAR_FIN ']'
String message;
int messageRecu = false;
// fonction a intégrer dans loop() ou dans serialEvent()
reception_serie()
{
while ( Serial.available() )
{
char c = Serial.read();
switch ( State )
{
case ATTENTE_SYNCHRO:
// Caractère de début : on commence a recevoir un nouveau message
message = "";
State = LECTURE_MESSAGE;
break;
case LECTURE_MESSAGE:
switch ( c )
{
case CHAR_DEBUT:
// Si on reçoit le caractère de debut, on repart sur un nouveau message
// Si un message était déjà en court de réception mais que l'on a perdu
// le caractère de fin, alors on poubellise le message incomplet car
// il est probablement inexploitable.
// Une autre politique peut être de considérer qu'un caractère de début
// en plein milieu d'une reception en cours agit à la fois :
// - comme un caratère de fin et lance le process de traitement du message
// - et comme un début de nouveau message
message = "";
State = LECTURE_MESSAGE;
break;
case CHAR_FIN;
// on signale a la boucle de traitement qu'il y a un message a traiter
messageRecu = true;
break;
default:
// tout autre caractère est ajouté au message en court
message += c;
}
}
}
}
// Fonction de traitement des messages, a intégrer dans loop()
traitement_message()
{
if ( message_reçu )
{
// faire le boulot ici d'analyse du message
// notez que les characteres de début et fin ne sont plus dans le message
}
}
Pour info, l'utilisation de la classe String ci-dessus, bien que simplifiant le code n'est pas une bonne idée dans la pratique car le fait d'ajouter caractère par caractère va faire une utilisation abusive d'allocation/re-allocation dynamique de mémoire.
Il est plus efficace d'utiliser un tableau de char dimensionné suffisamment pour les message le plus grand et de gérer le non débordement de ce message.
Si besoin je peux revenir sur le code ci-dessus avec une telle méthode.
Si le code de réception est dans loop() (et non pas dans serialEvent()) alors il est possible d'appeller la fonction de traitement directement depuis le case CHAR_FIN.
Sinon, et si les messages peuvent arriver rapidemment, il peut etre prudent de gérer une FIFO de messages pour éviter que le message en cours de traitement soit effacé par un nouveau arrivant.
Mais comme l'Arduino n'est pas nativement multitâche ca ne devrait pas se produire.
Oui, je suis d'accord avec toi. Mais je voulais d'abord validé le fait que la communication fonctionnais.
Maintenant que je sait comment émettre puis recevoir, il faut que je normalise. C'est vrai que Moteur et Light c'est pas le même nombre de caractère. Envoyer des chiffres, berc, incomprehensible alors que l'on peut se permettre mieux.
J'ai regardé ton code, wah, il est lourd et complet. Je voudrais vraiment simplifier.
Ok pour un tableau de char mais alors, il faut régler le souci des if. A propos, je transmet en clair l'ordre afin de soulager la uno, sauf dans certains cas.
Ok aussi pour gérer la perte de signal ou bien, le fait de recevoir plein de trame et de les traiter.
D'une manière générale, il faut moins de 100 ms entre traitement carte 1, liaison et traitement carte 2, exécution. Donc il faut vraiment que ça punch. Peut-être en passant par des fonctions de traitement. Genre, si je reçois quelque-chose j'appel la fonction de récupération de valeur, je retourne la valeur, je transmet la donnée au bon endroit, je passe à la suivante. Mais si entre temps j'ai reçu d'autres trames, c'est mort. L'autre solution, est de mettre en attente les envoies avec un . A ce moment la, le maître n’enverra la commande que si l’acquittement de réception à été donné par l'esclave.
@ barbudor : Bon et bien, ton code ne fonctionne pas !!!!
Je pense que la logique y est mais pas le code
Bon, ce que je vais faire, c'est dans le loop()
Si pas d'opération, attendre un Serial.available()
-- Appeler la fonction réception, recevoir l'ordre 1 sous la forme "<Led1, on>" ou "<Led1, off>" par exemple.
-- Traiter l'opération par une fonction, Lancer un depuis une fonction Acknowledge ""
Bonjour a Tous je suis nouveau , je voudrais avoir un peu d aide pour programmer sur Arduino .J ai un projet qui consiste a espionner des câbles sans modifier les données,pour moi c est la RS232. et j aimerai stocker les données de la liaison série dans un tableau mais je ne sais pas comment m y prendre. Voici ce que j ai fais juste pour lire des données :
#include <SoftwareSerial.h>
#define rxPin 2 // Je definis les broches Rx et Tx #define txPin 3
