No hay garantías con un diseño de protocolo desafortunado como este. Pero puede hacerlo al menos tan bien como lo hace un UART en datos seriales asíncronos. Déjame explicarte.
Dado que ya ha encontrado los límites de bytes en el flujo de datos, puede pensar que el byte del encabezado (H) es similar a un bit de inicio de UART, y que el byte inactivo (I) es similar a un (opcional) Bit de parada UART.
Configure una máquina de estados que se inicie en un estado "inactivo" y busque el siguiente byte de encabezado, ignorando cualquier cosa que no sea una H (incluidos los I bytes reales). Una vez que encuentre una H, capturará los siguientes 3 bytes de datos, independientemente de su valor. Luego, dependiendo de si el siguiente byte después de eso es H o no, avanzará al estado de "encabezado" o "inactivo".
Sí,aligualqueunUART,estopuedebloquearseenunadesalineaciónsilospaquetesdedatos(prefieroeltérmino"paquetes") contienen H bytes repetidamente, pero a menos que los datos sean particularmente patológicos, la máquina de estado debería alinearse rápidamente. en los encabezados "reales": todo lo que necesita es un paquete que no contenga un byte H falso.
Si puede asegurarse de que el ASIC no envíe su primer paquete hasta que se inicialice la máquina de estado, entonces no debería haber ningún problema. De lo contrario, si la máquina de estado se inicia en un punto arbitrario en un flujo de datos que ya está en ejecución, puede tener problemas. Puedes verificar los bytes que no son I cuando estás en el estado "inactivo", esto indica que estás fuera de alineación.
EDITAR: La respuesta anterior se basó en la suposición errónea de que el byte "H" aparece antes de los datos en cualquier paquete dado; Resulta que estaba equivocado sobre eso. Sin embargo, voy a dejar esa parte como está, porque ese es, con mucho, el caso más común. A continuación, abordaré el problema al que se enfrenta el OP, que tiene el byte "H" siguiendo los bytes de datos.
En una situación como esta, es necesario configurar una canalización (registro de desplazamiento) que pueda contener el paquete completo de 4 bytes.
Losbytessedesplazanatravésdeloscuatroregistrosenlapartesuperiorensecuencia.Elbytemásantiguo(elLSB,quellegóprimero)terminaenelregistrodeladerechaalmismotiempoqueelbyte"H" para ese paquete llega al registro de la izquierda.
La máquina de estado supervisa el contenido del registro "H", y si de hecho es el valor "H" cuando está en el estado "encabezado", se confirma su salida, lo que habilita el registro de captura en el segundo fila, y también afirma la señal de "salida válida".
El diagrama de estado se ve así:
ComenzamosporlaizquierdayhacemosunasecuenciaatravésdelostresestadosdedatosantesdebuscarelprimerbyteH.Siestamosenelestadode"encabezado" cuando encontramos un byte H, los tres bytes anteriores DEBEN haber sido bytes de datos, para que sean capturados. Luego, volvemos a recorrer los tres estados de datos para capturar al menos tres bytes más antes de comenzar a buscar la H nuevamente.
Lamentablemente, este protocolo puede desincronizarse fácilmente si cualquier paquete que contenga un byte "HD" (encabezado falso) también está precedido por I (inactivo) bytes. Para que esta implementación se mantenga sincronizada, se debe cumplir al menos una de las dos condiciones:
- No hay bytes HD en los paquetes.
- No hay bytes I entre paquetes.
De lo contrario, simplemente no existe una forma sólida de mantener la alineación de paquetes. Como dije, esta es una elección "desafortunada" de protocolo por parte del diseñador ASIC. Si el byte H apareciera primero en el paquete en lugar de en el último, estas restricciones desaparecerían.