[Temps-x]

Bonjour tout le monde,

J'ai entrepris de lire un fichier son de nature Wav avec un pic, histoire de voir si on pouvais le faire, à priori ça fonctionne, mais j'ai beaucoup de chose à détaillé.

J'ai pour cela utilisé le Pic18F26K22 voici son datasheet

Ce pic possède 3896 octets de mémoire ram, 1024 octets de mémoire eeprom, et 64K de mémoire programme, malgré ses caractéristiques il ne fait pas le poids.

Un son de nature Wav prends énormément de place, et ne pourras pas tenir plus de 5 secondes à qualité très base et oui, faut pas rêver, les fichier de nature Wav occupe une place immense même en utilisant un Pic18F27k42 qui fait le double du Pic18f26k22 en mémoire programme, il est évident qu'il faudra stocker le fichier son en mémoire programme.

Explication

L'astuce... consiste à utiliser le Pwm de ce Pic, on faisant varier la modulation, ce qui permet de créer une tension qui va varié en fonction de la lecture du fichier son, après il faut le filtrer, et l'amplifier.

Pour le filtrage : j'ai utilisé un transformateur base fréquence, récupérer sur une télévision à tube cathodique que j'ai cannibalisé

Transformateur.jpg

Pour l'amplification : haut parleur avec ampli d'un vieux PC qui était jeté, c'est ce qu'on appelle faire du recyclage

Schéma

SchémaSon.jpg

Fichier son

En ce qui concerne le fichier son, il faut le convertir en format compatible pour pic, et pour version ASM, j'ai donc écrit un petit programme pour faire le travaille.

RecpWav.jpg

Une fois converti voici un extrait de ce que ça donne

Code : Tout sélectionner



;***********************************************************************************************
;******************************** Nom du fichier : Balla-2.wav *********************************
;********************** Taille : 32972 octets, Durée : 00 h 00 min 01 sec **********************
;**** Codec : Microsoft PCM Format (Cbr), Échantillonage : 22050 Bytes/Sec, 11025 Hz, Mono *****
; Utilisation pour microcontrôleur avec la fonction decfsz : 0x01(upper), 0x80(high), 0xA0(low) 
;***********************************************************************************************
 
    ORG H'8FC'
 
sonwav
      db 0x01,0x80,0xA0,0x00,0xFF,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xFF,0x00,0x00,0x00
      db 0xFF,0x00,0x00,0x00,0xFF,0x00,0x00,0x00,0xFF,0x00,0x00,0x00,0x00,0x00,0xFF,0x00
      db 0x00,0x00,0xFF,0x00,0x00,0x00,0xFF,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00



Les 3 premier octets définisse la taille des données pour l'utilisation du langage ASM, avec la fonction decfsz

0x01,0x80,0xA0

ça ne fonctionnera pas en C, en réalité la taille réelle est 0x00,0x80,0xA0, si vous voulez que je l'adapte pour langage C, demander le moi.

Ce programme sera disponible très bientôt, mais j'ai encore des choses à terminer avec l'usart

Code du Pic

Le code ASM a été écrit avec jens file Editor 3.95

Fichier code : SonWav(code).zip
Fichier à mettre dans le Pic : SonWav(Hex).zip

Le son n'est pas vraiment nette, je me demande si on peut l’améliorer, voici ce que ça donne avec un enregistrement micro

Fichier sortie pic : Balla-2(Mp3).zip



A+

[paulfjujo]

bonjour TempsX,

Effectivement ton SON est plutot BAD !
il y a contradiction entre 22050 bytes/sec et 11025Hz
à moins que les datas soient sur 16 bits ! ou en Stereo ?
mais meme le MP3 a un son dégueu..

question :
ton application en RapidQ, lecture de Wav , sert à generer la table de Datas en ASM ?

j'utilise AUDACITY pour transformer un fichier wav à 22050Hz en
le reéchantillonant à 11025Hz, mono, et 8bits PCM
ce qui reduit donc notablement la taille dans un rapport de 2 à 4 ..

j'ai déja bien entamé mon projet de lecture de fichiers *.wav
avec le 18F27K42 ... voir viewforum.php?f=10
je peux lire en direct un fichier wav de 7Ko, stocké en RAM, et le rejouer en PWM ...
voir Ok_11025.wav qui fait 6Ko (datas en 8bits PCM )
ou cestcela_oui_11025.wav et I_am_ready_11025.wav 10ko

la phase suivante est lire un fichier WAV jusqu' à 100Ko , le stocker en flash et
le jouer en PWM ..

Test vitesse de lecture Flash :

