bonjour et bonne année à tous et toutes.
J'ai acheté un kit robot à mon fils, qui commence à programmer.
Le soucis étant que l'API web ne reconnait pas la carte au branchement.
Je vous donne ici la démarche de débogage, mais je suis bloqué.
Donc :
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1bcf:28b8 Sunplus Innovation Technology Inc. Integrated_Webcam_HD
Bus 001 Device 003: ID 0a5c:5832 Broadcom Corp. 5880
Bus 001 Device 005: ID 046d:c077 Logitech, Inc. Mouse
Bus 001 Device 009: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Le robot est bien reconnu (CH340 seriel converter)
Ensuite
dmesg
[ 6406.465120] usb 1-3: new full-speed USB device number 9 using xhci_hcd
[ 6406.589978] usb 1-3: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 6406.590018] usb 1-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 6406.590034] usb 1-3: Product: USB Serial
[ 6406.593419] ch341 1-3:1.0: ch341-uart converter detected
[ 6406.594403] usb 1-3: ch341-uart converter now attached to ttyUSB0
[ 6406.712999] audit: type=1400 audit(1768075776.266:445): apparmor="DENIED" operation="open" class="file" profile="snap.vivaldi.vivaldi-stable" name="/proc/tty/drivers" pid=2223 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
On voit là que ya un problème car il a chargé un module ch341 et non ch340
Quelques recherches sur le net et je trouve cette page :
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/
Et donc je télécharge le ZIP avec le driver, qui se présente avec un script en C. Sauf que quand je le lance :
Make
vincent@XXXXXXXXX:~/Documents/CH341SER_LINUX/CH341SER_LINUX$ make
make -C /lib/modules/6.14.0-37-generic/build M=/home/vincent/Documents/CH341SER_LINUX/CH341SER_LINUX
make[1] : on entre dans le répertoire « /usr/src/linux-headers-6.14.0-37-generic »
make[2] : on entre dans le répertoire « /home/vincent/Documents/CH341SER_LINUX/CH341SER_LINUX »
warning: the compiler differs from the one used to build the kernel
The kernel was built by: x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
You are using:
CC [M] ch34x.o
/bin/sh: 1: gcc-13: not found
make[4]: *** [/usr/src/linux-headers-6.14.0-37-generic/scripts/Makefile.build:207 : ch34x.o] Erreur 127
make[3]: *** [/usr/src/linux-headers-6.14.0-37-generic/Makefile:1997 : .] Erreur 2
make[2]: *** [/usr/src/linux-headers-6.14.0-37-generic/Makefile:251 : __sub-make] Erreur 2
make[2] : on quitte le répertoire « /home/vincent/Documents/CH341SER_LINUX/CH341SER_LINUX »
make[1]: *** [Makefile:251 : __sub-make] Erreur 2
make[1] : on quitte le répertoire « /usr/src/linux-headers-6.14.0-37-generic »
make: *** [Makefile:5 : default] Erreur 2
Voilà voilà voilà, j'ai donc un soucis car il veut pas de mon kernel
uname -r
6.14.0-37-generic
Donc je suis bloqué, ça dépasse mes compétences actuelles.
Je pense qu'il faudrait re-compiler pour mon noyaux ?
ça m’agace pas mal, car j'ai pris du temps pour rechercher un kit qui allie les besoins d'apprentissage de mon fils, la solidité, l'évolutivité, et aussi l'obsolescence (possibilité de se passer des API du constructeurs plus tard).
merci de votre aide !
# Mauvaise version de compilateur ?
Posté par pseudonymous . Évalué à 1 (+0/-0).
Je vois
Sur ma Debian 13 (Trixie), plusieurs versions sont disponibles, la dernière étant la 14. Les versions 10, 12 et 14 sont installées.
Peut-être est-il possible d'installer la version 13 de votre distribution pour satisfaire le processus de compilation ?
[^] # Re: Mauvaise version de compilateur ?
Posté par Vincentb . Évalué à 1 (+0/-0).
Merci je n'avais pas vu/compris cette ligne.
je vais chercher déjà de ce côté.
[^] # Re: Mauvaise version de compilateur ? Ou pas
Posté par pseudonymous . Évalué à 1 (+0/-0).
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
dialuppeut 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
udevpourrait aussi faire appel àchmodpour 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
udevpeut 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
udevbasé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 …
[^] # Re: Mauvaise version de compilateur ? Ou pas
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
c'est
dialoutsur la plupart des distrosnope, a minima relancer la session.
Quand tu relances un shell / une fenêtre terminal, il hérite de la session en cours.
Sinon, dans le doute, reboote :D (mais ya pas besoin d'aller jusque là)
Très mauvaise idée. La gestion des droits est là pour une bonne raison.
Pour les thymio (des petits robots aussi), la doc https://www.thymio.org/fr/installation-sous-linux/ indique :
(vId et pId correspondent au périphérique…)
franchement, le 0666 me plaît très moyennement… tu peux avoir des outils qui vont tourner la nuit pour remodifier les droits à quelque chose de plus raisonnable pour des périphériques (msec par exemple sur Mageia)
je préfère
GROUP="dialout", MODE="0660"plutôt que de laisser tout utilisateur envoyer ce qu'il veut au robot…[^] # Re: Mauvaise version de compilateur ? Ou pas
Posté par pseudonymous . Évalué à 1 (+0/-0).
OK. Écrit de tête sans vérifier.
Oh ? Ça fait vraiment trop longtemps que je n'ai pas été confronté à ça.
Effectivement, ça sent le souffre !
Je vais corriger ma méthode de bourrin …
# Peut être pas un pb de driver
Posté par Olivier Esver (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 10 janvier 2026 à 22:56.
Dans tes logs, on voit :
Donc il est bien détecté et le lien série est sur /dev/ttyUSB0.
Par contre, il est possible que tu n'y ai accès qu'en root. Sous ubuntu/debian par exemple, il faut ajouter son utilisateur au groupe dialout pour y avoir accès.
En plus, dans le nom du driver que tu essayes de compiler il est écrit ch341 donc je pense que tu aurais le même problème ;-)
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Peut être pas un pb de driver
Posté par Vincentb . Évalué à 1 (+0/-0).
Merci je n'avais même pas vu, tellement la tête dans le guidon…
je vais regarder ce que tu proposes. Parce que comme ça, tout à l'air bon, je suis d'accord avec toi, tout est bien détecté. C'est dans le navigateur que ça marche pas.
[^] # Re: Peut être pas un pb de driver
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
oui et un
modinfo ch341sur mon noyau indique :donc le matériel
1a86:7523 QinHeng Electronics CH340 serial converterest pris en charge par ce pilote : pas besoin de recompiler de noyau, ni d'autre pilote d'ailleurs…un
ls -l /dev/ttyUSB0confirmera que l'ajout de ton utilisateur au groupedialoutdevrait faire une partie du taf'. Tu de déloggues de ta session puis te reloggue et unidte confirmera que le groupe a bien été ajouté à ton utilisateur.Ensuite bien choisir le navigateur web et sa configuration : je crois que Firefox n'a pas la gestion de l'USB (ou alors il faut configurer une option), chromium la propose (mais il y a peut-être une option à activer…) et selon que cela a été installé par le paquet de la distribution ou par snap/flatpak cela fonctionnera encore différemment…
[^] # Commentaire supprimé
Posté par MicP . Évalué à 1 (+0/-0). Dernière modification le 11 janvier 2026 à 10:10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Peut être pas un pb de driver
Posté par Vincentb . Évalué à 1 (+0/-0).
Salut et encore merci à toutes les réponses.
En réalité, j'avais deux soucis (oui, j'avais car c'est réglé).
Et tu as mis la main dessus pour les 2 !
Le premier est effectivement le type de navigateur. Je tourne sur Vivaldi et la FAQ disais que certains navigateurs ne fonctionnaient pas.
J'ai essayé opéra, chromium et ça voulait toujours pas.
ça a fonctionné avec Google chrome (snif… obligé de l'installer pour une simple API).
Le deuxième est effectivement les droits. Car il reconnaissait le montage sur ttyUSB0 mais après il plantait. J'ai rajouté l'user actif dans le groupe dialout et ça a résolue le problème.
Avec ces deux manips, c'est OK.
Bon le soucis maintenant c'est le bluetooth, mais là vraiment c'est accessoire. Mon fils peut programmer, téléverser et activer le robot. Donc tout va bien !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.