Это для экономии переменных в случае нескольких кнопок. Представь, к примеру, 3-х байтный массив. Каждый разряд которого будет счётчиком на 8. Таких счётчиков будет максимум 8. Для горизонтальных, при 8-ми кнопках, понадобилось бы 8 байт. Но считали бы они до 255.

Не совсем понятно И к сожалению почитать про вертикальные счётчики ничего не нашёл
И вообще, это про ASM?

иначе:
дело опять движется к холивару есть ли в ASM-е переменные

я правильно понял, что на 8 счетчиков занято 3 регистра, в первом побитно хранятся 1 (0е биты) всех счётчиков, во втором - 2 (1е биты), в третьем 4 (2е биты).
и если мне надо узнать сколько в 3м счетчике, то мне нужно из всех 3х регистров достать 3й бит и собрать из него значение, расположив эти биты по порядку...

допустим регистры (или память) таким методом мы сэкономим... но расчётов сколько...?

не проще было запихать по 2 счётчика в байт - да, израсходовалось бы на регистр больше, но работать было бы намного проще...

Добавлено after 8 minutes 50 seconds:
я предпочитаю сквозной счётчик (баловаться так бальваться терминами ) он один на всю клавиатуру и сбрасывается при изменении состояния любой кнопки, а как дотикал до нужного значения - дребезг кончился, можно опросить кнопки.

поддерживаю
тоже напридумываю терминов)) и буду тут завуалированно изъясняться

Добавлено after 8 minutes 37 seconds:
и...
вы можете со мной сколько угодно не соглашаться, но паралельный счётчик в диагональной проекции намного эффективнее всего выше приведённого))

Мужики. Ко мне какие вопросы? Человек спросил - я ответил. Не я же их придумал. https://embedders.org/blog/gdi/debouncing.html - для тех кто не может найти.
ВО! Значит, мыслим одинаково.)

понятно теперь. это чисто сишные приёмы.

Добавлено after 8 minutes 26 seconds:
в асме всего 2 варианта (если не ошибаюсь) - тикать в аппаратном таймере или тикать в программном цикле.
(в слове "тикать" - ударение на 1-й слог)

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

Не знаю, кому плюсик ставить? - поставлю обоим! Метод интересный.

shonty, Так у Paktok-а на вертикальных счетчиках не переменные. Там расход регистров большой
[шутка]Интересно, если взять планарный датчик, расход регистров уменьшится?[/шутка]

Вообще, антидребезг такая интересная штука... Я применяю 2 подхода.
1. Кольцевой массив. Каждый интервал времени в ячейку массива с индексом i читается состояние кнопки/кнопок. Потом индекс увеличивается (если выходит за пределы массива - то обнуляется).
После каждого чтения сравниваются между собой все элементы массива. Если все одинаковы - значит состояние кнопок устаканилось - и можно анализировать полученные данные.
Метод хорош, когда интервал чтения позволяет устранить дребезг за N чтений и это N меньше числа кнопок.
2. "Гистерезисный" счетчик.
Для каждой кнопки выделяется 1 байт. Старший бит - флаг нажатой кнопки. Младшие 7 - счетчик.
Обработчик дребезга вызывается с определенной периодичностью. В обработчик передается физическое состояние кнопки и ссылка на счетчик.
В обработчике старший бит выделяется во временную переменную флага, в счетчике бит временно обнуляется.
Далее, если физическая кнопка нажата - смотрим, если значение счетчика меньше заданного предела, то увеличиваем его. Если значение достигло заданного предела - смотрим, если флаг во временной переменной не поднят - генерируем событие нажатия кнопки. Потом поднимаем флаг во временной переменной.
Если физическая кнопка не нажата, то смотрим - если счетчик больше нуля - уменьшаем его. Если после уменьшения счетчик стал нулевой, смотрим - если флаг во временной переменной поднят - генерируем событие отпускания кнопки. Потом сбрасываем флаг временной переменной.
Далее новое значение флага объединияется со счетчиком и всё. На выходе обработчик отдает три значения - ничего не произошло, кнопку нажали, кнопку отпустили.

