¿Qué tan críticas son las frecuencias UART?

Voy a usar un cristal de 8 MHz para ejecutar mi microcontrolador a 16 MIPS (PLL 4x, instrucciones de 2 ciclos). Sin embargo, 8 MHz no se divide en ninguna frecuencia UART AFAIK ... entonces, ¿qué tan importantes son estas frecuencias? Planeo usar 115.200 baudios.

¿Puede UART ejecutarse dentro de ± 1%? Si esto no funciona, ¿qué frecuencia debo usar? (Me gustaría obtener lo más cerca de 16 MIPS como sea posible, para una velocidad de procesamiento máxima). Si es importante, estoy usando un PIC24FJ64GA004.

Si está dentro del 1%, debería estar bien.

Suponga que su UART usa un reloj de sobremuestreo de 16x, por ejemplo, puede configurarlo a 1,843,200 Hz a 16x sobremuestreo de 115,200 bps. (un sobremuestreo como este es bastante común) Esto permite que el UART cuente 8 over-relojes desde el borde descendente del bit de inicio, para que pueda ubicar el centro de las celdas de bit dentro de +/- un período del over clock que cuenta 16 períodos del reloj para determinar cuándo muestrear datos.

Si supone que puede alcanzar el centro del bit de inicio, para mantener el muestreo de datos en serie en las celdas de bits correctas en 8 bits de datos, la frecuencia del reloj debe permanecer entre (8-0.5) / 8 y (8 + 0.5 ) / 8, o +/- 6.25% de la tasa de bits prevista. Un overclocking más alto se acerca a la condición ideal de golpear el centro del bit de inicio, pero 8x o 16x generalmente está lo suficientemente cerca como para suponer que un 5% de desajuste funcionará.

Sin embargo, no puede contar con que el otro lado tenga una frecuencia perfecta. Si conecta un dispositivo que es 4% rápido a un dispositivo que es 4% lento, tendrá un problema. Me he encontrado con al menos un caso en el que una PC funcionaba un poco lento y un dispositivo un poco rápido, y los dos solo podían comunicarse marginalmente, aunque el mismo dispositivo estaba bien con otras PC, y la PC estaba bien con otros dispositivos. (O-alcance estos a aproximadamente 112 kbps y 119 kbps) Por esa razón, es bueno tratar de alcanzar la frecuencia nominal lo más cerca posible. Nunca he visto que algo dentro del 2% del nominal tenga un problema.

Lo habitual es utilizar una frecuencia de reloj principal que proporcione un número entero múltiplo de la frecuencia de sobremuestreo UART prevista multiplicada por la velocidad en baudios. Por ejemplo, si desea una CPU que funcione a aproximadamente 8MHz, puede usar un oscilador de 7.3728MHz, que se puede dividir por 4 para obtener 1.8432MHz, que es exactamente 16 veces 115200.

El 1% que menciona @JustJeff no es obligatorio. La mayoría de los UART permiten un error de medio bit en el último bit. La mayoría de las veces una trama consta de 1 bit de inicio, 8 bits de datos y 1 bit de parada, para un total de 10 bits. Medio bit en 10 bits es 5% (el 6.25% de JustJeff no toma en cuenta el bit de inicio y parada).

JustJeff se olvidó del bit de inicio, pero Stevenh agregó el bit de parada. Suponiendo el protocolo común de 8 bits de datos, 1 bit de inicio y ningún bit de paridad (el número de bits de parada no importa), hay 8 1/2 bits desde el borde inicial del bit de inicio hasta el centro del último bit de datos. En general, desea que el receptor muestree este último bit dentro de un tiempo de 1/4 bit. Tenga en cuenta que 1/2 bit es el umbral garantizado para fallar. Cualquier cosa cerca de allí se vuelve irrealizable ya que siempre hay algo de ruido eléctrico y jitter.

1/4 dividido por 8 1/2 = 2.94%.

Como mencionó JustJeff, la mayoría de las implementaciones de UART en realidad muestrean los datos entrantes con un reloj asíncrono 16x. Eso agrega otra incertidumbre de tiempo de 1/16 bit, ya que ese es el error con el que se puede medir el borde inicial del bit de inicio. 1/16 bit de tiempo fuera de 8 1/2 bits es otro .74%. Eso proviene del presupuesto de error calculado anteriormente. Se termina con un 2,2% de desajuste de reloj permitido para que el receptor muestree el último bit dentro de un tiempo de 1/4 bit de su centro.

Como otros han dicho, usar un cristal de 7.3728MHz es una práctica común cuando se requiere una velocidad de transmisión precisa. Por lo general, puede hacer arreglos para ejecutar la CPU cerca de su velocidad máxima mientras alcanza la velocidad de transmisión UART dentro del error de cristal.

Un punto que aún no se menciona es que algunos dispositivos esperan transmitir un byte de datos por cada byte de datos que reciben. Si un dispositivo de este tipo recibe datos de forma continua, su velocidad de transmisión es incluso un 0,1% más lenta que la del dispositivo de transmisión, y no tiene ninguna facilidad para enviar bits de parada ligeramente reducidos, su salida caerá un byte por cada 1000 consecutivos bytes que entran. Si el dispositivo está limitado a 16 bytes de almacenamiento en búfer, perderá un byte de datos después de pasar aproximadamente 16,000 y luego caerá aproximadamente un byte por mil. Vale la pena señalar que los llamados módems "1200 baudios" realmente funcionan a una velocidad ligeramente superior a 1200 bits / segundo (creo que es aproximadamente 1202) precisamente por esta razón (de modo que incluso si el transmisor es 0.15% más rápido de lo que debería) ser,