[likeasm 0]

У вас, как-то странно реализован Oversampling. Обычно создается аккумулятор, который делит несущую частоту, формируя одиночные импульсы длительностью в такт несущей и периодом в 16 раз больше скорости UART. Далее по этим импульсам(Тick-ам) идет работа вашего rx_in. И доменная синхронизация, и мажоритарный фильтр  надо ставить по Tick, а не по несущей частоте.

[flammmable 0]

4 hours ago, Flip-fl0p said:

Так МЖФ можно делать не на 3 отсчета, а на 5 например, или 7. Если у Вас столько игл - в сигнале, значит проблема на физическом уровне. Тут ничего не спасет.

Так я и говорю :) Можно не 3, а 7. Можно CRC16, а можно и CRC1024. Можно хендшейками рукопожиматься до посинения. Глобально - это всё не решения проблемы, а её маскировка.

И если говорить, что...

15 hours ago, Flip-fl0p said:

Для надежного uart - этого мало. Неплохо было бы поставить некий фильтр...

... то я вам возражу: по хорошему всё должно работать без фильтров. Иногда фильтр (или контрольная сумма) - это быстрая и дешевая заплатка, которая достаточно надежна для требований заказчика. Но закладывать заплатку на стадии проекта? Ну не знаю )) Это высокий уровень недоверия программиста к конструктору ))

Изменено 6 мая, 2021 пользователем flammmable

[flammmable 0]

3 hours ago, likeasm said:

Обычно создается аккумулятор, который делит несущую частоту, формируя одиночные импульсы длительностью в такт несущей...

Под несущей вы имеете ввиду частоту тактирования ПЛИСа?

3 hours ago, likeasm said:

Далее по этим импульсам(Тick-ам) идет работа вашего rx_in.

Вы имеете ввиду "работа с вашим rx_in"?

3 hours ago, likeasm said:

И доменная синхронизация, и мажоритарный фильтр  надо ставить по Tick, а не по несущей частоте.

К черту падежи, но почему "надо"? Типа, все так делают? Что случится, если оверсемплинг будет не в 16, а в 32 или в 33 раза больше частоты UART-а?

[Flip-fl0p 4]

3 часа назад, flammmable сказал:

Так я и говорю :) Можно не 3, а 7. Можно CRC16, а можно и CRC1024. Можно хендшейками рукопожиматься до посинения. Глобально - это всё не решения проблемы, а её маскировка.

И если говорить, что...

... то я вам возражу: по хорошему всё должно работать без фильтров. Иногда фильтр (или контрольная сумма) - это быстрая и дешевая заплатка, которая достаточно надежна для требований заказчика. Но закладывать заплатку на стадии проекта? Ну не знаю )) Это высокий уровень недоверия программиста к конструктору ))

 

Пологие фронты могут быть - могут. Навестись на провод всякая бяка может - может. Как бы мы не хотели, но мы живем в мире где действуют законы физики, которые надо учитывать при проектировании. И установка МЖФ - это один из способов повысить надежность проекта. При чем это почти ничего не стоит.  Не понимаю я Вашего упорства. Как я бы сделал - Вы услышали. А далее на Вашей совести то, как Вы реализуете UART.

 

 

[flammmable 0]

1 hour ago, Flip-fl0p said:

Пологие фронты могут быть - могут.

Мм. Пологие фронты у UART-а? Допустим. И как они помешают, если выборка производится в середине битового интервала? А даже если и нет, как МЖФ поможет при пологом фронте?

1 hour ago, Flip-fl0p said:

Навестись на провод всякая бяка может - может.

Если бяка большая - МЖФ не поможет. Если бяка маленькая - всё будет работать и без МЖФ.

1 hour ago, Flip-fl0p said:

МЖФ - это один из способов повысить надежность проекта...

...замаскировав источник проблем. Иногда этого будет достаточно. Иногда - это приведет к усложнению диагностики.

1 hour ago, Flip-fl0p said:

Не понимаю я Вашего упорства.

Я считаю, что выражение "МЖФ - способ повысить надежность проекта. При чем это почти ничего не стоит" излишне оптимистично. И может создать иллюзию отсутствия подводных камней.

 

P.S.

Кстати. Любопытно будет посчитать. Допустим у нас есть некий единичный период. И есть игла в N раз меньше этого периода, которая возникает с вероятностью 1/M. Тогда вероятность ошибочного считывания равна 1/NM . Во сколько раз МЖФ из 3-х триггеров понизит эту вероятность?

Я насчитал следующее:
при общей вероятности словить иглу в 20%, МЖФ понизит её до 10%
при общей вероятности словить иглу в 10%, МЖФ понизит её до 2,8%

при общей вероятности словить иглу в  5%, МЖФ понизит её до 0,7%

при общей вероятности словить иглу в  1%, МЖФ понизит её до 0,03%

при общей вероятности словить иглу в  0,1%, МЖФ понизит её до 0,0003%

Иными словами, что если на 1000 байт 1 плохой?
Если задача уровня "набор номера на домофоне", то 1 раз на 1000 можно и перенабрать его по новой.
Если же это поток каких-то важных данных со скоростью 1 килобайт в секунду, то благодаря МЖФ ошибка станет появляться не раз в секунду, а раз в 6 минут.
Ну. Такое себе.

Изменено 6 мая, 2021 пользователем flammmable

[likeasm 0]

Я использовал идеологию построения Serial interface от сюда https://www.fpga4fun.com/SerialInterface.html. Там все написано.

З.Ы. за падежи прошу понять и простить, последнее время хроническое недосыпание.

Изменено 6 мая, 2021 пользователем likeasm

[flammmable 0]

