[RESOLU] vitesse dialogue UART

Bonjour!

Récemment je demandais de l'aide sur le dialogue avec un PIC sur ce TOPIC.

Je cherche à dialoguer avec un PIC, depuis un arduino.

Je continu le projet et me retrouve à nouveau coincé, cette foie ci tout semble ok et pourtant le pic ne réagit pas avec un arduino uno...
Il y a une différence de 24,5µs de moins pour la longueur de la trame de 9 bytes depuis le arduino (ICI) par rapport à un autre pic () ...

La différence ce jouerait sur la longueur des bit qui du coté PIC font généralement 9µs et quelque fois 8,5µs et coté arduino font tous 8,5µs.

Est ce que cela peut avoir une incidence sur la compréhension du PIC et si oui comment le corriger? (la vitesse de transmission est de 115200 bps).

En espérant fournir suffisamment d'infos, merci pour vos réponses!

ricolewis:
Bonjour!

Récemment je demandais de l'aide sur le dialogue avec un PIC sur ce TOPIC.

Je cherche à dialoguer avec un PIC, depuis un arduino.

Je continu le projet et me retrouve à nouveau coincé, cette foie ci tout semble ok et pourtant le pic ne réagit pas avec un arduino uno...
Il y a une différence de 24,5µs de moins pour la longueur de la trame de 9 bytes depuis le arduino (ICI) par rapport à un autre pic () ...

La différence ce jouerait sur la longueur des bit qui du coté PIC font généralement 9µs et quelque fois 8,5µs et coté arduino font tous 8,5µs.

Est ce que cela peut avoir une incidence sur la compréhension du PIC et si oui comment le corriger? (la vitesse de transmission est de 115200 bps).

En espérant fournir suffisamment d'infos, merci pour vos réponses!

mets un log/affichage de ton analyseur sur une durée plus étendue aprs le déclenchement et exposant les 2 voies TX et RX

Artouste:
mets un log/affichage de ton analyseur sur une durée plus étendue aprs le déclenchement et exposant les 2 voies TX et RX

Bonjour Artouste! Merci de prendre le temps de intéresser à mon cas,
Je n'ai que des sauvegardes courtes pour le moment, je pourrais faire mieux ce soir au besoin.
Voici pour le ARDUINO.
Et pour le PIC.

Si ça peut être utile je peux partager directement les sauvergardes en ".rs" de PulseView.

EDIT : Juste petite précision par rapport à mon premier topic : cette foie ci je cherche à dialoguer dans l'autre sens. (donc c'est moi qui reçois la "routine").
Voila histoire de pas créer de confusion :wink:

Bonjour

Oui des sauvegardes de Pulseview sont plus utiles que des copies d'écran
(Certains içi utilsent Logic de Saleae et non le logiciel opensource et multiplateforme Sigrok/Pulseview disponible içi
Downloads - sigrok )

al1fch:
Bonjour

Oui des sauvegardes de Pulseview sont plus utiles que des copies d'écran
(Certains içi utilsent Logic de Saleae et non le logiciel opensource et multiplateforme Sigrok/Pulseview disponible içi
Downloads - sigrok )

Bonjour Al1fch!
Je mets ça sur le drive, dans ce DOSSIER.

Ce soir je rebranche tout mon bazard et prends un log plus long, mais dans l'idée :
Une fois la trame de 9 bytes reçus (0b 02 41 03 00 04 00 0f 40) le recepteur doit renvoyer une nouvelle trame et arrete sa "routine" qui sinon se répete toutes les 70 ms.
Coté arduino, la "routine" est bien comprise, il envoie au bout de 1ms la trame (0b....0f 40) mais il n'a comme réponse que la routine encore, 70 ms plus tard...

Attention Tu ne peux pas conclure sur des différences de 0,5µs entre deux durées d'impulsions si 0,5µS est la cadence d'échantillonage !!

al1fch:
Attention Tu ne peux pas conclure sur des différences de 0,5µs entre deux durées d'impulsions si 0,5µS est la cadence d'échantillonage !!

Oui pas faux!
J'ai donc refais des captures avec une cadence plus courte, j'ai placé les fichiers dans le dossier partagé.

Dans ces derniers enregistrements je ne vois pas d'écarts significatifs des durées de bits entre les signaux émis et reçus, juste des petites variations, artefacts de l'échantillonage.

Prenons l'enregistrement Arduino02, je suppose qu'il a été pris côté Arduino et que le signal D0 est TX et D1 RX (les infos décodées ne sont pas sauvegardées, on ne sait pas qui est RX, qui est TX)

Vu comme ça il semble qu'Arduino reçoive du Pic la trame 0B 02 41 26 0F 60 toutes les 70ms, indépendamment de la trame 0B 02 41 03 00 04 00 0F 40 envoyée par l'Arduino ) c'est bien ça ?
Le problème serait que la trame émise par l'Arduino n'a pas l'effet escompté

Prenons l'enregistrement PIC02 , on voit les vers t=0,7s le Pic réagir aux trames émises par l'Arduino, pour ensuite reprendre son émission toutes les 70mS


