Discussion :

[Nounours18200]

Bonjour,
Bon je me fais des noeuds au cerveau là-dessus donc je viens voir les experts !

J'écris une petite application qui reçoit par Bluetooth les données envoyées par un smartphone lorsqu'on appuie sur un bouton de l'écran du téléphone. Jusque là rien d'extraordinaire puisqu'on trouve plein d'exemples sur le Web pour faire ça.

Jusqu'à présent quand j'appuyais sur le "bouton 1" de mon application smartphone, je faisais émettre "1" au smartphone et je recevais donc "1" sur mon Arduino dans une chaine de caractère nommée "Incoming_value" prévue pour cela, laquelle envoyait donc "1" sur le moniteur série; et tout fonctionne bien.

Maintenant je fais émettre non plus le Numéro du bouton, mais le Nom du bouton; par exemple si le bouton 1 correspond à une action que j'appelle "STOP", je fais émettre "STOP" au téléphone.
Je reçois donc "STOP" sur l'Arduino, mais sur le moniteur série l'Arduino m'envoie successivement "S" puis "T" puis "O" puis "P", alors que je voudrais qu'elle envoie "STOP" comme une chaine de caractères unique.

Voici le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
char Incoming_value = 0; // on initialise cette chaine à 0 pour le démarrage
 
void setup() 
{
  Serial.begin(9600); // on définit la vitesse à 9600        
  pinMode(13, OUTPUT); // on connectera la LED de contrôle sur la pin 13 de l'Arduino   
 
}
 
