Electronique - Realisations - Lecteur audio 004b

Electronique > Réalisations > Lecteur audio 004b (juke-box)

Dernière mise à jour : 10/09/2021

Projet suspendu

Le coeur de ce projet est suspendu jusqu'à finalisation du lecteur audio 008c qui peut également faire office de Juke-box.

Présentation

Ce lecteur audio permet la lecture à la demande de fichiers enregistrés sur une carte SD (FAT16 ou FAT32) dans les formats WAV (44,1 kHz ou 48 kHz, 16 bits, stéréo) ou MP3 (32 kbps à 320 kbps, 32 kHz à 48 kHz), grâce à des boutons-poussoirs ou des commandes logiques.

Il fait appel à un PIC 18F45K22 et à un décodeur VS1053. Un afficheur LCD renseigne sur les actions en cours. Le but de ce montage ? Au début, c'était pour me faire la main avec le décodeur. Ensuite, l'idée d'un juke-box avec accès direct à 64 morceaux de musique m'a traversé l'esprit...

Remarques

Pour l'instant, le circuit en est à ses balbutiements et présente quelques limites :

- lecture de fichiers MP3 possible, mais les fichiers WAV ne sont pas encore pris en charge.
- les fichiers doivent être nommés à la "xxx.mp3" (xxx compris entre 000 et 999).
- deux programmes séparés pour FAT16 ou FAT32. A terme, le même programme gèrera les deux formats.

A venir :

- le schéma complet avec les 64 ou 128 boutons (avec multiplexage car on ne dispose pas de 64 broches libres sur le PIC).
- la gestion de plusieurs bibliothèques (via de simples répertoires sur la carte SD).

Là, c'est juste un squelette qui montre que la base fonctionne, et comme vous pouvez vous en douter, j'y travaille encore. Mais je suis déjà très content d'être arrivé à ce résultat en moins de deux jours de travail (5 heures pour lire sur une carte SD formatée en FAT16, 8 heures pour réussir à lire une carte SD formatée en FAT32). Tout cela grâce aux routines toutes faites de MikroPascal, qui m'ont évité de lire l'intégralité de la norme MMC/SD.

Schéma

Quelle horreur ! Vous êtes sûr qu'on peut s'en sortir ?

Allez, il y a pire ;-)

Pourquoi utiliser un PIC de la famille 18F ?

Parce que la librairie logicielle que j'utilise pour l'accès aux données inscrites sur la carte SD (écriture et lecture) ne fonctionne qu'avec cette famille de PIC, et parce que, mine de rien, on a besoin d'un minimum de mémoire et de puissance pour assurer un échange correct des données entre le PIC, la carte SD et le décodeur audio. Un PIC16 ne pourrait pas être utilisé pour les tâches qu'on demande ici, le minimum est un PIC18. Il pourrait sembler plus pertinent de passer directement au PIC24, PIC32 ou dsPIC. Mais comme ce que je voulais faire tient dans un PIC18, je n'allais pas m'en priver.

Utilisation de modules précâblés

Pour ce lecteur audio, j'ai utilisé deux modules d'extension proposés par MikroElektronika :
- MP3 click, qui sur un petit circuit imprimé très propre, regroupe le décodeur VS1053 et les prises jack d'entrées/sorties audio.
- microSD click, qui comme son nom l'indique en partie, comporte un support pour carte microSD/SDHC.

Module MP3 click de MikroElektronika

Module microSD click de MikroElektronika

J'aurais bien sûr pu acheter le minuscule composant VS1053 et le souder de mes petits doigts, mais voyez-vous, j'ai manqué de courage.

