Communication par USB

Version imprimable

Salut,

J'ai à faire une application utilisant ce convertisseur, mais j'avoue être dans le brouillard pour la partie USB. Il faut dire que je découvre ce protocole (j'ai réalisé quelques applis qui utilisent RS232, mais les communications sont loin d'être ma spécialité) et j'ai du mal à faire le lien entre les différentes docs que je consulte :

http://abcelectronique.com/acquier/USB.html
http://www.motrona.eu/PDF/Uz210_f.pdf
http://www.motrona.eu/PDF/Serpro_e.pdf
http://www.developpez.net/forums/d12...ipherique-usb/

Prises individuellement et du point de vue théorique, elles me paraissent claires (bien que je découvre que l'USB est bien plus complexe que le RS232 !), mais quand j'essaie de voir comment je pourrais faire pratiquement, j'ai l'impression qu'il me manque un paquet de choses essentielles ! Est-ce seulement parce que, je l'avoue, je n'ai pas pris le temps de lire toute la première doc, et d'en avoir pris seulement ce qui me semblait indispensable ? Si je ne doute pas qu'une lecture plus assidue me serait très bénéfique, je n'ai pas l'impression qu'elle m'aidera beaucoup sur le plan pratique...

Ce que j'ai à réaliser est simple :

Récupérer sur l'USB les données converties de l'entrée analogique pour les afficher sous forme de courbe. Peu importe de les récupérer "à la volée" ou par échantilonnage. Cela doit tourner sous Linux (je développe sur Ubuntu 12.04) et je pensais utiliser libusb.

Mais voilà : je ne parviens pas à voir comment "traduire" le protocole décrit par Motrona en code C qui, via libusb, fera le dialogue avec l'UZ210...

D'abord, me faut-il un driver ? Je pensais qu'avec libusb c'était inutile, mais les explications de djuju me mettent un doute... Si je dois en utiliser un, comment le générer ?

Ensuite, comment faire les requêtes ? J'ai un peu de mal à retrouver, dans les exemples que j'ai, la relation entre les appels de fonction qui sont faits et la théorie. J'ai fait quelques analyses avec wireshark, et j'ai là aussi du mal à retrouver les bmRequestType, bmRequest, wValue, wIndex, wLength... Il y a plusieurs cas où l'ordre ou la taille des données semble différent... Bref, quelque chose m'échappe, mais je n'arrive pas à voir quoi exactement... Y aurait-il un exemple qui se rapprocherait plus de ce que je dois faire ?

Ce que j'ai quand même réussi à faire

J'ai réalisé il y a quelque temps une commande d'un bras robotisé KSR10. Bon, je n'ai pas eu grand mal : je suis parti d'un script python que j'ai trouvé sur le net, et pour la partie USB je me suis contenté de recopier les appels à libusb. Cela me paraissait assez simple et clair : après recherche du bras et obtention du handle, tout ce qu'on fait est d'envoyer une série de bits sur 3 octets, chacun commandant un moteur :
Code:

1 2 3 4 5 6 7 8 9 r = libusb_control_transfer(devh, 0x40, //uint8_t bmRequestType, 6, //uint8_t bRequest, 0x100, //uint16_t wValue, 0, //uint16_t wIndex, cmd, // Les 3 octets de la commande CMD_DATALEN, 0 );
J'arrive aussi, en réutilisant le même code d'initialisation, à obtenir un handle pour l'UZ210. Mais après, je suis bloqué ! Je ne suis pas arrivé à faire la moindre récupération de données qui fonctionne... Je ne sais même pas que faire de la commande de lecture donnée dans la doc de l'UZ210 et ne comprends pas pourquoi elle n'a aucun rapport avec ce qui est décrit dans le site d'abcelectronique.com...

Si quelqu'un pouvait m'indiquer une doc, un exemple ou autre qui me mette le pied à l'étrier...

13/03/2013, 16h33
jibe74

Salut,

J'imagine bien que sans question(s) précise(s), il est difficile de me répondre ! Toutefois, j'apprécierais qu'on m'oriente au moins un peu sur la manière d'aborder le problème.

Je viens de découvrir ce document, qui est certainement le premier à lire ! Et du même coup, je découvre le site linux-usb.org qui me sera certainement très utile.

J'ai de quoi bien m'occuper et apprendre, mais si quelqu'un pouvait m'orienter sur ce qui m'est le plus utile pour ce que j'ai à faire, ça m'éviterait de passer des heures à lire des docs qui ne me serviront peut-être jamais !

Merci d'avance à ceux qui voudront bien essayer de me conseiller !
13/03/2013, 17h01
GeantVert13

Bonjour,

Bon je ne sais pas si ça va t'avancer, mais voilà un lien qui me semble intéressant pour démarrer facilement...si tu peux utiliser Python
bonne chance
13/03/2013, 17h33
jibe74

Merci : c'est toujours une piste, et la lecture en diagonale de l'article me laisse penser qu'il est agréable à lire et facile à comprendre. Je vais regarder ça plus en détails et éventuellement faire quelques essais... si je peux puisque je n'ai pas la chance d'être l'heureux propriétaire d'un si magnifique bouton ! :)
14/03/2013, 23h51
minnesota

Salut,

J'ai regardé vite fait et un driver est effectivement nécessaire, il est téléchargeable sur leur page support, cependant l'USB n'est utilisé ici que comme "interface de liaison" entre l'appareil et le PC alors la communication ou l'acquisition se fait sur un port virtuel COM, donc sur le fonctionnement, du point de vue de ton application, tu dois voir ton appareil comme ayant une interface rs232 et non USB...
18/03/2013, 09h33
jibe74
Salut,

Merci de t'être penché sur le problème :)

Citation:

Envoyé par minnesota

J'ai regardé vite fait et un driver est effectivement nécessaire, il est téléchargeable sur leur page support

Ai-je besoin de changer de lunettes ? Il y a effectivement un driver Windows, mais je n'ai rien su trouver pour Linux, ni sur le site ni sur le CD livré avec l'appareil...

Bon, s'il y en a bien un malgré le fait que je vienne de re-vérifier sans succès, je suis volontiers preneur de l'URL à laquelle on peut le télécharger :oops:

Citation:

Envoyé par minnesota

cependant l'USB n'est utilisé ici que comme "interface de liaison" entre l'appareil et le PC alors la communication ou l'acquisition se fait sur un port virtuel COM, donc sur le fonctionnement, du point de vue de ton application, tu dois voir ton appareil comme ayant une interface rs232 et non USB

C'est bien un peu la conclusion à laquelle j'étais arrivé, mais :
1. Que faire s'il n'y a pas de driver fourni ? (en supposant que ce n'est pas uniquement un problème de vue déficiente :P)
  1. En faire un ? Mais comment ?
  2. En trouver un ailleurs ? Un driver d'adaptateur USB/RS232 quelconque (ou universel ?) peut-il faire l'affaire ?
  3. S'en passer ? Mais comment ?
2. Il y a de nombreux appareils USB qui nécessitent un driver sous Windows, et qui fonctionnent très bien sans sous Linux. D'après toi, un driver Linux serait bien obligatoire dans ce cas ?
3. Que l'USB ne serve que d'interface de liaison (on parle bien des couches OSI, là ?) empêche-t-il toute communication par l'application elle-même ? Ou est-ce dans ce cas vraiment très différent d'une communication plus "classique" par USB, au point que ce soit impossible avec les bibliothèques standard ?
19/03/2013, 09h01
minnesota

com* il y avait un package, j'ai supposé qu'il y était inclus ou au minimum qu'il contiendrait un "readme" pour Linux...

Donc si c'est pas fourni et que ton système dispose d'un pilote générique, alors ton "device" devrait être accessible depuis le fichier virtuel /dev/ttyUSBx (x étant l'index 0... 1... 2..., attention à la casse). Si tu veux voir comment c'est fait, voici les liens vers le code source et le site, et à ce que j'ai pu voir, c'est intégré au noyau Linux depuis sa version 2.4.20, donc normalement ça devrait être bon pour toi.

Si toutefois ton appareil n'est pas reconnu alors tu peux tenter un pilote compatible fourni par FTDI (le virtual com port driver), d'ailleurs y'a de fortes chances que c’est un de leurs chips qui est utilisé dans ton appareil... et c'est ce que présuppose le pilote précédemment cité... Sinon, en tout et pour tout, les fournisseurs possibles de ce genre de microcontrôleurs se comptent sur les doigts de la main (donc FTDI, Silicon Labs, Prolific...), une recherche autour de "USB to UART bridge OR controller" utilisée conjointement avec les vendor_id et product_id retournés par la commande lsusb (ou un affichage de /proc/bus/usb/devices) ou équivalent devraient t'amener à bon port... aussi, au début, pour la prise en main, tu auras peut être besoin de dmesg, screen pour identifier le bon device et stty pour configurer le baud rate entre autres. Comme j'utilise pas Linux, je peux pas t'aider plus sur ces points.

voilà, donc normalement avec tout ça tu devrais t'en sortir, sinon n'hésite pas à contacter le fabricant et demander une mise en relation avec le support ou service technique :

Citation:

Envoyé par extrait page contact du site motrona.fr

ICA Systèmes Motion
Tél. 0390226683
Fax. 0390226684
info@icacontact.fr

Edit:

c'est une faute que j'ai laissée volontairement à la rapide relecture, car je la trouve très à propos... ça veut pas dire qu'il y'en a pas d'autres... :P

Salut,

Merci pour toutes ces explications, et désolé pour la lenteur à la réaction... Je fais plusieurs choses à la fois, et j'ai un peu de mal à le gérer :oops:

Citation:

Envoyé par minnesota

com* il y avait un package, j'ai supposé qu'il y était inclus ou au minimum qu'il contiendrait un "readme" pour Linux...

Hélas, il y a encore trop de fabricants qui n'ont même pas idée qu'il y a d'autres OS que Windows...

Il semble que le driver se charge bien :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ hwinfo --usb [...] 14: USB 00.0: 0000 Unclassified device [Created at usb.122] UDI: /org/freedesktop/Hal/devices/usb_device_2720_555a_070512555A00_if0 Unique ID: UfPf.ZWfqRc5yOmB Parent ID: 2XnU.CCckIHJirFC SysFS ID: /devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0 SysFS BusID: 5-1:1.0 Hardware Class: unknown Model: "MOTRONA Motrona UZ210xx" Hotplug: USB Vendor: usb 0x2720 "MOTRONA" Device: usb 0x555a "Motrona UZ210xx" Revision: "1.00" Serial ID: "070512555A00" Driver: "cdc_acm" Driver Modules: "cdc_acm" Speed: 12 Mbps Module Alias: "usb:v2720p555Ad0100dc02dsc00dp00ic02isc02ip00" Driver Info #0: Driver Status: cdc_acm is active Driver Activation Cmd: "modprobe cdc_acm" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #10 (Hub)
Mais maintenant, j'hésite :

Code:

ls /dev/ttyS*

me donne la liste complète de ttyS0 à ttyS30, ça ne m'avance guère !
Si je fais

Code:

sudo setserial -bg /dev/ttyS[0-9]*

ça me retourne :

Code:

/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A

Le 16550 me gène pour trois raisons :
- ce n'est pas de l'USB,
- J'ai un port RS232 sur ce PC, justement équipé d'un 16550
- Quand je débranche l'UZ210, setserial ne change pas sa réponse, ttyS0 correspond toujours au 16550...

Il semble donc que l'UZ210 ne soit pas affecté à un /dev/ttySx, me trompe-je ? Si c'est le cas, comment faire ? J'avais cru comprendre que c'est le driver qui fait cette affectation automatiquement quand il détecte un périphérique qu'il sait gérer ???

Ensuite, une fois que je pourrai utiliser /dev/ttySx, comment devrai-je faire ? Gérer ça comme si c'était une RS232 classique, ou utiliser libusb ?

26/03/2013, 10h45
Emmanuel Deloget

Citation:

Envoyé par jibe74

Salut,

<snip>

Il semble donc que l'UZ210 ne soit pas affecté à un /dev/ttySx, me trompe-je ? Si c'est le cas, comment faire ? J'avais cru comprendre que c'est le driver qui fait cette affectation automatiquement quand il détecte un périphérique qu'il sait gérer ???

Ensuite, une fois que je pourrai utiliser /dev/ttySx, comment devrai-je faire ? Gérer ça comme si c'était une RS232 classique, ou utiliser libusb ?

Sous Linux, les ports séries USB sont accessibles via /dev/ttyUSBx, pas /dev/ttySx :)
26/03/2013, 16h51
minnesota

salut tout le monde,

jibe74, même si tu es très pris, essaye au moins de ne pas lire les réponses en diagonale... c'est dommage parce que ce manque d'attention te fait poser des questions auxquelles j'ai déjà répondu, mais pire, il te fait perdre ton temps dans de mauvaises directions... je te laisse relire...
28/03/2013, 16h11
Masmeta

Je recherche pour mon problème et je suis tombé sur ton poste.
Juste pour information dans Linux, il faut avoir les droits pour lire et écrire sur l'usb.

Tu as 2 choix possible sous Ubuntu :
1. Créer une règle UDEV => permanent
2. En ligne de commande faire un chmod +rw 666 => a chaque connexion de ton appareil.

Pour l'utilisation de la libusb, il y a sous Windows un driver à générer et ensuite utiliser une dll.
Pour Linux, j'avais installer directement la *.so a partir de apt-get

En espérant, t'avoir fait avancer un peu
01/04/2013, 11h23
jibe74

Salut,

Merci à tous pour votre aide.

Citation:

Envoyé par minnesota

jibe74, même si tu es très pris, essaye au moins de ne pas lire les réponses en diagonale... c'est dommage parce que ce manque d'attention te fait poser des questions auxquelles j'ai déjà répondu, mais pire, il te fait perdre ton temps dans de mauvaises directions... je te laisse relire...

:oops: Désolé...

Effectivement, j'ai vu la confusion entre /dev/ttyUSBx et /dev/ttySx, rappelée par Emmanuel Deloget.

Je vais donc essayer d'être plus organisé et attentif, et surtout revoir tout ça en lisant plus attentivement vos messages et les docs. Il va probablement me falloir un peu de temps si je ne veux pas risquer de semblables confusions en voulant aller trop vite !

Je reviendrai poser des questions plus pertinentes ou tenir au courant de la solution adoptée dès que j'aurai revu tout ça (n'hésitez pas à me rappeler à l'ordre si vous pensez que j'ai oublié ! Je mets un suivi par mail sur cette discussion).
01/04/2013, 11h35
jibe74

Citation:

Envoyé par Masmeta

Tu as 2 choix possible sous Ubuntu :
1. Créer une règle UDEV => permanent
2. En ligne de commande faire un chmod +rw 666 => a chaque connexion de ton appareil.

Toutafé ! Encore faut-il le faire sur le bon port, sans confondre /dev/ttyUSBx et /dev/ttySx :oops:

La règle UDEV est bien sûr la meilleure méthode, même pour les tests : elle est assez facile à modifier si besoin, et ça évite de s'arracher les cheveux parce qu'on a oublié de refaire le chmod après redémarrage ou déconnexion/reconnexion !

Citation:

Envoyé par Masmeta

Pour Linux, j'avais installer directement la *.so a partir de apt-get

Oui, mais quelle *.so ? (bon, la question est peut-être idiote : je n'ai pas encore pris le temps de tout relire attentivement, et je passe peut-être à côté d'un truc aussi gros que /dev/ttyUSBx et /dev/ttySx...).

En tous cas, merci pour tes infos, Masmeta. Je te tiens au courant dès que j'ai avancé.