L’USB hôte, la clé USB et les fichiers

11 juillet 2025

Alors, oui, nous avons une piste pour régler nos problèmes de communication, surtout que l’USB nous avait été chaudement recommandé à la coupe.
Mais nous avions un autre souhait pour notre robot, avoir des logs. Mais pas juste une LED qui s’allume en cas de soucis, des vrais logs, des gros fichiers avec plein de données dedans !

Nous voyons que notre code de démonstration supporte la classe "Mass Storage", nous sommes donc sur la bonne voie. Mais que se passe-t-il lorsque nous connectons une clé USB ? Eh bien, pas grand-chose :

A device with address 1 is mounted
A device with address 1 is unmounted 

Alors comment aller plus loin ?

La bibliothèque TinyUSB propose une liste de fonctions pour gérer les périphériques "Mass Storage", accessible dans le fichier msc_host.h. Mais en observant ces fonctions, il n’y a rien qui ressemble à ouvrir ou fermer un fichier.

Du MSC au fichier : le système de fichier

Les fonctions USB vont permettre de lire ou d’écrire une plage d’octet sur le périphérique, comme si nous accédions à une mémoire — ce qui est le cas. C’est très bien pour écrire une donnée brute, mais pour créer des fichiers qui seront lisibles sur un ordinateur, il manque toute une couche logicielle. Ces fonctions USB sont inspirées du protocole SCSI dont nous avons la liste compréhensible des commandes. Et rien là-dedans ne permet d’ouvrir, lire ou écrire des fichiers. Il s’agit plutôt de fonctions pour copier des morceaux de mémoire.

Pour gérer des fichiers, il faut un système de fichier. Un système de fichier est une organisation de la mémoire qui contient :

• d’une part une table de partition qui indique le nom des fichiers, leur arborescence dans les répertoires, leur taille et où trouver leur contenu
• d’autre part, le contenu des fichiers aux endroits indiqués par la table de partition.

Sur microcontrôleur, il n’y a pas beaucoup de systèmes de fichier qui seraient à la fois simples et reconnus par un ordinateur. Le principal candidat est FAT/exFAT. Il s’agit en réalité d’une famille de système de fichiers (FAT12, FAT16, FAT32, exFAT). FAT12, le plus ancien date de 1980 et était utilisé sous QDOS, l’ancêtre de MS-DOS tandis que exFAT est encore couramment utilisé sur les cartes SD. Ces systèmes de fichier regroupent la mémoire par blocs pour faciliter sa gestion.

Si nous parlons d’une famille de système de fichier, c’est qu’au lieu d’implémenter la spécification, nous utilisons une bibliothèque qui gère toute cette famille. Cette bibliothèque, c’est FsFAT !

Interface entre TinyUSB et FsFAT

L’interface en TinyUSB et FsFAT se résume à quelques fonctions. Chacune de ces fonctions prend en argument le numéro du "disque" sur lequel effectuer les opérations.

• disk_initialize : rien à faire, la connexion à la clé est gérée par l’USB
• disk_status : renvoyer 0 si la clé correspondant à ce disque est branché, 1 sinon.
• disk_read : appeler la fonction tuh_msc_read10 avec les bons paramètres, attendre que les tâches USB se soient bien exécutées
• disk_write : appeler la fonction tuh_msc_write10 avec les bons paramètres, attendre que les tâches USB se soient bien exécutées
• disk_ioctl : obtenir la taille et le nombre de blocs contenus sur la clé

Le code à étudier est certainement l’explorateur de fichier fourni dans les exemples de TinyUSB.

C’est un détail, mais FsFAT demande une fonction qui renvoie la date actuelle. Si vous n’avez pas d’horloge à l’heure sur votre microcontrôleur, Vous pouvez renvoyer n’importe quelle date, mais c’est cette date qui apparaîtra comme date de création ou de modification du fichier.

Côté architecture logicielle, nous avons "juste" rajouté la couche FsFAT à notre projet précédent :

Architecture logicielle - USB + FsFAT

Écrire dans un fichier

Nous étions un peu là pour ça, non ?

Pour écrire dans un fichier, la procédure est la suivante :

1. f_mount : monter le système de fichier ;
2. f_open : ouvrir le fichier ;
3. f_write : écrire dans le fichier ;
4. f_sync : forcer les écritures qui pourraient avoir été mises en attente ;
5. f_close : fermer le ficher - une bonne pratique, pas forcément utile ici.

Rien de sorcier, mais il y a une petite subtilité. Les chemins sont sous cette forme :

