Discussion :

[hugo_98]

Bonjour,

tout nouveau sur le forum je viens solliciter votre aide car j'ai un petit projet qui me demande de mettre en place une communication basique, série, via les ports USB de mon pc pour dialoguer avec un microcontrôleur.

les choses à savoir :
- je souhaite faire tourner ma petite application sous linux
- le microcontrôleur est branché sur un port USB du pc, port qui n'est pas déterminé pour toujours (je souhaite pouvoir brancher mon petit module sur un autre port USB quand je l'envie m'en prend sans qu'au prochain démarrage de mon application je ressorte avec une erreur du genre "le prog n'a pas trouvé le module sur /dev/ttyS0" par exemple).
- même si je suis branché à l'aide d'un cable USB, la communication elle est une communication série toute bête (pas modem ou quoi que ce soit d'autre de plus complexe...)

Je me suis déjà bien goinfré avec le man termios donc je suis maintenant capable d'utiliser mes ports série. Mais la question qui subsiste c'est comment procéder à une détection automatique de mon périphérique ? je n'ai pas envie de commencer à envoyer n'importe quoi à une pauvre clé usb branché là ou là croyant que je suis sur mon microcontrôleur ! Sans compter qu'en moyenne il y a quasiment 50 ttyS* alors si j'envoie dans le vide c'est pas top non plus....

J'ai pensé qu'il fallait déjà lister tous les ports usb disponibles sur le pc avant de commencer. Il y a donc la commande lshw que je peux solliciter avec un appel système exec, puis je fais le tri dans le fichier de sortie. Mais je trouve ça un peu lourd surtout que je ne m'intéresse vraiment qu'à 5% du fichier...

Ensuite, je pensais ouvrir à tour de rôle les ports usb matériel trouvés et par un moyen ingénieux (que je n'ai pas encore véritablement trouvé) identifier mon microcontrôleur.

L'idéal serait quand même que lorsque je branche mon module, le pc m'envoie une notif comme lorsque je branche n'importe quel autre clé usb ou souris etc... bien que ces périphériques utilisent le protocole USB....

Alors avez vous des pistes, des idées pour solutionner le problème ? Sinon je suis bon pour laisser indéfiniment branché mon module sur le même port usb et identifier le port à coup de tests successifs....du pas propre pour moi, en tous cas ça ne répond pas au cahier des charges de mon application !

Merci beaucoup ! Hugo

[Obsidian]

Bonjour et bienvenue,

Ce n'est pas forcément insurmontable mais il y a plusieurs choses à mettre au clair au départ pour pouvoir te répondre car le port USB et son protocole — en eux-mêmes — sont très sophistiqués. La toute première question est :

• Est-ce que ton module est nativement un périphérique USB qui déclare appartenir à la classe des périphériques RS/232 ou est-ce un périphérique série RS/232 ordinaire que tu branches sur un adaptateur qui, lui, se branche sur le port USB ?

Dans la première option (peu probable sauf si tu utilises des micro-contrôleurs USB avec des bibliothèques toutes faites proposées par le constructeur), ton périphérique répondra à l'énumération lancée à l'initiative du système et entamera également une négociation pour gagner des milli-Ampères supplémentaires, etc. À cette occasion, ton périphérique transmettra forcément une paire d'identifiants VendorID/ProductID sur 16 bits chacun qui permettront au système de l'identifier à coup sûr. Tu peux alors utiliser udev ou systemd pour associer une action à l'événement concerné, lorsque le périphérique est ajouté.

Dans la seconde, par contre, il n'y a rien qui te permette de savoir a priori si quelque chose est branché sur un port série natif et encore moins USB. Et ça ne te permettra sûrement pas d'identifier l'équipement terminal sans l'interroger explicitement. La seule chose que le périphérique en question puisse faire est de gérer proprement les signaux de contrôle de l'interface RS/232 comme les lignes CTS (Clear To Send) ou CD (Carrier Detect) indiquant ainsi au système que le feu est vert pour transmettre des informations via cette voie et que, donc, il y a quelque chose de branché dessus. Par contre, cela ne nous dit pas quoi.

Quand à savoir si tu risques d'envoyer par erreur des données à « une pauvre clé USB », si par ces mots tu penses au support de stockage dont on a tous l'habitude aujourd'hui, alors il n'y a aucun risque : elle, en revanche, est bien un périphérique USB authentique qui se déclare comme tel auprès du système et s'annonce comme étant un périphérique de classe Mass Storage. Le système va alors immédiatement la classer dans les disques et tu ne risqueras pas de la prendre par erreur pour un port série.

Bon courage.

[hugo_98]

Effectivement j'ai oublié de préciser comment ça se passait du côté de mon périphérique.
Pour rappel les objectifs à réaliser sont les suivants :
- lorsque je branche mon périphérique, il est reconnu par le pc (comme lorsqu'on branche n'importe quel autre périphérique)
- l'identification du port sur lequel le périphérique est connecté est automatique

Le périphérique et le pc doivent échanger des petites données de taille fixe, qui sont entre autre des paramètres de réglages, l'heure, la date etc...
Le MCU du périphérique est un attiny 13 disposant d'un UART. C'est donc par ce biais que je comptais communiquer avec le PC et le petit montage électronique adéquat pour que je puisse relier les lines TX/RX du miconcontrôleur au câble USB sans souci. Autrement dit, que le PC questionne mon MCU ou non, tant que je ne dirais pas au MCU d'envoyer quelque-chose il n'enverra rien.
Ca c'était la première solution envisagée. Je n'ai pas de hardware spécifique USB.

S'il faut absolument passer par le protocole USB pour que mon périphérique soit identifié comme n'importe quel autre périphérique USB, j'avais effectivement pensé à utiliser un convertisseur Serie/USB. Mais je ne sais pas si ce petit convertisseur est identifiable par le PC.

La dernière solution serait d'émuler en quelque sorte une interface USB du côté du MCU ce qui ne doit pas être irréalisable (du moins je pense, ne m'étant pas encore renseigné sur le sujet) en passant par l'UART. Si comme tu le dis, au branchement d'un périphérique USB, le Pc l'interroge, c'est qu'il doit bien y avoir un moyen de répondre à ces interrogations !
Si le pb ne se pose pas côté hardware c'est forcément réalisable avec le minimum de matériel je suppose....

J'espère que c'est plus clair pour la suite !

[Obsidian]

Bonjour,

Effectivement j'ai oublié de préciser comment ça se passait du côté de mon périphérique.
Pour rappel les objectifs à réaliser sont les suivants :
- lorsque je branche mon périphérique, il est reconnu par le pc (comme lorsqu'on branche n'importe quel autre périphérique)
- l'identification du port sur lequel le périphérique est connecté est automatique

Ça, c'est déjà pris en charge par toute la pile USB, si tant est que ton périphérique soit pleinement USB, ce qui est difficile à mettre en œuvre depuis zéro.

Le périphérique et le pc doivent échanger des petites données de taille fixe, qui sont entre autre des paramètres de réglages, l'heure, la date etc...
Le MCU du périphérique est un attiny 13 disposant d'un UART. C'est donc par ce biais que je comptais communiquer avec le PC et le petit montage électronique adéquat pour que je puisse relier les lines TX/RX du miconcontrôleur au câble USB sans souci. Autrement dit, que le PC questionne mon MCU ou non, tant que je ne dirais pas au MCU d'envoyer quelque-chose il n'enverra rien.
Ca c'était la première solution envisagée. Je n'ai pas de hardware spécifique USB.

Ça veut dire que tu comptais directement attaquer les lignes du port USB avec l'UART avec les lignes d'entrées-sorties du micro-contrôleur ?

Pour info, l'USB est fait pour être simple d'exploitation par l'utilisateur mais, dans sa conception, il est plus sophistiqué qu'une carte Ethernet. Il est aussi plus rapide dans sa version Hi-Speed (480 Mbits⋅s). Cela s'appelle Universal Serial Bus parce que ça transmet effectivement les données en série sur deux fils mais c'est à peu près le seul point commun avec RS/232 et les UART des micro-contrôleurs. Il y a des contraintes au niveau électrique, une transmission différentielle (D+ et D-) pour détecter les parasites, du bit stuffing imposé en hardware, une modulation des données transférées en NRZI, il y a une limitation au courant que tu peux tirer sur l'alimentation, égale à une « unité » de 100 mA (il faut réclamer logiciellement au système des unités supplémentaires au besoin… qu'il peut te refuser). Ça implique aussi que les données émises et reçues transitent par les MÊMES fils. Ça veut aussi dire que l'USB est entre 50 fois et 12500 fois plus rapide qu'une interface RS/232.

Et tout cela, ce n'est que pour garantir une connexion propre au niveau électrique d'un périphérique sur son port (en gros : ce qui passe par le câble). Une fois que la communication est établie, il y a encore des étapes logicielles transparentes pour le niveau applicatif mais requises par la norme : entre autres, le périphérique doit s'identifier lors de l'énumération (en envoyant ses identifiants), puis déclarer ses interfaces, en gros une liste de endpoints avec leur direction (même si tout transite par le même câble, au niveau logiciel, chaque endpoint est unidirectionnel, un peu comme un pipe UNIX) et déclarer une classe de périphériques à chaque interface, ce qui permet au système de savoir à l'avance de quoi il s'agit. C'est pour cela qu'une clé USB, par exemple, est non seulement reconnue comme telle quand tu la branches sur ta machine mais qu'elle est également utilisable immédiatement et sans pilote. Pour la petite histoire, quand elles sont sorties, Linux les a immédiatement reconnues car l'implémentation de la norme USB avait vite été prise en charge par les développeurs) mais pas les versions de Windows en vigueur (notamment W95 et W98), ce qui a obligé les fabricants à accompagner leur clé USB d'une disquette pilote, ce qui nous apparaîtrait comme un comble aujourd'hui.

Enfin, le transfert des données lui-même se fait par rafales de données, selon quatre modes : Control transfer, Bulk transfer, Isochronous transfer et Interrupt transfer. Pour faire court, cela émule d'une part les canaux de données et de contrôle, et rend d'autre part des services comparables au TCP et à l'UDP avec le protocole Internet.