11 hours ago, likeasm said:

Я использовал идеологию построения Serial interface от сюда https://www.fpga4fun.com/SerialInterface.html. Там все написано.

З.Ы. за падежи прошу понять и простить, последнее время хроническое недосыпание.

 

Сердечно желаю вам выспаться, это действительно роскошь.

Однако на fpga4fun в разделе Receiver написано "Receivers typically oversample the incoming signal at 16 times the baud rate. We use 8 times here". Иными словами 16 - это рекомендованный оверсемпл, от которого, очевидно, можно отходить в обе стороны.

[sazh 3]

23 hours ago, flammmable said:

Мм. Пологие фронты у UART-а? Допустим. И как они помешают, если выборка производится в середине битового интервала? А даже если и нет, как МЖФ поможет при пологом фронте?

Если бяка большая - МЖФ не поможет. Если бяка маленькая - всё будет работать и без МЖФ.

...замаскировав источник проблем. Иногда этого будет достаточно. Иногда - это приведет к усложнению диагностики.

Я считаю, что выражение "МЖФ - способ повысить надежность проекта. При чем это почти ничего не стоит" излишне оптимистично. И может создать иллюзию отсутствия подводных камней.

 

P.S.

Кстати. Любопытно будет посчитать. Допустим у нас есть некий единичный период. И есть игла в N раз меньше этого периода, которая возникает с вероятностью 1/M. Тогда вероятность ошибочного считывания равна 1/NM . Во сколько раз МЖФ из 3-х триггеров понизит эту вероятность?

Я насчитал следующее:

Ну. Такое себе.

 

Правильно мыслите. Какие пологие фронты, если в линии +-5В, а отсекаются при приеме на уровне +-3В.

Покритикую проект. Если позволите. Проект не полностью параметризирован (разрядность счетчиков к параметрам не привязана). 

Загружать счетчики надо (значением - 1), ибо счетчик крутится от 0 до (2**n) -1 и если вдруг загрузите 2**n, загрузите нули.

По мне, так в автомате не хватает еще одного состояния. начинаете со старта. Заканчивать надо на стопе  (если там будет 0 - это ошибка кадрирования).

Мне понравилась реализация  30 тилетней давности в ДВК3.

По перепаду из 1 в 0 добегаем до середины стартового бита, и если добежали, от этой середины просто нарезаем биты , в том числе стоп.

За 10, 11 бит просто невозможно уход от середины бита в следующий бит.

Простой тестовый пример. Если интересно.

mail_out_2021.zip

[Александр77 1]

15 часов назад, sazh сказал:

По перепаду из 1 в 0 добегаем до середины стартового бита, и если добежали, от этой середины просто нарезаем биты , в том числе стоп.

За 10, 11 бит просто невозможно уход от середины бита в следующий бит.

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

[RobFPGA 27]

Приветствую!

24 minutes ago, Александр77 said:

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

UART потому и асинхронный  что синхронизируется в начале каждого байта по стартовому биту.  Поэтому сколько  там будет тысяч байт не важно. Важно чтобы на длине посылки рассогласование из за разницы тактовых было не более +- 1/2 бита.  Что на типичной длине  10 бит дает макс разницу тактовых ~5%.  На сколько помню стандартные требование еще жёстче, <4% разницы в скорости. 

 

Различные  методы обнаружения/коррекции ошибок (мажоритирование, бит паритета, CRC, ...)  призваны решать разные задачи в общем русле повышения надежности передачи данных. И это отнюдь не маскирование проблем, а порой суровая необходимость.

   

Удачи!  Rob. 

[_4afc_ 24]

On 5/7/2021 at 8:41 AM, flammmable said:

Однако на fpga4fun в разделе Receiver написано "Receivers typically oversample the incoming signal at 16 times the baud rate. We use 8 times here". Иными словами 16 - это рекомендованный оверсемпл, от которого, очевидно, можно отходить в обе стороны.

Так а у вас где оверсемплинг в коде?

 

Я на UART_RX подавал частоту 14769231/18=820513Гц

И используя овесемплинг в 7 раз принимал данные на средней частоте 117216Гц

Устойчивый приём был в диапазоне 112993-121363Гц

 

Изначально находимся в ожидании старта

Если в сдвиговом регистре 7'h70 то старт принят

Если 1,2 и 3 биты одинаковые - бит принят иначе ждём старт

Приняли стоп - и чётность совпала - отдали байт дальше в ПЛИС и перешли в ожидание старта

[flammmable 0]

On 5/8/2021 at 10:25 AM, RobFPGA said:

Различные  методы обнаружения/коррекции ошибок (мажоритирование, бит паритета, CRC, ...)  призваны решать разные задачи в общем русле повышения надежности передачи данных. И это отнюдь не маскирование проблем, а порой суровая необходимость.

Положим, шанс возникновения ошибки в 1 бите равен p.
Шанс возникновения одной ошибки в байте - 8*p*(1-p)^7.
Двух ошибок в байте - 7*p^2*(1-p)^6.

Первый случай бит паритета отловит, второй - нет. Остальные при малом p - несущественны.

Иными словами бит паритета увеличивает вероятность правильной передачи в (8+6p)/7p раз.
Для p=1% - это 115 раз
Для p=0,1% - это 1143 раза
Для p=0,01% - это 11429 раз.

Т.е. для передачи 1кбит/с количество ошибок упадет с одной ошибки в секунду до одной ошибки в 20 минут. Ну да, как раз хватит чтобы сказать при пуско-наладке "Ну вот, работает же всё! А вы говорите!", надеть куртку и отбежать подальше. ))))

Изменено 11 мая, 2021 пользователем flammmable