Méthode de lecture des fichiers audio (désolé, c'est un peu technique)

La lecture d'un fichier audio se fait par petits bouts : le PIC lit des blocs de 448 octets depuis la carte SD et les place dans un buffer (zone mémoire du PIC) avant de les transmettre par paquets de 32 octets au VS1053 qui se charge alors du décodage MP3 proprement dit. Comme un fichier audio n'a pas une taille forcément multiple de 448 octets, il y a de fortes chances qu'à la fin du fichier il reste un nombre d'octets à envoyer inférieur à 448. Si tel est le cas, les octets restants sont transmis un par un (et non plus par blocs de 32) jusqu'au dernier. Le décodeur VS1053 possède quant à lui un buffer interne (FIFO) de 2048 octets, qui quand il est plein le signale à travers une de ses broches (DREQ, Data Request). Quand DREQ est à l'état haut, cela signifie que le VS1053 est prêt à recevoir de nouvelles données (paquet de 32 octets dans le cas présent). Cette "aire de sécurité" de 32 octets permet de transférer un bloc sans avoir besoin de vérifier entre chaque octet si le buffer du décodeur peut les accueilir : on gagne du temps puisqu'on a seulement besoin de regarder l'état de cette ligne après l'envoi de chaque bloc de 32 octets.

Les échanges entre carte SD et PIC, ainsi qu'entre PIC et VS1053, s'opèrent via une liaison de type SPI. Le PIC joue le rôle de maître (master) et le VS1053 celui d'esclave (slave), ce qui signifie que le signal d'horloge DCLK qui rythme les données est délivré par le PIC. La ligne XDCS doit être placée à l'état bas pour valider le traitement des données envoyées au VS1053. En théorie, cette ligne pourrait rester à l'état bas en permanence, mais il est conseillé de la désactiver et de la réactiver après chaque envoi de blocs de données (ici 32 octets) pour remettre les pendules à l'heure en cas de "glissement" du signal d'horloge DCLK.

Remarques diverses et plutôt techniques (encore désolé)

SCI = Serial Control Interface (interface série de contrôle) = commandes envoyées au VS1053 pour lui dire quoi faire, au format standard SPI. Chaque commande est constituée de 4 octets : un octet d'instruction Ecriture (WRITE, valeur $02) ou Lecture (READ, valeur $03), un octet d'adresse, et deux octets (un mot) de données. C'est par le biais de ces commandes qu'on peut lire ou écrire dans les registres du VS1053. A noter que la ligne DREQ passe à l'état bas après chaque commande SCI, et qu'avant de passer une autre commande SCI, on doit attendre que la ligne DREQ soit repassée à l'état haut.
SDI = Serial Data Interface (interface série de données). C'est par le biais de cette liaison que les données audio à décoder sont envoyées (par paquets de 32 octets) au VS1053.
Lors de l'initialisation du VS1053, la vitesse de transmission des données SPI est faible (démarrage en mode 1.0x, CLKI=XTALI, 12.288 MHz). Tant que l'horloge du VS1053 n'est pas configurée à une valeur élevée, la vitesse de transmission des données SPI doit rester faible : CLKI/6 au maximum (si quartz 12.288 MHz, vitesse bus SPI max de 2 MHz). Une fois le circuit initialisé, la liaison SPI peut opérer en vitesse rapide. Retenons toutefois que la vitesse de transmission adoptée pour la lecture des données depuis la carte SD est 4 fois plus élevée que celle d'envoi des données vers le décodeur VS1053. La vitesse maximale autorisée pour l'accès aux registres (via des commandes SCI/SPI) est en effet plus limitée quand le même bus SPI sert pour dialoguer avec une carte SD : vitesse max du bus SPI = CLKI/7 (pour lecture SCI) et CLKI/4 (pour écriture).

Panneau de commande (lecture des morceaux de musique)

Actuellement, j'utilise 6 boutons-poussoirs câblés sur le port D du PIC pour déclencher quatre fichiers ou passer aux suivants ou précédents. A terme, le lecteur disposera de 64 boutons de commande, extensible à 128. Bien sûr, comme le PIC ne dispose pas de 64 broches libres (et encore moins 128), on doit faire appel au multiplexage. OK, mais de quel genre ? Style matrice standard 8 rangées x 8 colonnes ? cela demanderait 16 lignes d'entrées/sorties (17 lignes pour 128 commandes). Eh bien figurez-vous que la méthode que j'ai décidé d'utiliser ne réclame que... 5 lignes d'E/S pour 160 commandes et qu'elle ne fait pas appel au multiplexage ! Oh, rien de miraculeux. Juste quelques entrées analogiques qui reçoivent une tension différente selon le bouton-poussoir pressé, on l'a déjà vu ailleurs (par exemple ici).

Dans le cas présent, je n'utilise que 3 entrées analogiques :
- une entrée pour un premier paquet de 32 boutons-poussoirs (sélection morceau #1 à #32)
- une entrée pour un second paquet de 32 boutons-poussoirs (sélection morceau #33 à #64)
- une entrée pour les autres commandes (choix bibliothèque, mode aléatoire, etc)

Le schéma qui suit représente deux modules pour 32 commandes chacun. J'en utiliserai 3 pour la sélection des 64 morceaux et pour les autres commandes (extension à 5 modules pour 128 morceaux).

J'aurais pu aller plus loin et câbler 64 boutons-poussoirs sur une même entrée analogique, mais la facilité de distinction entre deux boutons proches était beaucoup moins grande. J'ai préféré jouer la sécurité. Le principe de fonctionnement est simple. Un générateur de courant alimente un réseau de résistances de même valeur câblées en série. A chaque point de liaison (entre deux résistance), on trouve donc une tension différente. Quand on appuie sur un des boutons-poussoirs, ladite tension se retrouve sur l'entrée analogique, et il suffit de lire sa valeur pour savoir quel bouton a été pressé. Comme les résistances sont parcourues par un courant constant et qu'elles ont toutes la même valeur, le pas de tension entre chaque bouton-poussoir reste constant. N'aurais-je pas pu utiliser un simple réseau de résistances sans générateur de courant ? Si, bien sûr ! Pourquoi ne l'ai-je pas fait ? Pour donner raison à mon prof de math qui disait que j'aimais compliquer les choses.

Remarques :
- dans le circuit final, qui ne fera plus usage de ma platine de développement, je déplacerai les lignes DREQ, CD2 et CS2 pour libérer les entrées analogiques AN2 (pour sélection morceaux #65 à #96), AN3 (sélection morceaux #97 à #128) et AN4 (pour toutes les autres commandes).
- toutes les résistances de 100 ohms seront des modèles 1% parce que j'en ai en stock.
- le code fourni actuellement ne permet pas la lecture de ces blocs de 32 boutons-poussoirs.

Prototype

Réalisé avec ma platine EasyPic7, le module MP3 click (enfiché sur le support MikroBUS N°1 de la platine de développement) et le module microSD click (enfiché sur le support MikroBUS N°2) comme on peut le voir sur la première photo ci-après.

Les premiers tests ont consisté à faire jouer un fichier MP3 parmi ceux présents sur la carte microSD, en appuyant sur les boutons-poussoirs câblés sur le port D du PIC (mise à 1 des entrées RD2 à RD7, les entrées RD0 et RD1 servent à ajuster le volume sonore en sortie du VS1053). Dans un premier temps j'ai affecté les six touches SW3 à SW8 aux six premiers fichiers (001.mp3 à 006.mp3). Ensuite, j'ai affecté les quatre touches SW5 à SW8 aux quatre premiers fichiers (001.mp3 à 004.mp3), et les touches SW3 et SW4 aux fonctions "fichier précédent" et "fichier suivant". Tout fonctionne bien. Les cartes SD testées sont les suivantes :
- microSDHC Duracell 4 GO formatée en FAT16. Pour le formatage de cette carte, j'ai du passer par le gestionnaire de disque de Windows (outils administrateur) car le formatage en FAT16 n'est pas possible depuis l'explorateur de fichiers (Windows XP/7).
- microSDHC SanDisk Ultra 8 GO formatée en FAT32

Le boîtier retenu est un vieux poste de radio à lampe :

Je viderai l'intérieur mais conserverai sans doute le HP en place (s'il est encore en état) et remplacerai la platine disque par un panneau qui comportera tous les boutons-poussoirs. Derrière la face avant, à l'emplacement des gros boutons, je placerai quelques LED qui s'animeront différemment selon que l'appareil est au repos ou en mode lecture.

Logiciels du PIC

Fichiers binaires compilés *.hex disponibles dans l'archive suivante (deux programmes séparés pour FAT16 ou FAT32).

Lecteur audio 004 - PIC 18F45K22 - (16/02/2014)
Si vous souhaitez recevoir par la poste un PIC préprogrammé et prêt à utiliser, merci de consulter la page PIC - Sources.

Circuit imprimé

Non réalisé.

Historique

10/09/2021
- Suspension de ce projet jusqu'à finalisation du lecteur audio 008c qui peut également faire office de Juke-box.

02/02/2020
- Prolongation/reprise du projet lecteur audio 004 (ce dernier est désormais abandonné dans sa forme d'origine).