Если вдруг у кого есть кусок кода с антидребезгом, поделитесь кому не жалко. Лениво тратить время на исследования задержек по антидребезгу

Если память не изменяет, там все делается без антидребезга, это же не кнопка.
Код есть только на С.

да вот начитался теории, даже рисунки кто-то приводил, как выглядит дребезг на разболтанном энкодере. Пришёл к выводу, что лучше сразу учесть возможность дребезга. К сожалению пишу на ассемблере, код на С мне поможет только если реализован какой-нибудь изящный алгоритм, чтоб взять за образец для перекладки на асм.

Обсуждалось уже, неоднократно. Воспользуйтесь поиском по форуму. В двух словах - реализуется через автомат состояний.


Для механического энкодера подавление дребезга обязательно. Но это реализуется алгоритмически.

попробую пояснить, чего я хочу- мне нужен не алгоритм, мне нужен кусок работающей программы работы с энкодером для того, чтобы я его интегрировал в свой проект (управление LED-драйвером с помощью ШИМ). Никаких сложностей с самостоятельным написанием я не испытываю за исключением того, что это отнимет у меня пару-тройку дней. Возможно несколько больше, с учётом того, что занимаюсь я этим в свободное от работы время. Я просто уверен, что работа с энкодером уже многими вылизана до блеска.

Прекрасно работает без дребезга. Не нужно никакого подавления.

без дребезга при наличии сглаживающих емкостей? Или дребезг не наблюдается и при отсутствии емкостей? А как быть с китайским энкодером, который давно эксплуатируется?

Если через автомат состояния - да, там подавление само собой получается. Если (как иной раз делают) типа D-триггера (один сигнал на строб, другой на данные для определения направления) - то вообще нежизнеспособно.



Дребезг контактов механического энкодера - есть всегда. У старого, у нового - не важно. Он есть. Конкретные значения есть в даташите.

Какая разница?
Дребезг первого контакта заканчивается на срабатывании второго.

Еще когда начинал практически работать с AVR, ввел для себя такое понятие как "доверие к датчику". Т.е. если датчик имеет нереальное состояние, выдает не соответствующие ожидаемым данные или слишком сильно "дребезжит" - "доверие" к нему теряется. Дальше по возможности, или корректный останов программы с индикацией ошибки, или запись в лог/передача ведущему устройству журнала "доверия".
Согласен, сильно избыточно, но поверьте - выйти из строя может все, а такое "высокоинтеллектуальное" устройство, как микроконтроллер, не только может - обязано иметь режимы самодиагностики. Ремонтники потом большое спасибо скажут.

мысль не нова и безусловно интересна. Но на мой взгляд наполняемость устройства различными функциями самодиагностики возможна только в процессе эксплуатации, накоплении опыта по непредвиденным ситуациям и их анализу. На этапе разработки практически невозможно учесть всё. И всегда стоит вопрос, насколько есть необходимость в этой самодиагностике?
Лично я сторонник таких устройств, которые бы железобетонно работали при любых непредвиденных ситуациях безо всяких остановок по малейшему чиху. Кроме того, я сторонник того, чтобы обходиться минимальными средствами для того, чтобы устройство могло выполнять свои функции. Попробую пояснить что я имею в виду.
1. Как я уже писал выше, я просил кусок кода для управления LED-драйвером с помощью ШИМ. Регулировка ШИМ планируется осуществляться от энкодера. Можно было бы для этих целей использовать ATMEGу, просто так на всякий случай, завести кучу цепей для диагностики светодиодов, источника питания, самого драйвера, написать код на С. Я предпочитаю использовать Tiny13A, написать код на ассемблере и держать тиньку большую часть времени в спящем режиме.
2. Следующий пример. Мне по работе достался проект от предыдущего разработчика. Устройство должно формировать определённые запросные импульсные последовательности, принимать ответы на эти запросы, декодировать ответы, проверять их на корректность и передавать в компьютер. Мне были переданы схема, разведённые платы, недописанная программа. Схема как и положено ей быть серьёзная, с ATMEGA256, жирной ПЛИСиной. По сути я дописывал кусок программы, который и должен был осуществлять необходимый функционал с импульсами. Предыдущий разработчик сильно затянул время разработки проекта и в конце концов уволился. Доделывая проект я пришёл к следующим выводам- во-первых программа была перегружена функциями самодиагностики, при этом по требующимся функциям написано было очень мало. Зато самодиагностика в некоторые моменты сама давала сбои. А во-вторых устройство можно было бы сделать значительно более простым. Хватило бы и одного контроллера с меньшим количеством выводов.

Подведу итог. Всё мною написанное говорит о том, что разработчик в первую очередь должен сосредоточиться на тех функциях, которые должно выполнять устройство. Сначала нужно запустить устройство, а потом уже смотреть, есть ли время, возможность и необходимость добавлять дополнительные фичи.

Не мое, точно, с ПЛИС не работаю
По длительному опыту работы с ЧПУ могу сказать - пренебрежение потенциальным отказом энкодера может привести к катастрофе. У поворотных энкодеров есть "запрещенное состояние", в случае которого система должна давать немедленный безусловный "стоп", это еще на уровне электроавтоматики.
В подобной задаче у меня контроллер постоянно пишет в глобальную переменную тайминг сигнала энкодера, по нему определяется скорость и косвенно - состояние энкодера. Хотя, у меня энкодер оптический, там дребезга-то нет
Сделать сначала функционал, а потом самодиагностику - согласен, так и делаю. Только на всем этапе разработки держу в уме, как это сделать, чтоб потом не перелопачивать заново схему и код

Какое отношение к енкодеру имеют последние 3 ответа?

косвенное Раз нет желающих помочь мне с кодом для обработки энкодера, можно и пофлудить немного

А что за запрещённое состояние есть у энкодеров?

Может вместо флуда воспользоваться поиском по помойке и таки найти код, если почитать лень , и самому написать тем более