Manejo de errores UART

8

No me estoy concentrando en una MCU específica, ya que UART de la mayoría de los controladores tiene una arquitectura similar. Tienen FIFOs tanto para Tx como para Rx.

Los errores más comunes generados por UART son: - 1. Error de encuadre 2. Error de paridad 3. Error de sobre-ejecución (desbordamiento de FIFOs de Tx / Rx) 4. Recibir un error de ruptura (algún error con los bits de parada)

¿Cómo se deben manejar estas condiciones de error para mantener la comunicación correctamente?

Entiendo que es una pregunta vaga, pero la mayoría del momento en que la gente se confunde sobre lo que uno debería hacer cuando ocurren tales errores y termina simplemente eliminando los bits de error.

    
pregunta Swanand

3 respuestas

6

Para responder realmente a tu pregunta, generalmente descarto todo lo recibido con un error. Esto puede incluir reiniciar el hardware de UART, dependiendo de qué error sea y de los detalles del hardware de UART.

La única excepción es si desea recibir deliberadamente descansos. Los que aparecen como errores de encuadre. En ese caso, se pasan los errores de encuadre a los niveles superiores como condiciones especiales. Sin embargo, eso requiere que la información fuera de banda se pase a niveles más altos y, por lo tanto, la interfaz del receptor UART no se puede ver como algo tan simple como obtener una corriente de bytes. Creo que he hecho esto exactamente una vez en muchos proyectos de microcontroladores porque tenía que ser compatible con un sistema antiguo donde se usaban deliberadamente los descansos.

Steven te ha dado algunas buenas ideas sobre qué hacer al respecto en el nivel superior. Cuando crees que hay una posibilidad real de errores y la integridad de los datos es importante, entonces normalmente encapsulas fragmentos de datos en paquetes con sumas de comprobación. El receptor envía un ACK por cada suma de comprobación recibida correctamente.

Sin embargo, la gran mayoría de las veces los errores UART son tan poco probables y no tan críticos que puedes ignorarlos en el nivel alto. El tipo de errores que el hardware de UART puede detectar se debe generalmente a la estupidez del operador, no al ruido de la línea. La mayor parte del ruido puede causar datos erróneos, que el UART no detectará. Por lo tanto, el controlador UART de bajo nivel arroja todo lo que se asocia inmediatamente con un error UART, pero por lo demás continúa pasando el flujo de bytes recibidos hasta el siguiente nivel. De hecho, lo hace incluso si está utilizando paquetes y sumas de comprobación, ya que se realiza a un nivel más alto que donde se reciben los bytes individuales.

    
respondido por el Olin Lathrop
9

Estos errores no pueden solucionarse, por lo que se requiere la retransmisión. Esto necesita algún protocolo a un nivel más alto que el UART; Por lo general, querrá reconocer la recepción correcta de un paquete de datos. Este paquete puede ser de 1 byte, pero también se pueden usar paquetes más largos si la comunicación tiene pocos errores. Reconozca cada paquete enviando un ACK al transmisor, un NACK si ha ocurrido un error. En este último caso, deseche el paquete y espere la retransmisión.
Si utiliza transferencias de paquetes, es posible que desee considerar la verificación de errores CRC en lugar de la paridad, que no es muy eficiente (agrega 1 bit por byte) y solo detecta errores de bit único.

    
respondido por el stevenvh
3

Cuando hay un error de trama en los datos de UART recibidos, las probabilidades son buenas de que todos los bytes sucesivos serán basura hasta que, dependiendo del UART, haya diez o más bits de tiempo entre bordes descendentes consecutivos en el cable de datos, diecinueve bits de espaciado consecutivo, o nueve bits de marcado consecutivo (el último de ellos funcionará en todos los UART). Si uno recibe un byte correctamente encuadrado con valor 0x00 o 0x80 (0x100 en modo de 9 bits) y el transmisor no envía interrupciones largas o el receptor dejará de intentar analizar los bytes de cualquier interrupción larga que envíe el transmisor, se puede Tenga la seguridad de que es correcto y que los bytes posteriores también serán correctos. Si uno recibe un valor en el que hay 0-6 "ceros" consecutivos en los bits más bajos, y los bits restantes están todos establecidos, ese valor de byte puede o no ser correcto, pero los bytes siguientes serán (uno podría, por ejemplo, recibir un valor de 0xC0 cuando el transmisor intentaba enviar 01).

S=START P=prev byte data s=stop D=current byte  - =idle
0111111101000000011111 -- Signal on line
Ps------SDDDDDDDDs--- : As intended by transmitter (0x02)
SPPPPPPPPsSDDDDDDDDs- : As received (0xC0)

Si cada paquete comienza con 0x00 y va seguido de 0xFF, un error de trama en un paquete no afectará al siguiente. Cuando el receptor se da cuenta del error de trama, puede comenzar a descartar datos hasta que vea un 0x00 correctamente encuadrado, con lo que sabrá que tiene un inicio legítimo de paquete.

    
respondido por el supercat

Lea otras preguntas en las etiquetas

Comentarios Recientes

en FRAME Componente con primitivas. Roland Mars Altmaier C IDlmentun 4 de agosto de 2004 En el contexto de un binario en ejecución, ¿deberíamos trabajar juntos con el módulo de visualización directa (DPM o LCD) y manipular la representación de 3? Def. 7. Hay una diferencia en cómo mostrar la entrada o el control entre el módulo de visualización directa y su alternativa en el menú del sistema. Las técnicas relacionadas con el hardware de Matteo Roy C DOI 3 de abril de 2008 dependen parcialmente de la entrada... Lees verder