void loop()
{
  if(Serial.available() > 0)  // quand on appuiera sur un bouton du Smartphone, cette valeur deviendra forcément supérieure à 1
                              // et ça voudra dire qu'une valeur reçue est disponible
  {
    Incoming_value = Serial.read(); // une valeur ayant été reçue, on la transfère dans notre chaine "incoming value"  
    Serial.print("RX recu = ");     // essaie pour faire afficher ça sur le Moniteur serie
    Serial.print(Incoming_value); // Envoie la valeur de Incoming_value reçue sur le Moniteur série
    Serial.print("\n");             // on fait un retour à la ligne pour que la prochaine valeur s'affiche sur la ligne d'après
 
    // DEBUT du test pour Button 5
     if(Incoming_value == 'STOP')       // si on reçu la valeur "STOP" alors on envoie "STOP" sur le Moniteur série
      {
      Serial.print(Incoming_value); // Envoie la valeur de Incoming_value reçue sur le Moniteur série  
      Serial.print("Appui sur Button5: STOP");      // on envoie sur le Moniteur Série qu'on a détecté l'appui sur Button5
      }
    // FIN du test pour Button 5

Comme la phrase "Appui sur le Button5: STOP" ne s'affiche pas sur le Moniteur série, j'ai l'impression que mon programme ne passe pas dans la portion entre "//DEBUT du test pour Button 5" et "//FIN du test pour Button 5": donc où est mon erreur ?

[al1_24]

Bonjour,

1. Incoming_value est déclaré comme un caractère.
2. Serial.read() retourne le premier caractère disponible dans le tampon de lecture du port Serial.

A l'issue de la commande Incoming_value = Serial.read(), Incoming_value ne pourra donc jamais contenir qu'un unique caractère.

Par ailleurs, la comparaison de chaines de caractères ne s'effectue pas avec l'opérateur ==.

Il faudrait donc commencer par revoir les fonctions de gestion des chaines de caractères afin de faire évoluer ce programme.

[Nounours18200]

oui Merci alt1_24: c'est carrément n'importe quoi mon code: voilà ce qui arrive quand on n'a plus programmé depuis 1 an et qu'on s'y remet.....

bon je retourne à mes docs...

[Jay M]

Avez vous vraiment besoin de passer en mode d'envoi de plusieurs caractères?

ce n'est pas compliqué mais ça oblige à coder plus de chose, notamment la réception asynchrone
Pour que ce soit robuste il faudra aussi sans doute émettre un marqueur de fin de communication (par exemple un passage à la ligne)

[jpbbricole]

Bonsoir Nounours

Si tu as la possibilité de terminer l'envoi, depuis le smartphone par un caractère Nouvelle Ligne ou LF ou \n ou ASCII 10, je peut te passer la routine que j'emploie toujours pour ce type d'opérations.

Cordialement
jpbbricole

[Nounours18200]

Désolé pour ma réponse un peu tardive, mais je ne reçois pas les notification de réponse du forum (rien dans les spams non plus !), et il faut donc que je vienne voir s'il y a une réponse,

@JayM: merci pour les liens, je vais regarder s'il y a des infos qui m'intéressent dedans !

Si tu as la possibilité de terminer l'envoi, depuis le smartphone par un caractère Nouvelle Ligne ou LF ou \n ou ASCII 10, je peut te passer la routine que j'emploie toujours pour ce type d'opérations.

@jpbbricole:
ça ce serait vraiment sympa de me passer ta routine !

Je suis arrivé à réceptionner correctement les chaînes de caractères émises par le Smartphone, donc mon programme fonctionne, bien que je ne l'ai pas encore testé de façon intensive.

J'avoue que je ne sais pas comment émettre le caractère "LF ou \n ou ASCII 10"... pour l'instant j'émets une chaîne de caractères depuis le Smartphone, par exemple "toto": quel serait le caractère à émettre à la fin de "toto" pour qu'il soit interprété comme \n ?

Merci à tous pour votre implication !

[Jay M]

J'avoue que je ne sais pas comment émettre le caractère "LF ou \n ou ASCII 10"... pour l'instant j'émets une chaîne de caractères depuis le Smartphone, par exemple "toto": quel serait le caractère à émettre à la fin de "toto" pour qu'il soit interprété comme \n ?

Quel est le langage de programmation utilisé sur le smartphone?

[jpbbricole]

Bonjour Nounours18200

Je te propose un exemple de ce que j'utilise quasiment dans tout mes programmes, dans cet exemple qui tourne sur un UNO le BT est reçu via SoftwareSerial Rx 2 et Tx 3.
Pour ce qui est de la terminaison de la chaîne, tu peux mettre ce que tu veux si tu ne peux pas mettre "Nouvelle ligne"
Choisi un caractère pas utilisé couramment comme la barre verticale | (altGr 7) et tu changes cette ligne dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
void btSerialEvent()
...
if (monChar == '\n')
 
// en
 
if (monChar == '|')

ou le caractè de ton choix

Dans ce progamme tu peux encoyer des coommandes depuis BT, via SoftwareSerial avec la terminaison de ton choix (par défaiut \n) ou depuis la ligne de commande de l'IDE Arduino avev Lf comme terminaison.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
 
/*
    Name:       ARDDEV_Nounours18200.ino
    Created:	07.06.2021
    Author:     jpbbricole
*/
#include <SoftwareSerial.h>     // https://github.com/PaulStoffregen/SoftwareSerial
 
//------------------------------------- Liaison Bluetooth
SoftwareSerial btSerial(2, 3); // RX, TX
bool btCmdRecue = false;         // Si une nouvelle commande a été reçue
String btTexte = "";             // Texte de la commande
 
//------------------------------------- Ligne de commandes
bool cmdNouvelleRecue = false;      // Si une nouvelle commande a été reçue
String cmdTexte = "";               // Texte de la commande
 
void setup() 
{
	Serial.begin(115200);
	btSerial.begin(9600);
}
 
void loop()  
{
	//--------------------------------- Ecoute du port BT
	btSerialEvent();    
	if (btCmdRecue)      // Si une nouvelle commande depuis BT
	{
		Serial.print(F("\nRecption Bluetooth ")); Serial.println(btTexte);
		cmdExecute(btTexte);
 
		btTexte = "";
		btCmdRecue = false;
	}
	//--------------------------------- Ecoute du port serie
	//serialEvent();           // Enlever le commentaire si l'appel ne se fait pas automatiquement
	if (cmdNouvelleRecue)      // Si une nouvelle commande depuis le moniteur
	{
		Serial.print(F("Recption Console ")); Serial.println(btTexte);
		cmdExecute(cmdTexte);
 
		cmdTexte = "";
		cmdNouvelleRecue = false;
	}
}
 
/*---------------------------------------------------------------------------
	Execution de la ligne de commande
'*----------------------------------------------------------------------------
*/
void cmdExecute(String cmdRx)
{
	Serial.print(F("Traitement de la commande ")); Serial.println(cmdRx);
}
 
/*-----------------------------------------------------------------------
	Réception de commandes depuis Bluetooth
'*------------------------------------------------------------------------
*/
void btSerialEvent()                                       
{
	while (btSerial.available())
	{
		char monChar = (char)btSerial.read();     // Char received from IDE monitor
		if (monChar == '\n')                      // If new line char received = end of command line
		{
			btCmdRecue  = true;
		}
		else
		{
			if (monChar >= ' ') {btTexte += monChar;}     // >= ' ' to avoid not wanted ctrl char.
		}
	}
}
 
/*-----------------------------------------------------------------------
	Réception de commandes depuis le moniteur
'*------------------------------------------------------------------------
*/
void serialEvent()                                       
{
	while (Serial.available())
	{
		char monChar = (char)Serial.read();     // Char received from IDE monitor
		if (monChar == '\n')                    // If new line char received = end of command line
		{
			cmdNouvelleRecue  = true;
		}
		else
		{
			if (monChar >= ' ') {cmdTexte += monChar;}     // >= ' ' to avoid unwanted ctrl char.
		}
	}
}

Quel programme utilises-tu sur ton smartphone?

A+
Cordialement
jpbbricole

[Jay M]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void btSerialEvent()                                       
{
	while (btSerial.available())
	{
		char monChar = (char)btSerial.read();     // Char received from IDE monitor
		if (monChar == '\n')                      // If new line char received = end of command line
		{
			btCmdRecue  = true;
		}
		else
		{
			if (monChar >= ' ') {btTexte += monChar;}     // >= ' ' to avoid not wanted ctrl char.
		}
	}
}

Attention si les commandes arrivent vite vous allez avoir potentiellement un souci

Imaginez que le séparateur est | (pour faciliter la lecture)
Disons que vous voulez envoyer xy=22|yz=33| et que lorsque vous appelez btSerialEvent() le buffer a reçuxy=22|y alors btTexte va être initialisé à "xy=22y" ce qui va potentiellement induire en erreur l'analyse de la commande et la commande suivante sera "z=33" qui génèrera un bug possible en affectant une mauvaise commande.

-> il serait bien d'introduire un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

break;

juste après

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

btCmdRecue  = true;

[jpbbricole]

Bonsoir Jay M

J'ai fait des essais, sans constater ce type de problème. Dès que j'ai le temps, je vais pousser plus loin.
Depuis que j'emploie cette routine, je n'ai jamais décelé le moindre problème.

Cordialement
jpbbricole

[Jay M]

Salut

Si vous envoyez les commandes complètes une par une à la main ça ne doit pas se voir

c’est un risque statistique à cause de la transmission asynchrone. Si vous envoyez un flux assez continu de commandes sans trop de séparation temporelle Vous devriez voir le problème

Vous pouvez simuler le problème en envoyant une commande le séparateur et le début d’une autre commande puis envoyer la fin de la deuxième commande et le séparateur.

cela va se produire si la vitesse d''arrivée des caractères est rapide, par exemple testez avec ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
bool cmdNouvelleRecue = false;      // Si une nouvelle commande a été reçue
String cmdTexte = "";               // Texte de la commande
 
void setup()
{
  Serial.begin(500000);
}
 
void loop()
{
  if (cmdNouvelleRecue)      // Si une nouvelle commande depuis le moniteur
  {
    Serial.print(F("Recption Console ")); Serial.println(cmdTexte);
    cmdTexte = "";
    cmdNouvelleRecue = false;
  }
}
 
 
void serialEvent()
{
  while (Serial.available())
  {
    char monChar = (char)Serial.read();    
    if (monChar == '|')                   
    {
      cmdNouvelleRecue  = true;
    }
    else
    {
      if (monChar >= ' ') {
        cmdTexte += monChar; // >= ' ' to avoid unwanted ctrl char.
      }
    }
  }
}

réglez la console pour qu'elle soit à 500,000 bauds et n'envoie pas de caractères de fin et entrez xy=33|ab puis validez
puis tapez ensuite =66| et validez

vous verrez dans la console
Recption Console xy=33ab
Recption Console =66

ou alors tapez d'un seul coup: xy=33|ab=66|xy=33|ab=66|xy=33|ab=66|xy=33|ab=66|
vous verrez
Recption Console ab=66xy=33ab=66xy=33ab=66xy=33ab=66

même à 115200 bauds vous allez avoir des soucis, par exemple j'ai eu
Recption Console xy=33
Recption Console ab=66
Recption Console xy=33
Recption Console ab=66
Recption Console xy=33ab=66xy=33
Recption Console ab=66

==> on est dépendant de l'asynchronicité de la transmission et de la rapidité du remplissage et vidage du buffer Série

maintenant mettez un break; après cmdNouvelleRecue = true;

si vous tapez xy=33|ab=66|xy=33|ab=66|xy=33|ab=66|xy=33|ab=66|
vous verrez
Recption Console xy=33
Recption Console ab=66
Recption Console xy=33
Recption Console ab=66
Recption Console xy=33
Recption Console ab=66
Recption Console xy=33
Recption Console ab=66

ce qui est attendu sans doute

[Nounours18200]

Quel programme utilises-tu sur ton smartphone?

J'ai créé l'appli avec MIT Appinventor": pas envie, ni le temps, de me lancer dans l'apprentissage d'Android Studio !

MIT AppInventor suffit largement à mes besoins pour l'instant, même si dans le futur j'aimerais que mon appli puisse piloter plusieurs devices, et là je ne sais pas encore faire avec AppInventor, mais ça peut attendre l'an prochain...

Donc je n'ai pas vraiment accès au code sur Smartphone, je lui dis juste ; si ce bouton est cliqué, alors tu envoie "STOP". Et je reçois bien "STOP" ce qui me permet de faire ce que je veux.

Mais pour rajouter "\n" alors là ???...

Attention si les commandes arrivent vite vous allez avoir potentiellement un souci

Je n'ai pas encore testé à fond, pour l'instant ça a l'air de marcher puisqu'en utilisation normale je ne pense pas que l'utilisateur appuie sur 2 boutons différents en moins d'1 seconde, mais on n'est pas à l'abri effectivement...

Le programme tourne sur une MEGA 2560, et je trouve qu'il y a une petite latence entre le moment où on appuie sur un bouton du Smartphone, et le moment où la réception s'affiche sur le Moniteur Série, sans que je sache comment optimiser cela ? (augmenter la vitesse du HC0x au-delà de 9600bauds ? idem moniteur série ?)

Je pourrais voir ce que ça donne en conditions réelles la semaine prochaine, puisque j'intègrerai cette partie "réception smartphone" à mon programme principal qui a déjà été testé et est OK.
Je suis davantage inquiet pour le portage sur une UNO: le proc est moins puissant et je ne sais pas ce que ça donnera.

Pour l'instant je ne peux pas tester vos routines car je ne récupère mon boîtier (contenant mon programme principal) que Dimanche puisqu'il était testé par un pro (sans réception Smartphone jusqu'à présent).

Vos routines me paraissent un peu compliquées mais je vais les étudier !

[jpbbricole]

Bonjour Jay M

Vous pouvez simuler le problème en envoyant une commande le séparateur et le début d’une autre commande puis envoyer la fin de la deuxième commande et le séparateur.

Et pourquoi on enverrais une commande puis un sépatateur puis un bout de la commande suivante...., qui ferait ça dans un programme?

réglez la console pour qu'elle soit à 500,000 bauds et n'envoie pas de caractères de fin et entrez xy=33|ab puis validez....

Une liaison Smartphone, BT, Arduino à 500'000 !!!! Où as-tu déjà vu ça alors qu'elles sont, en général à 9600 ou 115200.

Je trouve ton analyse du programme que j'ai proposé inutilement anxiogène ,indigne de toi. Cette routine fonctionne sur mes montages sans aucuns problèmes depuis pas mal de temps et c'est en toute confiance que je l'ai proposée dans ce post.

Cordialement
jpbbricole

[Jay M]

Ce n'est pas parce que ça n'a jamais buggué qu'il n'y a pas de bug...

Et pourquoi on enverrais une commande puis un sépatateur puis un bout de la commande suivante...., qui ferait ça dans un programme?

Personne (et encore), je vous proposais un moyen simple de mettre en évidence la dépendance de votre code à la nature asynchrone de la connexion série. ça marche parce que vous avez de la chance.
(un programme peut construire la commande bout par bout et faire plusieurs print() pour envoyer la commande - de l'autre côté de la liaison série on a un flux de données sans trop savoir comment elles ont été émises. L'objectif de l'exemple était de montrer la dépendance au timing de soumission des données).

Mais restez à 115200 et un client qui envoie rapidement des commandes... par exemple votre gestionnaire de commandes pour le train, le programme Processing qui va balancer tout un tas d'ordres d'un coup.

Vous pouvez simuler l'arrivée massive de plusieurs commandes d'un coup en tapant xy=33|ab=66|xy=33|ab=66|xy=33|ab=66|xy=33|ab=66| comme proposé et comme je l'ai indiqué ci dessous votre code va analyser cela comme ceci
Reception Console xy=33
Reception Console ab=66
Reception Console xy=33
Reception Console ab=66
Reception Console xy=33ab=66xy=33
Reception Console ab=66

et sans doute avec des variations suivant la charge du processeur et du traitement des actions.

Je trouve ton analyse du programme que j'ai proposé inutilement anxiogène ,indigne de toi.

Vous avez un bug potentiel qui peut arriver dans des situations réalistes
Je vous le montre.
Je vous montre comment en 1 seule ligne de code vous le réglez (un break qui sort du while quand on a trouvé une commande pour que le programme principal puisse traiter la commande).

--> Je ne sais pas où est la partie anxiogène du truc...C'est quand même incroyable comme réaction...

Ensuite vous faites ce que vous voulez dans votre code. Tout le monde a le droit de laisser des bugs en dormance. Mais comme c'est un forum de libre expression, tout le monde a aussi le droit de donner son opinion.

[Jay M]

Vos routines me paraissent un peu compliquées mais je vais les étudier !

Si vous lisez les tutos que j'ai mentionné au début, vous comprendrez sans doute mieux pourquoi il faut faire "un peu compliqué" mais en gros le code proposé par JP reçoit les caractères et les stocke dans une chaîne jusqu'à ce qu'un séparateur soit trouvé (et va éventuellement plus loin si le buffer de réception contient d'autres caractères - d'où ma suggestion du break qui fâche JP). Ensuite il ne reste plus qu'à analyser cette chaîne pour déterminer quelle commande on a reçu.

[jpbbricole]

Bonsoir Jay M

d'où ma suggestion du break qui fâche JP...

Oh tu ne me fâche pas, je trouve ça simplement inutile, c'est chercher des poux dans la paille, mais c'est toi l'expert.

Cordialement
jpbbricole

[Jay M]

je ne me fâche pas non plus, je ne me fâche jamais. Je marque ma surprise sur votre réponse.

Ça semble quand même logique d'arrêter de lire les données que l'on reçoit et de soumettre la commande quand on a reçu le marqueur de fin, même s'il y a encore des données dans le buffer série - Non?

Si vous pensez que c'est inutile de corriger les bugs, c'est votre droit le plus entier et je le respecte.

Ensuite c'est pas plus mal que ceux qui lisent ce forum le sache, ils pourront ainsi prendre une décision informée s'ils veulent rajouter le break ou pas.

[jpbbricole]

Bonsoir Nounours18200

Mais pour rajouter "\n" alors là ???...

Il semblerai que la syntaxe soit la même que dans le langage Arduino, c'est à dire, ajouter \n à la String à envoyer, ainsi, "\n" ou peut-être ainsi "Commande=200\n".
Je n'ai pas essayé.

Cordialement
jpbbricole

[Nounours18200]

Je n'ai surement pas votre expertise, mais pour tester ça proprement, j'ai besoin de recevoir mes circuits imprimés câbler tout ce beau monde correctement...

Peut-être en fin de semaine...