La derniètre trame émise par l'Arduino es,t sur cet enregistrement, 0B 02 57 01 00 0F 50
Est-elle correcte , doit-elle produire l'arrêt de l'émission par le Pic?

L'autre fil de discussion (de mon point de vue c'est le même) commence en indiquant qu'un fonctionnement satisfaisant aurait été obtenu en remplaçant la carte Arduino par un PC avec un logiciel de type terminal

Dans ce cas il serait donc intéressant de comparer :
-un enregistrement PC<-> Pic où le protocole fonctionne
-un enregistrement Arduino <-> Pic ( trames reues par le Pic identiques) où il ne fonctionne pas

Une idée , comme ça... la dernière trame serait envoyée trop tôt au Pic, (flèche rouge = 157µS après la fin de la dernière trame qu'il a envoyé)

intervalle.png
Pour les trames précedentes (flèche vertes) l'intervalle était de 2,4 ms

intervalle.png

Tout d'abord, merci al1fch de prendre du temps pour te pencher sur mon problème!
Ensuite, désolé je n'ai peut etre pas été très claire sur ce que je cherchais à faire est la source de mes captures...
Je vais tacher de clarifier cela en répondant à tes posts :wink:

al1fch:
Prenons l'enregistrement Arduino02, je suppose qu'il a été pris côté Arduino et que le signal D0 est TX et D1 RX (les infos décodées ne sont pas sauvegardées, on ne sait pas qui est RX, qui est TX)

Cet enregistrement est bien celui entre le Arduino et le Pic. Plus exactement entre un Arduino et un st485 puis un autre puis un pic.

EDIT : Non un PIC mais un multiplexeur hef4052bt

L'enregistrement PIC02 est la même chose mais à la place du Arduino, un autre Pic. (cet enregistrement est donc le résultat voulu!)

Question con : comment joindre les infos décodées? :confused:

al1fch:
Vu comme ça il semble qu'Arduino reçoive du Pic la trame 0B 02 41 26 0F 60 toutes les 70ms, indépendamment de la trame 0B 02 41 03 00 04 00 0F 40 envoyée par l'Arduino ) c'est bien ça ?
Le problème serait que la trame émise par l'Arduino n'a pas l'effet escompté

Oui tout à fait!

al1fch:
Prenons l'enregistrement PIC02 , on voit les vers t=0,7s le Pic réagir aux trames émises par l'Arduino, pour ensuite reprendre son émission toutes les 70mS


La derniètre trame émise par l'Arduino es,t sur cet enregistrement, 0B 02 57 01 00 0F 50
Est-elle correcte , doit-elle produire l'arrêt de l'émission par le Pic?

Donc comme expliqué plus haut : ici pas de arduino.
Cette enregistrement est donc celui d'un dialogue sans erreurs.
La trame 0B 02 57 01 00 0F 50 est bien celle qui clos la discussion, c'est en fait une sorte d’acquittement en réaction à la derniere trame reçu.

al1fch:
L'autre fil de discussion (de mon point de vue c'est le même) commence en indiquant qu'un fonctionnement satisfaisant aurait été obtenu en remplaçant la carte Arduino par un PC avec un logiciel de type terminal

Dans mon premier topic j'avais réussi à obtenir un résultat satisfaisant avec un terminal, en envoyant la trame faisant réagir le pic plusieurs fois de suite tout en faisant une autre action directement sur pic de l'autre main...
L'erreur venait de mon code qui envoyait une trame indésirable (celle qui se repete toutes les 70ms) avant celle devant faire réagir.

Aujourd'hui, je suis de l'autre coté de la discussion (j'essais de me faire passer pour l'autre pic).

al1fch:
Dans ce cas il serait donc intéressant de comparer :
-un enregistrement PC<-> Pic où le protocole fonctionne
-un enregistrement Arduino <-> Pic ( trames reues par le Pic identiques) où il ne fonctionne pas

Finalement l'enregistrement PIC02 est celui voulu.

