Vous n'êtes pas identifié(e).
Si tu veux visualiser l'effet de la manipulation des commandes, il faudrait l'augmenter afin de voir une trame d'octets entière.
J'ai tenté, mais je n'ai pas réussi à synchroniser correctement. Par contre, tu ne crois pas qu'on devrait quand même voir quelque chose bouger ? Les largeurs et nombre d'impulsions devraient varier, même sans synchro ça devrait se remarquer, or strictement rien ne bouge...
Je n'ai pas utilisé d'oscilloscope depuis environ 15 ans, donc ma science du déclenchement est complètement rouillée.
Donc, un peu plus récente que la mienne ! Reste que je ne vois pas comment on pourrait faire : pour autant que je me souvienne, on déclenche sur un niveau, en regardant ce qu'il y a juste avant ou après pour savoir si c'est un front montant ou descendant. Ou alors, il faudrait un déclenchement externe, et donc que l'UART ou le récepteur fournisse un top synchro au moment du start bit...
Donc il y a un problème qui écroule le niveau bas (actif). Tu es sûr du câblage ?
Oui, trois fils avec photos, je ne devrais pas me tromper, quand même ! Et si je me trompe, il va y avoir un problème d'alim (masse, plus, signal...) !
La sortie du récepteur sur l'entrée RX de l'UART et la masse/0V sur la masse ?
Ben oui, je répète : si c'était faux, le récepteur serait mal ou pas alimenté.
Tu as enlevé le pont entre TX et RX ?
Oui : je suis obligé pour brancher autre chose à la place.
Bon, je crois donc qu'on peut en conclure que mon UART chinoise ne vaut pas grand chose et qu'il faut que je m'en procure une autre ?
Hors ligne
Les largeurs et nombre d'impulsions devraient varier
Non, seulement le niveau des bits de données des octets transmis. Je répète, ce n'est pas du PWM. C'est une transmission de données numériques.
que l'UART ou le récepteur fournisse un top synchro au moment du start bit...
Pas suffisant, ça déclencherait sur le bit de start n'importe quel octet. Or pour avoir une chance d'observer quelque chose il faudrait déclencher sur le premier octet d'une trame. Pour ça il faudrait un temporisateur réarmable qui se déclenche sur front descendant et a une durée supérieure à quelques octets (pour rester actif tant qu'il y a des octets transmis, jusqu'à la fin de la trame).
Bon, je crois donc qu'on peut en conclure que mon UART chinoise ne vaut pas grand chose
En rebouclage, sa sortie TX arrive quand même à envoyer quelque chose sur son entrée RX, donc l'entrée RX ne doit pas être si pourrie.
D'ailleurs tu pourrais regarder la forme du signal sur la sortie TX à vide et rebouclé sur RX. Pour générer du trafic en continu sur TX tu peux envoyer un fichier quelconque ou /dev/zero, /dev/urandom... sur /dev/ttyUSBx.
C'est peut-être la sortie du récepteur qui a une impédance trop élevée (peut-être endommagée après avoir été connectée sur le bus USB).
Tu peux essayer d'évaluer grossièrement les impédances
- de la sortie signal du récepteur (non connectée à RX) en connectant des résistances de différentes valeurs entre la sortie et le +3,3V et en observant à l'oscilloscope jusqu'à quelle valeur minimum de résistance le niveau bas reste acceptable (0,5 V max par rapport à GND)
- de l'entrée RX de l'UART (non connectée au récepteur) en connectant des résistances de différentes valeurs entre RX et le +3,3V et en observant au voltmètre quelle valeur minimum il faut pour faire basculer la tension de l'entrée en dessous de 0,8V.
Dernière modification par raleur (09-08-2020 18:13:11)
Il vaut mieux montrer que raconter.
Hors ligne
Non, seulement le niveau des bits de données des octets transmis. Je répète, ce n'est pas du PWM. C'est une transmission de données numériques.
Ben... Excuse-moi de ne pas être d'accord, mais un octet donne une trace de ce genre, et un autre octet aura une trace différente, avec d'autres bits, et donc des largeurs et un nombre d'impulsions variable, ce qui devrait quand même se voir...
Bon, quoi qu'il en soit, il y a effectivement un problème d'adaptation d'impédances, reste à déterminer pourquoi. Un défaut du récepteur n'est pas impossible, mais j'en ai deux et je suis presque sûr de n'en avoir branché qu'un seul en USB, donc l'endommagement dû à ce branchement est très peu probable. Je vais essayer de voir ce qu'il en est...
Hors ligne
un octet donne une trace de ce genre, et un autre octet aura une trace différente, avec d'autres bits, et donc des largeurs et un nombre d'impulsions variable, ce qui devrait quand même se voir
Oui, mais pour observer cela il faudrait pouvoir visualiser un octet à la même position dans les trames successives. Or le déclenchement se fait sur n'importe quel octet, et la trace sur la photo est déjà la superposition d'octets de valeurs différentes (il y a des traces à l'état haut et à l'état bas pour chaque bit sauf les bits de start et de stop) donc un changement de valeur de certains octets n'est pas forcément visible.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Suggestions bienvenues !
Je ne me serais pas embêté et j'aurais utilisé une porte logique non inverseuse quelconque (buffer, AND ou OR) ou deux portes logiques inverseuses (NAND ou NOR) en cascade, mais si le signal de sortie est bon, c'est le principal. Tu devrais peut-être mettre une résistance en série sur la base du premier transistor, sinon si l'impédance de sortie du récepteur à l'état haut est faible, elle et le transistor risquent de souffrir.
La LED "data" de l'UART reste obstinément éteinte
D'après le schéma que j'ai transcrit à partir des photos du circuit imprimé, la led DATA est cablée sur la sortie TX, donc c'est normal qu'elle ne s'allume pas avec l'activité sur RX.
Tu as relancé inputattach --dump ou bien picocom sur le port série ttyUSBx en 115200 bit/s pour voir s'il reçoit quelque chose ?
Dernière modification par raleur (15-08-2020 18:45:42)
Il vaut mieux montrer que raconter.
Hors ligne
Je ne me serais pas embêté et j'aurais utilisé une porte logique non inverseuse quelconque (buffer, AND ou OR) ou deux portes logiques inverseuses (NAND ou NOR) en cascade,
Ben le problème, c'est que l'UART fout pas mal de trucs à genoux. Pas vraiment pu déterminer l'impédance, et le comportement est bizarre : avec une résistance de 47Ω vers la masse, j'ai encore plus de 2V sur RX, ce qui laisse supposer une résistance de pull-up sur le 3.3V de 30.5Ω. Par contre, chose curieuse, quand je court-circuite RX à la masse, j'ai un courant de 48mA, ce qui laisse supposer une résistance de pull-up de 68.8Ω... J'ai du mal à comprendre comment c'est foutu ! Donc, j'ai préféré un transistor qui mette RX à la masse (0V) lorsqu'il est saturé, au moins je suis sûr !
Tu devrais peut-être mettre une résistance en série sur la base du premier transistor, sinon si l'impédance de sortie du récepteur à l'état haut est faible, elle et le transistor risquent de souffrir.
C'est vrai, je n'y avais pas réfléchi...
Tu as relancé inputattach --dump ou bien picocom sur le port série ttyUSBx en 115200 bit/s pour voir s'il reçoit quelque chose ?
picocom ne reçoit rien du tout (mais je ne suis pas très sûr des bits de start/stop/parité... pas pris le temps de fouiller le net ou d'essayer toutes les combinaisons)
Par contre, à propos d'inputattach, quand j'ajoute --dump, il n'est pas content :
Quand je n'ajoute pas l'option, il semble se comporter normalement, mais on ne reçoit rien. Serait-ce le module que j'ai compilé qui n'est pas bon ?
Hors ligne
avec une résistance de 47Ω vers la masse, j'ai encore plus de 2V sur RX, ce qui laisse supposer une résistance de pull-up sur le 3.3V de 30.5Ω
Et surtout un courant de plus de 40 mA. C'est totalement anormal. Un pull-up de polarisation n'aurait jamais une impédance aussi faible.
quand je court-circuite RX à la masse, j'ai un courant de 48mA, ce qui laisse supposer une résistance de pull-up de 68.8Ω... J'ai du mal à comprendre comment c'est foutu !
D'une part, l'impédance d'un étage d'entrée ou de sortie logique n'est pas linéaire. Parfois le pull-up n'est même pas une vraie résistance (les résistances de valeur élevée sont encombrantes à intégrer sur une puce de silicium) mais une source de courant active, d'impédance théorique infinie. Si la valeur du courant varie peu en fonction de la tension, alors c'est peut-être le cas ici.
Ou bien l'entrée RX est grillée et s'est mise en court-circuit à la masse. Tu as revérifié si picocom recevait toujours l'écho avec le cavalier de rebouclage entre TX et RX ?
picocom ne reçoit rien du tout (...)
Par contre, à propos d'inputattach, quand j'ajoute --dump, il n'est pas content :
Tu les as bien exécutés sans avoir lancé (ou après avoir arrêté) l'instance d'inputattach sur le port avec --fsia6b ?
Dernière modification par raleur (15-08-2020 20:59:05)
Il vaut mieux montrer que raconter.
Hors ligne
Si la valeur du courant varie peu en fonction de la tension, alors c'est peut-être le cas ici.
Peut-être. Mais reste que, comme tu dis, un courant de plus de 40mA, c'est trop...
Tu as revérifié si picocom recevait toujours l'écho avec le cavalier de rebouclage entre TX et RX ?
C'est ce qui me surprend : aucun problème de ce côté ! Mais bon, si cette UART n'est pas conforme aux normes et que le courant élevé qu'on constate est "normal" pour elle, encore heureux que la sortie TX soit compatible avec !
Tu les as bien exécutés sans avoir lancé (ou après avoir arrêté) l'instance d'inputattach sur le port avec --fsia6b ?
Pour picocom, oui. Pour inputattach, pas d'instance en cours et je lance :
J'ai essayé avec et sans le --baud 115200, puisque normalement --fsia6b positionne déjà à 115200bauds.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
L'impédance d'entrée devrait être élevée.
Effectivement, d'après la DataSheet, ça semblerait... C'est pourquoi je suis assez étonné des mesures que j'ai faites ! Pourtant, elles sont assez confirmées par le comportement, en particulier l'écrasement du signal sans mon petit adaptateur...
Pourrait-il y avoir un court-circuit avec une des broches voisines du circuit intégré (TXD et RTS) ? Je sais bien que l'exemplaire sur la photo n'est pas le tien, mais on peut voir une masse claire entre les broches RXD et RTS (au niveau des lettres "SI" du marquage "SILABS") qui ne me plaît pas trop.
Ébédidon ! Je n'avais pas regardé la photo si attentivement ! C'est vrai qu'il semble bien y avoir un court-circuit entre les broches ! Mais mon exemplaire est assez clean de ce côté là.
Après, le PCB semble être du 4 faces, va savoir ce qui se passe sur les faces centrales ! Un via pourrait être placé trop près d'une masse ou va savoir...
Je commence à être à court d'idées.
Déjà, merci infiniment pour ton aide très précieuse et le temps que tu as passé sur ce problème C'est vraiment sympa !
Je propose qu'on attende une ou deux semaines que j'aie reçu la nouvelle UART que j'ai commandée. On peut effectivement se demander assez sérieusement si celle que j'ai n'a pas un gros défaut soit de conception soit de réalisation...
Je te tiens au courant dès que j'ai reçu et testé la nouvelle, ça confirmera/infirmera déjà cette question.
Hors ligne
C'est vrai qu'il semble bien y avoir un court-circuit entre les broches
Ce n'est pas forcément de l'étain, ça pourrait aussi bien être un reste de flux de soudure mal nettoyé mais inoffensif car isolant.
Mais mon exemplaire est assez clean de ce côté là.
Ça vaut quand même le coup de contrôler hors tension à l'ohm-mètre ou au testeur de diode entre broches adjacentes et avec VDD (3,3V).
le PCB semble être du 4 faces
Qu'est-ce qui te fait dire cela ? A mon avis la densité du circuit ne justifie pas 4 couches et un double face suffit largement. D'ailleurs toutes les liaisons nécessaires me semblent présentes sur les deux faces.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (16-08-2020 13:50:09)
Il vaut mieux montrer que raconter.
Hors ligne
Un 4 couches serait séparé en 3 parties.
Evidemment ! Suis-je bête !
Hors ligne
et j'ai bien des tas de données qui défilent
Pas essayé encore en utilisation réelle : je viens aussi de rajouter une carte graphique, et mon simulateur de drone ne fonctionne plus (probablement juste à reconfigurer). FlightGear semble ne pas accepter ça comme joystick, à voir, mais je n'en suis pas vraiment surpris. En tous cas, je ne vois pas pourquoi, maintenant, la télécommande ne pourrait pas être utilisée comme joystick au moins avec un simulateur de drone (je poserai la question pour FlightGear sur le forum dédié), ce qui est mon but principal, au moins tant qu'un quadricoptère à peu près correct n'est pas dispo sous FlightGear.
Donc, merci infiniment pour ton aide précieuse et efficace, @raleur Je passe le sujet en résolu, le problème venait bien de toute évidence de cette UART. Je redonne à toutes fins utiles celle qui fonctionne bien : c'est ce modèle-ci, probablement dispo chez d'autres fournisseurs.
Hors ligne