¿Alguien sabe cómo cambiar frecuencia de sample del ADC en modo burst-DMA en el 1769?

[C. Marchese]

Hola, ¿Cómo están? Ariel Lutenberg me pasó el contacto de este grupo ya que estoy teniendo un inconveniente con un proyecto en el LPC1769. A ver si alguno me puede ayudar.

Estoy procesando audio de baja frecuencia y tomando muestras del ADC por DMA en modo burst modificando el ejemplo del LPCopen y estoy usando freertos (Lo del freeRTOS no lo puedo cambiar lamentablemente es requisito de la materia que curso). Ya probé todo lo que se me ocurrió para bajarle la frecuencia y nada parece variarla salvo el divisor por 8 que trae que me baja la frecuencia a la mitad, pero no me alcanza. el  registro LPC_ADC->CR ya se lo toqué y no hace nada, hay una variable que se llama _bitrate, lo toqué y tampoco hace nada.

Mi problema es que quiero tomar un par de segundo de información de un estetoscopio para procesar. Menos de 1 segundo no tengo latidos y necesito más de un latido para sacar información. La información más rapida está en unos 300 o 400Hz. Si quisiera tomar un segundo de muestra a 100KHz necesitaría un buffer de 200KB por lo que me gustaría reducirlo a 1KHz o alguna frecuencia similar. Probé realizar el ADC con interrupción cada 1ms y el problema es que entre  el ADC, el DAC y un filtro en el medio ya se toman todo el tiempo de procesamiento no entrando nunca en las rutinas de teclado, display o escritura de sd card.

No sé si alguno ya encaró algún problema similar y me puede orientar en su solución ya sea en decirme como bajarle la frecuencia al burst mode o cambiar el enfoque de trabajo si es que lo estoy pensandolo mal.

Adjunto el código retocado del ejemplo del lpcopen que mensiono por mayor claridad.

Saludos!!

Cristian Marchese.  

[Sergio Adrián Lapilli]

Hola Cristian.

 

Cuando usas el modo burst, una vez que la señal de comienzo de conversión se genera (y puede ser por ejemplo por software) repite las conversiones una detrás de la otra (en la secuencia que programaste si hay más de un canal) y el tiempo entre conversiones queda definido por los ciclos de conversión necesarios y el clock de entrada del ADC que sólo lo podés controlar  con el divisor CLKDIV del registro ADCR. CLKDIV divide el clock PCLK_ADC que se puede controlar con el registro PCLKSEL0.PCLK_ADC pudiendo elegir entre CCLK, CCLK/2, CCLK/4 y CCLK/8. Esto te da cierta libertad para elegir la frecuencia de muestreo  que quedaría como FrecMuestreoADCBURST=PCLK_ADC/(64*(CLKDIV+1)).

 

En tu programa, al llamar a la rutina Chip_ADC_SetSampleRate(LPC_ADC, &ADCSetup, ADC_MAX_SAMPLE_RATE) le estás poniendo que genere el máximo de la frecuencia de muestreo (que es 200K). Probá a colocar 1000 y si la configuración que vos tenés de CCLK y PCLK_ADC te permite llegar a ese valor va a funcionar. Si no llega a la velocidad de muestreo no uses el modo BURST de ADC (Ojo que la restricción de usar el DMA para el ADC se refiere al modo BURST del DMA, no del ADC).

 

Para poder muestrear a cualquier velocidad, hay que sacarlo del modo burst y utilizar una señal de start proveniente de uno de los timers (por ejemplo MAT0.1). El timer hay que programarlo para que tenga un período en la señal elegida de 1KHz. Por ejemplo: seleccioná para el timer 0 en modo timer, en el registro match control register colocá que se resetee al llegar al valor de MR1 -> T0MCR.MR1R=1, en MR1 colocá un valor que genere un período de 500useg; además colocá en el external match register que genere toogle en MAT0.1 cuando el contador llegue a MR1 -> T0EMR.EMC1=3. Seleccioná la señal MAT0.1 en la señal de start del ADC ADC0CR.START=4

 

Siempre fíjate en los manuales usuario que todo esto está explicado en detalle, para este micro es el UM10360.pdf

 

Saludos.

 

Mg. Ing. Sergio A. Lapilli

 

Enviado desde Correo para Windows 10

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/10ba10c6-4c81-474f-a787-2034931a4e01n%40googlegroups.com.

 

[Pablo Slavkin - disenioconingenio]

No se si es buena idea bajar mucho la frec de captura.

Lo ideal seria que captures en el menor tiempo posible y luego duermas
el adc hasta la proxima muestra a tiempos regulares (cosa que el dma no
necesariamente te cumpla).

