¿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 críticas son estas frecuencias? Planeo usar 115,200 baudios.

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

Respuestas (4)

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

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

Si supone que puede tocar el centro del bit de inicio, entonces, para seguir muestreando 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 suelen estar lo suficientemente cerca como para suponer que funcionará una falta de coincidencia del 5 %.

Sin embargo, no puede contar con que el otro lado esté perfectamente en la frecuencia. Si conecta un dispositivo que es un 4 % rápido a un dispositivo que es un 4 % lento, tendrá un problema. Me encontré con al menos un caso en el que una PC funcionaba un poco lenta y un dispositivo un poco rápido, y los dos solo podían comunicarse marginalmente, aunque el mismo dispositivo funcionaba bien con otras PC y la PC funcionaba bien con otros dispositivos. (Amplió estos a unos 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 valor nominal tenga un problema.

Lo habitual es utilizar una frecuencia de reloj maestra que proporcione un múltiplo de un número entero de la frecuencia de sobremuestreo del UART deseada multiplicada por la velocidad en baudios. Por ejemplo, si desea que una CPU funcione a aproximadamente 8 MHz, puede usar un oscilador de 7,3728 MHz, que se puede dividir por 4 para obtener 1,8432 MHz, que resulta ser exactamente 16 veces 115200.

8 MHz podrían dividirse entre 69 para obtener 115 942, que está dentro del ±1 %. Me pregunto si el PIC admite este tipo de división para su generador de velocidad en baudios. Eso espero, pero no creo que lo haga.
El PIC tiene un generador de velocidad en baudios. Funcionaría bien, pero solo para baudios más bajos como 9600, no funcionaría para baudios altos como 115,200, se vuelve demasiado impreciso.
¿Crees que podría usar un cristal de 7.3728 MHz? (No voy a usar el oscilador interno de 7,37 MHz porque me gustaría precisión). Me permite dividir por 64 para obtener una frecuencia UART de 115.200. Es lo más rápido que puedo ir con una alta tolerancia.
si su UART lo admite, es preferible darle un overclock (como 16x) para que pueda sobremuestrear el bit de inicio y encontrar el centro de la celda de bit, pero obtener un 16x para 115K dentro del 1% podría ser un desafío, a menos que usas un cristal múltiplo en baudios.

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 tiene en cuenta el bit de inicio y parada).

no me cite mal; re "1%", mi declaración fue que esto podría ser difícil de lograr. El "6,25 %" suponía que había tocado el centro del bit de inicio y sería la diferencia máxima permitida en las velocidades de reloj del receptor frente al transmisor en tales condiciones.

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 en baudios es incluso un 0,1 % más lenta que la del dispositivo transmisor y no tiene capacidad para enviar bits de parada ligeramente reducidos, su salida se retrasará un byte por cada 1000 bits consecutivos. bytes que ingresan. Si el dispositivo está limitado a 16 bytes de almacenamiento en búfer, eliminará un byte de datos después de pasar aproximadamente 16,000 y eliminará aproximadamente un byte por mil a partir de entonces. Vale la pena señalar que los llamados módems de "1200 baudios" en realidad funcionan a una velocidad ligeramente superior a 1200 bits/segundo (creo que es alrededor de 1202) precisamente por esta razón (de modo que incluso si el transmisor es un 0,15% más rápido de lo que debería). ser, el módem aún pasará a través de todos los datos).

JustJeff se olvidó del bit de inicio, pero Stevenh agregó el bit de parada. Asumiendo el protocolo común de 8 bits de datos, 1 bit de inicio y ningún bit de paridad (la cantidad de bits de parada no importa), hay 8 1/2 tiempos de bit desde el borde anterior 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 de bit. Tenga en cuenta que 1/2 bit es el umbral de falla garantizado. Cualquier cosa cerca de allí se vuelve irreal ya que siempre hay algo de ruido eléctrico y fluctuaciones.

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 de 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 de ataque del bit de inicio. 1/16 bit de tiempo fuera de 8 1/2 bits es otro 0,74%. Eso sale del presupuesto de error calculado anteriormente. Termina con un 2,2% de desajuste de reloj permitido para que el receptor muestree el último bit dentro de 1/4 de tiempo de bit de su centro.

Como han dicho otros, el uso de un cristal de 7,3728 MHz 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 en baudios de UART dentro del error de cristal.

No estoy de acuerdo en que los bits de parada no importen. En esta pregunta, la comunicación falló porque el bit de parada se configuró erróneamente en un nivel bajo.
El bit de parada tiene que estar allí para que funcione la comunicación general, pero no entra en el cálculo del presupuesto de error para la mayoría de los UART. Los UART requerirán un tiempo mínimo después del último bit de datos antes del siguiente borde de ataque del siguiente bit de inicio. Para eso está el tiempo de bit de parada. Cuando no se cumple este tiempo, obtiene un "error de encuadre". Tal vez eso se muestree como un bit de datos, pero conozco casos en los que se manejó de manera diferente. Los teletipos antiguos necesitaban 2 bits de parada para dar tiempo al mecanismo mecánico a estar listo para capturar el siguiente carácter.
Me refiero al bit de inicio tres veces, ¿no?
@OlinLathrop: se requiere el bit de parada para garantizar que, al enviar un byte cuyo MSB sea cero, habrá un flanco descendente para el siguiente bit de inicio. Distintos dispositivos se comportan de manera diferente en los casos en que la línea de datos baja antes de lo que se supone que debe hacerlo, pero si no hubiera un bit de parada, una secuencia transmitida de cero bytes no contendría información de tiempo útil. Tal requisito podría cumplirse a través de otros medios con una sobrecarga de trama fija inferior al 25%, pero no tengo conocimiento de que nadie lo haga.
¿Qué tan críticas son las frecuencias UART?
RespuestasAquíPolítica de privacidad1y, 0v