Подпрограмма обработки энкодера на ассемблере Опции

[Игoрь]

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

[Игoрь]

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

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

[Abell]

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

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