[aaarrr 63]

11 minutes ago, jcxz said:

это же не XMC4xxx, а всего-лишь STM32

Не иначе как @AlexandrY укусил

[Arlleex 131]

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

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

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

Цитата

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

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

[jcxz 184]

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% обнаружения старт-бита и синхронизации приема следующего байта, ИМХО, в общем случае не возможно (слишком много неизвестных и случайных состояний)

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

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

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

[haker_fox 60]

17 hours ago, MegaVolt said:

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

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

17 hours ago, jcxz said:

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

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

[vladec 7]

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

[yes 5]

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

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

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

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

[Arlleex 131]

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

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

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

[Obam 30]

M-последовательность (ПСП) не бывает 64 бита ;-)

[Arlleex 131]

Кто?

[Obam 30]

Конь в па (Хоровиц с Хиллом т.2 стр 277..286) Pseudo Random Sequence - Последовательность ПсевдоСлучайная

[Arlleex 131]

А она тут каким боком??

[Herz 4]

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

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

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

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

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

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

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

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

[Arlleex 131]

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

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

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