Controller un PIC à partir d'un PC par bluetooth

[invite0cebd2e1]

bonjour,

voila j'aimerais pouvoir controller un systeme electronique à partir d'un PC en utilisant le bluetooth.
J'ai trouvé un petit systeme tout fait (tapez 532 7473 sur radiospare si vous voulez voir à quoi ca ressemble) qui se connecte par bluetooth au PC et qui peut communiquer via 2 ports séries (un input ,un output) avec un microcontrolleur.

Mon probleme se situe au niveau du PC, je sais qu'on peut envoyer normalement à partir du terminal de windows des info par bluetooth au destinataire lié (ici ca serait le petit systeme) mais j'ai eu beau chercher un peu sur le net, je ne vois pas du tout quoi envoyer pour mettre un bit à 1 sur un port ou meme mettre une variable à 1.

Si quelqu'un s'est deja plongé dedans, ca m'aiderait beaucoup
-----

[Seb.26]

Tout d'abord, "of course" il te faut un dongle bluetooth sur ton PC ...

Ensuite, le logiciel "blue soleil" te permet de creer un VCP : Virtual Com Port ... en gros, tu as un nouveau port COM sur ton PC, ce que tu envois dessus arrive sur le Tx de ton module bluetooth ( de l'autre coté ), et idem pour le Rx ... simplissime !!!
( je m'en sert regulièrement pour rendre bluetooth des modules UART TTL )

@++
Seb.

[edit] si je peux me permettre, 100€ par module, c'est un poil cher ... essaye ça : http://www.sparkfun.com/commerce/pro...roducts_id=149
( il existe aussi une version DIP si tu prefère ! )

[invite819c0860]

il y a des reference aussi sur lextronic, assez peu chere et simple a metre en oeuvre. meme certaine integrant des canaux audio (le top !)

question seb : est ce que ce que tu raconte est compatible XP ? et vista ? et comment parle du au port serie en prog ? depuis win 95 et 98 et leurs protection de barbare, je n'y arrive plus et doit me contraindre a utiliser un port ethernet qui meme si il est plus complexe se pilote beaucoup plus simplement (les voie de bil gates sont impenetrable)

ps : mes langage de predilextion : Visual basic 6 et 2007 (ou 2006 j'ai un doute soudain) et C++ (borland / visual C++)

cordialement

[invite0cebd2e1]

Merci de ton aide Seb

J'ai ma foie encore quelques questions, tu dis que ce que j'envoi de l'ordinateur arrivera sur le port TX du "module bluetooth". Donc moi qui controlle mon microcontrolleur en langage asm, je vais devoir envoyer des commandes en asm si je comprends bien.

Par contre si je veux afficher des données ou meme rien qu'une phrase sur le terminal, tu me dis qu'il me suffi d'envoyer les données sur le port RX qu'il les envoyera sur le pc. Mais a vrai dire je ne vois pas trop comment envoyer ca, comment le PC comprend t'il qu'il faut afficher quelque chose, et comment l'afficher ??

ps: merci pour le lien de ton module, j'avoue que le mien faire tres cher à coté ^^
ps2: je pense qu'un ordi qui a un module bluetooth integré à des ports qui lui sont associés, enfin sur le mien c'est comme ca

[A voir en vidéo sur Futura]

[invite323b3419]

En communiquant par Bluetooth, tu envoies des états à ton microcontroleur. Tu ne le commandes pas directement, c'est le programme que tu as chargé dans ton microcontroleur (en C, en assembleur,...) qui interprete le signal.

[invite0cebd2e1]

Ca reviendrait à faire la meme chose que pour un emetteur recepteur standart ?? Creer un ptit programme de reception qui traite les données arrivant ??

Mais je ne vois tjs pas trop quoi taper sur mon terminal d'ordinateur. J'envoi directement des mots de 8bits ??

[invite323b3419]

Oui je pense qu'il faut que tu envoies des mots (pas forcément 8 bits d'ailleurs) à ton µC. Par contre je ne sais pas comment le faire depuis un pc.

[Seb.26]

En fait, ce que je propose permet de rendre transparent le BlueTooth ... c-a-d que si ton systeme fonctionne avec un cable RS232 PC<---->PIC ... ça marche ra sans rien toucher avec le bluetooth ...

En gros, le logiciel sur Pc envoie des données sur le port COM virtuel, ces données sont alors emises par le PC via le dongle BlueTooth, et arrivent sur le module BlueTooth du PIC, elles sont alors envoyées sur le PIN Tx du module ( donc la PIN Rx du PIC ) et tu les reçois comme si elles venaient directement ...

idem pour le sens PIC vers : PC

Tentative de schéma ( MDR à l'avance )

[PC.Tx]>VCP>DongleBlueTooth ) )) ))) ModuleBlueTooth>[PIC.Rx]

