Jitter de UART TX pin

4

Estoy desarrollando un pequeño robot utilizando la placa de descubrimiento STM32L152C. Actualmente estoy intentando configurar la placa utilizando el STM32CubeMX. Nunca he trabajado en este nivel muy bajo (mi experiencia es mucho más sobre algoritmos), por lo tanto, comencé a hacer cosas simples, como enviar pocos caracteres al puerto UART. La placa no tiene un oscilador externo. Por lo tanto, estoy usando el oscilador RC interno.

Después de hacer esto, escribí un software muy fácil que envía continuamente un carácter al puerto UART:

void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_USART2_UART_Init(void);

int main(void)
{
    HAL_Init();
    SystemClock_Config();
    MX_GPIO_Init();
    MX_USART2_UART_Init();
    unsigned char msg = '@';

    while (1)
    {
        HAL_UART_Transmit(&huart2,&msg,1,1);
    }
}

Usando un osciloscopio de 100 MHz esto es lo que obtengo del pin:

Elcarácterqueestoyenviandoesclaramentevisible,peroparecequelasalidaesalgoasícomoinestable.HepresionadoelbotónAUTOenelalcancemuchasveces,peronadacambia.

PenséquetalvezpodríaserunproblemaconelosciladorRC.Despuésdeconfigurarlafrecuenciadelreloja4.194MHz(elmáximo)conelconfiguradorSTM32,medíelreloj,perolasalidanoesloqueesperaría.

Estoesloqueobtengo:

Primero,notéquelaondanoestan"cuadrada", y también la frecuencia es ligeramente diferente: 4.202 MHz en lugar de 4.194 MHz.

Me gustaría entender mejor por qué obtengo esta salida.

Con respecto a la forma, ya que el osciloscopio es de 100 MHz y el reloj tiene una frecuencia de ~ 4 MHz, supongo que la herramienta de medición no es el problema. Con respecto a la frecuencia, diría que el problema está en la precisión del propio oscilador RC. ¿Pueden estos ser la causa del problema que estoy recibiendo en la UART?

    
pregunta Alek

2 respuestas

5

Aquí hay algunas respuestas, comenzaré desde la más fácil de explicar simplemente (para mí de todos modos) a respuestas más confusas.

Primero, La forma de onda que publicó no es "cuadrada" debido a un par de factores, a saber, los efectos electrónicos parásitos que afectan al pin que está sondeando, como capacitancia, conexión a tierra inadecuada a su alcance, resistencia en serie en la traza, inductancia parásita y me gusta. Básicamente, todos estos efectos parasitarios están limitando la rapidez con que el pin puede cambiar de estado. Una verdadera onda cuadrada es imposible en la práctica, ya que requeriría un circuito para cambiar de estado instantáneamente (si ese fuera el caso, nuestras computadoras correrían MUCHO más rápido que ellas). También hay un "gotchya" agregado con los microcontroladores STM32 y otros en los que se puede cambiar la potencia de la unidad de salida. Es decir, puede, en el firmware, dictar la cantidad de corriente que está introduciendo en el resto del circuito, cambiando la velocidad a la que puede cambiar el estado. El código que publicaste no muestra ninguna mención de esto, por lo que lo más probable es que el micro se esté ejecutando a los 20MHz predeterminados, lo cual es compatible con la captura de pantalla de tu alcance (tiempo de subida de ~ 50 ns).

Segundo, Usted tiene razón al suponer que la discrepancia en la frecuencia de salida se debe al oscilador RC interno. EnlahojadedatosdelSTM32L152C,página75,puedeverqueelRCinternomuestraunaprecisiónenelpeordeloscasosde-4%a+3%entodoelrangodetemperaturadeoperación,yde+/-1%atemperaturaambiente.Entonces(4.202-4.194)/4.194*100=0.19%dediferencia,queestádentrodelasespecificaciones.

Porúltimo,EljitteresmásprobabledebidoalasbibliotecasHALpiss-porr(Séqueestanoesunagranexplicación,peromehetopadoconmuchosproblemasconesteb/sdesdequedejarondeadmitirlabibliotecaSPLquehemosestadoescribiendonuestropropioHALencasaparalosvariosSTM32's).SiobservaelcódigoHAL,lamayoríadelasvecessetransmitenestructurasdedatosgigantescaseinfladasquerepresentanelcódigoHALconfiguradoautomáticamenteconcadallamadadefunción.Loquenormalmentesepodríahacerenviando4bytesalregistroapropiado(algunos,sino1ciclosdecpu)compilahastamuchas,MUCHASlíneasdeensamblaje.CombineesoconunoscuantosISRsqueestánaquíyallávaahaberunpocodejitter.Elcuelloprincipaldelabotellaaquíeseltiempoquetardaelprocesadorencapturarlassiguientesinstruccionesdeflash,enrealidadesunprocesocomplicadocuandoelprocesadorestáhaciendocosasconrecuperacionesdeinstruccionescanalizadas.Puedeleerelmanualdelprocesadorhere Sección 3. Intentaría cargar su programa en la placa de desarrollo para ejecutar desde RAM y ver si El problema desaparece, si no es así, estoy siendo un idiota y me estoy perdiendo algo simple. Pero mi recomendación sería deshacerse de las bibliotecas HAL si puedes, desafortunadamente, ST no ha lanzado su SPL para las series de piezas L1 y L4, por lo que es posible que tengas que cavar un poco.

Finalmente ... :) ¿Es esto incluso un problema? ¿Puede su computadora recibir los Char's correctamente o puede decodificarlos con su alcance?

    
respondido por el Luke Gary
1

¿Ves dónde está el punto de activación de la traza de alcance? Está en el medio de la traza. El jitter está antes del disparador y ocurre entre un personaje y el siguiente. Esto no afectará la recepción del personaje, ya que la comunicación asíncrona no asume ningún carácter de carácter de carácter a carácter.

Si cambia la configuración de su alcance para que el disparador esté en el lado izquierdo y para que pueda ver dos caracteres, será más obvio lo que está sucediendo.

¿Tiene alguna rutina de servicio de interrupción de temporizador en ejecución? Por ejemplo, en la función "SystemClock_Config ()", habilita un temporizador periódico.

Si es así, hay un ISR que está robando periódicamente el tiempo de main () y causando que el retraso entre los caracteres varíe.

    
respondido por el Kevin White

Lea otras preguntas en las etiquetas