Jump to content

    
flammmable

Как отловить ошибку в UART ? [РЕШЕНО]

Recommended Posts

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

Share this post


Link to post
Share on other sites
4 hours ago, Flip-fl0p said:

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

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

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

15 hours ago, Flip-fl0p said:

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

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

Edited by flammmable

Share this post


Link to post
Share on other sites
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-а?

Share this post


Link to post
Share on other sites
3 часа назад, flammmable сказал:

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

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

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

 

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

 

 

Share this post


Link to post
Share on other sites
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 минут.
Ну. Такое себе.

Edited by flammmable

Share this post


Link to post
Share on other sites

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

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

Edited by likeasm

Share this post


Link to post
Share on other sites
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 - это рекомендованный оверсемпл, от которого, очевидно, можно отходить в обе стороны.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
15 часов назад, sazh сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

   

Удачи!  Rob. 

Share this post


Link to post
Share on other sites
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 биты одинаковые - бит принят иначе ждём старт

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

Share this post


Link to post
Share on other sites
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 минут. Ну да, как раз хватит чтобы сказать при пуско-наладке "Ну вот, работает же всё! А вы говорите!", надеть куртку и отбежать подальше. ))))

Edited by flammmable

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.