[PC.Rx]<VCP<DongleBlueTooth ((( (( ( ModuleBlueTooth<[PIC.Tx]

C'est Oki ?

NB: le module que je donne est compatible Audio aussi ;o)

Quad à Lextronic, quand on connait un peu cette boite, on evite ... ;o)
( ceci n'engage que moi ! )

[invite0cebd2e1]

Wep j'avais bien compris cette partie
Ton schéma n'est pas si mal ^^

Ce que je ne comprends pas c'est quoi envoyer à partir du PC. Quelle sorte de données peut on envoyer et comment les envoyer ?? (faut il utiliser un langage spécial ?)

Je suis un peu dans le flou
Autant pour un systeme emetteur/recepteur, on envoi au emetteur des mots du nombre de bits souhaité et qui sont envoyés au recepteur ou on peut travailler dessus.
Mais ici, je me vois mal taper des mots (en bits) sur mon ordi pour les recuperer sur le recepteur

[Seb.26]

OK ...

(merci pour le schéma !!! t'es indulgent ! )

Pour les données à envoyer, c'est à toi de definir un protocole de communication !

Si tu veux un début de piste, voici un exemple (très) simple :

Format generale de chaque packet :
[Header] = byte[] = { 0x22, 0x55 }
[Size] = byte[1] = longueur totale du packet
[Code] = byte[1] = le "code" du packet
[Data] = byte[] = les données optionnelles
[CRC] = byte[] = Checksum du packet

Les codes :
> 0x01 = ACK ( chaque packet correct devra être acquité )
Data = null
Reponse normale = null

> 0x03 = NACK ( emis quand un packet reçu est incorrect )
Data = null
Reponse normale = null

> 0x10 = SetPort_8b :
Data[0] = byte[1] = Num du port ( 0=A, 1=B, 2=C ... )
Data[1] = byte[1] = Valeur à ecrire dans le port
Reponse normale = ACK

> 0x20 = GetPort_8b :
Data[0] = byte[1] = Num du port ( 0=A, 1=B, 2=C ... )
Reponse normale = ACK + ValuePort_8b ( 0x21 )

> 0x21 = ValuePort_8b :
Data[0] = byte[1] = Num du port ( 0=A, 1=B, 2=C ... )
Data[1] = byte[1] = Valeur du port
Reponse normale = ACK

> ...ect...

Dans mon exemple, pour demander à ton PIC de mettre le port B à 0xFF, il faut donc envoyer le packet suivant (HEXA) :
0x 22 55 07 10 01 FF 8E ... ce à quoi le PIC repondra un ACK pour que le PC sache qu'il a bien reçu la commande ... sans quoi le PC devrait re-emetre son packet (timeout ou NACK) ...

Voila, tu as l'esprit du truc ou pas vraiment ?!

[invite0cebd2e1]

[...]

Apres y avoir pas mal reflechi (c'est pas mal compliqué au début ^^), je pense avoir compris un peu pres, à part peut etre le "8E" qui correspond donc au checksum. Ce serait en fait l'addition des valeurs de toutes les celles qui sont envoyé dans le paquet ?? et ou l'on garderait seulement les 2 LSB ? Si c'est le cas c'est pas tres pratique faut tout calculer a chaque fois ^^
Ah oui et aussi le "[Header] = byte[] = { 0x22, 0x55 }" je ne vois pas trop a quoi ca correspond enfin ce que ca veut dire

Mais donc si j'ai bien compris ce que tu appelle [CRC] et [size] c'est surtout pour verifier que le paquet envoyé n'a pas été erroné lors de son envoi par bluetooth, ce sont ce que tu appelle [code] et [data] qui vont permettre de gerer les ordres.

Ca reste assez simple (une fois qu'on a compris ) mais le seul reproche que je pourrais faire c'est que si je developpe un systeme comme ca, je ne pourrais pas en faire profiter d'autres personnes qui ne s'y connaitrait pas du tout en electronique.
Quoique qu'avec un mode d'emploi super détaillé ca doit etre possible

[Seb.26]

Le header :
> c'est simplement pour verifier que l'on soit bien au début d'une trame ... en general, je mets 2 byte, ça fait 1 chance sur 65536 de trouver ça dans un autre packet ... mais c'est vrai qu'en bluetooth ça sert sans doute à rien ... la connection étant securisé par le bluetooth lui même ... mais c'est une bonne habitude à prendre ... et puis comme ça, ton programme sera ok pour une liaision serie ( où là des octets peuvent disparaitre si c'est trop loin/bruité ).
Tu peux ne mettre qu'un octets, mais tu tombe alors à 1 chance sur 256 de trouver ton header dans un packet ...

NB: le header est utilisé lorsque le paquet que tu as dans ta FIFO est invalide ... dans ce cas, que faire ?
* vider la FIFO ? --> Tu risque de detruire le début du packet suivant, et donc de boucler sans fin
* supprimer 1 octets ? --> C'est long, car il faut verifier le packet ) chaque octets, de plus, tu peux croire voir un packet valide ...

Le header te permet de supprimer un octet jusqu'a voir { 0x22 0x55 } en debut de FIFO ... simple et efficace !

[Seb.26]

Le checksum, c'est effectivement le resultat de l'addition de tous les byte du packet.
Cela permet de verifier que les données soient valides ...

Si le Checksum n'est pas bon, il faut envoyer un NACK pour que l'emeteur repete ...

[Seb.26]

Ca reste assez simple (une fois qu'on a compris ) mais le seul reproche que je pourrais faire c'est que si je developpe un systeme comme ca, je ne pourrais pas en faire profiter d'autres personnes qui ne s'y connaitrait pas du tout en electronique.
Quoique qu'avec un mode d'emploi super détaillé ca doit etre possible

A toi de leur fournir un petit logiciel/librairie pour exploiter ton projet !

[Seb.26]

Pour finir, un mini exemple d'algo pour le noyau de reception :

Enregistrer les données Rx dans la FIFO

// On cherche le début du prochain packet
Tant que( FIFO.taille>2 ET FIFO[0]<>0x22 ET FIFO[1]<>0x55 )
. supprimer 1er byte FIFO

// On attend d'avoir 3 octets pour pouvoir tester la longueur du packet
SI( FIFO.taille>3 )
. TaillePacket = FIFO[2]

// On attend que le packet soit complet
. SI( FIFO.taille>TaillePacket )

. . // On verifie que le packet soit correct
. . SI( CalculChecksum()<>FIFO[TaillePacket-1] )

. . . // Packet pas correct : on supprimer le 1er byte, le reste sera purgé + tard
. . . supprimer 1er byte FIFO
. . . envoyer un NACK

. . SINON
. . . // Packet correct : on traite la commande
. . . CodePacket = FIFO[3]

. . . Switch(CodePacket)
. . . . case 0x01: // ACK

. . . . case 0x03: // NACK
. . . . . repeter le dernier packet

. . . . case 0x10: // Set port
. . . . . ecrire valeur FIFO[5] dans port n° FIFO[4]

. . . fin switch

. . . supprimer 'TaillePacket' bytes de la FIFO

. . . envoyer un ACK

[invite0cebd2e1]

Oui j'imaginais un peu un programme de reception comme ca en tous cas merci de ton aide.

Juste un dernier petit truc, pour l'ACK ou le NACK, qu'on renvoi à partir du microcontroleur vers le PC, on doit envoyer quoi pour que le PC comprenne qu'on a bien recu ou mal recu la trame.
Est ce que 0x01 pour ACK ou 0x03 pour NACK est compris du PC ???

Et un peu dans le meme sens, est il possible de faire un programme de reception pour l'ordi ??
C'est à dire, est ce qu'on peut lui faire afficher des phrases ou des données, en envoyant une trame particuliere aussi du microcontroleur au PC ??

[Seb.26]

Juste un dernier petit truc, pour l'ACK ou le NACK, qu'on renvoi à partir du microcontroleur vers le PC, on doit envoyer quoi pour que le PC comprenne qu'on a bien recu ou mal recu la trame.
Est ce que 0x01 pour ACK ou 0x03 pour NACK est compris du PC ???

Et un peu dans le meme sens, est il possible de faire un programme de reception pour l'ordi ??
C'est à dire, est ce qu'on peut lui faire afficher des phrases ou des données, en envoyant une trame particuliere aussi du microcontroleur au PC ??

En fait, c'est toi qui decide comment ça marche ... car c'est aussi à toi de faire le programme sur le PC ... un PC ne comprend rien tout seul ... c'est ton programme qui va interpreter ce qui va être lu sur le port COM ...

Ton Pc et le PIC vont dialoguer, dans mon exemple, j'ai mis un seul message du PC vers le PIC, mais ensuite, tu ajouteras sans doute des messages du PIC vers le PC ( un evenement sur changement d'etat de l'entrée X du PIC par exemple )

[invite0cebd2e1]

Donc on peut creer un programme aussi sur le PC qui va gerer les données qui arrive c'est cool
Le probleme maintenant c'est que je maitrise pas trop les langages de programmation pour PC mais bon c'est une autre histoire ^^

Merci pour toute ton aide