¿La comunicación UART no funciona con valores de velocidad de transmisión más altos?

0

Tengo un PIC32MX795F512L que está conectado a 8MHZ crystal. El programa UART funciona con el valor de 9600 baudrate pero no funciona con valores de baudios más altos como 115200 .

El siguiente es el código:

#define FCY 72000000UL //PIC32 working on 72MHZ
#define FPB (FCY/2)    // Peripheral clock is half of FCY
#define BAUDRATE    9600 // Baud Rate Value
#pragma config POSCMOD=HS,FNOSC=PRIPLL //Using High speed mode with primary Oscillator 
#pragma config FPLLIDIV=DIV_2, FPLLMUL=MUL_18, FPLLODIV=DIV_1
#pragma config FPBDIV=DIV_2, FWDTEN=OFF
int main()
{
  OpenUART1( UART_EN | UART_NO_PAR_8BIT | UART_1STOPBIT  , UART_RX_ENABLE | UART_TX_ENABLE, (FPB/16/BAUDRATE)-1 );
  while(1)
  {
   putsUART1("hello\n");
   DelayMs(1000);
  }
}

Esto podría ser el cristal no funciona correctamente. ¿Qué otras razones pueden hacer que la UART no funcione con velocidades más altas?

    
pregunta user007

3 respuestas

4

Supongo que el micro no puede alcanzar las velocidades de transmisión más altas con la suficiente precisión dada la velocidad de reloj más bien baja de 8 MHz. Esto ilustra uno de los inconvenientes de usar una biblioteca enlatada a ciegas. Aparentemente, su biblioteca no tiene medios para decirle con qué velocidad en baudios terminó y en el tiempo de ejecución es demasiado tarde para hacer algo al respecto.

La mayoría de los UART necesitan un reloj a 16 veces la velocidad en baudios. A 9600 baudios, eso significa que el UART necesita obtener 153.6 kHz de su generador de velocidad en baudios. Si está comenzando con 8 MHz y está limitado a dividirlo solo por números enteros, entonces lo mejor que puede hacer es 52, que es un reloj 16x de 153.8 kHz, y una velocidad en baudios de 9615. El sistema funcionará bien con ese error de 0.16%, y no lo estás notando.

A 115.2 kBaud necesitas un reloj UART de 1.843 MHz. Eso es 8 MHz / 4.34. Lo más cerca que puede acercarse es dividir por 4, lo que produce un reloj UART de 2 MHz y una velocidad en baudios de 125 k. Eso es un error del 8,5%, que es demasiado grande para permitir que el sistema funcione.

Cuando necesita altas velocidades en baudios, y especialmente cuando desea mantener bajo el reloj del microcontrolador, generalmente desea usar un cristal de velocidades en baudios, como 7.3728 MHz. Eso es deliberadamente un múltiplo de todas las tasas de baudios comunes multiplicadas por 16.

    
respondido por el Olin Lathrop
2

Según mis cálculos, diría que el problema es un error de velocidad de transmisión en exceso. El valor colocado en el registro UxBRG determina en última instancia su velocidad de transmisión. Dado que el valor del registro debe ser un número entero, el valor obtenido de las fórmulas de velocidad de transmisión prescrita (en la hoja de datos) se redondea al número entero más cercano y se coloca en el registro; siempre hay algún error, la pregunta es '¿cuánto?' y '¿Es tolerable?'. Ya que está usando FCY / 2 (= 72/2 = 36 MHz) como reloj periférico y está usando el modo de velocidad estándar (es decir, BRGH = 0, también evidente porque está dividiendo por 16), entonces, para 1152000 baudios, según a la fórmula:

    UxBRG = (FPB / 16 / BaudRate) - 1 
    UxBRG = (36000000 / 16 / 115200) - 1 = 18.53 = 18

Para calcular la cantidad de error que tenemos al truncar 18.53 hasta 18,

    Baud Rate = FPB / 16 * (UxBRG + 1)
    Baud Rate = 36000000 / 16 * (18 + 1) = 118421 // approximate
    % Error = ((118421 - 115200) / 115200) * 100 = 2.79 %

El error de velocidad de transmisión aceptable difiere según el dispositivo y si sus dos dispositivos de la misma clase hablan entre sí (por ejemplo, PIC a PIC), pero en general está de acuerdo en que el 2% es un buen máximo para la mayoría de los casos y el 2.79% supera ese valor. Entonces, para resolver este problema, hay 2 formas en que puedo verlo:

  • En su lugar, use 72 MHz como el reloj periférico, si es posible.

    UxBRG = (72000000 / 16 / 115200) - 1 = 38.06 = 38
    Baud Rate = 72000000 / 16 * (38 + 1) = 115384
    % Error = ((115384 - 115200) / 115200) * 100 = 0.16 %
    

    Este error es aceptable.

  • Cambia del modo de velocidad estándar al modo de alta velocidad. Esto implica configurar BRGH o, usando su biblioteca, llamar a OpenUART1 de esta manera:

    OpenUART1( UART_EN | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_BRGH_FOUR, UART_RX_ENABLE | UART_TX_ENABLE, (FPB/4/BAUDRATE)-1 );
    

Con este cambio, los nuevos valores son:

    UxBRG = (36000000 / 4 / 115200) - 1 = 77.125 = 77
    Baud Rate = 36000000 / 4 * (77 + 1) = 115384
    % Error = ((115384 - 115200) / 115200) * 100 = 0.16 %

El mismo error que antes, sigue siendo aceptable.

    
respondido por el TisteAndii
2

En el pasado tuve problemas con el uso de la UART a 2 Mbps, pero mi problema era que el búfer en el extremo receptor se estaba llenando antes de que pudiera extraer los bytes recibidos.

Obtendría los primeros bytes correctamente y después de eso todo fue basura.

Hay dos cosas que haría:

  1. Verifique las líneas con un osciloscopio (mencionó un depurador pero no sé cómo puede verificar el nivel lógico de las trazas de PCB con eso) o un analizador lógico para asegurarse de que la imagen que se está escupiendo es correcta. Puedes enviar bytes que en binario serían 01010101 para que puedas examinarlos fácilmente en la pantalla del alcance.
  2. No descuidaría el otro lado de la línea. En primer lugar, compruebe si el chip MAX32 puede aceptar la velocidad en baudios que eligió. AFAIK los chips FTDI también tienen registros de baudios, por lo que no puede alimentarlos en baudrate. En segundo lugar, usaría los pines de handshaking del hardware y vería si hay una diferencia.
respondido por el George Psarras

Lea otras preguntas en las etiquetas