Arduino <== RS232 ==> Arduino

A note qu'en i2c il y a un maitre et plusieurs esclaves, alors qu'en serie on peut en mettre autant qu'on veut et il n'y a ni maitre ni esclave.

Au départ, je voulais faire du full I2C.

Il s'avait ait que pour piloter un roc aquatique, cela se serait avéré trop lent.

Au niveau de la carte mega, je gère le poste de pilotage et ses boutons. Dans ce cadre j'ai normalement asser d'entrée sans i2c. En revanche je me laisse la possibilité de mettre des accessoires externe sur l'i2c.

À partir de la, part un fil série, hors i2c, qui va sur une uno qui elle est embarqué.

D'une manière générale, l'union donne priorité au pilotage donne par la mega. Mais retourne des valeurs tel que voie d'eau, luminosité, température, pression.

Si aucune commande n'est exécuté ou si la consigne à la pression à été donné, la uno gère un petit auto pilotage du ballast afin de maintenir la profondeur.

Je rajoute qu'en plus de tout ça, il y a une camarade et un bras manipulateur.

Donc mega ---> i2c ----> écran LCD
Mega ---> tx ---- > rx ----> uno (ordre de pilotage)
Uno ---> tx ---> rx ---> mega (renvoie des paramètres)

Uno -> servo (M1)
Uno -> servo (M²)
Uno -> servo 1, 2, 3 (bras manipulateur)
Uno -> servo (pompe ballast)
Uno <- capteur pression (analogique)
Uno <- capteur 1 ballast
Uno <- capteur 2 ballast
Uno <- capteur température (analogique)
Uno <- capteur lumière (analogique)

En gros, ça c'est ce que je veux faire dans la pratique.

Ok pour encapsuler. Je tente une connexion en directe tx RX et rx TX. Et je voir comment je peux gérer tout ça dans les deux cartes :wink:

Bon alors, pour les essais, la méga j'ai pu compiler sans problème ce code

//Carte Mega télécommande

#include <Wire.h>

#define addresseLCD 0x63

void setup() {
  
  Serial.begin(9600); //Lancer le mode série
  
  Wire.begin(); //Lancer I2C
  
  Wire.beginTransmission(addresseLCD); //Aller sur l'adresse
  Wire.write((byte)0x00);              //Null
  Wire.write((byte)0x0C);              //Effacer Ecran
  Wire.write((byte)0x04);              //Retirer le curseur
  Wire.write((byte)0x13);              //Allumage de l'ecran
  Wire.endTransmission();              //Fin de transmission
  
  Wire.beginTransmission(addresseLCD); //Aller sur l'adresse
  Wire.write((byte)0x00);              //Null
  Wire.write((byte)0x01);            //Mettre le curseur au début
  //Wire.write((byte)0x02);              //Préparer le curseur à aller ailleur
  //Wire.write(3);                       //Aller sur la case N° 26
  Wire.write("Telecommande");          //Ecrire
  Wire.endTransmission();              //Fin de transmission
}

void loop() {
  
  Serial.print("[ON]");
  delay(2000);
  Serial.print("[OFF]");
  delay(2000);
}

Par contre je n'arrive pas à compiler ceci:

//Carte Uno sous-marin

void setup() {
  
  Serial.begin(9600); //Lancer le mode série
  
  pinMode(13, OUTPUT);
  
  
  
  delay(50);
}

void loop() {
  
  char Buffer[10];
  
  if(Serial.available){
    
    delay(20);
    
    for(int i=1; i<=9; i++){
      Buffer[i]='\0';
    }
    
    int x=0;
    while(Serial.available) {
      
      Buffer[x]=Serial.read();
      x++;
    }  
  }
  
  if(Buffer=="[ON]") {
    digitalWrite(13, HIGH);
  }
  
  if(Buffer=="[OFF]") {
    digitalWrite(13, LOW);
  }
}

Et j'obtient cela :

Mini02___Sous_marin.cpp: In function ‘void loop()’:
Mini02___Sous_marin.cpp:21: erreur: could not convert ‘Serial.HardwareSerial::available’ to ‘bool’
Mini02___Sous_marin.cpp:30: erreur: could not convert ‘Serial.HardwareSerial::available’ to ‘bool’

