[jcxz 184]

6 минут назад, Arlleex сказал:

Только при условии, что приемник UART правильно синхронизировался с передатчиком (старт-бит передатчика взялся в расчет приемным UART-ом именно как старт-бит нового байта). А при горячем подключении это может оказаться далеко не так. Старт-битом для приемника может оказаться и любой нулевой бит в середине байта, если приемник активизировался именно в этот момент.

Ну так сделайте байтом границы кадра такой, у которого всё однозначно: байт == 0. Кстати у COBS граница кадра как раз байт == 0.

https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing

[ViKo 1]

9 минут назад, Arlleex сказал:

Посмотрите внимательно, DF это неправильная интерпретация EF при выключенном паритете.

Выше вы писали про два стопа и паритет. Я для такой ситуации вам и ответил. А так можно много кодов найти, которые сдвинутые тоже будут попадать под правильную интерпретацию УАРТом.

[jcxz 184]

1 минуту назад, ViKo сказал:

Выше вы писали про два стопа и паритет. Я для такой ситуации вам и ответил. А так можно много кодов найти, которые сдвинутые тоже будут попадать под правильную интерпретацию УАРТом.

Под 0 никакой код не попадёт. Естественно если не считать сигнала BREAK и неправильную скорость UART.

[ViKo 1]

3 минуты назад, jcxz сказал:

Под 0 никакой код не попадёт. Естественно если не считать сигнала BREAK и неправильную скорость UART.

Да. Потому что из единиц -- только стопы. )

FF с дополнением до нечётного тоже годится. Потому что из нулей - только старт.

[jcxz 184]

45 минут назад, ViKo сказал:

FF с дополнением до нечётного тоже годится. Потому что из нулей - только старт.

Не сгодится, так как если приёмник включится в момент конца какого-то символа, у которого в конце один только бит==0, то он может воспринять его как 0xFF. А значит 0xFF нельзя назначать как символ границы кадра. Это уже не говоря о необходимости наложения дополнительных требований к интерфейсу (чётность). С 0-м же никого не спутаешь, в какой момент не включайся.

Самый правильный символ границы кадра ==0.

PS: А самый правильный метод выделения кадров из потока байт == COBS.   

[Arlleex 131]

Нужно было, наверное, в самом первом топике указать один момент... Интересовал именно механизм выделения сырых байтов из линии. Именно корректных с точки зрения согласованности битов передатчика и приемника. Как кадры выделять из потока я знаю; для чего кодонезависимые протоколы мне тоже известно не понаслышке (применяю везде и всюду, где требуется). Мне было интересно, существуют ли способы однозначного "засинхрона" передаваемых данных с приемником, при условии, что данные могут лететь безостатоновочно и протокол, который ходит поверх - не кодонезависимый, а любой - в моем случае ASCII. Причем разделителем команд служит любой из десятка предопределенных символов. Поэтому если я врежусь в поток и не правильно засинхронизируюсь, существует вероятность того, что UART не будет рапортовать об ошибках (ведь с его точки зрения их и не будет до первого встречного Framing Error или какого-то другого вида ошибки), а значит в буфер FIFO поступят мусорные данные, которые будут обработаны. И вот если этот мусор еще и окажется вполне валидной командой, будет печалька. К сожалению, протокол я менять не могу - таковы входные данные. Вот я и интересовался, возможно ли какими-то надстройками UART-а (паритет, кол-во стоповых битов, а может еще что-то) однозначно определить позицию старт-бита следующего байта. Видимо, это не реально (интерфейс такой).

[ViKo 1]

Паузами между передачами тоже можно улучшить распознавание.

ASCII символы - набор ограниченный. Словить что-то ошибочное, да из допустимых - тоже непросто.

[mantech 34]

7 минут назад, ViKo сказал:

Паузами между передачами тоже можно улучшить распознавание.

Так Break - это по сути и есть минимально необходимая пауза...

[Arlleex 131]

1 час назад, ViKo сказал:

Паузами между передачами тоже можно улучшить распознавание.

С паузой - понятное дело, просто. Но в общем случае между байтами может не быть пауз (СТОП предыдущего -> СТАРТ следующего).

[jcxz 184]

2 часа назад, Arlleex сказал:

протокол, который ходит поверх - не кодонезависимый, а любой - в моем случае ASCII.

ASCII - это не протокол. Но есть протоколы с передачей ASCII-строк. Например: AT-командные. В них можно кадрами считать строки. Или блок строк - от команды до "OK" или "ERROR".

Если блоков строк нет, то границей кадра можно считать символы перевода строки.

[amaora 20]

Если даже определить, по анализу принимаемых данных, что вот сейчас UART принимает фреймы не с того места, и так везёт/совпадает, что не определяются никакие ошибки. Тогда следующий вопрос, как пересинхронизироваться? включать-выключать UART и надеяться, что на этот раз повезёт?

[Arlleex 131]

4 минуты назад, amaora сказал:

Включать-выключать UART и надеяться, что на этот раз повезёт?

Вот, видимо, так и делать. Увы, другого варианта не вижу.

[jcxz 184]

Ещё можно:

1) По принятому потоку битов сделать предположение - в какой позиции может быть правильный старт-бит;

2) Вычислить момент времени (в будущем) когда будет один из следующих старт-битов;

3) Выключить UART и включить его прямо перед этим старт-битом.

Но думаю будет непросто. Особенно с п.1.   

 

PS: Если сложно с точным включением UART (это же не XMC4xxx, а всего-лишь STM32  ), то ещё можно пожертвовать один таймер, подключить его выход к линии RXD (а может с помощью мультиплексора пинов можно подобрать такой таймер, который выходит на ту же ногу, что и RXD), и выставить низкий уровень (BREAK) на такое время, чтобы он закончился незадолго перед вычисленным старт-битом. С той же целью. Ну конечно последовательный резистор или диод на RXD ещё добавить.

[aaarrr 63]

Воткнуть промежуточный синхронизатор - принимаем 921600 без пауз, выдаем 1500000 с паузами. А уж в него hot plug.

[jcxz 184]

2 минуты назад, aaarrr сказал:

Воткнуть промежуточный синхронизатор - принимаем 921600 без пауз, выдаем 1500000 с паузами. А уж в него hot plug.

Только не забыть запитать его от источника данных на RXD. А то если он будет запитан и выключаться/перегружаться в то же время, что и защищаемый МК, то толку не будет.

Ну или эфемерное питание ему от RXD сделать.

 

PS: Есть ещё решение: программный UART. С сохранением истории битового потока. Чтобы по истории можно было с любой точки данные вытянуть. Ну или в будущем легко точку старт-бита рассчитать.