[pucpood]

Bonjour,

Dans mon cadre professionnel, je dois développer le firmware d'une plateforme à base de PIC24.
Cette plateforme possède un module bluetooth RN4678.
Si je comprends bien, le RN4678 fonctionne exclusivement en SPP. Est-ce je traduis bien en disant qu'il ne peut être visible que comme un port COM ?
Je souhaite utiliser ce module bluetooth pour transférer des fichiers. Avez-vous déjà fait ça ? Existe-t-il un protocole recommandé/standard, des librairies, ... ?

Merci de vos retours d'expériences.

Laurent

[paulfjujo]

bonjour,

j'utilise un RN41 (MikroE click) en mode SPP esclave.... ( comme un HC06 )
dans mon appli EDFinfo et un PC avec appli RapidQ en face..
pour recevoir la trame horodatée (RTC) du linky + mesure de temp. ambiante garage..
Je peux aussi envoyer un fichier *.csv de configuration planning de chauffe pour 4 fils Pilotes via mon PC vers le PIC.

coté PC (en Win10) ,j'utilise BlueSoleil pour gérer les échanges Bluetooth <--> COM port virtuel (UART 115200bds)
et une cle USB/Bluettoth (distance entre les 2 modules ~15M et via 2 cloisons)

je suppose que le RN4678 englobe d'autres protocole que le SPP..

mais le RN41 ou un simple HC05 peut etre commuté en mode "maitre"
Le RN41 en classe 1 permet jusqu'à 30M ..
Il est possible aussi d'envoyer des fichiers vers le RN41
en gerant l'UART via CTS RTS pin ...
ou un protocole XON-XOFF ....pour cadencer le transfert
ou au fil de l'eau ,si le nb de datas est faible.

si sur ton application ton RN4678 est MAITRE (PIC-<->UART>RN)
en face un RN4678 esclave permettra d'obtenir un port virtuel COMxxx
il faut alors un convertisseur TTL/USB 6 pins ! (RN <-> UART<-> USB port COM viruel PC)

dans ton cas ,qui est le maitre PIC24 ou ?
plate forme Windows ou autre ?
quels genre d'info à échanger ?
distance maxi ?

[pucpood]

Bonjour @paulfjujo,

En bluetooth classique, le RN4678 semble ne supporter que le SPP. Il fait aussi du BTLE, mais c'est un domaine qui m'est encore moins connu que le classique (en admettant que ce soit possible !).

Derrière mon post, il y a surtout la question de savoir si je dois tout programmer "from scratch" ou si je peux espérer trouver des librairies en C. L'idée est de produire un firmware le plus possible dans les "standards" et, si possible, de ne pas réinventer la roue s'il y a déjà des choses existantes.

Concernant le choix du RN4678, il est pour le moment figé, mais si j'en trouve un autre qui facilite les échanges de fichiers (FileTransfertProfile), avec librairies en C et tout, je ferai le forcing pour qu'il soit changé.

Le TOP serait de pouvoir échanger des fichiers entre ma plateforme PIC et les outils standards d'échange de fichiers en bluetooth Windows et Android.

Et enfin, ça serait encore mieux que tout ça se fasse en BTLE parce que c'est un outil nomade, mais ça on verra plus tard.

[paulfjujo]

bonsoir,

donc tu cherches du "tout cuit ,tout rôti "
et ce n'est pas le but de ce forum ... . surtout pour un développement concernant une entreprise.
quand à trouver des librairies toutes faites ..voir plutôt sur le forum Microchip qui est le mieux placé.
ou carrément du coté Arduino et ESP32 ..

...avant de mettre les roues, il faut un chassis ...

attendons les réactions des Pro PIC24 ..

[pucpood]

Bonjour du jour !

donc tu cherches du "tout cuit ,tout rôti "

Je n'irai pas jusque là, parce que je ne mettrai pas quoi que ce soit en œuvre sans l'avoir compris , surtout pour du pro.
Mais tu comprends, il faut en parallèle que je développe mon 1er firmware, en découvrant le PIC, le bluetooth, le GPS, l'USB, l'afficheur...
Alors je compte sur les forums pour m'aider à éclaircir tout ça.
Pour l'instant j'arrive à causer avec mon RN4678, mais je n'ai pas encore trouvé un tutoriel ou un forum qui m'éclaire vraiment bien sur qui fait quoi et comment sur l'ensemble d'un process bluetooth. Peut-être ne suis-je pas sur le bon forum, il me semblait que si pourtant...

