ttyUSB0 et fstab

Le
Paul Pygeon
Bonjour,

J'ai une station météo qui doit obligatoirement être sur le pilote usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB, ma station ne peut plus transmettre ses données via Internet.

Y a-t-il moyen de forcer le pilote à rester le même même si la station est débranchée de temps à autre pour une raison quelconque? Parce que là udev me met ttyUSB1 si la station est débranchée par le système et rebranchée dans les 5 minutes suivantes.

Si vous avez une solution, je suis preneur et vous en remercie. Je suis sous Mandriva 2009.

Paul
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture !
Q: Mais pourquoi citer en fin d'article est-il si effroyable ?
R: Citer en fin d'article.
Q: Quelle est la chose la plus désagréable sur les groupes de news ?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
François Patte
Le #18071111
Le 06.12.2008 23:21, Paul Pygeon a écrit :
Bonjour,

J'ai une station météo qui doit obligatoirement être sur le pilote
usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB,
ma station ne peut plus transmettre ses données via Internet.

Y a-t-il moyen de forcer le pilote à rester le même même si la
station est débranchée de temps à autre pour une raison quelconque?
Parce que là udev me met ttyUSB1 si la station est débranchée par le
système et rebranchée dans les 5 minutes suivantes.

Si vous avez une solution, je suis preneur et vous en remercie. Je
suis sous Mandriva 2009.



Utiliser uuid:

Monter le périph usb et récupérer son uuid en faisant:

ls -l /dev/disk/by-uuid/

Puis inclure le machin dans fstab avec comme identifiant l'uuid.

--
François Patte
Université Paris Descartes
Erwan David
Le #18071481
François Patte
Le 06.12.2008 23:21, Paul Pygeon a écrit :
Bonjour,

J'ai une station météo qui doit obligatoirement être sur le pilote
usbsérie ttyUSB0 parce que si elle change de numéro de pilote USB,
ma station ne peut plus transmettre ses données via Internet.

Y a-t-il moyen de forcer le pilote à rester le même même si la
station est débranchée de temps à autre pour une raison quelconque?
Parce que là udev me met ttyUSB1 si la station est débranchée par le
système et rebranchée dans les 5 minutes suivantes.

Si vous avez une solution, je suis preneur et vous en remercie. Je
suis sous Mandriva 2009.



Utiliser uuid:

Monter le périph usb et récupérer son uuid en faisant:

ls -l /dev/disk/by-uuid/

Puis inclure le machin dans fstab avec comme identifiant l'uuid.



C'est pas du montage de disque : c'est du port série...

Il doit y avoir le moyen de faire des choses en ajoutant des règles
UDEV, mais je ne maitrise pas le comment.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Paul Pygeon
Le #18071751
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:

C'est pas du montage de disque : c'est du port série...

Il doit y avoir le moyen de faire des choses en ajoutant des règles
UDEV, mais je ne maitrise pas le comment.



En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.

SUBSYSTEM=="tty", KERNEL=="ttyUSB?", NAME="%k", SYMLINK+="wview", RUN+="/etc/init.d/wview"

Merci quand même d'avoir répondu.
Paul
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture !
Q: Mais pourquoi citer en fin d'article est-il si effroyable ?
R: Citer en fin d'article.
Q: Quelle est la chose la plus désagréable sur les groupes de news ?
Erwan David
Le #18072381
Paul Pygeon
Erwan David a papoté sur Usenet le dimanche 07 décembre 2008 09:47:

C'est pas du montage de disque : c'est du port série...

Il doit y avoir le moyen de faire des choses en ajoutant des règles
UDEV, mais je ne maitrise pas le comment.



En effet, mais en cherchant un peu plus j'ai trouvé la solution. Il faut créer une règle dans /etc/udev/rules.d/ pour que peu importe la numérotation du port USB lors de sa détection, il porte toujours le même nom. Dans mon cas, le port ttyUSBx se nommera toujours wview et une commande dans la règle udev redémarre le service idoine. Voici d'ailleurs le fichier 40-weather.rules.

SUBSYSTEM=="tty", KERNEL=="ttyUSB?", NAME="%k", SYMLINK+="wview", RUN+="/etc/init.d/wview"

Merci quand même d'avoir répondu.



ça me console de voir que j'étais sur la bonne piste.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Thierry B.
Le #18073601
--{ Erwan David a plopé ceci: }--


SUBSYSTEM=="tty", KERNEL=="ttyUSB?", NAME="%k", SYMLINK+="wview", RUN+="/etc/init.d/wview"




