Forum Linux.embarqué Copier coller dans un terminal avec une pause entre les lignes

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
2
22
jan.
2026

Salut,

Pour développer sur un système embarqué (sous uboot) je passe par un port série que je pilote avec l'excellent découverte linuxfr tio.

Ça marche parfaitement bien sauf quand je cherche à copier coller une suite de commandes uboot.

Genre pour écrire dans des registres d'un composant i2c j'ai une cinquantaine de commandes d'écriture à lancer à la suite.

Le problème c'est qu'uboot panique si je copie colle brutalement, ça va trop vite. Je me demandais s'il n'existerait pas une technique/option qui forcerait l'ajout d'une petite tempo à chaque retour à la ligne du copier coller. Ça évite d'avoir à copier les 50 lignes une par une.

  • # mais pourquoi ?

    Posté par  . Évalué à 4 (+1/-0).

    si tu fais un copier des 50 lignes
    envoie les dans un fichier

    puis rejoue ce fichier par un script qui lit ligne par ligne avec une pause entre chaque ligne

    • [^] # Re: mais pourquoi ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

      puis rejoue ce fichier par un script qui lit ligne par ligne avec une pause entre chaque ligne

      C'est ce que je suis en train de faire. Mais je me demandais s'il n'existerait pas une option magique pour éviter d'avoir à écrire un script.

      J'ai plus qu'une balle

      • [^] # Re: mais pourquoi ?

        Posté par  . Évalué à 3 (+2/-0).

        helas non, j'avais le meme probbleme pour programmer des cisco 800, le tech copier coller le fichier mais cela n'arriver pas jusqu'au bout, il etait patient et pouvais recommencer toute la journée pour reussir.

        nous sommes passé au ftp, sinon je pense que le buffer clavier n'arrive pas envoyer tout et ca doit sabré une partie pour réussir

        tu peux essayer avec : expect

        ca permet de coller des caractere pas trop vite

        #!/usr/bin/expect
spawn bash
send "e"
sleep 0.2
send "c"
sleep 0.2
send "h"
sleep 0.2
send "o\r"
interact

        • [^] # Re: mais pourquoi ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 22 janvier 2026 à 15:56.

          Merci, je l'ai finalement fait en python.

          J'ai plus qu'une balle

        • [^] # Re: mais pourquoi ?

          Posté par  (site web personnel) . Évalué à 6 (+3/-0).

          Autant s'en servir comme son nom l'indique non ? (ie. n'envoyer un caractère que lorsqu'il a été reçu en face, affiché et donc renvoyé)

          #!/usr/bin/expect
spawn bash
send "e"
expect "e"
send "c"
expect "c"
send "h"
expect "h"
send "o\r"
expect "o\r"
interact

      • [^] # Re: mais pourquoi ?

        Posté par  . Évalué à 3 (+0/-0).

        augmenter le buffer terminal de la connexion par la console
        terminal length 0

        augmenter la vitesse de l'interface serie à 115200, les switchs un tant soit peu recent le permettent.

        envoyer la config via des fichiers avec les protocoles prevus pour (historiquement TFTP, mais desormais aussi SCP/SFTP)

  • # Fiabilité du port série ?

    Posté par  . Évalué à 2 (+1/-0).

    Est-ce que le port série ne serait pas sollicité à un débit trop élevé ?

    Parce que j'ai tendance à pousser le bouchon toujours trop loin, ça m'arrive encore d'avoir des problèmes de communication entre PC <--> adaptateur USB/U(S)ART FTDI <--> MCU (STM32).
    J'aime pousser au-delà de 115200 bps : 230400 quand ça n'est pas 460800.
    Ma justification (discutable ?) étant que plus le débit est grand, moins l'usage de l'U(S)ART côté MCU n'a d'impact (le plus souvent, j'en fais une console de trace et de commande).
    Mais le risque de mauvaise transmission n'est jamais loin à ces vitesses, particulièrement quand la quantité de texte est élevée. J'ai l(a mauvaise) habitude d'utiliser PuTTY, que ce soit contraint sous Windows, ou libre sous Linux.

    Si cette piste semble plausible, et si le matériel est disponible, il faudrait contrôler la communication avec un analyseur logique.

    Je n'ai jamais eu l'opportunité d'utiliser un Digilent.
    Un Saleae oui; ils en font de très bons, mais très chers.
    On trouve des semi-clones 8 voies au lieu des 16 généralement chez Saleae, apacher chez Jeff ou chez Jack (encore que, ça n'est plus lui le boss il me semble ?).
    Pour les clones, le soft Saleae fonctionne aussi … Pas cool pour eux.
    Mais l'alternative libre Sigrock / Pulseview les gère aussi.

    • [^] # Re: Fiabilité du port série ?

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      c'est pas une question de fiabilité du port série ;-)
      c'est une question de quel débit accepte le périphérique ?

      ce qui répondrait à la question :

      Je me demandais s'il n'existerait pas une technique/option qui forcerait l'ajout d'une petite tempo à chaque retour à la ligne du copier coller. Ça évite d'avoir à copier les 50 lignes une par une.

      d'après https://github.com/tio/tio

      on peut lancer tio --baudrate 115200 plutôt que 115200 — qui est la valeur par défaut — j'essaierais 28800 voire 14400 (faudrait voir les spécifications du matos).
      Je me fais régulièrement avoir avec Universal G-code sender où j'essaie d'envoyer trop vite les données à notre graveuse laser en DIY…

    • [^] # Re: Fiabilité du port série ?

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Je pense que le problème vient plutôt de mes commandes uboot qui mettent du temps à s'exécuter. Comme je bourre toutes les commandes d'un coup, le tampon déborde et mange une partie de mes commandes.

      J'ai plus qu'une balle

      • [^] # Re: Fiabilité du port série ?

        Posté par  . Évalué à 3 (+2/-0).

        OK, tout à fait possible.
        Je repense à des paramétrages qui sont désactivés la plupart du temps de nos jours :

        S'il est possible de configurer la console uboot pour utiliser l'un ou l'autre, de même que l'outil côté PC, la communication pourrait être mise en pause quand le buffer de réception est plein ?
        C'est le genre de chose dont j'avais oublié l'existence depuis de nombreuses (dizaines d') années, tellement la fiabilité et la rapidité de traitement prédominent. Sauf dans ce cas.

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.