problème: picaxe 08M2 et module bluetooth FB155BC

[patrol1953]

Bonjour à tous
Mon projet consiste à envoyer à partir d'un PC windows des commandes servo en bluetooth. J'ai d'abord écrit en visualC (api windows) un pgm qui envoie des commandes série du type ###abc vers l'entrée serial in du 08M2.
Le 08M2 execute l'ordre et renvoie au pc la commande qu'il vient d'executer par la patte serial out (acquittement). La liaison série tourne à 19200 bauds et le picaxe à 16MHz et l'instruction principale est un "serrxd("#","#","#"),b5,b6,b7" qui boucle en attente de l'arrivée d'un caractère. En liaison cablée USB (AXE27) tout se déroule correctement à condition que le programme windows envoie les caractères avec un délai de qqs ms entre chaque caractères (10ms environ).Si les caractères sont accollés sans délai, le 08M2 ne suit pas.
Avec le module FB155BC de Firmtech (en liaison radio BT "SPP" bidirectionnelle , mode connection2, même vitesse, même config UART) en remplacement de la liaison USB, il y a un taux d'echec de 30% environ. Après examen à l'oscillo ,il s'avère que le module BT accolle de temps en temps 2 caractères ce qui explique l'échec de la commande. En général, ce genre de problème provient de la mise en buffer des caractères reçus puis d'un vidage de celui-ci induisant une discontinuité dans l'arrivée des caractères au picaxe.
Dans le datasheet du module,on trouve un chapitre 5.3 BUFFER SIZE, mais pour le FB155BC que j'utilise: "not in use".

Voilà, si quelqu'un a une idée, je suis à son écoute.

D'avance merci

Patrice

 

[PieM]

Bonjour,

Suis un peu sec sur le sujet ! mais est-ce qu'un débit plus faible que le 19200 en n'améliorerait pas les choses ? Il y a parfois des pb avec le 08M2 en fonction du débit . Les M2 ne sont pas réputés pour faire des merveilles à haut débit.
Avez vous essayé d'envoyer byte après byte ? Voire d'utiliser un hserin, malgré ses limitations ?

 

[PapyJP]

Suis un peu sec sur le sujet !

Moi complètement mais :

avez vous essayé d'envoyer byte après byte ?

Voilà une bonne idée !
Il y a un sujet, traité par Westaust55 ( excusez du peu ), sur le Forum uk ( impossible de le retrouver parmi les 13000 sujets en archive sur ce Forum ) qui traite des échanges entre Picaxes de modèles différents.
Il explique que, par construction, les fréquences horloge sont systématiquement plus faible pour les 08M2 et plus élevées pour les 18M2 ( a moins que ce soit l' inverse ? ) que celles annoncées par les data sheet.
Si bien que les échanges de caractères accolés conduisent à des échecs dus au fait que, au 20ème, 30ème bit, ... , les trames en émission et celles en réception ne se recouvrent plus et sont décalées ---> Erreurs
D' où l' idée excellente d' essayer le protocole proposé par PieM entre un PC et un Picaxe.

 

[MGU]

Bonjour,

Il y a peut être moyen d'utiliser CALIBFREQ pour ajuster les fréquences horloge et améliorer les timing?

MM

 

[patrol1953]

Merci pour vos idées.
Le problème se situe clairement au niveau du module bluetooth, puisqu'il n'apparait pas en liaison série/usb filaire à la même vitesse.(dans ce cas les caractères arrivent régulièrement espacés et non collés)
Le décalage des fréquences émission/reception peut poser problème sur de longues séquences d'envoi de caractères, mais à mon niveau j'envoie caractère par caractère avec un délai de 10 ms entre chaque , le tout sur séquence très courte de 6 caractères. Je retiens l'info si un jour je transfère des fichiers entre pc et picaxe.
Il est vrai qu'utiliser un protocole d'échange plus solide peut rendre les échanges plus fiables mais mon problème est celui d'un echange bluetooth qui accolle 2 caractères de temps en temps alors qu'ils sont émis avec un délai d'attente suffisamment long pour que le 08M2 puisse suivre la cadence.
J'ai remarqué qu'en allongeant cette tempo inter-caractère vers 50ms, le phénomène de "collage" disparait presque totalement mais le délai d'envoi d'une commande s'allonge pour atteindre 1/2 seconde ce qui rend le montage peu réactif.
J'ai fait des recherches sur le forum uk mais le nom "FB155BC" n'apparait sur aucun échange.Cela m'étonne que ce module bluetooth ne soit pas utilisé par d'autres bricoleurs picaxiens...Merci encore pour vos pistes de recherche
Patrice

 

[BESQUEUT]

Merci pour vos idées.
Le problème se situe clairement au niveau du module bluetooth,

Bluetooth est un protocole "paquet". Le µcontrôleur qui gère l'émission accumule les datas dans un tampon pour former un paquet et l'envoyer au récepteur avec un maximum d'efficacité (rapport entre le nombre d'octets transmis et le nombre de paquets. L'en-tête de chaque paquet fait plus de 120 bits...).
Il y a quand même une tempo (que vous avez mesuré autour de 50ms) qui fait que si plus rien n'est reçu, alors tant pis, on émet un paquet quasi vide...
Je n'est rien trouvé pour empêcher ce comportement ou réduire à un seul octet la taille du buffer.

Pour moi, le problème est plus coté Picaxe, incapable de recevoir 2 caractères qui se suivent ! (j'ai constaté le même problème, et je suis passé sur Xmega pour les projets qui impliquent des liaisons séries...).
Je vote également pour le récepteur hardware forcément plus performant, et pour le Background receive.

 

[patrol1953]

Je suis tout à fait d'accord que le µcode du FB155BC gère au mieux l'arrivée des caractères selon un algorithme bien à lui, et peut décider de les accoler en sortie par souci d'efficacité ,d'autant que la norme RS232 reste respectée. Je suis tout à fait d'accord qu'il est inutile de se battre avec un algorithme propriétaire non documenté mais qu'il vaut mieux augmenter les performances du picaxe , en utilisant un modèle plus hardware comme le 20X2 avec les instructions de type hserin/hserout ou par interruption, de sorte que recevoir des caractères accolés ne soit plus un problème et qu'ainsi la norme RS232 soit respectée au niveau picaxe.
Cependant je voulais rester dans mes choix initiaux de simplicité et j'ai voulu vérifier que je n'avais pas oublié un détail dans la configuration du module Bluetooth.
Mais apparemment personne ne joue avec ces petits modules.(tout en écrivant dans ce forum)
Bonne continuation!