[disque#:][/]répertoire/fichier

Les crochets [...] indiquent des éléments facultatifs. Si vous n’indiquez pas de disque, FsFAT supposera que vous cherchez à écrire sur le disque 0. Dans notre cas, ceci nous a joué un tour. Si nous connections la clé USB directement sur le Raspberry Pi Pico, elle obtenait l’adresse 1. Nous avions codé en dur l’adresse du disque dans nos fonctions disk_*. Mais en ajoutant un hub, l’adresse de la clé passait à 2 et plus rien ne marchait. C’est embêtant au début, mais très flexible par la suite. Vous pouvez gérer plusieurs clés USB par exemple. Imaginez en garder une en permanence sur le robot et une qui reçoit automatiquement les derniers logs lorsque vous la branchée.

Pour plus de détails, lisez la bonne documentation.

Alors, nous y sommes ?

Les performances ? Pas terribles, nous ne dépassons pas les 64 ko/s, ce qui est aussi la limite trouvée par rppicomidi dans son projet pico-usb-host-msc-demo... D’après le projet de rppicomidi, c’est la conception de l’USB sur le Raspberry Pi Pico qui n’est pas faite pour obtenir de bonnes performances en mode "hôte". De notre côté, nous n’avons pas les compétences pour nous prononcer sur la cause, mais nous réalisons le même constat...

Alors 64 ko/s, ça paraîtrait OK pour du log, mais ça veut dire que nous utilisons un cœur complet pour écrire sur la clé, et que notre ressource USB ne fait qu’écrire les logs, Or nous comptons sur l’USB pour la communication intra-robot, pas question de partir sur une solution qui semble déjà montrer ses limites...

Vous trouverez notre code en ligne ici !

0 commentaire

Et si on parlait de l’USB

7 juillet 2025

Après plusieurs participations, nous avons observé des problèmes de communication I2C entre nos cartes équipées de Raspberry Pi Pico. Nous avions deux choix :

• Continuer à analyser le problème côté logiciel pour rétablir la communication en cas de coupure ;
• S’assurer qu’il n’y ait plus de coupure de communication.

Nous avions tenté, avec plus ou moins d’acharnement et pas trop de succès, le premier choix. La difficulté résidant dans la reproduction du défaut. On peut toujours débrancher un fil, mais le débranche-t-on le bon fil ? au bon moment ? Bref, nous n’avons rien produit de concluant.

Pour la seconde solution, nous faisons l’hypothèse que les problèmes de communication viennent des perturbations électromagnétiques. Alors qu’est-ce qui permettrait de se protéger des perturbations électromagnétiques ?

• Un protocole qui utilise une paire différentielle ;
• Un câble blindé ;
• Un connecteur qui relie le blindage à la masse proprement.

Et quel protocole (relativement) bien supporté par tout microcontrôleur moderne coche ces cases ? Devinez... L’USB !

Des notions d’USB

De son nom, Universal Serial Bus, nous pourrions croire que le protocole se rapproche d’une liaison UART un peu évoluée, mais il n’en est rien. Le protocole est organisé autour d’un "hôte" (host) et des périphériques (devices). La norme USB décrit un empilement de protocoles, de la définition du 0 et du 1 sur le bus à la définition des classes de périphériques (Devices class) qui vont jusqu’à spécifier, de manière flexible, les cas d’utilisation de l’USB.

Ces classes de périphérique permettent de prendre en charge un grand nombre de périphérique différents sans développer de pilote spécifique à chaque fois. Quelques exemples de classes :

• Video device class : pour les webcam, autorisant des flux élevés de données mais avec de potentielles pertes de débit
• Mass Storage class (MSC) : pour les systèmes de stockage tels que les clés USB, les disques USB. C’était aussi utilisé sur les vieux téléphones portables
• Media storage class : pour les systemes de stockage qui vont gérer les permissions sur les fichiers indépendamment de l’hôte USB. C’est ce qui est actuellement utilisé sur les téléphones portables pour transférer des photos ou des vidéos. Vous n’avez accès qu’à ce que le téléphone vous propose.
• Communication device class (CDC) : pour tout ce qui émule une liaison série. Si vous mettez un composant pour convertir votre UART en liaison USB, ce composant se déclarera certainement en CDC. C’est ainsi que le Raspberry Pi Pico (et probablement les autres microcontrôleurs) communique avec l’ordinateur par défaut
• Human interface device (HID) : pour les claviers, les souris, mais aussi les manettes de jeux, et entrées de simulateurs (cockpits d’avion, volants et pédales de voiture).

Pour une liste plus complète, wikipédia en anglais propose quelque chose de compréhensible.

Vouloir utiliser l’USB sans utiliser l’une des classes existante demande un effort considérable ! Bref, nous ne le conseillons pas !

La flexibilité du protocole USB en fait sa force mais crée une complexité qui fait que, même si nous maîtrisions parfaitement le protocole, nous ne pourrions le résumer en un billet de blog. Le meilleur résumé que nous pouvons vous proposer en ligne est USB in a Nutsheel. En français, j’ai le souvenir d’une revue qui présentait l’USB à travers une série d’articles, mais je n’en trouve pas la trace.

Et nos microcontrôleurs, dans tout ça ? La plupart des cartes pour développer sur microcontrôleur proposent un port USB, mais nous les classerons en 3 familles :

• Celle où le microcontrôleur sort les données en UART et les envoie à un composant qui les adapte pour l’USB
• Celle où le microcontrôleur supporte nativement l’USB, mais pour la partie "périphérique" seulement
• Celle où le microcontrôleur supporte nativement l’USB, la partie "hôte" et la partie "périphérique"

Les 2 premières familles peuvent envoyer des données sur le bus USB sans soucis. La première sera restreinte à la classe CDC, tandis que la seconde sera plus flexible et pourra, par exemple, émuler un clavier ou une souris.

Mais seuls les microcontrôleurs appartenant à la 3e famille peuvent coordonner le bus USB. La solution "simple" est de laisser un ordinateur embarqué assurer ce rôle. Mais ce n’est pas notre souhait. Le Raspberry Pi Pico, basé sur le RP2040 est de la 3e famille, qui support hôte et périphériques. Notons qu’ayant qu’un seul port, un seul des rôles USB (hôte ou périphérique) peut être actif à un moment donné.

Hôte USB

Pour tester la fonctionnalité hôte USB, nous utilisons le code de démonstration fourni dans pico-example : host_cdc_msc_hid.

L’exemple de la fondation RaspberryPi marche bien. Ce qui nous a pris du temps :

• Compiler l’exemple dans un projet indépendant ;
• Avoir le bon câble, de type MicroUSB OTG (lien boutique) ;
• S’installer pour récupérer les retours du microcontrôleur hôte.

Câble micro USB OTG

Si le port USB est pris, il faut récupérer les informations par un autre moyen. Nous utiliserons la liaison UART avec un convertisseur UART / RS232 puis un second convertisseur RS232/USB (parce que nous avions ceci sous la main).

Montage pour tester l’USB hôte

Note : sur le montage ci-dessus, il manque encore un câble USB pour l’alimentation...

L’exemple permet de gérer 4 types de périphériques USB :

• HUBs ;
• HID (Claviers, souris, manettes) ;
• CDC (Communication type série) ;
• MSC (Mass storage : clé USB, disque USB).

Côté architecture logicielle, nous en somme là :

Architecture logicielle - démo USB

Pour tester, nous commençons par relier un Raspberry Pi Pico avec un bête code printf("exemple\n") toutes les secondes à notre hôte USB. La connexion est détectée et les informations sont bien reçues !

Sortie du programme TinyUSB Host CDC MSC HID Example # Branchement d'un Rapsberry Pi Pico CDC Interface is mounted: address = 1, itf_num = 0 Baudrate: 115200, Stop Bits : 0 Parity : 0, Data Width: 8 A device with address 1 is mounted # Echo des données reçues Exemple Exemple Exemple # Déconnection du Raspberry Pi Pico A device with address 1 is unmounted CDC Interface is unmounted: address = 1, itf_num = 0 # Branchement d'un hub USB A device with address 1 is mounted # Branchement d'un Rapsberry Pi Pico sur le hub CDC Interface is mounted: address = 2, itf_num = 0 Baudrate: 115200, Stop Bits : 0 Parity : 0, Data Width: 8 A device with address 2 is mounted # Echo des données reçues Exemple Exemple Exemple # Déconnection du Raspberry Pi Pico A device with address 2 is unmounted CDC Interface is unmounted: address = 2, itf_num = 0 # Déconnection du hub USB A device with address 1 is unmounted

0 commentaire

Après la Coupe 2025

29 juin 2025

Voilà un mois que la coupe 2025 s’est terminée. C’était pour nous une coupe très particulière. En effet, nous étions grandement impliqués dans les deux équipes "Riombotique", au point d’avoir décidé de ne pas réaliser de robot pour Poivron Robotique cette année. C’est une expérience totalement différente avec énormément de trucs chouettes et quelques écueils qui nous ont fait mal.

L’une de nos conclusions, c’est que nous aimons notre équipe "Poivron Robotique". Mais Poivron Robotique c’est quoi ? Notre équipe n’est pas la seule à se poser ce genre de questions existentielles, vous avez Les Karibou qui présentent leurs réflexions à ce sujet.

En très bref, Poivron Robotique est bâti sur deux axes : maîtriser les technologies que nous utilisons et écrire des articles les présentant. Le détail de nos réflexions se trouve sur notre page Présentation.

La suite

Poivron Robotique sera probablement présent à la coupe de France de Robotique 2026. Nous travaillons toujours - bien qu’avec moins d’acharnement - sur nos articles sur le déplacement d’un robot.

Après des échanges avec différentes équipes, nous allons troquer notre bus de communication I2C pour un bus USB. Ce qui amènera probablement un ou plusieurs articles sur l’USB. Nous cherchons également à stocker nos logs, pour enregistrer massivement ce que se passe sur le robot. Enfin, nous cherchons un moyen de mieux comprendre l’environnement du robot à partir des capteurs VL53L8CX. Nous avons bien quelques idées mais rien d’abouti pour l’instant.

L’été s’annonce chargé et j’espère que nous reprendrons le rythme de publication que nous avions les années précédentes !

0 commentaire

Bonne année 2025

15 février 2025

Nous profitons de cette nouvelle année pour présenter, tardivement, nos meilleurs vœux pour cette année 2025.
Après une année 2023-2024 bien chargée, nous levons un peu le pied, ce qui explique cette activité éditoriale bien plus faible.
Cependant, plus faible ne veux pas dire inexistante ! Nous préparons une série d’articles sur le déplacement des robots qui sera publiée sur ce site quand elle sera prête, et pas avant. Si vous êtes curieux, ou que vous souhaitez participer à la rédaction de ces articles, notre bouillon (qui commence à prendre forme) est en ligne sur ce le wiki Eurobot.

Nos projets se concentrent sur les activités du club robotique de Riom. Ces activités nous amèneront probablement à publier des articles mais pas les points d’avancement que nous partagions habituellement sur ce site...

Bref, nous sommes toujours là, mais moins actifs ici !

0 commentaire

La coupe de France de Robotique 2024 - le bilan

19 mai 2024

Après une participation à la Coupe de France de robotique puis une participation à la Coupe d’Île de France, la fin du projet appelle un bilan et comme tous les ans, nous terminons ce projet avec une sensation d’inachevé.

Notre projet était ambitieux et supposait que nous partions d’une base solide - notre robot de l’année précédente.

Globalement, le travail réalisé cette année manquait de fiabilité :

• La prise des pots était délicate et comptait énormément sur l’odométrie du robot. En l’absence de capteur dédié, le robot ne pouvait que supposer qu’il avait attrapé un pot.
• La prise des plantes a gagné en fiabilité, ajustement après ajustement, mais avait parfois encore des ratés
• Même la dépose des plantes ou relâcher un pot n’était pas fiable à 100%

Le robot de l’an dernier avait bien un ou deux soucis, tels que :

• un plantage de la communication I2C ;
• un plantage dans la lecture du gyroscope.

Nous avons observé ces soucis sur le robot de cette année également, dans une moindre mesure, certes, mais ces problèmes sont toujours présents. Et cette année, en plus, le robot pouvait redémarrer de manière "aléatoire". Nous ne l’avons observé que quelques rares fois en essais, mais une fois à notre dernier match de la coupe d’Île de France.

Vue arrière du robot (mars 2024)

Côté PAMI, c’est un peu le même constat. Nous sommes partis du code de déplacement du robot principal. Ceci nous a montré à quel point le code était réutilisable - et ça nous a fait vraiment plaisir ! Par contre, quand vous réglez l’asservissement la veille de la compétition, évidemment que le robot manque un peu de maturité. Nous nous sommes fait avoir par :

• les boutons de sélection de couleur qui ont lâché les uns après les autres. Probablement à cause des efforts sur les contacts dû au manque de place sur le PAMI ;
• la gestion des multiples tirettes et le départ différé. Un faux contact et votre PAMI s’enclenche. Au bout de 90s, il ne bouge pas, car il y a un autre PAMI devant lui. Quand les autres PAMIs partent, ils restent coincés derrière celui qui a fait un faux départ.
• la gestion des piles. Nous avons limité nos essais pour ne pas vider nos batteries puis à la coupe d’Île de France, nous avons remarqué que notre chargeur de piles rechargeables était défectueux.

Les PAMIs juste avant le départ

Donc, oui, il y a des raisons d’être insatisfaits de nos robots.

Et de l’autre côté, nous avons rempli nos objectifs :

• la manière d’attraper les pots était unique et n’était accessible qu’à un robot holonome ;
• le robot a offert un vrai spectacle sur les tables de matchs ;
• peindre le bois a rendu le robot plus lisible ;
• nos PAMIs sont trop mignons - objectivement ;
• les trajectoires courbes de nos PAMIs étaient classes.

Bref, nous espérons avoir quand même vendu du rêve, car c’était un de nos buts !

Alors pour fêter ça, voici une vidéo des meilleures actions du robot :

BestOf 2024 - 720p (18Mo).

0 commentaire