SANS afficher les datas lues!
Test 4A Re-Lecture 128 Bytes en Flash at @ 0x7D00 soit 32000
Duree relecture 128 bytes en flash :416 uS

c'est jouable ! 3µS / byte
à 11025Hz cycle de ~90µS
il reste donc suffisament de temps pour envoyer la data lue en flash vers PWM output
il faudra eventuellement faire des ajustement dûs au décalage temporel lors du
franchissements de page de 128 bytes..

---------------
avec AFFICHAGE data lues
Test 4A Re-Lecture 128 Bytes en Flash at @ 0x7D00 soit 32000

32000 -> 0x00.0x01.0x02.0x03.0x04.0x05.0x06.0x07.0x08.0x09.0x0a.0x0b.0x0c.0x0d.0x0e.0x0f.
32016 -> 0x10.0x11.0x12.0x13.0x14.0x15.0x16.0x17.0x18.0x19.0x1a.0x1b.0x1c.0x1d.0x1e.0x1f.
32032 -> 0x20.0x21.0x22.0x23.0x24.0x25.0x26.0x27.0x28.0x29.0x2a.0x2b.0x2c.0x2d.0x2e.0x2f.
32048 -> 0x30.0x31.0x32.0x33.0x34.0x35.0x36.0x37.0x38.0x39.0x3a.0x3b.0x3c.0x3d.0x3e.0x3f.
32064 -> 0x40.0x41.0x42.0x43.0x44.0x45.0x46.0x47.0x48.0x49.0x4a.0x4b.0x4c.0x4d.0x4e.0x4f.
32080 -> 0x50.0x51.0x52.0x53.0x54.0x55.0x56.0x57.0x58.0x59.0x5a.0x5b.0x5c.0x5d.0x5e.0x5f.
32096 -> 0x60.0x61.0x62.0x63.0x64.0x65.0x66.0x67.0x68.0x69.0x6a.0x6b.0x6c.0x6d.0x6e.0x6f.
32112 -> 0x70.0x71.0x72.0x73.0x74.0x75.0x76.0x77.0x78.0x79.0x7a.0x7b.0x7c.0x7d.0x7e.0x7f.

Duree relecture 128 bytes en flash :64593 uS (inclus le bavardage affiché ci dessus !)

d'ailleurs je pourrais aussi generer un fichier ASM Data ....dans la foulée..

----------------------------------------------------------------------------

USAGE de RTS pour gerer le flux hardware PC --> vers RX UART1 18F27K42
// nota:
in fine, si on veut controler soit meme le flux,
il vaut mieux ne pas utiliser le mode RTS de l'UART HARDWARE
mais de gerer la sortie RC5 -> RTS de l'interface Prolific TTL/USB (vers terminal)
pour lire par paquet .. j'avais choisi 64 bytes,
Le 1er paquet de 64 bytes sera lu en RAM , pour verifier les paramatres du fichier wav
Freq echantillon 11025Hz , mode Mono , PCM 8bits , taill des datas à suivre
ensuite lecture par paquet de 128 bytes pour etre en adequation avec les blocs en Flash 128bytes.
le dernier paquet peut eventuellement etre omis si < 128 bytes..
Une fois mis en Flash
Lecture de celui ci directe sur sortie PWM ..RC1
nota : vu que l'amplitude du wav est sur 8 bits, on a pas besoin de la résolution 10bits du CCP1 PWM
avec une valeur plus faible de PR2 , le 100% du tycycle est atteint pour 720 au lieu de 1023.
Je n'ai pas trouvé comment travailler en 8bits avec ce CCP PWM 18F27K42 ?
pour avoir duty value= 255 => 100% et profiter de toute la dynamique du signal audio.

----------------------------------------------------------------

Usage de TIMER2 associé à CCP1 PWM
CCP1 associé à Timer2
il faut privilégier l'usage d'une valeur maxi pour TMR2PR ideal=255 pour avoir le maximum de resolution = 10bits
sinon on atteint 100% PWM avec une valeur moindre
exe avec F PWM désirée proche de 11050Hz (et T2CLCK=FOSC/4=16MHz)
si TM2PR= 180 Prescaler 1/8 et Postscaler 1/1 => 1/8 maxi 100% duty avec consigne < 720 points
RAPPEL : Le postscaler timer2 n'intervient pas si activation du CCP1 PWM !...... assez piégeux !!!

