Electronique
> Réalisations >
Lecteur audio 001
Dernière mise à jour : 08/02/2015Présentation
Ce lecteur audio est un circuit qui permet de déclancher un ou plusieurs sons à la demande, via par exemple un bouton poussoir, un relais ou transistor, ou pourquoi pas une LDR qui agit quand la nuit tombe ou quand le jour se lève. L'ensemble est basé sur l'emploi d'un microcontrôleur PIC associé à une carte SD (/MMC) pour le stockage du ou des fichiers son à faire jouer. Ce lecteur peut lire les fichiers audio monophoniques au format 8 bits non signé (unsigned) avec une fréquence d'échantillonnage de 16 kHz (bande passante max 8 kHz), les autres formats ne peuvent pas être lus. Pour lecture à partir d'une mémoire flash EEPROM externe, merci de vous reporter au lecteur audio 002. Deux versions de lecture sur carte SD sont proposées ici :- Schéma 001 : à base de PIC 18F4520 (simulation OK et prototype OK)
- Schéma 001b : à base de PIC 18F2520 (simulation OK et prototype OK)
Le microcontrôleur PIC 18F2520 dispose de moins de broches d'entrées / sorties, mais dispose comme son grand frère 18F4520 d'un module SPI et d'assez de mémoire pour travailler confortablement avec quelques échantillons audio piochés à gauche ou à droite (selon sens de la carte).
Avertissements et remarques
- Pour le moment, le circuit ne peut jouer que quatre sons différents, bien que normalement capable d'en jouer bien plus puisque je suis parti sur une base de quatorze fichiers différents. J'ai en effet actuellement quelques soucis avec le déclenchement de certains sons, qui une fois partis ne veulent plus s'arrêter. Mais c'est mieux qu'un seul, comme c'était le cas au début du développement de ce projet.- La résolution n'est que de 8 bits et la fréquence d'échantillonnage de 16 kHz. Cela convient souvent pour jouer des sons style bruitage (explosion, aboiement de chien, etc) ou des voix humaines (annonce, alarme, etc), mais ce n'est pas du tout adapté pour de la chanson ou de la musique hifi ! Je suis bien conscient que la qualité sonore obtenue en 8 bits / 16 kHz fait plus penser aux vieux ordinateurs de jeux qu'à autre chose, mais c'est le prix à payer pour la grande simplicité de mise en oeuvre dont le circuit fait preuve.
- Les cartes SD actuellement supportées par le lecteur audio 001 sont des cartes SD (non SDHC) qui doivent être formatées en FAT16, leur capacité maximale ne peut excéder 2 GO.
- Tous les fichiers son doivent se trouver à la racine de la carte SD. Dossiers et sous-dossiers ne sont pas interdits mais ignorés.
- Si vous utilisez le fichier binaire compilé (*.hex) prêt à flasher dans le PIC que je fourni, le nom des fichiers audio devra respecter la syntaxe précisée dans le texte descriptif qui suit. Si vous savez modifier et recompiler le code source fourni, vous pouvez modifier le nom des fichiers audio à rechercher sur la carte SD, à votre guise.
- Si la carte SD a été partitionnée en plusieurs lecteurs, l'accès aux fichiers son sera possible uniquement sur la première partition.
- Je ne peux pas tester toutes les cartes SD du marché et ne peux en aucun cas garantir que le système décrit ici fonctionne bien avec n'importe laquelle.
- Le format des fichiers audio à lire doit impérativement être *.WAV Mono / 8 bits / 16 kHz, aucun autre format n'est supporté.
- Le stockage des sons sur la carte SD se fait simplement par copier / coller ou glisser / déposer depuis n'importe quel PC, avant de placer la carte dans le connecteur relié au microcontrôleur.
- La carte SD formatée FAT16 doit être insérée dans son support lors de la mise sous tension du montage, le logiciel tel qu'il est actuellement écrit ne supporte pas l'insertion d'une carte en cours de route (à chaud).
- Toutes les entrées de déclenchement doivent impérativement être raccordée au +5 V au travers d'une résistance de rappel de 10 kO, même pour celles qui ne seront pas utilisées. Si vous ne le faites pas (si vous laissez des entrées en l'air), des lectures aléatoires de fichier peuvent se produire à tout instant.
Schéma 001 - avec PIC 18F4520
Oh, une grosse bête pleine de pattes...
Pourquoi utiliser une carte SD ?
Certains microcontrôleurs offrent une capacité de mémoire flash importante, que l'on pourrait utiliser pour stocker un son. Mais qu'appellle-t-on capacité importante ? 4 KO ou 8 KO ? Vrai que c'est beaucoup pour stocker des infos utilisateurs, mais ça reste tout de même faible pour stocker un son, même si ce dernier est mono, quantifié sur 8 bits et joué avec une fréquence d'échantillonnage de 32 kHz. Un rapide calcul montre qu'avec 8 KO de mémoire, la durée max du fichier audio serait de 250 ms ! On peut bien sûr réduire la fréquence d'échantillonnage et se contenter d'une lecture à 16 kHz (pour une bande passante d'environ 8 kHz), mais on ne dépasserait pas dans ce cas 500 ms de durée de stockage audio. Toujours un peu faible, non ? La solution réside bel et bien dans l'emploi d'une unité de stockage externe tel qu'un disque dur, une mémoire flash externe, une clé USB ou une carte SD ou MMC.- Disque dur ? Un peu trop gros pour moi.
- Clé USB ? Ca viendra...
- Mémoire EEPROM externe ? Exemple.
- Carte SD ? Je ne connaissais pas et j'ai décidé de m'y mettre !
Pourquoi utiliser un PIC de la famille 18Fxxxx ?
Parce que la librairie logicielle que j'utilise pour l'accès aux données inscrites sur la carte SD/MMC (écriture et lecture) ne fonctionne qu'avec cette famille de PIC, tout simplement.Câblage et alimentation carte SD
Pour les tests, je me sert d'un support pour carte SD fourni sous la forme d'une extension optionnelle pour ma platine de développement EasyPic4. A noter que les cartes d'extensions actuelles proposées par MikroElektronika ne sont plus les mêmes que celle que j'ai acquise il y a maintenant quelques années.L'alimentation de la carte SD se fait sous 3,3 V et non sous 5 V, ce qui impose l'emploi d'un régulateur de tension juste pour la carte SD. Vous pouvez utiliser n'importe quel régulateur de tension intégré, pour ma part j'ai choisi le LM317 en boîtier plastique TO92 car la tension d'alim générale de mon montage est de 12 V. Si j'avais voulu obtenir du 3,3 V à partir du 5 V, le LM317 n'aurait pas convenu à cause de sa tension de déchet de 3 V. Il aurait fallu un régulateur LDO (Low Drop Out, faible chute de tension) du genre LM3940. Comme le PIC est alimenté en 5 V et que la carte SD l'est en 3,3 V, il est nécessaire de baisser l'amplitude des signaux qui partent du PIC et qui vont vers le lecteur de carte. C'est la raison d'être des résistances R25 à R30 montées en diviseurs de tension. Pour ce qui est des signaux partant du lecteur de carte SD et qui vont vers le PIC, rien de spécial à faire car point de danger de détruire quoi que ce soit et une tension de 3,3 V sera bien considérée comme un état haut, même si le PIC attend normalement une valeur de 5 V.
Méthode de lecture des échantillons audio
Il existe plusieurs méthodes pour lire les échantillons audio contenu dans la carte SD, en voici deux répendues :- Lecture directe - dans ce cas on travaille octet par octet, les échantillons sont lus les un après les autres et envoyés au fur et à mesure vers le convertisseur N/A. Il s'agit d'une méthode simple mais qui dans certaines situations (fréquence d'échantillonnage élevée par exemple) peut conduire à des petites "sautes" (drop-out) dans la lecture du fichier audio. Cette méthode impose une maîtrise dans les temps processeur de chaque instruction, pour que les échantillons soient lus à la bonne vitesse. Pour une bonne maîtrise de la vitesse de lecture, on peut faire usage d'un timer pour cadencer le tout.
- Lecture via buffer - dans ce cas on ne travaille plus octet par octet mais avec des blocs de plusieurs octets. Le buffer peut par exemple posséder une taille de 500 ou 1000 octets. Les échantillons sont lus depuis la carte SD et sont rapidement placés dans le buffer, par paquet. Ensuite ou "en même temps", on va chercher les échantillons placés dans le buffer pour les envoyer au convertisseur N/A. L'accès aux échantillons situés dans le buffer peut là aussi se faire via un timer, pour disposer d'une vitesse de lecture bien contrôlée et adaptée à la fréquence d'échantilonnage du fichier audio à lire.
Conversion numérique / analogique
Afin de consommer le moins de temps processeur possible, j'ai choisi d'utiliser un port complet - le port B - pour y envoyer à tour de rôle les échantillons audio. Je n'ai pas la certitude que c'est le mieux à faire mais ça me semble logique d'accéder aux huit bits en une seule étape. J'aurais aussi pu utiliser un convertisseur numérique / analogique prêt à l'emploi, de 8 bit ou pourquoi pas de 12 bits (dans ce cas sous-utilisé) de type MCP4921, ce dernier fonctionnant aussi avec une liaison SPI. On aurait ainsi remplacé le réseau R/2R (16 résistances) par un seul circuit intégré à 8 broches. Mais l'envoi des données sous forme série aurait aussi demandé plus de temps processeur. J'aurais pu aussi (et vous pourriez aussi) utiliser un convertisseur numérique / analogique 8 bits parallèle tel le DAC0808 déjà utilisé dans mon convertisseur N/A 002. Le réseau R/2R reste une solution très simple mais attention toutefois, la qualité sonore - même si on ne travaille qu'en huit bits - est un peu dépendante des valeurs des résistances, qui devront pour cette raison être des modèle 1%, de préférence.Amplification BF
La sortie audio Out est au niveau ligne, il faut un petit ampli BF pour pouvoir attaquer un haut-parleur. Que dites-vous d'un petit LM386 en boitier 8 broches ? Moi j'aime bien.
Plus de détails en page Ampli BF 003.
Schéma 001b - avec PIC 18F2520
Même chose dans les grandes lignes, mais avec un pavé de 28 broches à la place du pavé de 40 broches.
Par rapport au schéma 001, moins de broches disponibles sur le PIC, ce qui explique en grande partie le retrait d'un certain nombre de boutons poussoir. Mais on s'en fiche puisque le but de l'opération n'est pas de lire des dizaines de fichiers audio. Au fait, savez-vous qu'en modifiant le code logiciel on peut disposer de fonctions de lecture différentes ? Par exemple, au lieu de lire tel ou tel fichier à la demande et de façon "directe" (bouton N°1 pour le fichier audio N°1, bouton N°2 pour le fichier audio N°2, etc), on peut parfaitement envisager d'utiliser un bouton poussoir pour une fonction "fichier suivant", un autre bouton pour "fichier précédent", un bouton pour "lecture", etc. Et ce avec des fichiers dont le nom n'est pas imposé comme c'est le cas pour le moment.
Côté simulation...
Avant d'entamer le moindre test physique (avec des composants réels), je tenais à me faire les dents avec le simulateur de Proteus. J'ai peiné car il m'a été difficile de comprendre tout bien dès le début, les infos trouvées ici et là sur le Net n'arrivaient pas à faire le chemin vers les bons synapses. On a toujours l'impression que les choses sont évidentes pour ceux qui maîtrisent le sujet, mais on s'y pert facilement. C'est très vrai pour moi qui aime particulièrement compliquer les choses. Aussi je ne pense pas superflu de décrire ici les étapes que j'ai suivies pour arriver à quelque chose qui fonctionne. Je parle bien côté simulation.Dans un premier temps, il faut savoir que l'outil Proteus de Labcenter permet de simuler des microcontrôleurs, et avec certaines limitations permet de simuler les fonctions USB et Ethernet que certains de ces composants supportent. La simulation de carte mémoire est également possible grâce au composant "MMC" qui une fois posé sur la feuille de travail de Isis ressemble à un support de carte mémoire avec une carte qu'on peut "enficher ou retirer" à volonté. Dans ma petite tête, je m'étais persuadé qu'il suffisait de spécifier un lecteur de carte mémoire déjà raccordé sur l'ordinateur, et qu'à partir de là on pouvait lire ou écrire ce qu'on voulait sur la carte mémoire incluse dans ce lecteur, depuis Isis ou plus précisement depuis le microcontrôleur relié au composant MMC. Je suis resté un certain nombre d'heures avant de comprendre que cela ne pouvait fonctionner ainsi, car dans ma tête toujours, l'echec des simulations provenait du logiciel de test spécifiquement écrit pour le microcontrôleur sous test. Puis à force de recherche, j'ai compris qu'il fallait spécifier une image d'une carte mémoire et non un emplacement mémoire. J'ai donc parcouru le Net pour trouver un fichier image de carte mémoire, et les simulations ont enfin pris une tournure positive. Une fois cette première étape passée, j'ai constitué moi même un fichier image à partir d'une carte mémoire USB qui contenait un fichier audio prêt à lire. Pour réaliser cette image, j'ai utilisé l'outil USB Image Tool de Alex, que j'ai vu conseillé dans un forum. Pour résumer :
1 - J'ai raccordé un lecteur de carte USB sur mon ordinateur et ai placé dedans une carte SD de 256 MO qui comportait un fichier audio nommé "audio.raw".
2 - Avec l'outil USB Image Tool, j'ai créé un fichier image appelé "cardimg.mmc" de la totalité du contenu de la carte SD 256 MO (fichier résultant 247 MO).
3 - Dans Isis, j'ai ouvert la fenêtre des propriétés du composant MMC et dans le champ Card Image File, j'ai spécifié le fichier image "cardimg.mmc" nouvellement créé.
Et c'est tout ! Si ces quelques infos peuvent vous aider, j'en serai heureux.
Préparation des fichiers audio 8 bits
Nous qui sommes maitenant habitués à une résolution de 16 bits avec le CD audio et à plus quand on travaille dans le domaine pro (20 ou 24 bits), nous voilà bien embêté quand revient le temps des 8 bits. Les interfaces audio actuelles sont capables de grandes prouesses, et pourtant quand on leur demande d'enregistrer ou de jouer un fichier son 8 bits / 16 kHz, ça bloque presque toujours. Alors que normalement, qui peut le plus devrait pouvoir le moins. Bah non, ça ne marche pas comme ça. Si vous vous trouvez dans la même situation que moi (à savoir enregistrer directement en 8 bits), vous devrez constituer vos sons 8 bits / 16 kHz en deux étapes :1 - étape d'enregistrement
2 - étape de conversion
L'étape d'enregistrement nécessite un logiciel qui permet l'enregistrement, ça va de soi. Mais vous n'êtes pas obligé d'enregistrer sur un ordinateur, vous pouvez très bien le faire via un appareil autonome tel un lecteur / enregistreur MP3 si ce dernier possède un microphone et la fonction "dictaphone". Peu importe l'appareil qui vous permet d'enregistrer votre son, le principal est qu'il vous permette d'obtenir la qualité minimale qui correspond à votre besoin, et que vous puissiez ensuite le transférer sur un ordinateur pour l'étape de conversion. Je vous conseille dans la mesure du possible d'enregistrer en mono, avec une fréquence d'échantillonnage la plus faible possible mais bien sûr au moins égale à 16 kHz.
L'étape de conversion consiste à transformer les fichiers son préalablement enregistrés dans le format de votre choix, en fichiers aptes à être lus avec le lecteur audio 001 - et donc en mono 8 bits 16 kHz. Il existe plusieurs logiciels capables d'une telle chose, pour ma part j'utilise Wavelab qui fait partie depuis longtemps de mes outils, mais vous pouvez fort bien utiliser Audacity qui est gratuit. Bien que l'ayant déjà utilisé par le passé, je ne l'utilise plus et je vous invite donc à consulter son mode d'emploi si vous ne trouvez pas de façon intuitive comment procéder pour la conversion.
Audacity permettant aussi l'enregistrement direct, vous pouvez l'utiliser pour les deux étapes.
Conseil
Quand on travaille dans le domaine numérique, il convient de faire très attention à la saturation au moment de l'enregistrement, et de se réserver une petite marque de sécurité (dans le jargon on appelle cette marge Headroom). Cette marge est habituellement de quelques dB mais si on la conserve au moment de la conversion en 8 bits, le résultat sonore sera sans doute assez désastreux. Pourquoi ? Imaginez que vous enregistriez en 16 bits, avec une marge de sécurité de 18 dB. Le fichier résultant est comparable à un fichier de résolution 13 bits sans marge. Après conversion en 8 bits, on dispose de l'équivalent d'un fichier dont la résolution n'est que de 5 bits. Vous voyez le tableau ? Avant passage en 8 bits, il convient donc de "normaliser" le fichier son à une valeur de 0 dBFS (0 dB Full Scale) afin de lui faire prendre toute la place disponible dans l'échelle des valeurs d'amplitude. La normalisation peut certes apporter quelques petits défauts sonores (remontée de bruit et apport de distorsion), mais rien de méchant à côté de ce que vous auriez sans cette manip. De toute façon, coder un fichier en 8 bits (256 valeurs possibles) apporte forcement une bonne petite distorsion. Une fois la normalisation à 0 dBFS effectuée dans le fichier audio 16 bits, la marge initiale de 18 dB n'existe plus et le fichier converti en 8 bits sera un vrai 8 bits. Et je vous assure qu'entre 5 et 8 bits on entend très bien la différence. Bien plus qu'entre 20 et 24 bits ;-)Prototype
Réalisé de mon côté pour la version 001 (PIC 18F4520) sur plaque sans soudure reliée à ma platine de développement EasyPic4. Réalisé pour la version 001b (PIC 18F2520) par Olivier F.Mon prototype
Ca fait un peu imposant comme ça mais rassurez-vous, une fois la EasyPic4 rangée dans son coin il ne reste au final pas beaucoup de composants. Notez le raccord un peu particulier du connecteur de carte SD à la platine EasyPic4, qui n'est pas direct et se fait en passant par la plaque d'expérimentation sans soudure, avec quelques fils assurant le "pontage". Je voulais ici pouvoir essayer différentes broches pour la ligne CS du lecteur de carte, car en liaison directe (connection sur la ligne RC2 du PIC), ça ne fonctionnait pas. Un simple problème de configuration quelque part je pense, mais comme en essayant avec la broche RC0 ça fonctionnait bien, je ne me suis pas plus cassé la tête que ça (je chercherai plus tard, comme on dit). La dernière photo montre le réseau bien aligné des résistances R/2R qui assure la fonction de conversion N/A, avec à sa gauche un petit ampli BF à base de LM386, comme évoqué ci-avant.
Vidéo de démonstration
Le son vaut ce qu'il vaut, on ne fait pas dans la hifi.
Prototype de Olivier F.
Réalisé sur plaque à pastille après premiers essais sur plaque sans soudure.
Merci à lui pour ses retours !
Logiciels du PIC
Code source (format MikroPascal Pro V5.30) et fichier binaire compilé *.hex disponible pour les deux versions 001 (18F4520) et 001b (18F2520) dans l'archive suivante.Lecteur audio 001 - PIC 18F4520 et 18F2520 - (01/02/2015)
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
08/02/2015- Ajout photos du prototype d'Olivier F. (version 001b avec PIC 18F2520) que je remercie pour ses retours positifs.
01/02/2015
- Correction bug dans code du lecteur audio 001b pour PIC 18F2520. Le fichier numéro 1 était lu au démarrage du logiciel et la pression des boutons poussoirs ne produisait rien. Pour cause, j'avais laissé le code de "débogage" en place ! Merci à Olivier F. de m'avoir signalé le problème.
04/12/2011
- Ajout précisions concernant la préparation des fichiers son 8 bits / 16 kHz.
27/11/201
- Première mise à disposition.