Je suis actuellement en train de travailler sur un projet auquel j'apport des évolutions. Dans la première version, j'utilise les 2 ports UART de mon ESP32-WROOM-32UE (un pour le débug, l'autre pour communiquer en série avec une device android extérieure).
J'utilise sur chaque port un driver USB-UART (FT231XS-R) et jusque là tout fonctionne normalement. Aujourd'hui j'envoie un tag en continu en tâche de fond pour vérifier si une connexion série a lieu mais c'est embêtant car j'envoie des données en parallèle et parfois elles se chevauchent. Même si des solutions soft sont possibles, j'aimerais trouver un système hardware qui me permette de créer une interruption dès qu'on vient deplug le câble USB.
J'ai relu la datasheet du FT231XS-R et j'ai vu les pins RTS,CTS,DTR et DSR (inutilisées sur la V1 de mon projet). J'ai aussi lu sur la doc API ESP le chapitre hardware flow control mais je ne sais pas vraiment si ces pins peuvent répondre à ma problématique.
Est-ce que tu as un multimètre ?
Si oui, tu pourrais vérifier l'état des fameux pins RTS, CTS, DTR et DSR. Il y a de fortes chances que l'un d'eux (CTS par exemple) change d'état au moment où le câble est débranché.
Et si l'état change en fonction du câble, tu pourras détecter s'il est branché ou non
Oui j'ai un multimètre mais je n'ai pas de device ayant ces pins de routées... à la rigueur j'aimerais partir sur la conception d'une EVM qui validerait ce type de circuit pour ne pas me planter sur la prochaine version.
J'ai compris que si DTR passe à l'état bas, ça veut dire que l'appareil/device n'est pas prête à communiquer. La pin DSR sert à l'ESP32 pour dire qu'il est prêt à communiquer.
Connaître l'état des pins en fonctions des cas est certes utile mais ce n'est pas uniquement en regardant ces changements que je vais y comprendre quelque chose, surtout si je dois faire une carte derrière. J'aimerais m'assurer que ce sont uniquement ces 2 là par exemple
Edit : je peux peut-être souder des fils entre les pins concernées sur le composant FTDI et des GPIO du micro pour tenter quelquechose avec la version actuelle
Pardon Anthhony (pour rattraper mon erreur j'en ai mis 2 )
Si je peux avoir accès aux pins en questions c'est ce que j'ai suggéré dans mon message au dessus. J'ai pas de point de tests sur ces pins donc je devrai directement mettre la sonde sur la pin donc pas très pratique. Sinon directement prendre un fil et relier à des gpios pour constater des changements d'états.
Uniquement pour détecter si le câble est débranché, pour éviter d'envoyer des tags "connecté" à l'esp32 toutes les N secondes.
Edit : De manière logiciel c'est fonctionnel mais vraiment pas pratique car le tag "connecté" coupe mes messages
En regardant sur internet des images ça m'avait pas l'air compliqué. J'ai pas du tomber sur le même module que toi. Est-ce que tu peux envoyer la référence exacte accompagnée d'une photo ?
Normalement, c'est DTR et DSR qui servent à ça mais encore faut-il qu'ils soient gérés par l'équipement distant ce qui n'est pas garanti car on utilise de moins en moins ces signaux.
RTS et CTS servent pour le handshake lors des transferts pour interrompre la communication lorsque le récepteur est saturé par exemple.
Oui il s'agit d'un FT231XS-R cf la datasheet : datasheet
Alors je comprends l'anglais technique de la datasheet mais comme je ne l'ai jamais fait je auparavant je préfère en discuter ici pour en savoir davantage.
Justement. La dernière fois que j'avais joué avec ces derniers, c'était entre un ordinateur et un viel équipement des années 1990. Dès lors que je branchais le câble série sur l'ordinateur, CTS était triggé. Il faut dire que la vitesse et la taille d'un buffer d'un ordinateur de nos jours sont tellement importantes que l'on a presque plus besoin de mettre pause aux communications. Surtout par rapport à des ordis des années 90.
La device extérieur est une tablette android samsung sur laquelle j'ai développé une appli mobile pour afficher des données. Je suppose qu'il s'agit d'USB 3.0 minimum mais de toute façon que la device extérieur le gère ou non on s'en fiche, il n'y a pas de pins DSR ou DTR sur les ports USB.
De mon côté j'imaginais relier les pins du bridge usb uart ftdi vers 2 pins de mon esp32 et écouter l'état des pins. Est-ce correct comme raisonnement?
Si j'ai la puce de soudée j'arrive à programmer la carte depuis longtemps maintenant, simplement les pins DTR et DSR sont en NC. Je peux regarder leur état et je vous tiens au courant.
Ces fameux caratères, si transmis par la tablette ou autre, et si traités par ton module FT231XS-R, ne sont pas transmis à l'Arduino. Si le FT231XS-R les prends en compte, il changera justement l'état de ces pins.
La différence est donc que tu devras câbler un fil en + pour récupérer l'état, et dans ton code au lieu de faire la vérification en envoyant un message (et j'imagine en vérifiant que tu obtiens une réponse en retour), tu aurais juste à lire l'état de ce pin
A noter qu'il est possible que tu aies besoin de pull-up (ou pull-down) sur les pins.
A ce sujet je ne peux pas affirmer quoi que ce soit. Mais si jamais tu as toujours le même état ça peut valoir le coup d'essayer. Par exemple si l'état est toujours un état bas, essaie de mettre un pull-up (et vice-versa)
La différence est donc que tu devras câbler un fil en + pour récupérer l'état, et dans ton code au lieu de faire la vérification en envoyant un message (et j'imagine en vérifiant que tu obtiens une réponse en retour), tu aurais juste à lire l'état de ce pin
Oui j'obtiens bien un acquittement en retour donc si je peux directement vérifier l'état de la pin de la liaison ftdi vers esp c'est plus simple. C'est une bonne idée de relier directement la pin au micro? Pour le débug d'un ESP il y a une circuiterie à base de transistor pour faire commuter les pins GPIO0 et EN, cf schéma : (je ne m'étais pas intéressé à cette partie c'était du pur copier coller de la doc ESP pour le routage du microcontroleur)
PS : Le screen correspond au port de débug de la carte, soit le port UART RX/TX par défaut de l'ESP32. Dans le sujet actuel, il s'agit d'un autre port UART sur des pins configurées pour de l'UART avec un autre controleur ftdi, je précise pour qu'il n'y ait pas de mauvaise interprétation.
Du coup je me posais la question dans le dernier message, je pense fixer l'état je vais faire les tests nécessaire et en fonction mettre une PD ou une PU
)