Pour du perso, pour le fun, on peut s'amuser à tout refaire de zéro, mais pour du pro je trouve dommage de refaire de qui a déjà été très bien fait par d'autres : le temps c'est de l'argent.

voir plutôt sur le forum Microchip qui est le mieux placé

J'ai déjà fouillé, peut-être pas assez ...

Quant au "chassis" , ça fait plusieurs semaines que je bosse dessus, mais quand on bosse seul sur un sujet ce n'est pas toujours facile de trouver le bon angle d'attaque.

A bientôt et merci de tes réponses.

[pucpood]

Hello,
Trouvé cette page relativement claire pour éclaircir le paysage :
http://tvaira.free.fr/projets/activites/activite-bluetooth.html

[pucpood]

Bonjour,

Je continue sur ce sujet du Bluetooth RN4678. A 115200bps ça part en cacahuète, mais ce n'est pas grave pour le moment. Je suis passé en contrôle de flux hardware pur et dur et je reste à 57600, ça suffira pour l'instant. Je commence à maîtriser le langage du RN4678. Je sais le personnaliser, le rendre "visible/invisible", l'appairer avec un smartphone Android, avec un code PIN : ça se présente plutôt bien.

Maintenant je veux échanger des données avec ce smartphone en BT Classique (SPP). J'ai fait une petite appli Android qui cherche à s'y connecter par un socket en indiquant bien l'adresse mac et l'UUID du service ... sans succès.
Côté Android, je suis sûr de mon coup parce que ça fonctionne avec une autre plateforme qui a un RN42.
Côté RN4678, j'ai vérifié les différents UUID qui semblent conformes (notamment le 1101 du SerialPortProfile).
J'ai restreint sa config au BT classique, et je spécifie le mode Quiet 0 ("Q,0"). Ça ne change rien (j'ai aussi essayé les autres modes dans le doute).

Y a-t-il quelque-chose à faire pour mettre explicitement le RN4678 en mode d'attente de connexion ? Je ne trouve aucune explication là-dessus et je pensais que, par défaut, il était dans ce mode...

Pas moyen non-plus de trouver le code la démo du kit PICtail associé à ce produit ... (vu le prix, je ne l'ai pas achetée !)

[paulfjujo]

bonsoir,

je ne connais pas le RN4678
un (vrai) HC05 peut se "souvenir" du dernier connecté
et donc retablir la connexion automatiquement des que l'autre se presence parmi les reseaux BT detecté..

[pucpood]

Bonjour et merci du retour,
Le RN4678 peut le faire aussi, mais là, c'est lui qui est censé "attendre" la connexion (je crois qu'on dit qu'il a le rôle "peripheral").
L'appairage se passe bien. C'est après que ça se gâte.
C'est l'Android (rôle dit "central") qui contacte le RN4678 grâce à l'adresse mac de ce dernier. Mais l'Android n'obtient pas de réponse.

@paulfjujo, peut-être connais-tu le RN42 ? Si oui, sais-tu si dans sa config par défaut il attend bien sagement une demande de connexion ?

Je fini par me demander si le firmware de mon RN4678 n'aurait pas besoin d'une mise à jour ...

[pucpood]

Rappel de mon environnement : plateforme animée par un PIC24FJ, programmé avec MPLAB X. Essais d'échanges Bluetooth à partir d'un smartphone Android.
Si je détaille mon test.
La plateforme avec le RN va attendre d'être contactée explicitement avec son adresse mac et en mode SPP par l'appareil Android, dans le but d'échanger des choses.
J'ai fait un factory reset du RN4678, puis un reboot.
Je lis "passivement" l'uart. J'obtiens %REBOOT% : normal.
Je continue à lire et pendant ce temps je fais une ouverture de socket sur l'adresse mac de mon RN4678 depuis mon appli Android.
J'obtiens : %CONNECT,78B8D6677F4E%%DISCONN%%CONNECT,78B8D6677F4E%%DISCONN%%CONNECT,78B8D6677F4E%%DISCONN%
L'adresse mac affichée est bien celle de mon Android (78B8D6677F4E).
J'en conclue que les tentatives de connexion de l'Android sont immédiatement suivies d'une déconnexion (à l'initiative de qui ?).

Est-ce que ça vous paraît normal ?