Por supuesto, es posible que tengas un error en tu implementación de UART de bits modificados. ¿Cómo hace su tiempo, hace un ciclo de tiempo o hace un ciclo hasta que llega un momento de queratina en el tiempo (la única forma realista, más allá de la codificación isosincrónica) para hacer esto es usar un temporizador de funcionamiento libre? ). Puede observar su salida con mucho cuidado con un carácter de prueba de 0x00 y ver cuánto se desvía el tiempo (inicio de inicio a inicio de parada) del ideal. Me sentiría cómodo con el 1% o menos, podría sobrevivir con un poco más.
Dicho esto, estoy de acuerdo con brhans. Hay situaciones en las que una comunicación entre el remitente y el receptor de UART totalmente correcto comienza en el momento "incorrecto" y continúa desincronizada para siempre. Esta es una propiedad del protocolo UART y no tiene nada que ver con la calidad (o falta de ella) de ninguno de los dos lados. La única salida es una pausa en la transmisión (no es necesaria una interrupción) de más de la longitud de un personaje.
Como una ilustración de la situación de desincronización, considere una transmisión continua del patrón 0011111101 (formato 8N1).
Cuando el primer 0 se interpreta como bit de inicio, los bits de datos son 01111110, seguidos de un bit de parada (1) y el siguiente bit de inicio (0). Esta es una secuencia totalmente válida de 0x7E bytes.
Pero cuando el último 0 se interpreta como un bit de inicio, va seguido de 1 y 0011111101, que se interpreta como 10011111 y un bit de parada 1, seguido de un próximo 0 bit de inicio. Este es un flujo válido igual de 0x9F bytes.
Creo (pero no lo intenté) que con otros patrones puede haber más de 2 formas válidas de interpretar un flujo. Creo (pero, de nuevo, no intenté probar) que el uso de paridad y / o más de 1 bit de parada reducirá la posibilidad de múltiples interpretaciones pero no la eliminará.