¿Qué causa los errores UART?

Me gustaría saber para saber por qué ocurren los errores de UART y cuándo se deben verificar dichos errores. Aquí hay una publicación que pregunta sobre el manejo de errores individuales, como desbordamiento, paridad, etc. Tengo claro por qué ocurre el desbordamiento de datos, por qué ocurre el error de paridad, pero me gustaría saber cuál es la causa raíz. Mi pregunta se centra más en por qué podrían ocurrir estos errores (razones físicas) y cuándo se debe hacer que la verificación de errores sea un factor para su aplicación.

Hasta ahora, mi programa parece funcionar muy bien (sin verificación de errores), pero sé que el ruido puede estropear las cosas. ¿Cómo podría simular condiciones que podrían hacer que los puertos UART Rx / Tx fallen?

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

• Fuentes de alimentación mal reguladas;
• Fuentes de alimentación conmutadas;
• Desacoplamiento capacitivo insuficiente de los rieles de alimentación cerca de la MCU;
• Acoplamiento inductivo de fuentes electromagnéticas cercanas (incluyendo 50 o 60Hz de la red eléctrica; incluso si el circuito funciona con batería, experimentará esta interferencia cuando esté lo suficientemente cerca de una fuente de red);
• Fuentes de RF cercanas a la frecuencia resonante de un rastro en la placa de circuito, o uno de sus armónicos;
• Enrutamiento de trazas de alta corriente en la placa de circuito cerca de líneas de señal;
• Etc.

Además (como mencionó @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 e interactuando con otro sistema que razonablemente puede esperarse 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 básica al ruido (y sesgo) de su interfaz, que incluyen:

• Congelación (enfriar el circuito a la clasificación mínima de sus componentes);
• Hornear (calentar al máximo);
• Exposición a EMI :
  • Coloque la placa encima del cable de alimentación de un calentador de espacio en funcionamiento;
  • Clave 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 sea aceptable un nivel mínimo de pérdida de datos, siempre es prudente incluir algún tipo de verificación de errores en su código de comunicaciones. Incluso una simple suma de control es mejor que nada.

Una fuente común de errores en UART además de la calidad del nivel de señal (ruido, tiempos de subida / bajada) es la inclinación 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, ocasionalmente puede leer un bit incorrecto.

La mayoría de los errores provienen de tres causas: (1) la señal generada por el transmisor no representaba 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 n. ° 1 es un transmisor que se reconfigura o apaga mientras transmite datos. El problema # 2 puede ocurrir fácilmente para las señales que viajan a través del "mundo exterior" como resultado de cosas como la interferencia de radio (¡los teléfonos móviles pueden ser sorprendentemente desagradables!), Pero generalmente no debería ocurrir para las señales confinadas en una sola placa. El problema n. ° 3 puede ocurrir porque muchos bytes llegan más rápido de lo que pueden procesarse o porque el receptor se reconfigura, apaga o inicia durante una transmisión.

En muchos casos, es difícil eliminar por completo todos estos problemas; El objetivo de uno debería ser asegurar que el "daño" total hecho por ellos (probabilidad de ocurrencia, multiplicado por daño por ocurrencia) sea aceptablemente bajo. Esto se puede hacer más fácilmente eligiendo una estimación pesimista de confiabilidad y luego diseñando un protocolo para que el impacto en el rendimiento del sistema de incluso las peores fallas que sean consistentes con las estimaciones de uno esté dentro de límites aceptables.

Los errores de trama pueden ser causados ​​por lo que @jippie menciona: el receptor ha detectado el bit de inicio y, cuando 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 afecta 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 provoca 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 los bytes de datos sucesivos y permanece así. Es un retroceso a los viejos sistemas de telegrafía, creo. No me molestaría en verificar esto a menos que esté utilizando esta "función" para indicar (por ejemplo) un comando de reinicio al receptor.

El error de desbordamiento es cuando se recibe un nuevo byte antes de que una CPU leyera el byte anterior. Ligeramente diferente cuando se trata de un FIFO pero equivale a 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 solicite al transmisor que vuelva a enviar el mensaje / comando completo.

En ejecución no es realmente un error, pero indica al UART emisor que su búfer de transmisión está vacío, es decir, está solicitando un nuevo byte para transmitir. No necesita verificar esto.

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

básicamente, dos partes importantes para comenzar son las sumas de verificació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 verifique 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 confirmada), etc.

Además, asegúrese de implementar tiempos de espera en su protocolo de nivel superior. Si obtiene algún tipo de error de trama, es posible que su UART nunca se recupere y comience a procesar nuevamente. puede estar esperando el bit de detención en una trama que el remitente UART cree que ya se envió, pero que se corrompió por ruido, distorsión del reloj, etc. Esto enviará cualquier código de entrada a un bucle infinito. asegúrese de tener un límite sensato en cuanto a cuánto tiempo debe esperar su lectura de entrada hasta que decida abandonar este mensaje, y nuevamente, vuelva a intentar, NACK, abandone, etc.