C'est passionnant en soi de se pencher dessus mais si ce n'est pas l'objet de ton projet, alors oublie l'idée de te brancher directement sur le câble USB si ton microcontrôleur n'a pas d'interface dédiée à cela.

S'il faut absolument passer par le protocole USB pour que mon périphérique soit identifié comme n'importe quel autre périphérique USB, j'avais effectivement pensé à utiliser un convertisseur Serie/USB. Mais je ne sais pas si ce petit convertisseur est identifiable par le PC.

Si, tout comme le sont les clés USB de stockage. Ils font partie des classes de périphériques standards et s'ils ne l'étaient pas, il suffirait de les installer normalement une seule fois au départ pour ne plus avoir à y penser ensuite.

Du côté de ton PC, si tu utilises Linux, ton adapteur USB↔Série sera automatiquement déclaré « /dev/ttyUSB<numéro> » et il se manipulera exactement comme une interface série RS/232 native hébergée sur ta machine-hôte. Tu pourras donc l'utiliser comme un « /dev/ttyS<numéro> ».

La seule ambiguïté surviendrait si tu utilisais plusieurs adaptateurs identiques de la même marque sur une même machine. Ça marche sans problème mais il n'y aurait aucun moyen a priori de les distinguer entre eux. Par conséquent, il faudrait se baser sur autre chose, généralement le port USB physique utilisé, pour les départager si c'est nécessaire.

La dernière solution serait d'émuler en quelque sorte une interface USB du côté du MCU ce qui ne doit pas être irréalisable (du moins je pense, ne m'étant pas encore renseigné sur le sujet) en passant par l'UART. Si comme tu le dis, au branchement d'un périphérique USB, le Pc l'interroge, c'est qu'il doit bien y avoir un moyen de répondre à ces interrogations !
Si le pb ne se pose pas côté hardware c'est forcément réalisable avec le minimum de matériel je suppose.... J'espère que c'est plus clair pour la suite !

On a vu au dessus que le problème se présentait déjà au niveau hardware. Si ce n'était pas le cas, alors ça aurait été possible dans l'absolu, mais comme le protocole implique de nombreuses couches, il faut déjà utiliser un microcontrôleur à la fois suffisamment rapide et disposant de suffisamment de mémoire pour implémenter tout cela au propre, même si, du côté du périphérique, on peut se cantonner à n'implémenter que ce qui est utile pour lui. Ça rend la chose abordable, mais pas avec un « nano-contrôleur », si j'ose dire.

[hugo_98]

Super ! Un grand merci pour toutes ces précisions
effectivement l'objectif de mon projet n'est pas de refaire toute une interface USB (ce qui aurait pu clairement être cool !) donc je vais opter pour un convertisseur USB-Serie, si ça revient moins cher que de prendre un MCU avec une interface USB intérgrée...

Du coup côté périphérique on va dire que le souci est solutionné !
Tu dis qu'une fois mon convertisseur connecté il sera automatiquement reconnu par le PC. Donc je pourrais comme tu me le disais dans ton message précédent, utiliser udev par exemple pour identifier mon périphérique et le port utilise ?
Aussi une fois identifié, puisque tu m'indiques que la communication pourra être gérée comme une communication RS232 standart, celà implique-t-il que je pourrais gérer celà grâce aux termios ? Ou du coup puis-je utiliser une bibliothèque C conçue pour communiquer en USB ?

[Obsidian]

je vais opter pour un convertisseur USB-Serie, si ça revient moins cher que de prendre un MCU avec une interface USB intérgrée...

Au niveau du prix, je pense que que les deux cas se valent. Par contre, il sera nettement moins compliqué de mettre en œuvre une liaison série ordinaire que monter une pile USB, même si le micro-contrôleur propose des bibliothèques toutes faites.

Tu dis qu'une fois mon convertisseur connecté il sera automatiquement reconnu par le PC. Donc je pourrais comme tu me le disais dans ton message précédent, utiliser udev par exemple pour identifier mon périphérique et le port utilise ?

Oui mais tu n'en aura même pas besoin. Si tu branches un seul adaptateur USB↔Série sur ta machine, il n'y a pas d'ambiguïté et tu n'as pas besoin de connaître le port. Tu écris directement dans /dev/ttyUSB<numéro> et tu utilises stty ou les IOCTL associées pour paramétrer ton port. Normalement, <numéro> devrait être « 0 ».

Aussi une fois identifié, puisque tu m'indiques que la communication pourra être gérée comme une communication RS232 standart, celà implique-t-il que je pourrais gérer celà grâce aux termios ?

Oui.

Ou du coup puis-je utiliser une bibliothèque C conçue pour communiquer en USB ?

Tu peux le faire en C mais tu n'auras même plus besoin de t'occuper de l'USB du tout. Tout cela sera pris en charge par le système et ce sera transparent pour ton programme, qui communiquera avec le périphérique par l'intermédiaire du fichier /dev. En fait, tu pourrais même très facilement basculer d'une interface USB↔Série à une interface série ordinaire, sans rien changer à ton programme : uniquement le nom du fichier /dev ouvert.