Envío de medidas ADC con UART

Quiero medir la señal ADCy enviar las medidas a la PC para generar gráficos.

Mi código:

ADC_SoftwareStartConv(ADC3);
while(1)
{
    ADC3ConvertedVoltage = ADC3ConvertedValue * 3300/0xFFF;
    ADCresultsTab[i] = ADC3ConvertedVoltage;
    sprintf(str,"%u",ADC3ConvertedVoltage);
    USART2_SendText(str);
    USART2_SendText(";");
}

El problema es que quiero muestrear la señal lo más rápido posible. Aquí estoy usando baud rate = 256000(solo Windows). ¿Cuál es la posibilidad de muestrear señales más rápido? ¿Cuál es el código más óptimo para la medición de muestras y envíos?

Veo que el problema ahí es UARTla transmisión.

Y mis preguntas adicionales son: ¿Es la medición en tiempo real con este código? ¿Cómo se debe hacer si quiero medir en tiempo real?

Anuncio. lo más rápido posible: consulte la hoja de datos (así que agregue un enlace) sobre qué tan rápido es realmente el ADC. Anuncio. pregunta adicional: Primero defina cuál es su requisito para "tiempo real".
Pero ahí el problema también está en el envío de datos por uart. Sé que la limitación es la velocidad de ADC, pero en el código en cuestión se ralentiza mediante el envío de datos UART. Mi pregunta es cómo implementarlo de manera eficiente para no limitar la velocidad de medición. No entiendo la segunda parte de la pregunta, pensé que hay una definición de "tiempo real".
Interrumpe. El ADC puede realizar una conversión mientras los datos se transfieren a través de UART. Durante la conversión, la CPU no hace nada y puede usar ese tiempo para llenar el búfer UART con datos.
O DMA, aunque probablemente tendría que configurar dos transmisiones DMA (DAC a memoria, memoria a UART).
Haz el trabajo duro (División y multiplicación) en la PC. Si tiene capacidades DMA en la MCU, utilícelas.
Si el propósito de la transferencia a la PC es generar gráficos en tiempo real, tómese un momento para pensar en cómo se pueden usar e interpretar esos datos en el extremo del usuario. Graficar datos de 8 Mmuestras/segundo en tiempo real es simplemente inútil para la visualización. Además, lo de "lo más rápido posible" es un poco al revés. Comience con "tan rápido como necesite que funcione", ponga un número y esfuércese por lograrlo.

Respuestas (2)

Si bien sería necesario un código más elaborado basado en interrupciones o DMA para lograr el mejor rendimiento, mejoras relativamente menores en su código ya mejorarían la situación. Comenzaría transmitiendo muestras en binario en lugar de en texto. Esto requiere un poco más de trabajo en el extremo receptor, pero reducirá el ancho de banda UART requerido en al menos 2-3 veces (2 bytes por muestra frente a hasta 6 en texto con separador). También puede aumentar fácilmente la velocidad en baudios a, por ejemplo, 921,6 kbps, que es estándar y debería ser compatible con el extremo receptor. Suponiendo una arquitectura STM32F2 estándar, podría subir hasta 7,5 Mbps, pero necesitaría verificar el soporte para eso en el extremo receptor.

Con 2 bytes por muestra y 921,6 kbps, obtendrá un rendimiento de alrededor de 46 000 muestras/s. A 7,5 Mbps, obtendría 370 000 muestras/s. Si su aplicación lo permite, puede reducir la resolución a 8 bits y, por lo tanto, usar un solo byte por muestra, duplicando efectivamente el rendimiento en muestras/s.

Si bien 370 kmuestras/s no está mal, todavía está bastante lejos de los 6 Mmuestras/s teóricos (asumiendo STM32F2, conversión de 12 bits y usando el 3 ADC en modo triple intercalado). Esto se traduce en 12 MB/s de datos para transferir desde la MCU a la computadora, que no es una cantidad trivial. UART no servirá. SPI, a un máximo de 30Mbps (2-3MB/s) tampoco lo hará. Escribir en una tarjeta microSD a través de SDIO estaría cerca. USB 2.0 lo haría, pero es mucho más complicado en cuanto al software y requiere componentes externos para el PHY. ETH también funcionaría bien, pero requeriría componentes adicionales y una pila de red para implementarse en la MCU. Esta complejidad explica por qué, en la mayoría de las aplicaciones, las muestras se almacenan en la memoria y se transfieren de forma asíncrona.

Vale la pena mencionar que STM32 USART tiene un pico teórico de 4Mbps y, de manera realista, para PC a través de un dongle FTDI, tal vez 3Mbps como máximo. Algunas configuraciones específicas de RS485 tal vez podrían ser un poco más altas.

Probablemente también valga la pena mencionar que la sprintfllamada probablemente sea bastante lenta y (si es la única vez que la usa) extrae una gran cantidad de código de biblioteca. Incluso si desea mantener un ascii legible por humanos, probablemente podría serializar el número mucho más rápido que sprintf. Mientras está en eso, puede incluir el punto y coma en la cadena y hacer solo una llamada a USART2_SendText.

Envío de medidas ADC con UART
RespuestasAquíPolítica de privacidad1y, 0v