Discussion :

[jibe74]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[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 !

[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

[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 !

[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...

[jibe74]

Salut,

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

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

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 )
   
   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 ?

[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 :

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...

[jibe74]

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

ls /dev/ttyS*

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

ça me retourne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/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 ?

[Emmanuel Deloget]

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

[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...

[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

[jibe74]

Salut,

Merci à tous pour votre aide.

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...

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).

[jibe74]

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

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 !

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é.