Contrôle de flux UART (PIC24FJ)

[pucpood]

Bonjour,
Après bien des visites de forums et autres sites plus ou moins exotiques, je n'ai toujours pas bien compris le fonctionnement du contrôle de flux d'un UART.
Dans mon cas, je dois faire communiquer un PIC24FJ avec un RN4678 (module bluetooth Microchip). Il semblerait que côté PIC on soit vite débordé, donc je souhaite mettre en place le contrôle de flux.
Initialement, la vitesse était réglée sur celle par défaut du RN4678 = 115200 bauds. Il y avait un shunt entre RTS et CTS du RN4678 qui, par défaut aussi, a le contrôle de flux matériel actif.
Ça communiquait, mais au bout de 6 octets ça me mettait n'importe quoi bien que le nombre d'octets fut cohérent.
J'ai passé le RN4678 à 9600 et là c'est beaucoup mieux. Sauf que c'est la préhistoire : beaucoup trop lent. Un contrôle de flux devrait, si j'ai bien compris, me permettre de temporiser le RN4678 afin de garder un débit digne de l'an 2000.
1ère étape : j'ai fait sauter le shunt entre RTS et CTS et je l'ai remplacé par un shunt "logiciel" en recopiant RTS du RN4678 sur son CTS le plus souvent possible.
Ça fonctionne.
2ème étape, je veux mettre en place un contrôle de flux, mais CTS du RN4678 n'est pas branché sur une patte offrant la fonctionnalité native RTS de l'UART du PIC. Elle est gérée comme un port standard (en sortie). Ce cas est d'ailleurs prévu dans les registres de paramétrage de l'UART.

1ère question : est-il possible de gérer logiciellement ce contrôle de flux avec CTS et RTS du RN4678 branchés sur des ports standards du PIC ?

2ème question : ne serait-il pas beaucoup plus pratique de tirer profit de la vraie patte RTS de l'UART du PIC pour qu'il gère lui-même la chose comme un grand ?

Merci d'avance
-----

[umfred]

1: oui, c'est un peu ce que tu fais quand tu décris ta 1ère étape (recopie du RTS sur le CTS)
2: bien sûr qu'il est plus pratique d'utiliser l'interface UART du PIC et tu n'aurais sans doute pas eu le souci de lecture ainsi


Sinon en vitesse, il y en a d'autres entre 115200 et 9600
Tu gérais la communication par l'UART ou par logiciel ?

[pucpood]

Bonjour @umfred,

Tes réponses semblent confirmer ce que je pensais. Je ne suis pas électronicien, mais c'est moi qui programme en C le firmware de notre compas forestier électronique (sorte de pied à coulisse géant pour mesurer les arbres). C'est mon premier projet bas niveau. Le hard est géré par un ingénieur électronicien que je ne vois qu'1 heure par semaine, qui a des idées bien arrêtées sur la question et qui a du mal à me les faire passer (ou qui n'a pas envie de re-router la carte ).
Il me proposait, après avoir mis en évidence que mon "shunt soft" fonctionnait, de le positionner stratégiquement dans mon code. Je le cite : "en retardant la recopie du bit tu retardes d'autant la vitesse".

Admettons, mais je trouve que ça fait un peu bricolage, alors qu'en utilisant la ligne RTS du PIC ça se ferait tout seul n'est-ce pas ?

[paulfjujo]

bonjour,


Le module RN4678 est-il en mode SSP , ou mode BLE évolué ?
Qui est le maitre ? le PIC ?
comment se fait la reception , par interruption RX UART ?

y a t-il un caractere specifique fin de message CR (Carriage Return ou autre caractere en fin de message du RN4678)
y a-t-il un Protocole d'échange ?

un pic peut dialoguer à 115200 bds avec un HC05 ou RN41 sans gerer de CTS ou RTS

J'ai déja testé des liaisons UART avec
gestion CTS , via une sortie dédiée et Terminal PC
Encore faut-il avoir un cordon de liaison TTL/USB incluant CTS et RTS en 6 fils ...
ou en mode protocole XON XOFF (software only)

Je n'ai pas (encore) eu l(occasion de tester la gestion RTS-CTS Hardware d'un UART 18F27K42 !!!!

[A voir en vidéo sur Futura]

[pucpood]

Bonjour paulfjujo et umfref,

