¿Qué causa los errores UART?

Hay varias fuentes potenciales de noise en cualquier circuito. Algunos de los más comunes incluyen:

• Fuentes de alimentación mal reguladas;
• Cambio de fuentes de alimentación;
• Insuficiente desacoplamiento capacitivo de los rieles eléctricos cerca de la MCU;
• Acoplamiento inductivo de fuentes electromagnéticas cercanas (incluidos 50 o 60Hz de la red eléctrica; incluso si el circuito funciona con baterías, lo hará experimente esta interferencia cuando esté lo suficientemente cerca de una fuente de alimentación);
• Fuentes de RF cerca de la frecuencia de resonancia de una traza en la placa de circuito, o uno de sus armónicos;
• Enrutamiento de trazas de alta corriente en la placa de circuito cerca de las líneas de señal;
• Etc.

Además (como se mencionó en @jippie), el sesgo del reloj es una causa muy común de errores en cualquier tipo de comunicación en serie que utiliza una velocidad de datos predeterminada. Si está utilizando un cristal externo y se está conectando a otro sistema que puede esperarse razonablemente que sea preciso, es menos probable que cause problemas. Sin embargo, los osciladores internos pueden tener tolerancias que son varios órdenes de magnitud peores que los cristales y tienden a variar más en los rangos de temperatura.

Hay varias pruebas básicas que se pueden realizar en un sistema en ejecución para determinar la inmunidad de ruido (y sesgo) básica de su interfaz, incluyendo:

• Congelación (enfríe el circuito hasta la clasificación mínima de sus componentes);
• Hornear (calentar a la máxima calificación);
• Exposición a EMI :
  • Coloque la placa sobre el cable de alimentación de un calentador de espacio en funcionamiento;
  • Teclee una radio CB en las proximidades de la placa;
  • Coloque la placa junto a su enrutador inalámbrico;
  • Utilice un cable de conexión largo (en lugar de un cable serie construido adecuadamente) para la conexión UART.

Hay muchos otros, de hecho, hay grandes laboratorios de pruebas dedicados a la calificación EMC .

En general, a menos que un nivel mínimo de pérdida de datos sea aceptable, siempre es prudente incluir algún tipo de comprobación de errores en su código de comunicaciones. Incluso una suma de comprobación simple es mejor que nada.

Una fuente común de errores en UART, además de la calidad del nivel de la señal (ruido, tiempos de subida / caída) es el sesgo del reloj. Si el reloj del transmisor y el reloj del receptor no se derivan de la misma fuente (que es el caso la mayor parte del tiempo), uno funcionará más rápido que el otro. Cuando el error de tiempo es demasiado grande, en ocasiones puede leer un bit incorrecto.

La mayoría de los errores provienen de tres causas: (1) la señal generada del transmisor no representó datos válidos; (2) la señal del transmisor no se recibió como se generó, o (3) el receptor no estaba listo para manejar los datos cuando se recibió. La causa más común que he visto para el problema # 1 es un transmisor que se reconfigura o apaga mientras está transmitiendo datos. El problema # 2 puede ocurrir fácilmente para señales que viajan a través del "mundo exterior" como resultado de interferencias de radio (¡los teléfonos móviles pueden ser sorprendentemente desagradables!), Pero en general no deberían ocurrir para señales confinadas en una sola placa. El problema # 3 puede ocurrir porque muchos bytes llegan más rápido de lo que pueden procesarse, o porque el receptor se reconfigura, se apaga o se inicia durante una transmisión.

En muchos casos, es difícil eliminar por completo todos estos problemas; la meta de uno debe ser garantizar que el "daño" total que hayan hecho (probabilidad de ocurrencia, daño de veces por ocurrencia) sea aceptablemente bajo. Esto se puede hacer más fácilmente seleccionando una estimación pesimista de confiabilidad, y luego diseñando un protocolo para que el impacto en el rendimiento del sistema, incluso de las peores fallas que fuera consistente con las estimaciones de uno, esté dentro de límites aceptables.

Los errores de encuadre pueden deberse a lo que menciona @ jippie: el receptor ha detectado el bit de inicio y, donde espera el bit de parada, los datos se invierten. Esto también puede deberse a la corrupción de datos causada por la interferencia de línea que incide en el bit de parada. Siempre debe verificar esto para cada byte recibido.

Los errores de paridad se producen cuando se implementa la paridad en el enlace de datos y hay una corrupción que causa una discrepancia de paridad en los datos recibidos. Siempre debe verificar esto para cada byte recibido.

La interrupción de recepción también se considera un error, aunque en realidad es una indicación de que los datos entrantes han caído a cero lógico durante más de 1 byte de datos. Normalmente, 1 lógico es el estado "ambiente" entre bytes de datos sucesivos y permanece de esta manera. Es un tiro atrás a los viejos sistemas de telegrafía, creo. No me molestaría en comprobar esto a menos que esté usando esta "característica" para indicar (digamos) un comando de reinicio al receptor.

El error de saturación se produce cuando se recibe un nuevo byte antes de que la CPU haya leído el byte anterior. Un poco diferente cuando se trata de una FIFO pero es lo mismo: los datos recibidos válidos se pierden debido a la lentitud de la CPU. Siempre verifique esto antes de leer un byte y si el byte es parte de un mensaje (o comando) más largo, deseche todo el mensaje / comando y de alguna manera solicite al transmisor que reenvíe todo el mensaje / comando.

La ejecución insuficiente no es realmente un error, pero indica al UART que envía que el búfer de transmisión está vacío, es decir, está solicitando un nuevo byte para transmitir. No necesitas comprobar esto.

Para lidiar con estos errores, debe implementar un protocolo lógico de nivel superior. algo parecido a TCP, o compruebe la pila OSI para obtener ideas.

básicamente, dos partes importantes para comenzar son las sumas de comprobación y los tiempos de espera. use un algoritmo para calcular un valor redundante que represente, en una forma más pequeña, el contenido de cada mensaje. luego verifica esto en el mensaje recibido. Si las sumas no coinciden, es posible que haya recibido un error de trama, ruido de bits, etc., y deberá descartar el mensaje e intentar algún tipo de recuperación, reenvío, señal NACK (no con acné), etc.

también, asegúrese de implementar tiempos de espera en su protocolo de nivel superior. Si recibe algún tipo de error de encuadre, su UART nunca se recuperará y comenzará a procesarse nuevamente. puede estar esperando el bit de parada en un cuadro que el remitente UART cree que ya se ha enviado, pero se corrompió por el ruido, la inclinación del reloj, etc. Esto enviará cualquier código de entrada a un bucle infinito. asegúrese de tener un límite sano en cuanto al tiempo que debe esperar su lectura de entrada hasta que decida abandonar este mensaje, y nuevamente, vuelva a intentarlo, NACK, abandone, etc.