Suponiendo que no todos los UART son iguales y que la documentación en general no es suficiente para responder a esta pregunta, tengo que preguntar cómo puedo saber qué UART (o los receptores en serie asíncronos en general) manejan adecuadamente la condición de interrupción y la sincronización. después?
Una condición de interrupción es un período extendido de entrada baja (0 espacios) en la línea RXD. Esto generalmente conduce a un Error de Encuadre ya que el receptor no detecta un estado alto (1 Marcado) cuando espera un Bit de Parada.
Algunos documentos sugieren que puede distinguir la diferencia entre una Interrupción y la corrupción de datos debido al ruido al leer directamente la línea RXD y verificar su estado. Por supuesto, eso no es estrictamente cierto porque para cuando se le avise del Error de Encuadre, ¿quién sabe cuánto tiempo ha pasado y si todavía estaría en la condición de Interrupción? Pero aparte de eso ...
Si lees algunas descripciones sobre la lógica detrás del diseño de UART, UART busca primero el bit de inicio. Detecta esto como una transición de alta a baja (1 - > 0) en la línea RXD, momento en el que ajusta su temporización para muestrear el flujo a mitad de bit. De esta forma puede recibir datos asíncronos.
Uno esperaría que una vez que se inicie una condición de Interrupción y tenga un Error de Encuadre, el UART caiga en algún modo en busca de una transición de alta a baja que indique un nuevo Bit de Inicio. En este caso, esperaría recibir un (1) Error de trama (datos 0x00) y luego un byte bueno para lo que sea que siga a la ruptura.
Desafortunadamente, no es así como algunos (con suerte no todos) realizan UART. Mi experiencia en este momento es que después del error de encuadre, el receptor continúa leyendo datos. Debe ver el siguiente bit como un bit de inicio solo porque es bajo (espacio 0) sin importar la transición. A continuación, recibirá cualquier número de errores de encuadre que puedan estar asociados con la duración de la interrupción. Me doy cuenta de que esto también podría ser útil.
Aún más problemático es que, dependiendo de la duración de la interrupción y la sincronización, el nivel de señal alto (1 Marcado) que sigue a la interrupción se considerará como un bit de parada válido. El final de la condición de interrupción genera un byte de datos "bueno" que contiene (de forma impredecible) uno de 0xFF, 0xFE, 0xFC, 0xF8, 0xF0, 0xE0, 0xC0, 0x80 o 0x00. Incluso esto no se puede garantizar, ya que podría obtener el primer byte de los siguientes datos.
Ahora, dependiendo de la duración del período de Marcación después de la interrupción, el UART podría estar buscando bits en el primer byte de datos para ese bit de detención difícil de alcanzar. Luego, perderá el primer byte de buena información o potencialmente más bytes hasta que la UART finalmente decida sincronizar correctamente.
¿Por qué esto importa?
Intenta leer datos DMX512. Este es un protocolo antiguo que está muy en uso hoy en día. Cada cuadro de datos comienza con una ruptura. El formato es 250 Kbaud, 8 bits de datos, 2 bits de parada y sin paridad. El prefijo Break es un mínimo de 92 microsegundos y no se especifica la duración total. Es muy probable que no sea un múltiplo exacto de las ranuras de datos. Ni siquiera tiene que ser el mismo fotograma a fotograma.
Peor, el Mark-After-Break necesita ser solo un mínimo de 12 microsegundos.
Sigue un Código de Inicio que generalmente debería ser 0x00 y no otro código único o algo indistinguible para un byte de Break o datos de canal cero. A continuación, puede haber hasta 512 bytes de datos de canal (0-255). No hay ningún requisito que todos los 512 canales sean transmitidos o que sean el mismo cuadro de cuadro a cuadro. No hay SOH, ni encabezado ni comprobación de errores.
En otras palabras, un UART no puede recibir estos datos.
Sé que puede manejar esto con un dispositivo dedicado como un PIC en el que puede leer la línea RXD y medir el ancho de pulso y, de lo contrario, habilitar / deshabilitar la recepción en serie y sincronizar manualmente. Simplemente sería mucho más fácil con un UART que manejó la re-sincronización correctamente. Un sistema de nivel superior no puede leer estos datos.
¿Alguien sabe de un receptor que maneje mejor la sincronización?
Simplemente me sorprende que después de más de 50 años con los procesadores altamente sofisticados que tenemos hoy, nadie se haya molestado en refinar este bloque de silicona que siguen pegando en el chip. Sin mencionar el estúpido bloqueo del reloj digital RTC que todos usan.