En préambule (et pour umfred) : mardi, je suis monté à 57600bds avec succès, avec un contrôle de flux à mon idée et pas le 'shunt logiciel' suggéré par mon collègue et auquel je ne parviens pas à trouver un sens.

Le module RN4678 est-il en mode SSP , ou mode BLE évolué ? Veux-tu dire SSP ou SPP ? Bref, c'est un vocabulaire que je ne maîtrise pas à ce jour, mais il sait faire plein de choses cet animal, dont du BLE.
Qui est le maitre ? le PIC ?
Par défaut on est en BT classique. Je n'en suis pas encore à récupérer ce qui arrive de la radio, même pas à gérer le couplage avec une plateforme tierce (smartphone par ex).
Je me contente de passer en mode commande pour lui envoyer quelques commandes 'Get' et 'Set' afin de récupérer son adresse mac et de lui personnaliser son nom.
L'architecture est comme suit : 1 seule plateforme incluant le chef d'orchestre (le PIC24) et le RN4678. Tx/Rx du RN connectés sur Rx/Tx de l'UART du PIC, CTS/RTS connectés sur des ports 'GPIO' du PIC.

comment se fait la reception , par interruption RX UART ?
Par interruption, oui : la routine est en charge de remplir un buffer circulaire de 255 octets avec l'octet reçu, ce qui est, pour le moment, largement suffisant pour stocker une réponse complète du RN.

y a t-il un caractere specifique fin de message CR (Carriage Return ou autre caractere en fin de message du RN4678)
Chaque commande envoyée au RN4678 doit en effet se terminer par CR.

y a-t-il un Protocole d'échange ?
Le protocole est hyper simple : c'est de l'ASCII, la commande suivie de CR et en réponse, soit 'AOK', soit 'ERRx', soit le renseignement demandé (@mac ou autre).

un pic peut dialoguer à 115200 bds avec un HC05 ou RN41 sans gerer de CTS ou RTS
C'est bon à savoir, le RN41 et le RN4678 ne sont pas si éloignés...
Comment gères-tu la réception ? Comment ton RN41 gère son flux par défaut ? Contrôle matériel ?
Comment signales-tu au RN41 que tu veux lui causer ?
Dois-je comprendre que ton PIC encaisse suffisamment vite tout ce qui lui est envoyé sans jamais avoir besoin de temporiser ton RN41 ?
Dans mon cas, à 115200, ça démarre bien, mais ça part en vrille au bout de quelques octets (moins de 10), alors que mon buffer circulaire a une capacité de 255 octets.
Je précise le 'ça part en vrille' : je reçois bien des octets, et même à peu près le bon nombre, mais ils sont tout pourris. Je suppose que des bits sont perdus et que le PIC trouve ses bits de start un peu plus loin...

J'ai déja testé des liaisons UART avec gestion CTS , via une sortie dédiée et Terminal PC
Malheureusement, rien sur ma plateforme ne permet le branchement direct d'un terminal, ni pour causer avec le PIC, ni pour une communication directe avec le RN4678.

[paulfjujo]

bonjour,

Effectivement , mistake ! SPP ...Serial Port Profile

The RN41 is ...simple to integrate Class 1 Bluetooth radio
for OEMs adding wireless capability to their products.
The RN41 is ....ready to use in the SPP (Serial Port Profile) configuration.

Notion de liaison serie transparente ...

