Опрос кнопок микроконтроллером

[Jack_A]

Со 100 Ом я малость промахнулся, тут тоже килоомы нужны. Зависит от емкости - больше время дребезга = больше емкость. А чего кнопке подгорать - она же не кондер напрямую разряжает, а через резистор. Абсолютно рабочий режим - доли миллиампера. Как правильно заметили, если кнопка дребезжит сотни мс, то ну ее в дупу. Схема рабочая. А если программно - тоже не надо 7 пядей во лбу, делается на раз.

[B@R5uk]

Со 100 Ом я малость промахнулся

Да нет, как раз чем быстрее разрядится конденсатор, тем лучше. В последнем посте на предыдущей странице я этот случай тоже расписал.

Однако, скорость разряда — это не самое критичное. Главное, чтобы предельное напряжение зарядки конденсатора было как можно ближе к верхнему напряжению гистерезиса, но всё же больше него. Тогда можно гасить очень длинный дребезг разумными емкостями. Однако, приближаясь рискуем не попасть в срабатывание.

[Alexeyslav]

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

Пожалуй, с триггером с величиной гистерезиса в 4В при 5В питании можно и реализовать подавление дребезга... но программное решение лучше - не нужны лишние детали.

[Gudd-Head]

Вот и я вас теперь "заебу одним аккордом"©, надеюсь поможете советами Сомнительные места пометил (цифрами).

Делаю менюшку с "джойстиком", нужен антидребезг. Как я это вижу:
— сканируем кнопки (побитово, т.к. разбросаны по разным портам). (1) Задержка между кругом сканирования нужна? Т.е. опросили 1-ю, 2-ю, 3-ю, 4-ю и сразу на снова 1-ю...4-ю, или подождать милисекунд... 10?
— после нажатия кнопки отрисовываем меню, по времени это 11 мс;
— (2) подождать несколько мс (дребезг при нажатии)?
— сканировать кнопки, ждать когда они ВСЕ будут отжаты (т.к. неизвестно какая была нажата);
— подождать 20 мс (дребезг при отпускании);
— начинаем всё сначала (сканируем кнопки).

[shads]

Вот и я вас теперь.....

Зря мешаешь кашу из разных задач (формирования меню и опроса кнопок)... Проще разделить задачи..

Сначала разбираешься с опросом кнопок... т.е. нужна библиотека обработки кнопок (в предыдущ моем посте ссылка), функция которой возвращает код кнопки после ее нажатия...
Мы крутимся в цикле (в нем же обрабатываем и другие текущие задачи) и постоянно опрашиваем функцию BtnGet()
Если кнопки не нажимались, то она возвращает 0, если кнопка была нажата, то возвращает код кнопки...

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

[Alexeyslav]

Читай все кнопки сразу, если это делать с интервалом не менее 10мс то никакой дребезг не страшен.
Главное условие - каждую кнопку за цикл опроса считать нужно только один раз. Будешь ли ты это делать по таймеру или до/после отрисовки меню - совершенно не важно, главное соблюсти условие что повторное считывание состояния кнопок производить не раньше 10мс.

[Paguo-86PK]

Повесить по счётчику на каждую кнопку. И считывать не биты состояния кнопок, а насчитанные величины счётчиков.

[B@R5uk]

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

[Gudd-Head]

Эээ, не... мне бы попроще, быдлокодом... Без "библиотек обработки кнопок" и "уровней абстракции".
Я спрашивал конкретно по моему алгоритму, где какие задержки нужны и как лучше бороться с дребезгом.

[Paguo-86PK]

Кстати, хотел спросить.
Были первые мышки некогда с механическим энкодером (вместо оптопар - лепестки контактов) и одну я на рынке нашёл, но дохлую...
Идея одна была: Напаять четыре TCXO одинаковой частоты вместо энкодеров: По два TCXO на ось...

Зачем? Статья интересная и хотел схему собрать с передачей данных на компьютер с минимальными затратами (легче же в мышь напаять кварцы, чем городить кучу микросхем).
Однако, ни одного TCXO не нашёл на рынке (есть 2 на EGA-карточке и 1 на i386 материнке. но губить рабочее железо?) и заказать через интернет не удалось. Да и мышек с механическими энкодерами сейчас уже не найдёшь под ногами...

Поэтому, чтобы снизить уровень неудовлетворённого любопытства, спрашиваю здесь: Что было бы?