J'utilise un Filtre passe bas avec un transistor monté en collecteur commun
du signal de sortie RC1 PWM avant de l'envoyer dans carte SON PC ou ampli BF.
moins lourd et encombrant qu'une self ..
D'ailleurs avec self et condo de liaison , tu risque d'avoir un phénomene de surtension à une certaine fréquence de résonnance..
si le Q est trop elévé ( pas le Q du bas, ni le Q(I) du haut ,mais le facteur de qualité Q)

A priori , la lecture de la flash rom , une fois rempli avec les datas du wav ( en C), pourrait etre faite en ASM
puisque tablat peut couvrir tout l'espace d'adressage de cette flash ?
peux-tu confirmer (ou pas) ?

Reste à voir aussi, quelle peut etre la vitesse maxi de lecture fichier wav (actuellement UART à 115200 bds)
testé à 460800 bds --> OK
test à 921600 --> BAD ! (limite prolific interface ?)

Penses-tu continuer sur le 18F27K42 ?

A+

[Temps-x]

Bonjour paulfjujo, et tous le forum,

Source du message Effectivement ton SON est plutot BAD !

Ouais ..... mais c'est du direct

Source du message ton application en RapidQ, lecture de Wav , sert à générer la table de Datas en ASM ?

Oui, mais je préfère te prévenir d'éviter de prendre un gros fichier, ça sent le rachat de Ram

à titre d'exemple

Taille du fichier son Wav : 1679300 octets(1 Mo) pour 2 minutes 13 secondes, 12000 Hz, Mono, sortie du fichier code 9 446 448 octets(9 Mo)

Source du message nota : vu que l'amplitude du wav est sur 8 bits, on a pas besoin de la résolution 10bits du CCP1 PWM
avec une valeur plus faible de PR2 , le 100% du tycycle est atteint pour 720 au lieu de 1023.

Un fichier son de de nature Wav de caractéristique mono ne peut pas dépassé 255 valeurs, quelque soit son échantillonnage, le faite d'avoir 720 point va diminuer la valeur de l'amplitude, c'est tout.... sinon, pas grave d'avoir une valeur maxi de 10 bits ===> 1023 il suffit de faire une division par 4 sur les valeur trouver, le seule problème c'est le temps que ça prends.

Avec le Pic18F26k22 pas de problème,

Plusieurs posibilité

PR2 D'255', T2CON B'00000101' j'obtient une fréquence de 15620 Hz

PR2 D'255', T2CON B'00000100' j'obtient une fréquence de 62500 Hz

Vérifier au fréquencemètre Ok, j'ai bien mais 255 valeurs, d'après mon petit programme ICI, par contre j'ai remarqué que le son était meilleur quand j'utilise le pwm à 62500 Hz....

Source du message Je n'ai pas trouvé comment travailler en 8 bits avec ce CCP PWM 18F27K42 ?

Normalement, et je crois avoir vu quand peut utiliser l'ancien méthode pour générer le PWM

Source du message moins lourd et encombrant qu'une self ..

Tu as tout ta fait raison, je vais essayer ta méthode, histoire de voir si j'ai une amèlioration, puis ça sera moins lourd et encombrant

Source du message puisque tablat peut couvrir tout l'espace d'adressage de cette flash ?
peux-tu confirmer (ou pas) ?

Je confirme que Tablat peut couvrir toute le section du Pic, j'ai déjà testé (retour au source Paul)

Source du message testé à 460800 bds --> OK

Teste en cours ... sur RS232 avec mon programme 1000000 bauds utilisation Ch340E pour communication avec le PC

Voir ICI ou j'ai déjà effectuer des tests avec la caméra OV7670

Source du message Penses-tu continuer sur le 18F27K42 ?

Je termine mes essais avec le Pic18F26K22, car plus simple à mettre en oeuvre, puis je changerais par un Pic18F27K42 car beaucoup plus de mémoire programme 128 Ko

J'ai pas mal d'essai à faire ce soir,

Voilà les résultats, ça fonctionne avec la communication PC et mon programme, j'ai pu écouter tout nu et tout bronzé (Carlos) if faut bien se distraire, mais bon... le son toujours aussi bad, je teste ton montage de filtrage demain, je pense que ça vient d'un mauvais filtrage.

A+

[paulfjujo]

Bonjour TempsX et à tous,

J'ai testé ton programme et il y a quelques points qui me chagrinent ..

les datas de ton fichiers WAV contient des valeurs trop extremes proche de 0x00 ou 0XFF .. pas bien !
=> ecretage du son
le PCM doit evoluer entre 0 et 255 pour pouvoir representer un niveau analogique et non proche du tout ou rien.
Amplitude à revoir , et centrée sur 128
essaie avec un autre fichier ( exemple OK_11025.wav)