Te sugiero para eso linkear un timer que dispare el adc en overflow y
cuando el adc temina te salte irq para mover el nuevo sample y ubicarlo
en tu buffer.

Ese timer si lo pones a 1k.


--

Saludos cordiales.
Pablo Slavkin

> --
> -- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
> ---
> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
> Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

> Para ver este debate en la Web, visita https://groups.google.com/d/msgid/embebidos32/10ba10c6-4c81-474f-a787-2034931a4e01n%40googlegroups.com.

[C. Marchese]

Hola, gracias por las repuestas, el  UM10360.pdf ya me lo leí completo y luego busque todas las partes relacionadas al adc y dma e intenté de estudiarlas, dice que la velocidad se fija tocando el clock en modo burst pero no dice mas que eso y después los dos registros de clock que me aparecían en el manual eran el CLKDIV que me comentás y el del registro CR. 

El CLKDIV viene para dividir máximo por 8 por defecto está en 4 a 200K, con ese pude bajarle la frecuencia a 100K. Modificar el registro CR no me dio ningún resultado sin importar el valor que pusiera, nada cambiaba. La función Chip_ADC_SetSampleRate creo que es eso lo que hace también, igual intenté de variarla y no genera ningún efecto. Según lo que me comentó el ayudante de la materia, esa función tiene que ver mas con la adquisición que con el tiempo entre los samples. El ayudante también estuvo intentando de variarle mas la frecuencia que esos 100KHz y tampoco pudo, por eso consultaba por acá también.

Mi problema de setear un match o de adquirir cada 1ms los datos por una interrupción or timer son las latencias generadas. De hecho  el proyecto ya lo tengo funcionando así, pero al habilitarle ADC, DAC y filtro, el teclado ya se vuelve algo insensible, y si le subo la prioridad a este pierde información sonora. A esto aún me falta un procesamiento de detección de soplos que por los papers que anduve indagando utilizan transformadas wavelets que también llevará bastante procesamiento del micro. (A todo esto ni siquiera sé si ese alcance que plantié es posible con este micro o debería usar un DSP, pero en la materia me imponen el micro y el uso de freeRTOS)

Saludos y de vuelta muchas gracias por las respuestas.

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/7_mnhsaqIF4/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/embebidos32/20210219134303.GF30614%40dci.dci.

[Leandro Palazzo]

Hola,

No soy muy conocedor del tema pero no creo que el tiempo de captura del conversor sea lo que te esté utilizando tiempo del micro. En general el conversor tarda N operaciones en converger, donde N es la precisión en bits. Entre eso, la copia del valor y el almacenamiento en ram dudo que sea un factor dominante.

Por otro lado, 1ms  es un tiempo relativamente alto para tomar muestras, por lo que usar DMA no creo que sea la opción.  Si tu información importante está a los 400 Hz, con una tasa de 1k tendría que ser suficiente, pero creo que se puede lograr aun mayor resolución si quisieras.

Utilizando freeRTOS, si le das la prioridad máxima igualmente no te tendría que comer casi nada de tiempo de procesamiento. Serían: 14 instrucciones para converger, otras 20 para hacer alguna operación que necesites y demás. 100 instrucciones como mucho contando también el sistema operativo. Eso te da 1 microsegundo de tiempo de ejecución @ 100 Mhz por cada 1 milisegundo (1%). Y estarás almacenando 2kBps.

Saludos y espero que puedas resolver el problema, cualquier avance comentalo!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAHF%2BnmtoPcU9XWSwQuVv9dkiMHVh8Sr8iCVxnboHJDG0gYYFCw%40mail.gmail.com.

[C. Marchese]

Hola Leandro, si gracias. Entiendo lo que me decís y estoy intentándo de encarar por ese lado porque ya estoy sobre el tiempo de entrega. Jugando con las prioridades y apagando todas las funciones que no esté usando y al parecer va funcionando, yo no hice calculos para ver cuando tengo de procesamiento pero si veo que si le subo la piorodad a lo que es adc y demás el teclado, SD card se quedan medio insensible y si le subo la prioridad a lo que es teclado pierdo información sonora. Tenía ganas de encarar el tema de procesamiento mas complejo que había planteado a principio de la materia pero ya por tiempos y lo difícil que me resultó lo del DMA creo que haré lo básico nada más de la forma que me lo planteas.

Muchas gracias a todos. saludos,

Cristian Marchese

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAEpiJ%2BQ%3D-c5ywv5Bd8gS0yxv3iGYa9rnWqSS_Z46Lp%3DJWkH2WA%40mail.gmail.com.