ça me console de voir que j'étais sur la bonne piste.



Puisque je constate qu'il y a des connaisseurs en udev, une chose
dans laquelle je suis très nul ;( je vous expose mon problème:

Je voudrais avoir un pavé numérique externe USB branché sur ma
machine, mais que ne soit pas "couplé" au clavier principal:
pour le moment, avec la reconnaissance automatique, ce que je
tape sur le pavé externe arrive sur le stdin du programme qui
a le focus. Et ça c'est pas bon pour moi.

Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.

Deux fichiers à propos de la chose:

http://foo.buvette.org/vrac/numpad.dmesg.txt
http://foo.buvette.org/vrac/numpad.lsusb.txt

--
Il n'y a pas de gestion des dependance dans la Slack, elle n'est pas
calamiteuse, elle n'existe pas.


C'est bien ce que je te dis. Elle est calamiteuse parce qu'elle n'existe pas


--{ JKB, in fcol.debats }--
Jonathan ROTH
Le #18088021
Le 07.12.2008 19:21, Thierry B. s'exprima:
Je voudrais avoir un pavé numérique externe USB branché sur ma
machine, mais que ne soit pas "couplé" au clavier principal:
pour le moment, avec la reconnaissance automatique, ce que je
tape sur le pavé externe arrive sur le stdin du programme qui
a le focus. Et ça c'est pas bon pour moi.

Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.




Je crois bien que pour l'instant ce n'est pas possible: tout
périphérique d'entrée de type clavier est connecté à stdin.

Ca pourrait être géré avec un pilote usb-hid modifié, mais plus
simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.
Nicolas George
Le #18089041
"Thierry B." wrote in message
Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.



Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement
des liens symboliques dans /dev/input/by-path/. Cf.
Documentation/input/input.txt dans les sources du noyau.

Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que
ces événements soient également envoyés à la console.
YBM
Le #18089171
Nicolas George a écrit :
"Thierry B." wrote in message
Le but est d'avoir ce pavé numérique géré par un programme
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.



Ça, on peut faire. Le device est /dev/input/eventX, et il y a normalement
des liens symboliques dans /dev/input/by-path/. Cf.
Documentation/input/input.txt dans les sources du noyau.

Ce que je ne sais pas encore faire, cependant, c'est désactiver le fait que
ces événements soient également envoyés à la console.



Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous
Debian ou Ubuntu).
Nicolas George
Le #18090271
YBM wrote in message
Regarde du côté de la commande libhid-detach-device (paquet libhid0 sous
Debian ou Ubuntu).



Ça n'a pas l'air d'être exactement ce que j'évoque.

Par défaut, on a à peu près ça :

USB ----> HID ----> console

---> evdev

Ce que j'évoquais, c'est couper le lien HID -> console, en préservant le
lien HID -> evdev, qui permet alors de récupérer les événements.

libhid-detach-device, ça coupe le lien entre USB et HID, et on peut
récupérer les événements directement en USB, au prix du décodage du
protocole HID (d'où la bibliothèque). Ça permet également de faire ce que
Thomas voudrait, mais c'est plus compliqué, et moins générique (ça ne
marchera pas pour un clavier bluetooth par exemple).
Thierry B.
Le #18095421
--{ Jonathan ROTH a plopé ceci: }--

Je voudrais avoir un pavé numérique externe USB branché sur ma
machine, mais que ne soit pas "couplé" au clavier principal:




[...]
autonome: { pave = open("/dev/keypad42", O_RDONLY); } puis
lecture des codes ascii, ou mieux, lecture des évenements
<key-up> et <key-down>, traitement et pour finir: pilotage
d'un expandeur MIDI.



Je crois bien que pour l'instant ce n'est pas possible: tout
périphérique d'entrée de type clavier est connecté à stdin.



C'est hélas la conclusion à laquelle je suis provisoirement
arrivé. J'entrevois un plongeon dans la kernelle.

Ca pourrait être géré avec un pilote usb-hid modifié, mais plus
simplement, pour ton soucis, tu peux utiliser un bête joystick/joypad.



Je préfèrerais quand même que ça fonctionne sur un kernel vanille,
éventuellement en créant des rêgles udev, en passant un paramètre
au boot...

Quand à la piste joystick, je suis en train de regarder aussi
comment ça fonctionne. Après tout, les principes ne doivent pas
être très différents.


--
INFINITY is INTEGER, unless declared REAL.
Publicité
Poster une réponse
Anonyme