Jump to content

    

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

Recommended Posts

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

PS: Если сложно с точным включением UART (это же не XMC4xxx, а всего-лишь STM32 :biggrin: )...

Хотите сказать в этом чудо-МК UART каким-то неведомым образом избавлен от озвученных проблем синхронизации? Хотелось бы верить, но верится с трудом.

Цитата

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

Как Вы себе это представляете? Вот даже фиг с ним, пусть у нас XMC4xxx, который умеет че-то там подтягивать к 0 аппаратно. Вот подается на вход не иначе, как галиматья из последовательности битов. Данные - ну разные абсолютно, приемник не знает природы их формирования. Как искать старт-бит? Заморочиться можно, кто ж спорит, только сделать алгоритм 100% обнаружения старт-бита и синхронизации приема следующего байта, ИМХО, в общем случае не возможно (слишком много неизвестных и случайных состояний):unknw:

Share this post


Link to post
Share on other sites

jcxz
1 час назад, Arlleex сказал:

Хотите сказать в этом чудо-МК UART каким-то неведомым образом избавлен от озвученных проблем синхронизации? Хотелось бы верить, но верится с трудом.

У XMC4xxx размер символа UART = 1...63 бита (данных). Что позволит гибко двигать точку старт-бита даже в непрерывном битовом потоке. А также там весьма мощный UART, многое умеющий. Например: принимать смешанный поток символов разного размера (от 1 до 63 бит вперемежку не останавливая UART), выполнять маскирования входного сигнала на заданное время и т.п. И наверняка можно, не выключая UART, на ходу сдвинуть точку старт-бита в непрерывном потоке байт.

А вообще моя та фраза касалась моего же совета относительно выключения UART на заданное время. На XMC можно просто приостановить приёмник на точно заданное время, по таймеру, не выключая UART.

Цитата

Как Вы себе это представляете? Вот даже фиг с ним, пусть у нас XMC4xxx, который умеет че-то там подтягивать к 0 аппаратно. Вот подается на вход не иначе, как галиматья из последовательности битов. Данные - ну разные абсолютно, приемник не знает природы их формирования. Как искать старт-бит?

Ну а как ваш парсер решает что кадр правильный? Он ведь это как-то решает? Тогда что ему мешает это делать не с одним потоком байт, а с 5-ю параллельными? Если у вас 8-N-1, то берёте 5 параллельных потоков, дешифруя символы со смещением в один бит. Начиная от первого спада сигнала (1-й старт-бит = 1-й поток) и далее - через каждый один бит может быть следующий стартовый. Получаете до 5-ти потоков символов. Подаёте это на 5 парсеров. Кто из них первый скажет "хороший кадр" - того и оставляете на развод. Остальных режете.

 

Цитата

Заморочиться можно, кто ж спорит, только сделать алгоритм 100% обнаружения старт-бита и синхронизации приема следующего байта, ИМХО, в общем случае не возможно (слишком много неизвестных и случайных состояний):unknw:

Протокол только Вы знаете. И только Вы знаете насколько возможно в нём отличить правильный кадр, от неправильного.

А по похожему алгоритму я много лет назад делал приёмник (но не UART). Только там всё было гораздо хуже: потоков было 10, и были они не байтовыми, а битовыми. Неизвестна была точка битовой синхронизации. Я просто запускал 10 приёмников, со смещением на 1/10 битового интервала один от другого. И смотрел - с выхода которого из них вылезет правильный кадр. Каждый битовый приёмник имел после себя байтовый парсер. С парсингом всех CRC и прочих обрамлений кадра. И работал он прекрасно - практически 100% определял правильную точку синхронизации (а при высоком SNR правильные кадры вылезали более чем из половины почти одновременно, одинаковые). Да и сейчас наверное работает - девайс уже лет 15 как в серии.

А XMC тут совсем не причём.

Share this post


Link to post
Share on other sites

haker_fox
17 hours ago, MegaVolt said:

Так протокол уже содержит byte stuffing о чём явно сказано в описании протокола.

Да, об это  и речь. Я свою доработку к протоколу делал: расширял адресное пространство и вводил служебные флаги.

17 hours ago, jcxz said:

COBS значительно лучше имхо.

Да, смотрел на него. Даже хотел как-то осилить, но не стал осиливать. Старый добрый WAKE оказался в очередной раз приятней. Оверхэд у меня небольшой, т.к. объёмы данных в моём приложении небольшие. Возможно, когда-то возьму и COBS.

Share this post


Link to post
Share on other sites

vladec

На протокольном уровне, можно искусственно или естественно расчленить поток на фреймы длинными нулевыми break-ами (сплошной ноль длинной больше одного байта), символизирующими начала фреймов, как это реализовано, например, в добром старом протоколе DMX. Решение достаточно простое, надежное и легко реализуемое в современных контроллерах.

Share this post


Link to post
Share on other sites

yes

бывает (или может раньше бывала) возможность стопбита 1.5 интервала

может по типу автобауда (то есть таймером) отловить 1 в n+0.5 интервала - следующий 0 стартбит

но это теоретическое рассуждение - не было нужды в такой синхронизации.

протокол лучше по любому будет

Share this post


Link to post
Share on other sites

Arlleex
03.02.2022 в 23:23, jcxz сказал:

У XMC4xxx размер символа UART = 1...63 бита (данных)...

Интереса ради: почему они сделали 63 бита. Почему не 64, чтобы можно было u64 принимать/отправлять?

Share this post


Link to post
Share on other sites

Herz
03.02.2022 в 10:48, Arlleex сказал:

Сейчас воткнул Rx FT232 к МК, который непрерывно отправляет 0xEF.

Кстати, напомнило.

Ровно год назад, в рамках одного проекта была похожая задача. Со стенда передавались в компьютер результаты измерений в виде ASCII, пять колонок цифр с маркерами переменной (буква), разделённые пробелом. В конце каждой пятёрки - перевод строки. Удобно было обрабатывать, как csv-запись. Каждая колонка - своя переменная. Передача была, можно сказать, медленной: то ли на 9600, то ли 19200 - уже не помню.

Каждый прогон - 15 минут.

Так вот, сначала связь была через какой-то первый попавшийся кабель-переходник RS232-USB. И через пару минут последовательность "сыпалась": то пропадали символы, то строка удлинялась, то возникали повторы...

Взяли хороший кабель, UGREEN - стало гораздо лучше, но всё равно на все 15 минут не хватало. В какой-то момент начинался бардак...

Так вот, не в этом ли часть Вашей проблемы?

Share this post


Link to post
Share on other sites

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

Так вот, не в этом ли часть Вашей проблемы?

Ну, UART не USART/SPI/другой синхронный интерфейс. В нем априори после некой паузы между фреймами следующий кадр гарантированно будет воспринят правильно. Т.е. данные никуда не сдвинутся/уедут. А я рассматривал возможность подключиться в линию, где уже передается сплошной поток данных (т.е. без временных или специальных кадровых разделителей типа Break/Idle Frame), при этом корректно определить старт-бит очередного кадра.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.