Добавлено after 10 minutes 35 seconds:
упс. Пока ответ писала - отвлекли. И пока написала - тут уже целый диспут ))))

тоже раньше использовал "кольцевой буфер на 8 элементов" = переменную Х типа статик чар
алгоритм:
сдвигаем содержимое переменной Х влево;
заносим в младший бит состояние кнопки;
проветяем результат(Х==...
0х00 - кнопка отпущена состояние (или нажата, смотря как подключена)
0х80 - кнопка отпущена событие
0хFF - кнопка нажата состояние
0х7F - кнопка нажата событие
)

потом делал типа гистерезисной: если кнопка нажата счётчик прирастал, иначе - уменьшался причем если уменьшался и был больше половины ёмкости переменной, то уменьшался до середины ёмкости, если меньше, но не равен 1, то уменьшался на 1.
с увеличением так-же, но в дтугую сторону.
если счётчик ==0 - кнопка деактивирована (например не отработано её событие или состояние программы неподходящее).
такой счётчик длиннее предыдущего и позволял отличать короткие нажатия от длинных и от удержания кнопки (в зависимости от требований просто вносились дополнительные условия проверяющие состояние кнопки и содержимое счётчика, дополнительных флагов не требовалось, просто условие по счётчику было жёстким и выполнялось только 1 раз за нажатие - дальше счётчик уходил с этого значения и событие больше не генерировалось)

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

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

Счетчики какие-то... По-моему, бред. Тупое считывание каждые 50 мс состояния хоть 8, хоть 16, хоть 32 бит-кнопок гарантирует отсутствие ложных (из-за дребезга) срабатываний, при единственном условии: нажатие длится не менее этих 50 мс, что для кнопок однозначно соблюдается.

Добавлено after 1 minute 52 seconds:
Хотя лично я зря не жоплюсь и считываю раз в 100 мс, и уже лет пять, как ни разу не пожалел об этом. А поначалу тоже всякие интервалы защитные соблюдал... Как вспомню, так вздрогну

Это если кнопки большие - пускатели там и т.п. Тогда и 200 можно. И ни о чём не жалеть.)

Можно с другого ракурса на вопрос взглянуть: дребезг же из ниоткуда не берётся
Если возник дребезг - значит было нажатие на кнопку.
И напрашивается вопрос: а стОит ли ждать, пока эти переходные процессы в кнопке устаканятся?

Добавлено after 4 minutes 33 seconds:
ps: я опрос порта по максимуму использую, а задержку ставлю перед возвращением из процедуры. Чисто по тактильным ощущениям подбираю.

Добавлено after 3 minutes 13 seconds:
что бы серийного срабатывания не было.

Любые кнопки, как органы управления человеком. Или вы Брюс Ли и можете кнопку нажать на 10 мс и каждые 20 мс?!

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

Описывать всякие алгоритмы можно до бесконечности..
Попробую проиллюстрировать как у меня..
Скачал график дребезга и дорисовал в ГИМП ход обработки нажатия (интервалы примерные):



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

Добавлено after 8 minutes 5 seconds:
Если по нажатию кнопки просто диодом моргнуть, то тут да, диод изморгается, но и то это можно скомпенсировать постзадержкой, или интервал опроса увеличить (как ARV писал)
А если выполнять какие либо более серьёзныне действия, то они перекроют весь дребезг + постзадержка по вкусу.

shonty, А если это помеха? Или кто то попой сел на клавиатуру? Какая кнопка опросилась или успела нажаться первой - та и обрабатывается?
Я, кроме дребезга, в обработке кнопок исключаю мультинажатия, если они не предусмотрены функционалом.

ввести captcha для подтверждения, что это пользователь, а не его (или чья-то) задница или помехи.

Ну не знаю
У меня опрос с минимальным интервалом. Поэтому мультинажатие от попы исключено

А так да.. пришлось бы ещё и дребезг попы обрабатывать))

Добавлено after 6 minutes 45 seconds:
Если серьёзно, то по поводу мультинажатия согласен.., только если оно предусмотрено, то обрабатывать нужно.
Но при минимальном интервале опроса одновременно 2 кнопки нажать.. это невероятно