jcxz 235 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 6 минут назад, Arlleex сказал: Только при условии, что приемник UART правильно синхронизировался с передатчиком (старт-бит передатчика взялся в расчет приемным UART-ом именно как старт-бит нового байта). А при горячем подключении это может оказаться далеко не так. Старт-битом для приемника может оказаться и любой нулевой бит в середине байта, если приемник активизировался именно в этот момент. Ну так сделайте байтом границы кадра такой, у которого всё однозначно: байт == 0. Кстати у COBS граница кадра как раз байт == 0. https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 9 минут назад, Arlleex сказал: Посмотрите внимательно, DF это неправильная интерпретация EF при выключенном паритете. Выше вы писали про два стопа и паритет. Я для такой ситуации вам и ответил. А так можно много кодов найти, которые сдвинутые тоже будут попадать под правильную интерпретацию УАРТом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 1 минуту назад, ViKo сказал: Выше вы писали про два стопа и паритет. Я для такой ситуации вам и ответил. А так можно много кодов найти, которые сдвинутые тоже будут попадать под правильную интерпретацию УАРТом. Под 0 никакой код не попадёт. Естественно если не считать сигнала BREAK и неправильную скорость UART. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 3 минуты назад, jcxz сказал: Под 0 никакой код не попадёт. Естественно если не считать сигнала BREAK и неправильную скорость UART. Да. Потому что из единиц -- только стопы. ) FF с дополнением до нечётного тоже годится. Потому что из нулей - только старт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 45 минут назад, ViKo сказал: FF с дополнением до нечётного тоже годится. Потому что из нулей - только старт. Не сгодится, так как если приёмник включится в момент конца какого-то символа, у которого в конце один только бит==0, то он может воспринять его как 0xFF. А значит 0xFF нельзя назначать как символ границы кадра. Это уже не говоря о необходимости наложения дополнительных требований к интерфейсу (чётность). С 0-м же никого не спутаешь, в какой момент не включайся. Самый правильный символ границы кадра ==0. PS: А самый правильный метод выделения кадров из потока байт == COBS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба Нужно было, наверное, в самом первом топике указать один момент... Интересовал именно механизм выделения сырых байтов из линии. Именно корректных с точки зрения согласованности битов передатчика и приемника. Как кадры выделять из потока я знаю; для чего кодонезависимые протоколы мне тоже известно не понаслышке (применяю везде и всюду, где требуется). Мне было интересно, существуют ли способы однозначного "засинхрона" передаваемых данных с приемником, при условии, что данные могут лететь безостатоновочно и протокол, который ходит поверх - не кодонезависимый, а любой - в моем случае ASCII. Причем разделителем команд служит любой из десятка предопределенных символов. Поэтому если я врежусь в поток и не правильно засинхронизируюсь, существует вероятность того, что UART не будет рапортовать об ошибках (ведь с его точки зрения их и не будет до первого встречного Framing Error или какого-то другого вида ошибки), а значит в буфер FIFO поступят мусорные данные, которые будут обработаны. И вот если этот мусор еще и окажется вполне валидной командой, будет печалька. К сожалению, протокол я менять не могу - таковы входные данные. Вот я и интересовался, возможно ли какими-то надстройками UART-а (паритет, кол-во стоповых битов, а может еще что-то) однозначно определить позицию старт-бита следующего байта. Видимо, это не реально (интерфейс такой). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба Паузами между передачами тоже можно улучшить распознавание. ASCII символы - набор ограниченный. Словить что-то ошибочное, да из допустимых - тоже непросто. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 7 минут назад, ViKo сказал: Паузами между передачами тоже можно улучшить распознавание. Так Break - это по сути и есть минимально необходимая пауза... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 1 час назад, ViKo сказал: Паузами между передачами тоже можно улучшить распознавание. С паузой - понятное дело, просто. Но в общем случае между байтами может не быть пауз (СТОП предыдущего -> СТАРТ следующего). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 2 часа назад, Arlleex сказал: протокол, который ходит поверх - не кодонезависимый, а любой - в моем случае ASCII. ASCII - это не протокол. Но есть протоколы с передачей ASCII-строк. Например: AT-командные. В них можно кадрами считать строки. Или блок строк - от команды до "OK" или "ERROR". Если блоков строк нет, то границей кадра можно считать символы перевода строки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amaora 24 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба Если даже определить, по анализу принимаемых данных, что вот сейчас UART принимает фреймы не с того места, и так везёт/совпадает, что не определяются никакие ошибки. Тогда следующий вопрос, как пересинхронизироваться? включать-выключать UART и надеяться, что на этот раз повезёт? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 173 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 4 минуты назад, amaora сказал: Включать-выключать UART и надеяться, что на этот раз повезёт? Вот, видимо, так и делать. Увы, другого варианта не вижу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба Ещё можно: 1) По принятому потоку битов сделать предположение - в какой позиции может быть правильный старт-бит; 2) Вычислить момент времени (в будущем) когда будет один из следующих старт-битов; 3) Выключить UART и включить его прямо перед этим старт-битом. Но думаю будет непросто. Особенно с п.1. PS: Если сложно с точным включением UART (это же не XMC4xxx, а всего-лишь STM32 ), то ещё можно пожертвовать один таймер, подключить его выход к линии RXD (а может с помощью мультиплексора пинов можно подобрать такой таймер, который выходит на ту же ногу, что и RXD), и выставить низкий уровень (BREAK) на такое время, чтобы он закончился незадолго перед вычисленным старт-битом. С той же целью. Ну конечно последовательный резистор или диод на RXD ещё добавить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба Воткнуть промежуточный синхронизатор - принимаем 921600 без пауз, выдаем 1500000 с паузами. А уж в него hot plug. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 3 февраля, 2022 Опубликовано 3 февраля, 2022 · Жалоба 2 минуты назад, aaarrr сказал: Воткнуть промежуточный синхронизатор - принимаем 921600 без пауз, выдаем 1500000 с паузами. А уж в него hot plug. Только не забыть запитать его от источника данных на RXD. А то если он будет запитан и выключаться/перегружаться в то же время, что и защищаемый МК, то толку не будет. Ну или эфемерное питание ему от RXD сделать. PS: Есть ещё решение: программный UART. С сохранением истории битового потока. Чтобы по истории можно было с любой точки данные вытянуть. Ну или в будущем легко точку старт-бита рассчитать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться