L’USB et la carte SD

11 juillet 2025

C’est Robotronik Phelma qui nous a aiguillé vers les cartes SD à la coupe. Alors, nous prenons notre moteur de recherche favori trouvons deux-trois informations prometteuses sur les cartes SD :

• Nous pouvons communiquer avec le protocole SPI. C’est un protocole parfaitement supporté par le Rapsberry Pi Pico ;
• Les cartes SD ont aussi un protocole plus évolué, le SDIO ;
• Nous trouvons un projet, qui implémente le protocole SDIO grâce aux modules PIO du Rapsberry Pi Pico : no-OS-FatFS-SD-SDIO-SPI-RPi-Pico.

Le protocole SDIO ressemble au protocole de communication SPI, avec 4 lignes de données et des commandes normalisées pour commander la carte SD (probablement les mêmes qu’en SPI). C’est surtout une vitesse de transfert 4 fois plus élevée pour la même fréquence d’horloge qui nous intéresse. Vous trouverez assez facilement des documents décrivant le protocole SDIO, En voici un au hasard.

Concernant le projet no-OS-FatFS-SD-SDIO-SPI-RPi-Pico, le README est particulièrement encourageant : il annonce des vitesses de lecture et d’écriture supérieures à 10 Mo/s. Maintenant, nous voulons tester ça !

Adaptateur de carte SD

Côté brochage de la carte, nous n’arrivons pas à trouver la description dans la norme, mais de nombreux sites proposent tous le même brochage, que voici :

Brochage carte SD

C’est un commentaire dans le code qui nous explique comment raccorder l’adaptateur SD avec le microcontrôleur :
Extrait de simple_sdio/main.c (no-OS-FatFS-SD-SDIO-SPI-RPi-Pico) /* SDIO Interface */ static sd_sdio_if_t sdio_if = { /* Pins CLK_gpio, D1_gpio, D2_gpio, and D3_gpio are at offsets from pin D0_gpio. The offsets are determined by sd_driver\SDIO\rp2040_sdio.pio. CLK_gpio = (D0_gpio + SDIO_CLK_PIN_D0_OFFSET) % 32; As of this writing, SDIO_CLK_PIN_D0_OFFSET is 30, which is -2 in mod32 arithmetic, so: CLK_gpio = D0_gpio -2. D1_gpio = D0_gpio + 1; D2_gpio = D0_gpio + 2; D3_gpio = D0_gpio + 3; */ .CMD_gpio = 3, .D0_gpio = 4, .baud_rate = 125 * 1000 * 1000 / 6 // 20833333 Hz };

C’est donc l’heure du shopping ! Nous cherchons un adaptateur de carte SD, mais qui support le protocole SDIO. Attention, certains adaptateurs n’offrent que le protocole SPI ! Nous sommes en amont du projet et nous ne sommes pas prêts à faire des compromis là-dessus.

Après quelques minutes de recherche, nous nous agaçons. Ce truc va nous coûter des sous, mettre du temps à arriver... Bref, nous trouvons une autre solution, pas forcément des plus élégantes :

Adaptateur carte SD

Non, nous n’avons pas soudé les fils directement sur une carte SD, ceci aurait été problématique pour la lire sur un ordinateur. Il s’agit d’un adaptateur de carte SD vers micro SD. En utilisant des cartes micro-SD, nous pouvons les connecter à la plaque de test ou les sortir pour les lire sur le PC. Pile ce qu’il nous fallait.

Carte SD reliée au RP2040 sur plaque d’essai

Test unitaire

Nous prenons le code de no-OS-FatFS-SD-SDIO-SPI-RPi-Pico et modifions l’exemple SDIO pour mesurer la vitesse d’écriture. Nous sommes d’abord ravis de voir apparaître les fichiers avec le bon contenu sur la carte SD. Puis en regardant les vitesses d’écriture, le doute s’installe :

Écrit: 38 octets en  46995 us
Écrit: 4066 octets en  30379 us
Écrit: 65482 octets en  28264 us

Comme si, plus nous écrivions de données, plus le temps total de l’opération diminuait. Ce qui n’est pas logique.

Des essais suivants montrent qu’il y a :

1. Un coût fixe, en temps, assez élevé pour la moindre écriture (peu importe la quantité de données)
2. Un coût aléatoire, probablement dû à l’age de la carte SD ou à la qualité du câblage

Mais globalement nous atteignons une vitesse de l’ordre de 2 Mo/s, et ça, c’est top !

Intégration avec le code USB

Aviez-vous remarqué que dans le nom du projet no-OS-FatFS-SD-SDIO-SPI-RPi-Pico, il y avait FsFAT ?

Bref, notre code USB et le code SDIO utilisent la même bibliothèque. À nous de créer un bout de code pour que la bibliothèque gère les deux supports. Si vous vous rappelez de notre article précédent, vous vous souvenez que :

• FsFAT peut gérer plusieurs disques
• Qu’il n’y a que quelques fonctions à adapter qui s’appellent disk_*

Nous reprenons la structure décrite dans diskio.c de FsFAT et sélectionnons la "bonne" fonction disk_* en fonction du numéro du disque. Les disques 0 et 1 sont des cartes SD et les fonctions disk_* appellent leurs homologues SDIO_disk_* tandis que les disques 2 à 9 sont des périphériques USB et les fonctions disk_* appellent leurs homologues USB_disk_*.

Architecture logicielle - USB + Carte SD

Côté performances

Au lieu de nous contenter d’une ou deux écritures sur la carte, nous lançons des écritures de 64 ko sur la carte SD et sur la clé USB. Nous restreignons l’acquisition à 1 minute et obtenons le graphique suivant.

Performance d’écriture (USB vs carte SD)

L’écart, en termes de performance, est sans appel.

Si nous réalisons le même exercice mais juste avec les écritures sur la carte SD, nous obtenons beaucoup plus de points en une minute, ce qui permet de valider la stabilité des résultats.

Performance d’écriture (carte SD)

Nous observons bien quelques pics de lenteurs autour de 0,5 à 1 Mo/s mais la vitesse moyenne d’écriture se situe bien autour de 2,0 Mo/s, ce qui est une très bonne nouvelle.
Écrire à la fois sur la carte SD et sur la clé USB n’est pas le plus utile ici ! Ce qui nous intéresse vraiment, c’est d’avoir la pile USB hôte fonctionnelle avec la capacité d’écrire des logs massivement !

Notre code est disponible sur notre dépôt !

Commentaires

• Suivez les commentaires de cet article par flux RSS

Ajouter un commentaire