[=AK= 10]

Символ же 0xFF, переданный перед началом пакета, гарантированно восстановит битовую синхронизацию:

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

 

Предлагаю конец теме — ... делаем задержку ... немного попринимали ... делаем задержку ...

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

[Plain 176]

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

[zltigo 1]

Если уж закладываться на кривизну PC16550

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

 

тупо NOP'ами

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

 

[=AK= 10]

автору наверное ещё вчера это сдать надо было, а теме уже 10-я страница.

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

[AHTOXA 15]

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

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

То же самое и с последовательностью 0x00, 0x00.

А вот последовательность 0xFF, 0xFF "прочистит" приёмник гарантированно, поскольку она опирается на детектирование стартового бита, которое у всех контроллеров одинаковое.

Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера.

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

[=AK= 10]

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

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

 

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

[Dima1060 0]

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

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

 

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

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

[Dima1060 0]

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

То же самое и с последовательностью 0x00, 0x00.

А вот последовательность 0xFF, 0xFF "прочистит" приёмник гарантированно, поскольку она опирается на детектирование стартового бита, которое у всех контроллеров одинаковое.

 

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

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

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

[AHTOXA 15]

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

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

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

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

 

[Dima1060 0]

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

 

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

Я надеюсь, к "таким" контроллерам не относятся STM32 ? У них есть флаг Frame Error.

А вот в Silabs (C8051F320) я такого флага не нашел, вообще ничего про это не написано...

[=AK= 10]

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

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

 

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

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