обработка клавиатуры?

[nocturnus]

Может, пригодиться... Клава 4х4. Висит на одном порту
Правда под PIC18F4520. Процедура вызывается как угодно раз в 10 мс.

void	KeyScan(void){
	int8	i;
	output_b(0);	//clear latch of B
	//read keys
	for(i=0;i‹4;i++){
		set_tris_b(0xff^(0x01‹‹i));	//select row
		delay_us(10);	//wait
		keyRows[i]=input_b()&0xf0;			//read port
	};
	set_tris_b(0xff); //direction - input
	//combine
	keyPort=make16((keyRows[0]|swap(keyRows[1])),(keyRows[2]|swap(keyRows[3])));
	//debounce
	if(keyPort^keyPrev)	debTimer=0;	//if state change -reset timer
	keyPrev=keyPort;		//store state
	if(debTimer›19){		//if debounced
		keyPrev=0;
		if((keyPort^0xffff)!=0){
			ScanCode=keyPort^0xffff;
			};			// if key pressed - store inversed
		}else	debTimer++;	//else inc
}

Sorry, 1 раз в 2,5мс

[maxNTF]

urry не поможеш в моем вопросе? Там я весь прект выложил. Я уже как не пробую не работает?
https://kazus.ru/forum/topics/8836.html

[rremix]

В предыдущем сообщении была ссылка на топик
https://kazus.ru/forum/topic_8574-0-asc-0.html

По костям разобрана моя процедура обработки клавы с подавлением дребезга и обраотчиками событий Press, Release, Hold. Константами настраиваются задержки и подавление дребезга. CERGEI1982 привел это в удобоваримый код проекта, за что ему "респект и уважуха" (с) Павел Воля ))
Все на асме, но учитывая законченность модуля несложно подключить к C. Модифицируется под любое количество кнопок и любую разводку.
Процедура тестировалась на клаве (жаль, нет ее больше живьем и фото не сделал) выполненной по след. конструкции: две площадки на текстолите, к одной из которых припаяна медная пластинка. При нажатии она касалась другой площадки, замыкая контакт. От окисла никто не защищался. Дребезг... сами понимаете. При этих условиях процедура показала 100%-ю работоспособность (т.е. мне не удалось добиться сбоя).

[maxNTF]

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

[area_51a]

Сообщение от urry

А что, основной цикл микроконтроллера - 10 секунд занимает ? Выделяете время в основном цикле на опрос, затем - когда удобно - анализируете состояние и обрабатываете. Время в основном цикле, выведенное под другие задачи, можно использовать как константу задержки для подавления дребезга. Еще вариант http://www.remexpert.com/forum/viewt...er=asc&start=0

Совершенно согласен с данным утверждением. Таймер же дергает задачу сколько-то раз в секунду (смена скан-кода). Вот в это время и производить опрос. По крайней мере у меня так. Дребезг давится проверкой на отпускание нажатой клавиши. Так же без труда можно добавить таймер времени нажатия если нужно. Мне было без надобности - по-этому я в своей разработке его не учитывал.

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

WaitQuake:
sbic pinb, 4
rjmp WaitQuake
ret

[zelen536]

Гораздо лучше фильтровать дребезг кнопок (контактов, реле и т. д.) скользящим средним, т. е. ставим таймер на, скажем (3-30)мксек. и опрашиваем прерыванием таймера клаву: в цикле (0) входные данные храним во временном массиве (z0_), в цикле (1) опрашиваем клаву в массив (z1_) и сравниваем массивы - если не равно хотя бы одно значение - обнуляем счетчик циклов, если равны, то идем на цикл (2) опрашивать клаву в массив (z0_) или (z1_) (после второго цикла значения в массивах (z0_) и (z1_) ведь равны) и сравниваем опять два массива - если равны, то дребезга (10-100)мксек не было и сохраняем данные клавы в массиве (zz_) с которым и работает основная программа, если не равны - опять обнуляем счетчик циклов, а в массив (zz_) ничего не пишем, оставляем "старые истинные" значения. Время опроса можно регулировать. Если после всей процедуры сравнивать "новые" значения клавы (массив (z0_) и "старые" из массива (zz_) и при их несовпадении выставлять назначенный бит-флаг, то основная прога может опрашивая только этот бит-флаг определять наличие изменений на клаве, если же изменений на клаве нет - основная прога пропускает блок "реакции" на клаву до изменения бит-флага - пусть проц поспит или чем-то другим займется.
В AlgorithmBuilder это блок, вызываемый в векторе прерывания таймера выглядит так (кому нужно на Си - могу выставить, но по этому алгоритму не трудно и самому написать, ведь процы у всех разные). Опрос со скользящим средним считаю предпочтительным, чем опрос нажатия-отпускания клавиши. Данный опрос применяю и в автоматике для ответственных приложений, проходящих приемку ПЗ (кто знает ПЗ - понял о чем речь).

-- Прилагается рисунок: --

[nokazus]

Сколько людей - столько и мнений. Суть одна - подавить дребезг. А решать надо исходя из конкретной задачи. В одном случае нужно фиксировать время удержания клавиши. В другом - еще и двойное нажатие. В третьем - клавиатура выдает длительный дребезг. В четвертом - алгоритм построен по жесткому временному циклу и нельзя отвлекаться на прерывания. В пятом наоборот - алгоритм не имеет четкого временного цикла и удобней использовать прерывания по таймеру.... Поэтому каждый решает по своему. Выложить свои идеи - очень благородно. Каждый может узнать что-то полезное и сделать выводы. А навязывать свой метод и говорить, что он самый лучший - нескромно.
Удачи.
PS Может кто-то захочет меня упрекнуть, что мол сам-то ничего не выложил. Так не вижу необходимости. Автор ведь понял, что причина в дребезге, а разбираться в моих писанинах кому охота?

[smg123]

В AlgorithmBuilder это блок, вызываемый в векторе прерывания таймера выглядит так

Выложите, please, файл проекта АВ.

[zelen536]

Ник. smg123:

Выложите, please, файл проекта АВ.

Какой файл проекта? Я же выложил кусок из проекта в АВ в верхнем посте опроса клавы и фильтрации дребезга. Если этого мало - выкладываю весь проект - это рабочая "болванка" большого проекта, только в АВ есть ошибка (давно Громова прошу исправить, че-то он тормозит с ней и отделывается полумерами) - если переменная с адресом вне адресного пространства внутреннего ОЗУ (во внешней "памяти") но стек мы ставим именно во внутреннем ОЗУ, то компилируется и работает в железе все нормально, но в симуляторе невозможно выйти на вектор прерывания. Единственный способ нормально просимулировать - выставить границу стека на конец внешней памяти (для ATmega64 $FFFF) и тогда все в норме, но не забыть при записи на кристал вернуть SP на $10FF и снова прокомпилировать. Введеный Громовым после моих обращений пару лет назад параметр отключаемый "Автоопределение границы стека" плохо работает особенно когда подпрограмма вектора прерывания находится не на "главном" листе проетка АВ. К чему я все это - кто возмет мой пример - симулируйте его с SP = $FFFF. Выставляю два проекта, в одном (Morda.rar) опрос с клавы 8х8 = 64 кнопки, в другом (Kontroller.rar) - опрос ПЛИС-ки (к ней обращение как к шести ячейкам внешней памяти - ясно, что там никакой внешний стек не пляшет) на 48 входов (на нее приходят сигналы от пускателей, реле и всяких других "грязных" фиговин) - в обоих реализована фильтрация дребезга тройным опросом в прерываниях таймера. АВ берите 5.__ серий, в 4.__ проекты не откроются.

Прикрепленный файл: 3143878.rar