Чтобы не быть голословным, испытал 11 лет назад схему на ИЕ17.
Суть простая: На вход реверса счёта подаём меандр с генератора одной частоты, а счёт тактируем генератором другой частоты. И стробируем регистр показания счётчика с выводом на индикацию.
Схему насобачил зимой 2005. Так, ИЕ17 хорошо прогревался от такого режима работы. При хорошей настройке частот, когда скважности выстраивались в нужной гармоннике, на индикаторе была устойчивая линия.
А вот от индукционных искр и трубки радиотелефона линия смещалась или размазывалась по всей матрице.
Однако, реакций на "пирамидки" не было. Разработал и печатную плату, но так и не продырявил...

Так вот. По сути, при движении мыши энкодеры выдают нечто подобное "00, 01, 11, 10" и "10, 11, 01, 00", т.е. импульсы сдвинуты на 90°. Теоретически, тактирование TCXO могло бы управлять направлением движения указателя курсора в плоскости и визуализировать некий график специальной программой.
Однако, подвёл хай-тек: Механические мыши - раритет, а TCXO - не найти (у нас в регионе).

[Барсик]

Для обработки нажатия кнопок я использую следующий быдлоалгоритм:
1. Настраиваем прерывание от таймера, чтобы оно просходило каждую миллисекунду. Заоодно получаются системные часы.
2. Внутри прерывания считываем состояние кнопок. В зависимости от состояния получается некое число или ноль, если ни одна кнопка не нажата. Это число будем считать номером нажатой кнопки. Надо прверить в течение какого времени это число (т.е. состояние кнопок) стабильно. Для этого устанавливаем счётчик времени, сколько миллисекунд должно длиться стабильное состояние.
3. Внутри каждого прерывания считываем номер нажатой кнопки и сравниваем его со старым значением из предыдущего прерывания. Если номера совпадают, то уменьшаем счётчик времени на единичку. Если не совпадают, то устанавливаем счётчик времени заново. Проверяем счётчик времени. Если он дотикал до нуля, то состояние кнопок стабильно. Запоминаем номер кнопки, и устанавливаем флаг, что кнопка нажата и требует обработки.
4. В основной программе, в главном цикле, считываем номер кнопки и флаг. Если номер кнопки не равен нулю (что-то нажато), то проверяем флаг - была ли уже обработана кнопка или нет. Если кнопка уже была обработана или номер кнопки равен нулю, то ничего не делаем. Если кнопка не была обработана, то в зависимости от номера кнопки, вызываем подпрограмму, которая обрабатывает эту кнопку. Поле возврата из подпрограммы, устанавливаем флаг, что кнопка обработана.
Отрывки быдлокода в присоединённом файле.

[Alexeyslav]

Слишком сложно. Достаточно насчитать 10 таких прерываний и просто зафиксировать состояние кнопок.

[Барсик]

Достаточно насчитать 10 таких прерываний...

А подробнее можно? От какого момента начинать считать?

[Psych]

По идее прерывание просто так не сработает, по этому гарантированное нажатие ловить не следует.
1) Сработало прерывание от порта, запоминаем какая нога, запускаем таймер, запрещаем прерывания порта, присваеваем глобал варибал(interrupt)
1.5) опрос где-то в фунции переменной и выполнение чего-то, сброс перменной
2) В таймере опрашиваем состояние порта по маске; что-то нажато? сброс счетчика, ниче не нажато? инкремент счетчика(interrupt)
2a) Дошли до кондиции? остановили таймер, разрешили прерывание порта(interrupt)

Хотя было уже наверно

[Gudd-Head]

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

[dosikus]

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

[Gudd-Head]

Почему же?
У меня 2 из 4-х кнопок на прерываниях висят.

[dosikus]

Почему же?

Ради бога, сей интерфейс для обработки IRQ внешней периферии, но никак не дребезжащей кнопки .
Но вам можно, помните анектод ?

[Alexeyslav]

С любого момента. каждое 10-е прерывание - тупо запоминаем состояние портов с кнопками и всё. больше ничего делать не надо. Дребезг уже не страшен. Максимум что может сделать дребезг - отложить момент регистрации нажатия на один цикл опроса, т.е. на 10мс.
С интервалом в 1мс можно только герконы опрашивать.

[Psych]

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

ЧТо???? Моветон?????
Извините конечно. Но не согласен. По перепаду уровней именно в большинстве случаев для кнопок имхо.