Если уж закладываться на кривизну PC16550, то проще всего делать XOR 0xFF каждого байта при приеме и передаче. Тогда два 0 в начале и 0 в конце передачи на линии появятся как 0xFF.


Варианты с задержками (в частности, Modbus RTU) обсуждались ранее. Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера.

Избыточное кодирование — та же задержка, плюс ещё сколько писанины, в сравнении хотя бы с тупо NOP'ами — автору наверное ещё вчера это сдать надо было, а теме уже 10-я страница.

Не наводите тень на плетень. Никакая и ничья кривизна здесь совершено ни причем. Абсолютно незавтсимое и естественое решение.


Да уж "трясти надо"(с)

А какая разница? Как ни сделай, хоть бы даже вообще тупо на подтяжки понадеяться, все равно первым сбиваться будет USB, а не RS485. Тем более что у ТС изохронная труба, которая не гарантирует доставку.

Суть в том, что последовательность 0xF0, 0xF0 "прочистит" приёмник не всегда, поскольку она опирается на framing error, который обрабатывается разными контроллерами по-разному.
То же самое и с последовательностью 0x00, 0x00.
А вот последовательность 0xFF, 0xFF "прочистит" приёмник гарантированно, поскольку она опирается на детектирование стартового бита, которое у всех контроллеров одинаковое.

Надо сделать всё, как вы описали, просто заменить символ 0xF0 на символ 0xFF, и всё будет прекрасно работать на любом контроллере.

Когда используется COBS, то удобнее всего при кодировании как специальный символ использовать 0. Поэтому, если надо получить на физическом уровне специальный символ 0xFF, то проще всего делать XOR 0xFF.

Что же касается 0xF0 в том топике, то там мой (радио)канал требовал, чтобы количество 0 и 1 в последовательности было равно. Поэтому я использовал именно 0xF0 как специальный символ для байт-синхронизации и взвешенное кодирование 6b8b для данных, и все прекрасно работало с обычным микроконтроллерным UART-ом.

не совсем понял, придется делать XOR всех байт пакета?


с чего это? USB наиболее удален от помех будет. и длина RS-485 будет 5 метров кабеля, а USB меньше 1 см на плате

Поясните пожалуйста поподробней, что не так, если передавать 0x00, 0x00 вначале? Первый 0x00 вызовет ошибку фрейма, второй 0x00 будет принят
Если 0xFF передавать, то возможно, что стартовый бит 0xFF попадет на стоповый бит "байта помехи". И тоже будет ошибка фрейма.

Не всегда. Существуют контроллеры, которые считают бит, на котором случился FE, стартовым для следующего фрейма. В случае такого контроллера второй байт 0x00 тоже вызовет FE. Вот тут я рисовал картинку. (Там для 0xF0, но суть та же).

Да, в случае такого контроллера это тоже не даст стопроцентной синхронизации. Но вероятность засинхронизироваться будет выше, чем при передаче 0x00.

Я надеюсь, к "таким" контроллерам не относятся STM32 ? У них есть флаг Frame Error.
А вот в Silabs (C8051F320) я такого флага не нашел, вообще ничего про это не написано...

Ага. А вас по каким-то причинам напрягает операция XOR? Религия не позволяет, или типа того? Ну тогда не делайте, посылайте как есть, на практике результат будет одинаковый.


Да хоть миллиметр. Помехи-то все равно пройдут сквозь него. Наведутся они вовне, а пройдут сквозь ваш короткий USB, если им деваться больше некуда. Опторазвязка может помочь частично, но за счет паразитных емкостей помехи все равно пройдут.