Fonction serout

pdevisme1

Senior Member
Bonjour à tous, un question petite question sur la fonction serout :

Si dans une case Basic de je mets ( en utilisant un 28X2 ) :

serout A.1, T9600_8, (10)
pause 10

Est-ce que la sortie A.1 va envoyer la valeur 10 en permanence ou juste 10 ms ?

Merci d'avance.
 

MGU

Senior Member
Bonjour à tous, un question petite question sur la fonction serout :

Si dans une case Basic de je mets ( en utilisant un 28X2 ) :

serout A.1, T9600_8, (10)
pause 10

Est-ce que la sortie A.1 va envoyer la valeur 10 en permanence ou juste 10 ms ?

Merci d'avance.
Bonjour,

Si il n'y a pas de boucle, chaque commande est lue une seule fois.

MM
 

PieM

Senior Member
Est-ce que la sortie A.1 va envoyer la valeur 10 en permanence ou juste 10 ms ?
Précision:
Le picaxe n’envoie pas le serout pendant 10ms !
Il envoie la valeur 10 une fois, ce va demander moins d'1 ms et ensuite le picaxe attend 10 ms.

attention également quand on utilise un serout T :
son niveau de repos étant le niveau haut, il faut avant le premier envoi, mettre la sortie correspondante à 1 par un high A1.
sinon le premier caractère envoyé sera erroné.
 

pdevisme1

Senior Member
Bonsoir à tous les deux, déjà, merci de vous pencher sur mon problème.

Donc dans une cellule basic, ça donnerait ça :

Prog-BP-SMS.jpg

J'essaie de récupérer la valeur 10 ( que je mets dans la variable "donnee_recue" via l'application en pièce jointe ) quand j'appuie sur un BP connecté à C.0 via une application faite sur App Inventor et à travers un module HC06.

En fait, l'application fonctionne très bien mais quand je ré-enregistre un numéro de mobile et un message avec le BP Enregistrer de l'appli, le SMS part de suite, malgré la mise à zéro de la variable "donnee_recue". On dirait que la variable "donnee_recue" est encore à 10 ( ou que le Picaxe envoie encore 10 ).

J'ai justement pensé à mettre une variable "autorisation" pour éviter l'envoi successif de SMS mais visiblement ça ne suffit pas.

Je mets le fichier ( à renommer en .aia ) de l'application en pièce jointe au cas où.

Pour Piem : on a déjà discuté de ce fameux module HC06 sur ce forum. Tu vois, j'ai persévéré sur App Inventor mais là je bloque. Je sais qu'on pourrait faire la même chose en mieux avec un module GSM mais là, ce n'est pas dans mes cordes.

Merci d'avance aux contribueurs.
 

Attachments

PieM

Senior Member
Bonjour,

Si je comprends bien, (pas certain!) l'envoi du 10 au module BT, ne sert qu'à déclencher l'envoi d'un SMS au numéro indiqué, avec le message indiqué.

Donc tout est local au sein du HC06 hormis cet ordre qui vient du picaxe.

je ne comprends pas la ligne Bytes AvailabletoReceive > 10. Elle suppose qu'il y a plus de 10 valeurs en buffer ....

Dans le principe il faut respecter une séquence:

on rentre un N°, puis un message.
on est en attente du déclenchement par le picaxe par un test d'un byte non signé = 10 (d'autres valeurs pourraient avoir d'autre effets)
si OK on envoie le SMS
on le dit au picaxe qui doit attendre l'info du HC06 qu'un nouveau message ou numéro a été rentré avant d'autoriser une nouvelle commande.

Car là il me semble que l'on est totalement désynchronisé, le picaxe étant totalement aveugle de ce que fait le HC06.

Autre question philosophique: a quoi sert le picaxe si on a besoin également de l'appli Androïd pour définir message et N° de tel ?
 

pdevisme1

Senior Member
Bonsoir,

Bonjour,
Si je comprends bien, (pas certain!) l'envoi du 10 au module BT, ne sert qu'à déclencher l'envoi d'un SMS au numéro indiqué, avec le message indiqué.
Donc tout est local au sein du HC06 hormis cet ordre qui vient du picaxe.
C'est ça.

