Merci pour l'info, c'est bon à savoir, et c'est l'occasion de changer mes mauvaises habitudes. La preuve : j'utilise encore PuTTY pour de la liaison série ! À ma décharge, je suis parfois obligé de travailler sous Windows plutôt que Linux, et PuTTY reste le même. Par contre, quelle blague, ces ports COMx sous Windows …
Je mentionne CuteCom juste pour le principe, et parce qu'il a aussi une case à cocher "Auto reconnect". Et parce que c'est une IHM, pour ceux qui préfèrent.
IHM dont je me passerai avec joie en testant tio !
Au passage, j'utilise quelques adaptateurs USB-UART basés sur des puces FTDI. À ma connaissance, ce sont les seules à présenter un numéro de série.
J'utilise ce numéro de série pour créer un lien symbolique dans /dev, via une règle udev, et éviter ainsi le caractère aléatoire de l'énumération des périphériques sur les bus USB.
C'est à dire qu'une puce FTDI peut être détectée comme /dev/ttyUSB2, et une autre fois comme /dev/ttyUSB0. Avec une règle udev1 , un lien symbolique, par exemple /dev/ttyFTDI5 -> ttyUSB0 est créé à chaque démarrage. Et je peux m'adresser à /dev/ttyFTDI5 sans me préoccuper de l'ordre de détection (et grace à une petite étiquette "5" collée sur la puce en question).
Avec d'autres puces, comme les CHxxx, il me semble que c'est impossible. Avec udevadm, je n'ai jamais trouvé de propriété exploitable pour arriver au même résultat.
1 : KERNEL=="ttyUSB*", ATTRS{serial}=="<n° de série de votre puce FTDI>", SYMLINK+="ttyFTDI5" placé dans un fichier /etc/udev/rules.d/<nom de votre choix>.rules
Il n'y a pas vraiment de problème.
Mais les fonctionnalités sont basiques, comparées aux autres outils cités ici.
PuTTY ne propose pas d'auto-reconnexion par exemple. Mais rendons à PuTTY … C'est d'abord un outil de connexion SSH et Telnet.
# Merci
Posté par lolop (site web personnel) . Évalué à 2 (+0/-0).
Minicom… fffff
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# CuteCom
Posté par pseudonymous . Évalué à 5 (+5/-0).
Merci pour l'info, c'est bon à savoir, et c'est l'occasion de changer mes mauvaises habitudes. La preuve : j'utilise encore
PuTTYpour de la liaison série ! À ma décharge, je suis parfois obligé de travailler sous Windows plutôt que Linux, et PuTTY reste le même. Par contre, quelle blague, ces ports COMx sous Windows …Je mentionne
CuteComjuste pour le principe, et parce qu'il a aussi une case à cocher "Auto reconnect". Et parce que c'est une IHM, pour ceux qui préfèrent.IHM dont je me passerai avec joie en testant
tio!Au passage, j'utilise quelques adaptateurs USB-UART basés sur des puces FTDI. À ma connaissance, ce sont les seules à présenter un numéro de série.
J'utilise ce numéro de série pour créer un lien symbolique dans
/dev, via une règleudev, et éviter ainsi le caractère aléatoire de l'énumération des périphériques sur les bus USB.C'est à dire qu'une puce FTDI peut être détectée comme
/dev/ttyUSB2, et une autre fois comme/dev/ttyUSB0. Avec une règleudev1 , un lien symbolique, par exemple/dev/ttyFTDI5 -> ttyUSB0est créé à chaque démarrage. Et je peux m'adresser à/dev/ttyFTDI5sans me préoccuper de l'ordre de détection (et grace à une petite étiquette "5" collée sur la puce en question).Avec d'autres puces, comme les CHxxx, il me semble que c'est impossible. Avec
udevadm, je n'ai jamais trouvé de propriété exploitable pour arriver au même résultat.1 :
KERNEL=="ttyUSB*", ATTRS{serial}=="<n° de série de votre puce FTDI>", SYMLINK+="ttyFTDI5"placé dans un fichier/etc/udev/rules.d/<nom de votre choix>.rules[^] # Re: CuteCom
Posté par Lutin . Évalué à 3 (+1/-0). Dernière modification le 26 novembre 2025 à 12:58.
Quel est le problème avec PuTTY ?
[^] # Re: CuteCom
Posté par pseudonymous . Évalué à 1 (+1/-0).
Il n'y a pas vraiment de problème.
Mais les fonctionnalités sont basiques, comparées aux autres outils cités ici.
PuTTY ne propose pas d'auto-reconnexion par exemple. Mais rendons à PuTTY … C'est d'abord un outil de connexion SSH et Telnet.
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.