la laision entre maitre est esclave est automatique
à part une init sommaire du module RN41, en utilisant le mode AT :
pour definir un nom de device , un code PIN, une vitesse, une adresse mac pour le destinataire,
le mode maitre ou esclave ...
(exemple ici,avec suivi de l'evolution sur un terminal PC (en option)

void  Init_BT_RN41_direct()  // En aveugle,sans tester la reponse
{
     OUT_RS232
     UART2_Write_CText("---");
     UART2_Write(13);
     Delay_ms(500);
    // Enter command mode
    UART2_Write('$');  Delay_ms(5);
    UART2_Write('$');  Delay_ms(5);
    UART2_Write('$');  Delay_ms(5);
    Delay_ms(500);
    UART1_Write_CText("SN,RN41-DB49\r\n"); // Name of device
    UART2_Write_CText("SN,RN41-DB49"); // Name of device
    UART2_Write(13);
    Delay_ms(1000);
    UART1_Write_CText("SU,19.2\r\n");
    UART2_Write_CText("SU,19.2"); // Vitesse en bauds 19200
     UART2_Write(13);
    Delay_ms(1000);
    UART1_Write_CText("SP,1234\r\n");
    UART2_Write_CText("SP,1234"); // <-- Standard PIN
    //UART1_Write_CText("SP,5678");  // special for HCO5 bleu
     UART2_Write(13);
    Delay_ms(1000);
    // Authentication (1 to enable, 0 to disable)
    UART1_Write_CText("SA,0\r\n");
    UART2_Write_CText("SA,0");    // open mode no encryption
    UART2_Write(13);
    Delay_ms(1000);
    UART1_Write_CText("SO,   pas d'extension\r\n");
    UART2_Write_CText("SO,");   // Extended status string
    UART2_Write(13);
    Delay_ms(1000);
    UART1_Write_CText("ST,250\r\n");
    UART2_Write_CText("ST,250");   // 250 sec in CMD mode
    UART2_Write(13);
     Delay_ms(1000);
    // Set mode (0 = slave, 1 = master, 2 = trigger, 3 =auto, 4 = DTR, 5 = ANY 6=Payring)
    UART1_Write_CText("SM,1   1= master \r\n") ; 
    UART2_Write_CText("SM,1");
     UART2_Write(13);
    Delay_ms(1000);
    UART1_Write_CText("D\r\n");
    UART2_Write_CText("D");
     UART2_Write(13);
    Delay_ms(1000);
   UART1_Write_CText("AT dialogue ---\r\n");
    UART2_Write_CText("---");
     UART2_Write(13);
    Delay_ms(1000);
 }

apres un 1er appairrage ,le RN41 se souvient de l'adresse MAC du module connecté...



La reception via interruption ne devrait pas bloquer apres 6 caracteres ..
meme à 115200bauds !
A verifier s il n'y a pas de overflow error ou framing error
ou un probleme de parité ...
ou probleme hardware, des signaux incorrects sur RX UART ( 3,3V ou 5V ?)

nota : à une commande AT +ADDR peut etre suivie d'une reponse tres longue
(... plus longue que la majorité des réponses )
exemple

AT
OK
AT+VERSION
VERSION:3.0-20170601
OK
AT+ADDR?
+ADDR:21:13:8E51
OK
+INQ:98D3:51:F94180,1F00,FFC1
+INQ:98D3:51:F94180,1F00,FFC2
+INQ:98D3:51:F94180,1F00,FFBF
+INQ:98D3:51:F94180,1F00,FFC5
+INQ:98D3:51:F94180,1F00,FFC4
+INQ:98D3:51:F94180,1F00,FFC0
+INQ:98D3:51:F94180,1F00,FFBA
+INQ:98D3:51:F94180,1F00,FFC1
+INQ:98D3:51:F94180,1F00,FFBC
+INQ:98D3:51:F94180,1F00,FFBB
+INQ:98D3:51:F94180,1F00,FFBD
+INQ:18:E4:400006,1F00,FFA8
+INQ:18:E4:400006,1F00,FFAE   <--- horloge defil 8 matrices Verticales (CH3)
+INQ:15:83:2B6D87,104,FFCE    <---- PC ASUS cle USB Konig
+INQ:15:83:2B6D87,104,FFD3
+INQ:98D3:21:F48701,1F00,FFAF
+INQ:98D3:51:F94180,1F00,FFC3
+INQ:98D3:21:F48701,1F00,FFAE
+INQ:98D3:21:F48701,1F00,FFAD

A mon avis, il faudrait d'abord se connecter avec un simple terminal, en mode AT
pour bien comprendre comment dialogue l'équipement distant ( le pied à coulisse ?)
definir le protocole d'échange via:
* quels ordres il comprend
* comment il répond ... format, longueur de trame ..etc ..
afin d'adapter le protocole d'echange avec le PIC24 .
Pendant cette phase , 2 terminaux PC (exemple YAT terminal) sont nécessaires pour surveiller
ce qui se passe dans les 2 sens ... usage de converter TTL/USB FT232 ou cordons prolific

nota :
une sortie UART TX PIC peut aller en même temps sur un convertisseur TTL (ou LTTL)/USB -> terminal
et sur le module BlueTooth..
de meme la reception UART RX PIC peut aller aussi sur un 2em Terminal .

Le 1er niveau d'echange PIC <-> module BT en SPP devrait etre assez facile à regler avec l'etude de la datasheet du module BT ...
Le second niveau PIC <-> Pied à coulisse ... dépendra de la doc. / datasheet de celui ci...