al1fch:
Une idée , comme ça... la dernière trame serait envoyée trop tôt au Pic, (flèche rouge = 157µS après la fin de la dernière trame qu'il a envoyé)

intervalle.png
Pour les trames précedentes (flèche vertes) l'intervalle était de 2,4 ms

Encore désolé pour mon manque de clarté, cet enregistrement étant sans problèmes.

Pour résumé :
1 -Dans mon code quand je reçois 0B 02 41 26 0F 60
2 -J'ai un delais de 1ms est je répond par 0B 02 41 03 00 04 00 0F 40
3 - Là je suis censé reecevoir en réponse : 0b 02 42 05 00 00 00 00 00 0f 41
4 -Puis continuer la discussion avec à partir de la des trames différentes à chaque fois.

Mais le point N°3 bloque...

J'ai fais des tests vite fait mais est il possible que la vitesse ne soit finalement pas 115200bps exactement?
Le arduino gere t-il bien les vitesses "batardes"? J'ai fait quelques essais hiers avec par exemple une vitesse à 115000bps, ça n'a pas l'air de changer grand chose à l'enregistrement. (que je rajoute au dossier)
A savoir que en dessous de 114500~ l'arduino ne comprends plus la reception de 0B 02 41 26 0F 60

Ok , il me faudra 'un certain temps' pour bien assimiler la problématique :wink:

Sauvegarde d'un enregistrement Pulseview accompagné des infos décodées ? je ne sais pas faire
(il me semble que Logic de Saleae le fait, c'est plus pratique)
Par contre avec Pulseview on peutau moins sauver sous forme de texte les infos décodées en sélectionnant au besoin une ligne (Export all annotations for this row)
exemple :

69262-69331 UART: RX: Start bit
69331-69886 UART: RX: 0B
69887-69956 UART: RX: Stop bit
69957-70026 UART: RX: Start bit
70026-70581 UART: RX: 02
70582-70651 UART: RX: Stop bit
70651-70720 UART: RX: Start bit
70720-71275 UART: RX: 41
71276-71345 UART: RX: Stop bit
71346-71415 UART: RX: Start bit
71415-71970 UART: RX: 01
71971-72040 UART: RX: Stop bit
72040-72109 UART: RX: Start bit
72109-72664 UART: RX: 26
72665-72734 UART: RX: Stop bit
72734-72803 UART: RX: Start bit
72803-73358 UART: RX: 0F
73359-73428 UART: RX: Stop bit
73429-73498 UART: RX: Start bit
73498-74053 UART: RX: 60
74054-74123 UART: RX: Stop bit

Un décodeur Sigrok/Pulseview est censé déterminer le débit (guess bit rate) il marche plus ou moins bien....

Le arduino gere t-il bien les vitesses "batardes"?

Le micro ATMega328 peut générer un très grand nombre de débits (voir data Sheet, partie USART)
Sous IDE Arduino,la page de référence de Serial.begin() ne parait pas limiter les débits à une liste prédéfinie
(En attaquant directement les registres UBRRn la palette des débits est ouverte...)

al1fch:
Sauvegarde d'un enregistrement Pulseview accompagné des infos décodées ? je ne sais pas faire
(il me semble que Logic de Saleae le fait, c'est plus pratique)

Bonsoir
oui le soft Logic de Saleae permet un log/enregistrement plus facilement exploitable.

Saleae avait d'ailleurs indiqué (à retrouver où et quand) que son soft ne chercherais pas à contrecarrer l'utilisation des petits clones asia 8 voies , ils ont pris la posture qu'ils avaient plus a gagner sur le reste de leur gamme qu'à vainement tenter d'interdire son utilisation .

Dans la mesure où le soft logic de Saleae est dispo/maintenu sous les principaux OS , Il n'y a à mon sens aucune raison de s'en priver 8)

ricolewis:
Cet enregistrement est bien celui entre le Arduino et le Pic. Plus exactement entre un Arduino et un st485 puis un autre puis un pic.

Rectification : Montage d'origine : Multiplexeur 4 voies (hef4052bt) --> st485 --> st485 --> PIC16f873.

Ici je cherche bien à prendre la place du PIC16f873 par un arduino.

Demain je regarderais ce que me renvoi le multiplexeur en sortie.... ça peut peut etre aider?

+1 Artouste !!

Logic de Saleae a des atouts et est tout à fait utilisable avec nos petits 'clones de Logic8'
Salea ne peut pas techniquement mettre sur la touche les clones sans se couper des Logic8 produits jusqu'à présent. Tous utilisent le même schéma type proposé par Cypress pour sa puce USB CYC68013A au VID/PID près.
Il n'y a aucune valeur ajoutée dans le schéma des Logic8 contrairement au reste de la gamme, pas de firmware résident.

-> Si sur ce forum Logic est plus utilisé que Pulseview il en publiant ses sauvegardes on augmente le nombre d'observateurs !!

Perso j'ai un faible pour l'OpenSource en général et Sigrok/Pulseview en particulier qui progresse sur le plan de l'ergonomie, prend en charge un très grand nombre d'appareils et a plus de contributeurs en matière de décodeurs. Le 100e décodeur est annoncé : radio SPI CC1101 de Texas Instruments
Voici la liste : Protocol decoders - sigrok

le multiplexeur 4052 ne fait que transmettre les signaux et , à moins qu'il soit basculé au mauvais moment, il est 'transparent" en se comportant comme une résistance d'une centaine d'Ohm

al1fch:
le multiplexeur 4052 ne fait que transmettre les signaux et , à moins qu'il soit basculé au mauvais moment, il est 'transparent" en se comportant comme une résistance d'une centaine d'Ohm

Oui tout à fait, il fait la bascule entre 4 circuits identiques.

Et sinon, je crois bien savoir d'où vient mon problème.... c'est très con mais j'y ai pas pensé.

J'ai donc fais des essais au niveau du multiplexeur :
Sans surprise il fonctionne correctement (voir dans le dossier partagé) avec une image pour les branchements.

Coté arduino, (tx et rx sur d8 et d9) on voit que ma réponse ne parvient pas au 4052.
J'imagine que le flux doit être coupé par le 1er st485. pin 2 & 3 à stimuler.

Voila-voila.... En tout cas merci de vous être penché sur mon problème! Je signalerais le post RESOLU après mes essais plus tard dans la journée ou demain mais à priori ça vient de là.