¿Cómo lidiar con la secuencia de inicio en la carga útil del paquete de comunicación?

En primer lugar, normalmente no tengo un marcador final. Normalmente tendría una longitud de carga útil como parte del encabezado.

En segundo lugar, normalmente incorporaría una suma de comprobación, generalmente al final de la carga útil (donde tiene la secuencia final).

En cuanto a los caracteres de escape utilizados en el encabezado cuando aparecen en la carga útil: Sí. Cómo escapar, depende de ti, es tu protocolo. Las opciones incluyen:

1. Usar un carácter de "escape" predefinido (27 se usa comúnmente) que a su vez necesita escapar.
2. Doble los caracteres de encabezado reservados. Entonces, digamos que el encabezado es 0x55 0xAA, entonces lo transmitirías en el cuerpo como 0x55 0x55 0xAA 0xAA y luego reconocerías los caracteres dobles como uno solo al descodificarlo.
3. Utilice diferentes tamaños de datos para el encabezado y la carga útil. Si restringe la carga útil a 7 bits por byte, tendrá los caracteres de encabezado con el bit alto establecido que nunca podrán aparecer en el cuerpo. Sin embargo, hace que el cuerpo sea más grande.

Si estás buscando una secuencia específica para el encabezado, no importa si esos caracteres aparecen individualmente en el cuerpo, solo la secuencia completa.

Puede usar una sola secuencia de eliminación, pero puede hacer que su código se apague. Puedes escapar de las secuencias pero se espera un crecimiento de tamaño. En su lugar, puede incluir un campo de tamaño de marco en el encabezado para que no sea necesario escapar.

Puede tomar mi Protocolo de transferencia en serie simple como se usa en mis diversos proyectos como ejemplo. Es lo suficientemente simple de entender, pero también proporciona un modo compatible con IPv4 y múltiples descargas con CAN PHY.

Aquí está la estructura de la trama SSTP descrita utilizando un pseudo código similar a C, enviado en formato big-endian (también conocido como orden de bytes de red)

struct sstp_frame {
    // frame header
    uint16_t magic;  // = 0x55aa
    uint32_t addr;   // IPv4 address. Send 0xffffffff (255.255.255.255) if unused.
    uint16_t proto;  // For simple UART communication send 0, in IP-compatible mode
                     // send IP next protocol number
    uint16_t size;   // frame length, includes header, and footer

    uint8_t  body[]; // body of the frame, unmodified

    // frame footer
    uint16_t crc;    // CRC of the body of the frame
    uint16_t magic2; // = 0xaa55
}

Después de enviar cada fotograma, la línea se mantiene en silencio durante el mismo tiempo que se tarda en enviar el fotograma.

El extremo receptor espera la magia del encabezado, lee el tamaño del cuadro después de la magia del encabezado, calcula el CRC mientras recibe el paquete y lo compara, y verifica la magia final. Cualquier desajuste (CRC incorrecto o magia incorrecta) o tiempo de espera hace que el paquete se descarte.

Si se usa CAN PHY o cualquier otro medio para lograr múltiples caídas, hable solo cuando la línea esté inactiva. Lea cada byte después de enviado, y siempre que ocurra una discrepancia, cancele el paquete y espere la misma longitud que el paquete que se envía hasta el momento en que se envía el encabezado, o un tiempo pseudoaleatorio si se detecta una colisión del encabezado.

Si necesita confiabilidad, puede ejecutar TCP sobre este protocolo, usando su modo de compatibilidad IPv4.