=AK= 17 28 ноября, 2015 Опубликовано 28 ноября, 2015 · Жалоба Символ же 0xFF, переданный перед началом пакета, гарантированно восстановит битовую синхронизацию: Если уж закладываться на кривизну PC16550, то проще всего делать XOR 0xFF каждого байта при приеме и передаче. Тогда два 0 в начале и 0 в конце передачи на линии появятся как 0xFF. Предлагаю конец теме — ... делаем задержку ... немного попринимали ... делаем задержку ... Варианты с задержками (в частности, Modbus RTU) обсуждались ранее. Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plain 206 28 ноября, 2015 Опубликовано 28 ноября, 2015 · Жалоба Избыточное кодирование — та же задержка, плюс ещё сколько писанины, в сравнении хотя бы с тупо NOP'ами — автору наверное ещё вчера это сдать надо было, а теме уже 10-я страница. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 28 ноября, 2015 Опубликовано 28 ноября, 2015 · Жалоба Если уж закладываться на кривизну PC16550 Не наводите тень на плетень. Никакая и ничья кривизна здесь совершено ни причем. Абсолютно незавтсимое и естественое решение. тупо NOP'ами Да уж :( "трясти надо"(с) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 28 ноября, 2015 Опубликовано 28 ноября, 2015 · Жалоба автору наверное ещё вчера это сдать надо было, а теме уже 10-я страница. А какая разница? Как ни сделай, хоть бы даже вообще тупо на подтяжки понадеяться, все равно первым сбиваться будет USB, а не RS485. Тем более что у ТС изохронная труба, которая не гарантирует доставку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 28 ноября, 2015 Опубликовано 28 ноября, 2015 · Жалоба Если уж закладываться на кривизну PC16550, то проще всего делать XOR 0xFF каждого байта при приеме и передаче. Тогда два 0 в начале и 0 в конце передачи на линии появятся как 0xFF. Суть в том, что последовательность 0xF0, 0xF0 "прочистит" приёмник не всегда, поскольку она опирается на framing error, который обрабатывается разными контроллерами по-разному. То же самое и с последовательностью 0x00, 0x00. А вот последовательность 0xFF, 0xFF "прочистит" приёмник гарантированно, поскольку она опирается на детектирование стартового бита, которое у всех контроллеров одинаковое. Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера. Надо сделать всё, как вы описали, просто заменить символ 0xF0 на символ 0xFF, и всё будет прекрасно работать на любом контроллере. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 28 ноября, 2015 Опубликовано 28 ноября, 2015 · Жалоба Надо сделать всё, как вы описали, просто заменить символ 0xF0 на символ 0xFF, и всё будет прекрасно работать на любом контроллере. Когда используется COBS, то удобнее всего при кодировании как специальный символ использовать 0. Поэтому, если надо получить на физическом уровне специальный символ 0xFF, то проще всего делать XOR 0xFF. Что же касается 0xF0 в том топике, то там мой (радио)канал требовал, чтобы количество 0 и 1 в последовательности было равно. Поэтому я использовал именно 0xF0 как специальный символ для байт-синхронизации и взвешенное кодирование 6b8b для данных, и все прекрасно работало с обычным микроконтроллерным UART-ом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 30 ноября, 2015 Опубликовано 30 ноября, 2015 · Жалоба Когда используется COBS, то удобнее всего при кодировании как специальный символ использовать 0. Поэтому, если надо получить на физическом уровне специальный символ 0xFF, то проще всего делать XOR 0xFF. не совсем понял, придется делать XOR всех байт пакета? А какая разница? Как ни сделай, хоть бы даже вообще тупо на подтяжки понадеяться, все равно первым сбиваться будет USB, а не RS485. Тем более что у ТС изохронная труба, которая не гарантирует доставку. с чего это? USB наиболее удален от помех будет. и длина RS-485 будет 5 метров кабеля, а USB меньше 1 см на плате Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 30 ноября, 2015 Опубликовано 30 ноября, 2015 · Жалоба Суть в том, что последовательность 0xF0, 0xF0 "прочистит" приёмник не всегда, поскольку она опирается на framing error, который обрабатывается разными контроллерами по-разному. То же самое и с последовательностью 0x00, 0x00. А вот последовательность 0xFF, 0xFF "прочистит" приёмник гарантированно, поскольку она опирается на детектирование стартового бита, которое у всех контроллеров одинаковое. Надо сделать всё, как вы описали, просто заменить символ 0xF0 на символ 0xFF, и всё будет прекрасно работать на любом контроллере. Поясните пожалуйста поподробней, что не так, если передавать 0x00, 0x00 вначале? Первый 0x00 вызовет ошибку фрейма, второй 0x00 будет принят Если 0xFF передавать, то возможно, что стартовый бит 0xFF попадет на стоповый бит "байта помехи". И тоже будет ошибка фрейма. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 30 ноября, 2015 Опубликовано 30 ноября, 2015 · Жалоба Поясните пожалуйста поподробней, что не так, если передавать 0x00, 0x00 вначале? Первый 0x00 вызовет ошибку фрейма, второй 0x00 будет принят Не всегда. Существуют контроллеры, которые считают бит, на котором случился FE, стартовым для следующего фрейма. В случае такого контроллера второй байт 0x00 тоже вызовет FE. Вот тут я рисовал картинку. (Там для 0xF0, но суть та же). Если 0xFF передавать, то возможно, что стартовый бит 0xFF попадет на стоповый бит "байта помехи". И тоже будет ошибка фрейма. Да, в случае такого контроллера это тоже не даст стопроцентной синхронизации. Но вероятность засинхронизироваться будет выше, чем при передаче 0x00. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dima1060 0 30 ноября, 2015 Опубликовано 30 ноября, 2015 · Жалоба Не всегда. Существуют контроллеры, которые считают бит, на котором случился FE, стартовым для следующего фрейма. В случае такого контроллера второй байт 0x00 тоже вызовет FE. Вот тут я рисовал картинку. (Там для 0xF0, но суть та же). Да, в случае такого контроллера это тоже не даст стопроцентной синхронизации. Но вероятность засинхронизироваться будет выше, чем при передаче 0x00. Я надеюсь, к "таким" контроллерам не относятся STM32 ? У них есть флаг Frame Error. А вот в Silabs (C8051F320) я такого флага не нашел, вообще ничего про это не написано... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 17 30 ноября, 2015 Опубликовано 30 ноября, 2015 · Жалоба не совсем понял, придется делать XOR всех байт пакета? Ага. А вас по каким-то причинам напрягает операция XOR? Религия не позволяет, или типа того? Ну тогда не делайте, посылайте как есть, на практике результат будет одинаковый. с чего это? USB наиболее удален от помех будет. и длина RS-485 будет 5 метров кабеля, а USB меньше 1 см на плате Да хоть миллиметр. Помехи-то все равно пройдут сквозь него. Наведутся они вовне, а пройдут сквозь ваш короткий USB, если им деваться больше некуда. Опторазвязка может помочь частично, но за счет паразитных емкостей помехи все равно пройдут. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться