[DASM 0]

44 minutes ago, Flip-fl0p said:

Почему алгоритмически неверно ?  Изначально счетчик в нуле, что соответствует не нажатой кнопке. Флаг button_pressed = '0'. Затем мы нажали на кнопку. Счетчик начал считать вверх. Из-за дребезга у нас с выхода кнопки то нули то единицы. Соответственно счетчик считает то вверх, то вниз. Когда счетчик смог досчитать до значения 2**debouncer_width - 1 ( во всех разрядах счетчика единицы) - значит что нажатие кнопки действительно было, и она была нажата достаточное время.  И мы выдаем флаг button_pressed = '1'. Ни о каком дребезге с кнопки речи быть не может.  Флаг button_pressed  станет снова нулем только тогда, когда счетчик досчитает до нуля ( во всех разрядах счетчика нули). Ежели у Вас такой сильный дребезг, что при нажатии кнопки счетчик прыгает от состояния "все единицы" <----> "все нули" - значит у вас сильно фиговая кнопка или неправильно настроен модуль - выбрана слишком маленькая разрядность счетчика, поэтому мы в настройках модуля выбираем бОльшую разрядность счетчика. Например 

debouncer_width =>  7 меняем на debouncer_width => 15

Ну тут под вопросом конечно как лучше. В случае плохой кнопки (а все механики рано или поздно станут оными) - у вас будут таки ложные нажатия и отпускания. В моем варианте - нет

[Flip-fl0p 4]

10 минут назад, DASM сказал:

Ну тут под вопросом конечно как лучше. В случае плохой кнопки (а все механики рано или поздно станут оными) - у вас будут таки ложные нажатия и отпускания. В моем варианте - нет

Так в Вы поделитесь своим вариантом. Ведь данная тема как раз была создана для того, чтобы мы делились своими наработками.

[DASM 0]

2 minutes ago, Flip-fl0p said:

Так в Вы поделитесь своим вариантом. Ведь данная тема как раз была создана для того, чтобы мы делились своими наработками.

я только алогоритмически заинтересовался, на плис пишу очень мало да и на верилоге, то, что я написал - давно и успешно в микроконтроллерных реализациях использую.

[Flip-fl0p 4]

15 минут назад, DASM сказал:

я только алогоритмически заинтересовался, на плис пишу очень мало да и на верилоге, то, что я написал - давно и успешно в микроконтроллерных реализациях использую.

А теперь представьте, что Вы нажали на кнопку, и держите её. Но из-за того, что кнопка старая иногда, когда Вы чуть-чуть ослабляете силу нажатия на кнопку она размыкает цепь, и даёт кратковременно ложные нули. Я с такими кнопками работал. Неприятно.  С такими кнопками ваш алгоритм будет давать неверные нажатия кнопки... 

[DASM 0]

1 minute ago, Flip-fl0p said:

А теперь представьте, что Вы нажали на кнопку, и держите её. Но из-за того, что кнопка старая иногда, когда Вы чуть-чуть ослабляете силу нажатия на кнопку она размыкает цепь, и даёт кратковременно ложные нули. Я с такими кнопками работал. Неприятно.  С такими кнопками ваш алгоритм будет давать неверные нажатия кнопки... 

вы не совсем дочитали или я мутно написал. После срабатывания алгоритм идет наооборот. То есть чтобы она была "отжата" должно пройти N выборок, среди которых все должны быть в состоянии "отжата".

Можно еще короче - состояние "нажата" фиксим если N выборок "все нажата" было подряд. "Отжата" - если N "все не нажата"

[Flip-fl0p 4]

5 минут назад, DASM сказал:

вы не совсем дочитали или я мутно написал. После срабатывания алгоритм идет наооборот. То есть чтобы она была "отжата" должно пройти N выборок, среди которых все должны быть в состоянии "отжата".

Можно еще короче - состояние "нажата" фиксим если N выборок "все нажата" было подряд. "Отжата" - если N "все не нажата"

Дык у меня почти тоже самое   Просто у нас слега отличается управление счетчиком. Вы считаете сколько времени кнопка была в нажатом\отжатом состоянии. А я просто считаю, что если счетчик смог таки досчитать до предельных значений. Во всех наших вариантах можно придумать "гипотетическую" кнопку, у которой дребезг больше чем пороги срабатывания. 

[DASM 0]

1 minute ago, Flip-fl0p said:

Дык у меня почти тоже самое   Просто у нас слега отличается управление счетчиком. Вы считаете сколько времени кнопка была в нажатом\отжатом состоянии. А я просто считаю, что если счетчик смог таки досчитать до предельных значений. Во всех наших вариантах можно придумать "гипотетическую" кнопку, у которой дребезг больше чем пороги срабатывания. 

ваш вариант сработает на дребезге с заполнением выше 50 %, мой - нет. У меня нет "дребезга выше порога" - абсолютно любой дребезг обнулит счетчик. Регистрируется только полностью четкое срабатывание. Фишка в обнулении.

[Flip-fl0p 4]

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

ваш вариант сработает на дребезге с заполнением выше 50 %, мой - нет. У меня нет "дребезга выше порога" - абсолютно любой дребезг обнулит счетчик. Регистрируется только полностью четкое срабатывание. Фишка в обнулении.

Для меня загадка, как может зарегистрироваться нечеткое нажатие в моем случае. Крайние положения счетчика - достаточное условие, чтобы сделать вывод о том в каком состоянии кнопка. Приведите абстрактный пример, когда моя логика приведет к неправильной фиксации события: кнопка нажата\отжата

[DASM 0]

15 minutes ago, Flip-fl0p said:

Для меня загадка, как может зарегистрироваться нечеткое нажатие в моем случае. Крайние положения счетчика - достаточное условие, чтобы сделать вывод о том в каком состоянии кнопка. Приведите абстрактный пример, когда моя логика приведет к неправильной фиксации события: кнопка нажата\отжата

да просто по определению - вы фиксируете количество по сути насколько больше событий нажатых чем не нажатых. Допустим N = 10, выборка раз в 1 мс. 9 мс кнопка была нажата, вы дошли до 9. На 10 ом разе прошел дребезг, счетчик стал 8. И дальше она дребезжит условно говоря полчаса и вы прыгаете между 8 и 9. Все это время кнопка находится в состоянии "работа без антидребезга", т.к. для достижения порога вам уже достаточно пары семплов. 

Фактически это не приведет и у вас к ложным фиксациям, но как-то оно неаккуратненько. Например если по каким -то условиям заложена латентность от фактического срабатывания до исполнения в эти 10 мс, то у вас его не будет.  Я не хочу сказать что у вас ужасный вариант или там нерабочий, нет. Но я считаю мой вариант более верным с точки зрения самого понятия "исключить дребезг". 

[Flip-fl0p 4]

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

да просто по определению - вы фиксируете количество по сути насколько больше событий нажатых чем не нажатых. Допустим N = 10, выборка раз в 1 мс. 9 мс кнопка была нажата, вы дошли до 9. На 10 ом разе прошел дребезг, счетчик стал 8. И дальше она дребезжит условно говоря полчаса и вы прыгаете между 8 и 9. Все это время кнопка находится в состоянии "работа без антидребезга", т.к. для достижения порога вам уже достаточно пары семплов. 

Фактически это не приведет и у вас к ложным фиксациям, но как-то оно неаккуратненько. Например если по каким -то условиям заложена латентность от фактического срабатывания до исполнения в эти 10 мс, то у вас его не будет. 

Латентность должен обеспечивать не модуль антидребезга, а дальнейшая логика проекта. Словил факт нажатия кнопки --> сделал необходимую задержку --> начал работать. Задача антидребезга обработать факт нажатия\отпускания кнопки, с чем мой модуль гарантированно справляется без ложных срабатываний. Можно конечно слегка изменить логику работы, чтобы было как у вас. Но это не приведет к каким либо улучшениям работы модуля, лишь потребует дополнительных ресурсов в ПЛИС.

[DASM 0]

2 minutes ago, Flip-fl0p said:

Латентность должен обеспечивать не модуль антидребезга, а дальнейшая логика проекта. Словил факт нажатия кнопки --> сделал необходимую задержку --> начал работать. Задача антидребезга обработать факт нажатия\отпускания кнопки, с чем мой модуль гарантированно справляется без ложных срабатываний. Можно конечно слегка изменить логику работы, чтобы было как у вас. Но это не приведет к каким либо улучшениям работы модуля, лишь потребует дополнительных ресурсов в ПЛИС.

ну не знаю чего там обнуление счетчика потребляет, ну да ладно, проехали.

[Мур 1]

Оказалось очень удобный  трюк!     Реализация концепции  насыщения.

Написано под впечатлением интернет-замечаний об удобстве нелинейного подхода в линейных трактах обработки(с помехами).

SATUR004_ADD.qar SATUR004_SUB.qar

[Мур 1]

On 2/9/2021 at 2:04 PM, Мур said:

Оказалось очень удобный  трюк!     Реализация концепции  насыщения.

Извините. Но практика показала ошибочность варианта. Я исправил его и выставляю результат.

Архив для Q11.1

SATUR_tb.vhd RND.vhd SATUR.vhd SATUR005_SUB.qar

[Мур 1]

Делюсь отлаженным решением по реализации  CRC8.  В архиве под Q18.0 есть тестбенч.

 

CRC8Dallas_full.qar

[Мур 1]

Замучила метастабильность по данным? 

...Есть вариант лечения, который обеспечит принудительную запись нужного кода. Запись через разрешение по отличию входа от выхода.   Трюк.

 

rg_ch.vhd