Идея такая. Нужно управлять устройство содержащее в себе энкодер. Управление будет осуществляться кнопками. Каждое нажатие это щелчок энкодера. В общем нужно в место энкодера сделать управление кнопками.
Неплохая идея.
2 лайка
Нет, мне кажется идея плохая.
Спасибо, это очень важное уточнение.
Это что, еще не пересдал? 0_о
Они еще и тему сюда перенесли.
или вовсе не задал никакого вопроса
1 лайк
Научиться программировать красиво и реализовать. Красиво.
2 лайка
И где решение?
Вывод: здесь данной теме самое место.
***************************************
//Мо лодец
***************************************
5 лайков
А кому может пригодиться скетч, который делает неизвестно что?
Единственное, что можно сказать о скетче, что он:
- блокирующий,
- не структурный,
- не допускающий расширения,
- не документированный.
А скетчей, которые демонстрируют, как не нужно программировать, в И-нете и так море.
1 лайк
В некоторой части Вы, сэр, неправы - в данном конкретном случае программа должна быть блокирующей.
Разве?
Поясните эту мысль.
Дык это-ж хуман интерфейс. А люди тормозят и блокируются. Покрутите энкодер и поймёте как это работает.
Люди - де…мо на блюде! 
Драйвер энкодера должен быть неблокирующим, конечно, если железо позволяет.
Граф, уточните Вашу мысль. Мне кажется, что 2 щелчка в одну или другую сторону ДОЛЖНЫ быть блокируемые. Так устроен HID. Человек несовершенен в отличие от Бендера.
1 лайк
Вы уже в третий раз пишете, что “должны”, но так и не пояснили, по какой причине.
Для того, чтобы что-то понять, совершенно необязательно крутить.
И еще: обычно я обрабатываю энкодер в аппаратных прерываниях. Объясните мне, как Вы представляете себе блокирующие функции в прерывании.
Механически. По реальной возможной скорости вращения.
Медленно работающая механика не должна тормозить выполнение грамотно написанной программы.
В конце концов, у программы могут быть и другие задачи кроме обслуживания тормозной механики.
На своем месте мне гораздо лучше пить самогон, чем помогать.
Помощь - продукт свободного волеизъявления. Вот! 