dans le commentaire la taille fichier est ; Taille : 32972 octets => 0x80CC
or dans le debut de table wav , es 3 premiers byte pour definir la taille à lire
; 0x01(upper), 0x80(high), 0xA0(low) =98464

ou j'ai mal compris ?


D'autre par , j'ai rajouté une sortie RA3 pour declencher mon analyser logique
dans la boucle de lecture ..
Je constate ( le meme probleme d'ailleurs avec ma version en C et le 18F27K42)
qu'il y a de gros trous de plusieurs mS même ! avec l'usage de la flash ....
voir capture SQA analyser


ce probleme n'existe pas , si on lit en RAM !
La lecture de tout l'espace flash ne se fait donc pas aussi directe qu'on le pense ..

mais j'avoue ne pas comprendre pourquoi , vu qu'il n'y a aucune interrupt active .

autre test SANS CCP1 .. mais il faut un WAV avec des Datas correctes ...
uniquement avec Timer2 en timeout ..

Code : Tout sélectionner


lecture_son
      bsf SQA                      ; trigger pour SQA analyser
      tblrd*+                             ; 
      movf TABLAT,W                       ; 
      movwf loop2 
      bcf PIR1,1               ; TMR2IF=0
      BSF T2CON,2            ; TMR2 ON
      BSF LATC,2            ; RC2 Output=1
More                                         
      btfss PIR1,1             ;  TMR2IF
      decfsz loop2,F          ; wait timeout
      bra More
      
      BCF LATC,2            ; RC2 output=0 
      bcf T2CON,2                ; TMR2 OFF      
      
      bcf SQA                   ; stop trigger
      decfsz loop6,F 
      bra lecture_son
      decfsz loop7,F                      ;
      bra lecture_son                     ;                         
      decfsz loop8,F                      ;
      bra lecture_son                     ; 


je vais recuperer les donnees de OK_11025.WAV
pour former un fichier datas DB .....
et refaire un test avec celui là...
..mais ça ne resoudra pas le probleme rencontré ..

PB_lecture_flash_2022-0913.jpg

[satinas]

Bonjour,
La lecture de la flash et de l'eeprom est 3 fois plus lente que la ram, mais cela reste faible devant le temps de traitement de la data.

1 cycle pour la ram
MOVF POSTINC0,W

2+1 cycles pour la flash ou l'eeprom
TBLRD*+
MOVF TABLAT,W

Tu dois pouvoir faire la boucle en utilisant TABLAT à la place de loop2.

[paulfjujo]

bonsoir,

j'ai modifié ma version C 18F27K42 pour editer les datas du fichier wav chargé , au format ASM DB ..
je mets le fichier récupéré ci dessous , pour OK_11025.wav
il est de petite taille , car utilisé auparavant , stocké en RAM du 18F27K42...

je me suis aperçu de 2 choses
Mon analyser SQA déconnait , car le sniveaux d'entree n'etatit pas en TTL 5V ( alim du PIC en 3,3V
apres choix input 3,6V .. il n'y a plus de gros trous de plusieurs ms , mais toujours de sgapdp de 200 à 300µS
qui rende le son restitué TRES Bruité ...

Je me suis rendu compte que lorsque j'éditais sur le terminal le contenu en hexa des datas lues via l'Uart, puis stockées ensuite dans la flash
plus de probleme de son Bruité .. et pas de trous dans le signal PWM
meme en rajoutant un petit delai dans le cas ou je n'imprime pas le detail
ça ne resoud pas le probleme de bruit ..
.. à suivre ...

OK_11025_wav_datas.txt

[Temps-x]

Bonjour paulfjujo, satinas, et tous le forum,

Source du message dans le commentaire la taille fichier est ; Taille : 32972 octets => 00x80CC
or dans le debut de table wav , es 3 premiers byte pour definir la taille à lire
; 0x01(upper), 0x80(high), 0xA0(low) =98464

ou j'ai mal compris ?

Tu as mal compris... voir Post #1 ou j'explique le pourquoi

L'utilisation de l'instruction decfsz et plus rapide qu'une comparaison, mais elle à un inconvénient, si elle arrive sur un zéro elle remet la variable à 255, c'est pas le cas si elle fait 1, j'espère de mettre bien expliqué car ce n'est pas facile à expliquer.

Dans mon petit programme en RapidQ j'ai prévu de rajouter 1 quand la dernière variable est à 0, ou les deux dernière variables qui son à 0, ou les trois dernière variables qui son à 0 (pour code ASM), je peux mettre la vrai taille pour un code C si ça intéresse quelle qu'un.

Je ne vois pas l’intérêt de se servir des interruptions pour remplir la ram, vu qu'on dispose d'un temps de 90 µs pour 11025 Hz il y a de quoi faire.

Avec un calcul rapide : 90 µs et une horloge à 64 Mhz ce qui nous fait 1440 instructions qu'on peut traiter.

Je viens de faire un essai avec Pic18F26k22 et ton fichier OK_11025_wav_datas.txt et ça fonction super bien, il y a plus de parasite ====> donc tu as raison il y a bien un effet de saturation, il faut donc normalisé le son autour de 127

Par contre j'ai changé le délais, je l'ai mis à 94 µs pour ton fichier ok... j'ai fais ça d'oreille, car je connais pas ta vrai voix .. ok.
de plus je suis pas sur d'avoir un vrai 94 µs (à vérifier)

Fichier source et code : SonWavDelay.zip

On avance, je vais modifier mon programme sur RapidQ pour normalisation, pour cette analyse, j'aurais du y pensée sachant qu'il y a une
alternance positive est négative.

Pour ton montage avec filtrage ça n'a rien changé, mais c'est plus léger

Ps : Essai ce fichier avec un Pic18F26K22 SonWavDelayv2.zip reste 2 k pour le programme, imagine avec un Pic18F27K42


A+

[paulfjujo]

bonjour à tous,

Je ne vois pas l’intérêt de se servir des interruptions pour remplir la ram, vu qu'on dispose d'un temps de 90 µs pour 11025 Hz il y a de quoi faire.

Je ne me sers des interruptions que pendant la reception du fichier WAV, pour le rangement en Flash ...
Apres GIE=0 ... pas d'interrupt pour la restitution

j'ai trouvé mon bug entre le choix AVEC ou SANS impression du contenu des blocs de 128 bytes ..
mon pointeur n'etait initialisé correctement que dans le mode AVEC
=> déplacement de l'init pointeur en amont du choix => probleme résolu


nota : une lecture de byte FLASH dans une boucle en C ..prend 3µS

Par contre j'ai changé le délais, je l'ai mis à 94 µs pour ton fichier ok... j'ai fais ça d'oreille, car je connais pas ta vrai voix .. ok.
de plus je suis pas sur d'avoir un vrai 94 µs (à vérifier)

.. ce n'est pas ma voix..
ne pas oublier que FOSC peut etre comprise entre -3% et +3% via OSCTUNE
mon timer 2 est initialisé à 90µS, soit 11111 ..pour 11025


L'ideal étant que le PWM ait exactement la meme frequence d'echantillonage que le fichier wav
pour conserver le meme niveau d'amplitude que l'original
et ne pas ecreter... bon ,tout le monde ,n' a pas non plus ,l'Oreille Absolue.

Ps : Essai ce fichier avec un Pic18F26K22 SonWavDelayv2.zip reste 2 k pour le programme, imagine avec un Pic18F27K42

dans ton fichier datas, il y a 3584 bytes inutiles au debut
ligne 384 à 1008 .. avec datas 0x80
je l'ai testé ... Tout nu tout...

mais des questionnements subsistent :
ton fichier wav original est échantillonné à quelle fréquence ?
pourquoi le timer2 est initialisé à 15620Hz ?
ce n'est pas une valeur normalisée pour un WAV
dans la boucle de restitution , pourquoi écrêter les valeurs au dessus de 250 ?

Plutot que l'imaginer , peux-tu poster le Carlos' wav original ?
je vais le tester en direct avec mon appli en C 18F27K42 ... qui peut aussi sortir les datas du wav au format ASM

Timer2_conf.jpg

[Temps-x]

Bonjour paulfjujo, et tous le forum,

Ma fréquence Pwm est de 62500 Hz

Je te réponds vite fait, car j'ai les mains toutes noirs,(je fais ma courroie de distribution), je détaillerais tard dans la soirée,

Voir Post #11 pour téléchargement

A+

[paulfjujo]

Bonjour paulfjujo, et tous le forum,

MA fréquence Pwm est de fréquence à 62500 Hz

Je te réponds vite fait, car j'ai les mains toutes noirs,(je fais ma courroie de distribution), je détaillerais tard dans la soirée,

Voici en entier, il fait une taille de 11.7 Mo , compressé il fait plus que 2.19 Mo

Carlos - tout nu et tout bronzé 09-15-2022 03-11-48.zip


A+

dans le zip
Carlos - tout nu et tout bronzé 09-15-2022 03-11-48.tab ?
je ne peux pas l'ouvrir
ce n'est pas un wav ...