Перейти к содержанию
    

Hot plug UART-Rx. Возможен ли?

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё можно:

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...