Et galère :cold_sweat:

Yop yop,

available n'est pas un attribut mais une méthode, il manque les "()".

if(Serial.available())
.
while(Serial.available())

Pourquoi pas le rs-485, facile à mettre en œuvre pour de grande distance ?

Bon ben ça compile 8)

Mais j'ai pas l'impression que mes trames sortes. Alors que je voir bien les messages de ma mega dans le Serial Monitor...

Je regarde à l'oscillo si ça trame, sinon, il faudra peu-être que je force sur TX0 RX0.

Geeks:
Bon ben ça compile 8)

Mais j'ai pas l'impression que mes trames sortes. Alors que je voir bien les messages de ma mega dans le Serial Monitor...

Je regarde à l'oscillo si ça trame, sinon, il faudra peu-être que je force sur TX0 RX0.

bonsoir
à tout hasard
rx--->tx
tx--->rx
ok
mais la reference commune des niveaux existe bien ?
les GND des differentes cartes sont bien reliés ?

Je regarde à l'oscillo si ça trame, sinon, il faudra peu-être que je force sur TX0 RX0.

Pas super clair :~

La boucle de réception est mal ficelée.
Le remplissage du buffer ne devrait commencer qu'après s'être assuré que le premier caractère était bien celui attendu [ sinon le buffer peut être rempli n'importe comment et jamais tu ne trouveras ton message.
De même l'interprétation ne devrait commencer qu'une fois le terminateur reçu ] ou éventuellement sur hors temps pour sécuriser la liaison.

Edit: je corrige, le terminateur n'est d'ailleurs pas ] mais \n puisque tu envoie une chaine de caractère.

Alors, l'oscillo ma permis de voir que mon Tx émettais bien des trammes. C'était avant tout pour éviter de dire, je donne un mot à titi, mais c'est tata qui envoie. Là, maintenant, je sait que quelque-chose passe par TX de la Mega.

Maintenant, oui, je suppose que la partie réception n'est pas correcte. Et je n'ai pas vraiment d'autres éléments. Donc là, sur ce point précis, je veux bien un coup de main.

Si quelqu'un à une idée pour détecter le premier "[", ce qui est dedans et enfin le "]". Comme j'ai dit, ce sera simple, [M1][F1] pour moteur 1 et fréquence 1ms, ou bien [M1][F1.5] pour 1,5ms sur M1... Ensuite je pense qu'on peut faire mieux non ?

Une idée qui m'étais venu etait ceci "Moteur:1/Frequence:1.5/Option:xxx" et au retour "Temperature:1/DegC:120". Je trouve que c'est beaucoup plus clair comme message et surtout tout est encapsulé entre "<" et ">". Comme en html quoi :wink:

Bon, des tests un peu plus poussé me disent que le buffer contient bien tantôt [ON] tantôt [OFF] ! Mais les if(Buffer="[ON]") et if(Buffer="[OFF]") ne fonctionne pas :cold_sweat:

Donc il faut chercher là :grin:

Si quelqu'un à une idée pour mes if, je suis preneur bien sûr :wink:

Yop yop,

Geeks:
Si quelqu'un à une idée pour mes if, je suis preneur bien sûr :wink:

if(Buffer=="[ON]")

valeur decimal du code ascii '[' == 91, ']' == 93
L’échange de trame sous forme de chaine je suis pas un grand fan, c'est lourd pour pas grand chose.
Un exemple simple de trame que je met en pratique Aidez nous ! Projet - Gestion domotique - #110 by system - Français - Arduino Forum

Oui, c'est ce que j'ai fait :drooling_face:

if(Buffer=="[ON]") {
      digitalWrite(13, HIGH);
    }
  
    if(Buffer=="[OFF]") {
      digitalWrite(13, LOW);
    }

Arf ce n'est pas aussi simple de comparé deux chaine ...

Par facilité utilisé la classe String String() - Arduino Reference ou alors avr-libc: <string.h>: Strings

Dans le cas ici soit equalsIgnoreCase() - Arduino Reference , soit avr-libc: <string.h>: Strings

Mais bon comme dans mon edit, utilisé les chaines de caractères (traitement lourd, mémoire, ...) pour de simple échange n'est pas ce qui ce fait de mieux quand on est sur µc.

Ben, oui, mais alors on est en désaccord avec le précédent code, sauf si après avoir constitué le Buffer, je le traduit en string.

  1. créer le buffer en char
  2. Buffer(char) to Variable(String)
  3. Tester sur Variable(String)

Si c'est bon, comment transcrire du char en string ?

Tu n'est pas obligé de construire ton buffer en char mais directement un String, enfin je sais plus si la clase string peux prendre un tableau de char en paramètre constructeur.
Normalement ceci devrait marché
Via la classe String

    String str = "";
    while(Serial.available()) 
    {
        str+=(char)Serial.read();
    } 
    
    if(str.equals("[ON]") )
    {
    }

sinon via la lib avr

  char Buffer[10];

    int x=0;
    while(Serial.available()) 
     {
      Buffer[x]=(char)Serial.read();
      x++;
    }
    
    if(strncmp(buffer, "[ON]", 4)) 
    {
    }

Pas vérifier mais ça devrait être quelque chose comme ça.
Attention avec ta boucle while(Serial.available()) rien ne dit que tu recevras bien toute la trame en 1 coup.

Plop,

Bon , je viens d'essayer ceci :

//Carte Uno sous-marin

void setup() {
  
  Serial.begin(9600); //Lancer le mode série
  
  pinMode(13, OUTPUT);
  
  delay(50);
}

void loop() {
  
  String str = "";
  
  if(Serial.available()){
    
    delay(20);
    
    while(Serial.available()) {
      
      str+=(char)Serial.read();
    }
    
    if(str.equals("[ON]")) {
      digitalWrite(13, HIGH);
    }
  
    if(str.equals("[OFF]")) {
      digitalWrite(13, LOW);
    }
  }
}

Pourquoi je me suis lever les bras en l'air en criant "Ça marche ! Ça marche !"...

Merci pour le coup de pouce :slight_smile:

A partir de là, je pense faire ceci:

  • Si on a bien un signal -> if(Serial.available()){
  • Si on a bien reçu le premier caractère "<"
  • Boucler tant que l'on a pas reçu le dernier caractère ">"
  • Récupérer la chaîne, parser les commandes "organe:numéro/option:valeur" Si pas d'option, se laisser la possibilité de mettre "organe:numero"

D'une manière générale, je vais faire un code tournant, c'est à dire passé commande par commande, plutôt que tout à la fois. Ainsi, j'aurais:
Mot1:1.5
Mot2:1.5
Ser1:2
Ser2:1
Ser3:1.5
Pre1:Lock ou Pre1:Unlock
Lig1:On ou Lig1:Off (pour les lights)

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 !!!! :sweat_smile:

Je pense que la logique y est mais pas le code :grin:

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 ""
  • Boucler

Bon et bien, je suis arrivé à un bout de quelque-chose...

//Carte Uno sous-marin

char commande[32];


void setup() {

  Serial.begin(9600); //Lancer le mode série
  pinMode(13, OUTPUT);
}

void loop() {

  if(readCommande() != 0) {
    
    Serial.println(commande);
    
    if(strcmp(commande, "<on>")==0) {
      digitalWrite(13, HIGH);
    }
    if(strcmp(commande, "<off>")==0) {
      digitalWrite(13, LOW);
    }
  }
  delay(20);
}

int readCommande() {
  if(!Serial.available()) {
    return 0;
  }
  
  int i=0;
  
  while(Serial.available()) {
    commande[i]=Serial.read();
    i++;
  }
  
  commande[i] = 0;
  return i;
}

Maintenant, il faut qu'au niveau de mon buffer, on puisse faire ceci:
"<" début de trame
">" fin de trame
"ordre, chiffre ou valeur" entre "<" ">"

Interdire tout autre traitement tant que le traitement en cours n'est pas effectif.

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

SoftwareSerial softSerial = SoftwareSerial(rxPin, txPin);

void setup() {

pinMode(rxPin, INPUT);//Configure les broches pour l entrée et la sortie
//pinMode(txPin, OUTPUT);
softSerial.begin(9600);

Serial.begin(14000);
}

void loop() {

int data = softSerial.read();
Serial.println(data); ASCII
}