I2s & pdm

[invite5bc96a17]

Bonjour à tous!

Voilà je suis sur un projet qui inclue un micro et un pic. J'aimerai enregistrer les données venant du micro dans la mémoir du pic. Le micro me donne à la sortie un signal PDM (Pusle-Density Modulation, à ne pas confondre avec un signal Pulse-Duration Muodulation). Ma question est de savoir s'il est possible de mesurer ce signal avec le mode capture du PWM du pic? D'après mon expérience je pense qu'il n'est pas possible de pouvoir le faire mais j'ai un doute.

J'aimerai utiliser le pic 18F46J50 pour cette application.

Merci pour votre aide et à bientôt j'espère ^^
-----

[RISC]

Salut,

L'unité de capture permet de mesurer : période, pulse, rapport cyclique.

Quand tu parles de micro, tu veux dire je suppose microphone

Cela dépend simplement de tes signaux d'entrée qui doivent être suffisamment "longs" vis à vis de la résolution du PIC et de la résolution que tu souhaites.
Le PIC18F46J50 fonctionne jusqu'à 48MHz ce qui donne Fcy = 12MHz --> Tcy = 83ns qui est donc la résolution de la capture.

Quelle est l'unité de base en temps que tu dois mesurer et avec quelle résolution ? (worst case)

a+

[invite5bc96a17]

Je doit mesurer pendant 4minutes (5 grand max) en continue et enregistrer les informations reçues.

Le microphone que j'ai à disposition est un WM7210. Je n'ai pas de résolution spécifique à respecter. Juste que la fréquence du clock minimum pour obtenir un signal correcte à la sortie du microphone est de 70kHz. Après le problème que j'ai c'est que plus la fréquence du clock est grande et plus j'aurai de données à enregistrer et plus il me faudra d'espace mémoire. Avec le pic je suis limité à 4Mbytes si mes calculs son bon.

Après avoir étudier mon problème plus en profondeur j'ai trouver une solution pour éviter la mesure du signal PDM avec le mode capture du PWM. J'utiliserais une des entrées interruptions externe (par exemple INT0) pour détecté chaque flanc sur le clock du microphone (flanc montant ou descendant suivant la configuration) et j'enregistrerai le signal bit par bit. C'est la meilleure solution que j'ai trouvée pour éviter d'utiliser le PWM que je ne connais pas énormément. De plus, vu que le pic est juste censé enregistrer le signal et le réstitué via l'USB du pic ça simplifierai les choses de mon point de vue.

Merci pour la réponse.

a+

[RISC]

Salut,

D'après la datasheet du WM7210, la clock est : 1 MHz < FCLK < 3.25 MHz
Je ne comprends pas ton allusion à une clock de 70kHz ?

Car si l'horloge est de 1MHz ou plus cela va être chaud pour faire cela par soft avec un tcycle de 83ns pour le PIC, surtout en C...

Tu fais une allusion à 4MBytes ? ce PIC contient 64Ko de Flash. La seule chose faisable est d'enregistrer dans une Flash SPI externe ou peut être une carte SD (uSD) externe.

a+

[A voir en vidéo sur Futura]

[invite5bc96a17]

Salut,

Je sais que sur le datasheet la fréquence du clock conseillée se situe entre 1 MHz et 3.25 MHz. J'ai quand même fait un teste avec des fréquence plus faible pour voir si le signal de sortie était correcte même en dessous de ces valeurs. Et les 70kHz, c'est la fréquence minimale que j'ai pu atteindre avec un signal correct en sortie.

Pour les 4MBytes, je me suis renseigner et effectivement ce pic ne contient aucune EEPROM. Donc je vais être obliger de choisir une mémoire externe.

Merci pour ta réponse.

a+

[Qristoff]

Salut,
La solution la plus simple à mon sens est de faire générer l'horloge par le pic et d'échantilloner la sortie PDM avec la même horloge... pas de perte de bits comme cela et traitement ultra rapide !
C'est d'ailleur comme cela qui font dans la datasheet, il utilise le front descendant de l'horloge pour le canal droit et le front montant pour le canal gauche.

[inoxxam]