je ne comprends pas la ligne Bytes AvailabletoReceive > 10. Elle suppose qu'il y a plus de 10 valeurs en buffer ....
Je n'avais pas interprété cette ligne correctement. Je vais faire autrement.

Dans le principe il faut respecter une séquence:
on rentre un N°, puis un message.
on est en attente du déclenchement par le picaxe par un test d'un byte non signé = 10 (d'autres valeurs pourraient avoir d'autre effets)
si OK on envoie le SMS
on le dit au picaxe qui doit attendre l'info du HC06 qu'un nouveau message ou numéro a été rentré avant d'autoriser une nouvelle commande.
OK. J'ai bien réfléchi, j'ai une petite idée, je regarde ça ce week-end si je peux.

Car là il me semble que l'on est totalement désynchronisé, le picaxe étant totalement aveugle de ce que fait le HC06.
Alors là, justement, pour parler de la synchronisation entre l'envoi de la donnée 10 par le Picaxe et la réception de la donnée par le HC06, il y a un truc que je ne comprends pas. Dans les messages plus haut, Piem tu me dis que l'envoi de la valeur 10 par le Picaxe va durer environ 1 ms. Dans l'application, j'ai vu que l'on pouvait régler la valeur en ms de l'horloge qui va vérifier cycliquement l'arrivée ou l'envoi de données ou autre, toutes les 1000 ms, 100 ms ou autre selon le réglage ( enfin, c'est ce que j'ai compris mais peut-être que je me trompe ).

Alors, comment faire pour que l'on soit sûr que ces données vont se croiser à un moment ou à un autre ? A part mettre un temps d'1 ms pour l'horloge, je ne vois pas comment faire autrement.

Autre question philosophique: a quoi sert le picaxe si on a besoin également de l'appli Androïd pour définir message et N° de tel ?
Comme tu demandes ça, j'en déduis qu'avec un Picaxe il est possible d'envoyer au module HC06 le message ainsi que le numéro de téléphone. Mais cela suppose, je suppose, de rajouter du matériel côté Picaxe pour entrer des données. Là, je profite du Smartphone comme d'une interface déjà présente.

Je sais que l'utilisation d'un module GSM aurait été plus approprié. Dans mon cas, la construction de cette application a plus un but pédagogique personnel qu'autre chose.

Je pensais commander des moteurs ou des servomoteurs suite à l'envoi du SMS.
 

PieM

Senior Member
Alors, comment faire pour que l'on soit sûr que ces données vont se croiser à un moment ou à un autre ? A part mettre un temps d'1 ms pour l'horloge, je ne vois pas comment faire autrement.
Pas de croisement nécessaire!
quand le picaxe envoie des données, elles sont empilées dans un buffer.
L'appli android va lire le résultat quand elle veut.
 

pdevisme1

Senior Member
Bonsoir Piem, merci pour la précision. Tu n'es pas obligé de répondre tout de suite, c'est le week-end quand même !

Pas de croisement nécessaire!
quand le picaxe envoie des données, elles sont empilées dans un buffer.
L'appli android va lire le résultat quand elle veut.
Ah ! D'accord ! Je comprends mieux.

Est-ce que ces données restent dans ce buffer jusqu'à l'arrivée de nouvelles données ?

Est-ce que cela expliquerait aussi les fonctions "recevoir octet signé numéro 1", "recevoir octet signé numéro 2 etc... de la fonction Bluetooth dans app inventor ? Si oui, pourquoi on zappe le numéro 3 d'ailleurs ?

Et par exemple : dans un premier temps, tu envoies 3 données dans cet ordre : A, B, C. Elles sont donc empilées dans cet ordre. La numéro 1 étant la A etc...

Et si dans un deuxième temps tu n'envoies que les 2 données suivantes dans cet ordre : D, E. Il n'y aura plus que 2 données empilées, non ?

Elles ne "poussent" pas celles qui y sont déjà ( du genre C, D, E ) ?
 

PieM

Senior Member
Je te répondrai dans l'autre fil déjà ouvert sur le Bluetooth, car on s'éloigne du titre de ce fil...
 
Top