• [^] # Re: Mauvaise version de compilateur ? Ou pas

    Posté par . En réponse au message [RESOLU] Problème module/driver - Carte Otto hp robots. Évalué à 2.

    Vu dans d'autres commentaires : avant de compiler un driver, j'ai loupé la détection effective de la puce CH, même si on a 340 d'un côté, et 341 de l'autre.

    Effectivement, une inclusion de l'utilisateur dans le groupe dialup peut résoudre le problème, qui devrait ici se résumer à des permissions manquantes pour l'accès au /dev/tty... par un utilisateur normal.
    Attention, selon le contexte, elle nécessite de relancer un shell, ou carrément toute la session graphique pour être prise en compte.

    Une règle udev pourrait aussi faire appel à chmod pour modifier ces mêmes permissions. La première solution est peut-être plus simple et propre.

    Pour la petite histoire, j'ai plus l'habitude des règles udev, mais avec des puces FTDI.
    Ces dernières ont un gros avantage : elles présentent un numéro de série. Grâce à ce numéro, la règle udev peut créer un lien symbolique vers le /etc/tty... "du moment".
    Je dis "du moment" parce qu'il arrive que lors du boot, par hasard, ou parce que le port USB a changé, ou parce que l'USB a été, est et restera l'USB ...
    Il peut arriver donc que l'ordre de détection des périphériques change. Et donc, une puce peut se voir attribuer /dev/ttyUSB2 à un moment, et /dev/ttyUSB0 à un autre.
    Avec une règle udev basée sur ce numéro de série, un lien symbolique totalement arbitraire et libre peut-être créé à chaque détection, par exemple /dev/ttyUSB-mon-device-a-moi-en-haut-a-gauche. Plus besoin de se poser la question du chiffre attribué au ttyUSB, il suffit d'utiliser le lien qui pointera toujours sur le bon ttyUSB.

    Malheureusement, je n'ai encore jamais vu de puce CH ou Prolific (ou autre ?) présentant un tel numéro de série. Et les FTDI sont sensiblement plus chère que les autres ...