Salut,
J'ai fait un truc comme ça il n'y a pas deux semaines sur une autre marque de processeurs. Le procédé que j'ai utilisé est assez simple: j'ai utilisé un module SPI en récepteur maitre. En tant que maître il génère une horloge (paramétrée à 2.4MHz dans mon cas). Je prélève un échantillon de 50 octets, je puis je compte le nombre de 1 dans l'échantillon, à partir de là je peux connaître la valeur de l'échantillon (au sens de l'échantillonnage audio) avec une simple loi affine. Ce procédé nécessite un bon filtrage car le bruit est plutôt élevé, rien de bien compliqué, un filtre RII bien conçu fait l'affaire.
Pour ta curiosité, après ce son je l'utilise pour le sampler, le filtrer, mettre des effets numériques (...) dessus et le balancer à un DAC qui fonctionne en I2S.
Bonne continuation!

[invite5bc96a17]

Salut et merci pour vos conseils et aides.

@Qristoff:
C'est ce que je compte faire. Par contre je vais devoir créer un clock avec un des timers disponible. Car la fréquence du pic doit être plus élevée que celle du clock du microphone. La raison c'est que à côté j'ai un autre capteur (accéléromètre). Et pour être sur de pouvoir tout faire je pense utiliser une fréquence de clock pour le microphone minimum 8 fois plus petite que celle du pic.

@inoxxam:
J'aurais volontier utilisé ta méthode, mais le problème c'est que l'accéléromètre utilise déjà le SPI. Et vu que ces deux capteurs fonctionne en même temps. Il est possible, avec ta méthode, de faire les deux mais ça risque de trop compliquer la programmation et pour l'instant je ne peux pas trop me le permettre. Il y a aussi le fait que, vu que je doit enregistrer 3minutes minimum & 5minutes maximum la fréquence d'échantillonnage joue un grand rôle sur le nombre de bits à enregistrer et je suis limiter dans la mémoire externe que je pourrais utiliser. Mais si je n'ai pas d'autre choix il y a de très forte chance pour que j'utilise ta technique ^^

Pour l'instant je vais rester sur mon idée de détecter chaque flanc montant du clock du microphone et enregistrer le niveau logique bits par bits.

En tout cas je vous remercie pour votre aide ^^

a+

[Qristoff]

Par contre je vais devoir créer un clock avec un des timers disponible.

pas nécessairement si tu veux les garder pour faire autre chose ! tu peux utiliser un diviseur externe pour conserver le synchronisme avec l'horloge maitre du pic. Ainsi les données et l'horloge du pic sont synchrones et tu n'a pas besoin de détecter les fronts montants..
Je ne sais pas quel pic tu utilises mais il y aussi une sortie CLKOUT que tu configures et qui fournit Fosc/4.

[inoxxam]

Sinon une autre solution, tu mets un filtre RC tout bête en sortie de ton micro, et avec un ADC tu viens lire la valeur en sortie de ton filtre à chaque période d'échantillonnage. Simple et efficace. Il faut néanmoins toujours générer une horloge mais ce n'est pas un gros problème je pense.

[invite5bc96a17]

Salut,

La solution du convertisseur A/D j'y avais déjà pensé. Mais est-ce que j'aurais le temps de convertir les données et faire des mesures sur l'accéléromètre à côté sachant que le clk du microphone est 1MHz et la fréquence max du pic 48MHz?

Merci pour l'aide.

a+

[inoxxam]

Le 1MHz du microphone tu t'en fiches en fait, il serait filtré par le filtre passe bas qu'il faudrait mettre. Tu pourrais te contenter d'échantillonner à 44100 Hz (voire moins).

[Qristoff]

Le 1MHz du microphone tu t'en fiches en fait, il serait filtré par le filtre passe bas qu'il faudrait mettre. Tu pourrais te contenter d'échantillonner à 44100 Hz (voire moins).

c'est vachement efficace comme solution...le microphone digitalise le son, tu le repasses en analogique avec ton filtre PB et tu redigitalises derrière...

[invite5bc96a17]

J'avais répondu à ma question par moi-même mais merci ^^

c'est vachement efficace comme solution...le microphone digitalise le son, tu le repasses en analogique avec ton filtre PB et tu redigitalises derrière...

Oui c'est pas tip top comme système mais pas le choix si on veut diminuer la fréquence d'échantillonnage du microphone. Si je ne fais pas ça même avec un pic fonctionnant à 64MHz j'aurais des soucis pour pouvoir faire autre chose en parallèle.

Merci pour les réponses ^^

a+

[inoxxam]

c'est vachement efficace comme solution...le microphone digitalise le son, tu le repasses en analogique avec ton filtre PB et tu redigitalises derrière...

Je n'ai jamais dit que c'était efficace. Mais c'est simple et ça fonctionne avec peu de ressources au niveau processeur. En plus s'il s'agit d'un petit micro CMS (comme ça l'était pour mon cas) je doute du fait que la qualité sonore soit d'une grande importance.