Я смотрю, последнее время популярны истории, в которых авторы ставят знак равенства между множествами «почти всегда это так» и «изредка это так», например, вольно сравнивая undo для IT и не IT. Что же, проблема эта известная и широко распространённая. Расскажу и я свою историю.
Коллеги-разработчики! Мы часто ноем, сталкиваясь с чужими багами и «особенностями дизайна», с проблемами, уходящими корнями вглубь. Порой, в настройке софта или в организации библиотеки/фреймворка нет никакой видимой логики или глубокой задумки — просто автору так захотелось, потом захотелось другому автору, потом третьему, и вот этот мутный франкенштейн коллективного творчества предстаёт перед нами с прилагающейся к нему шестисотстраничной документацией, забитой исключениями, отступлениями от POSIX и удивительно корявыми решениями. Их невозможно понять, их надо просто запомнить. И потом, через полгода, троллить новичков, решая «элементарные» проблемы. Но всё равно стресс копился, копилось раздражение, и тогда по совету коллеги я занялся микроэлектроникой в качестве хобби.
Карл, даже обычная кнопка оказалась проблемной. Вместо одного события нажатия прилетает десяток по прерываниям! Дебаунсинг, Карл! Хуже того — в простой кнопке нет состояния 0/1, там есть или что-то (например, 1, если цепь замыкается на +3,3 В) и floating, который определяется то как 0, то как 1. Это решается лишь чисто механически.
Разобрался с кнопкой? Призовая игра — rotary encoder (например, колёсико мышки), который шлёт несколько событий, позволяющих определить, в какую сторону он вращается. Из-за того же баунсинга зачастую приходят противоречивые сигналы. Типа, сперва +1 и тут же