Bonjour, Je suis en train de rélaiser un projet en SI avec un module bluetooth lié à une carte arduino qui reçoit les informations de l’application (appinventor) et renvoie un ordre qui fait clignoter la Led du pin 13. Malheureusement je n’arrive pas à connecter mon téléphone ou il ya un problème de programme .
Ici le programme sur arduino : #include <SoftwareSerial.h> SoftwareSerial Bluetooth(11, 10);//rxPin, txPin
Je ne connais pas trop Appinventor, ne l'ayant utilisé qu'une ou deux fois (et je pense que c'est pareil pour la majorité des membres du forum), aussi je te conseille de lire et tester ce qui est présenté sur le site de Martyn Currey (une référence dans le sujet). Si tu arrives à le faire fonctionner, tu peux alors reprendre des blocs pour ton propre usage.
Je n'utilise pas appinventor mais il semble que vous envoyez le chiffre 1 donc je me demande si ça envoie la version ASCII (donc dans votre code vous testeriez bien '1') ou la version binaire numérique (et donc il faudrait tester 1 sans apostrophes dans ce cas). Vu le nom de la fonction je pencherai plutôt sur l'envoi en numérique...
Enfin, en bloquant pendant 1 seconde votre code quand vous aurez reçu le bon élément, ça ne va pas faire un programme super réactif côté arduino... il faudrait éviter les delay(). C'est typiquement une définition de programme qui se prête bien à la programmation par machine à états (cf mon tuto éventuellement)
bonjour send1bytenumber envoie le caractère correspondant au nombre tapé
Send1ByteNumber(text number)
a relire donc sous forme de caractère du coté arduino
par contre la encore envoyer un truc sans définir un format d'envoi sans contrôle a priori et a postériori du format de ce qui est envoyé ou reçu reste assez aléatoire évidemment c'est beaucoup plus simple mais cela mériterait plus ample réflexion. (surtout dans un projet d'examen)
faire une approche sécuritaire avec définition d'un protocole (qui peut rester simple) serait surement d'un meilleur effet.
traiter la réception dans un serialEvent() aussi peut être ...
jfs59:
bonjour send1bytenumber envoie le caractère correspondant au nombre tapé
Send1ByteNumber(text number)
a relire donc sous forme de caractère du coté arduino
je suis allé voir la doc ils ont différentes fonctions mais ça a l'air de dire que ça envoie un ou plusieurs octets
Send1ByteNumber(number) Send a 1-byte number to the connected Bluetooth device.
Send2ByteNumber(number)
Send a 2-byte number to the connected Bluetooth device.
Send4ByteNumber(number)
Send a 4-byte number to the connected Bluetooth device.
SendBytes(list)
Send a list of byte values to the connected Bluetooth device.
SendText(text)
Send text to the connected Bluetooth device.
le plus simple c'est d'afficher la valeur reçue sur l'Arduino et on saura
j'ai utilisé et utilise appinventor avec bluetooth et c'est vraiment assez hard de savoir les tenants et aboutissant exacts !
la fonction qui envoie du texte est surement la plus simple et la plus sure a utiliser.
par exemple dans un de mes programmes j'envoie ceci
<CmdCfg=(1500,1000,2000,1500,1000,2000,50,100,100,255,255)> suivi d'une fin de bloc 23
dans le sérial évent je regarde s il y a des caractères je reconstitue le contenu caractère par caractère je vérifie la fin de bloc et ensuite je décode l’entête et les valeurs transmises on pourrait utiliser un json a la limite.
deux avantage c'est des caractères donc on peut envoyer n'importe quelle infos ! le format est connu donc on peut le décoder , il y a des sécurité dans l’entête et a la fin permettant de vérifier l'intégrité.
jfs59:
Utiliser les caractères fin de ligne et un format non défini est une très mauvaise idée ça fini toujours par merdouiller.
oui enfin là il n'envoie qu'un seul octet et teste une seule valeur donc pas besoin non plus de "faire bouillir l'océan" avec un protocole plus compliqué, on peut se contenter de son approche.
s'il avait besoin d'envoyer plus de choses alors tout à fait, il faut partir sur un protocole plus robuste avec marqueur de début et fin de trame et éventuellement un CRC si on veut être sûr de ce que l'on a reçu
oui c'est pas faux c'est même très vrai mais si un projet d'exam consiste a envoyer un 1 pour faire clignoter une led et basta ... bah c'est light
sans compter que la elle s'allume elle s’éteint et puis fini elle clignotera pas sauf si on considère que passer allumé éteint une fois c'est un clignotement.
j'ai l'impression que c'est une phase d'essai avant d'aller plus loin
Edit: je viens de lire les pages de Martyn Currey que je ne connaissais pas. Il passe plus de 50% du temps a expliquer son protocole de com. C'est vrai que son programme va aussi lus loin qu'un simple clignotement je le conseillerai pas a un débutant.
