Оцените алгоритм опроса матричной клавы

[supercelt]

supercelt, может посмотрите это решение на досуге?
В МК останется только код для инициализации, обработки прерывания и считывания результата. И ног гораздо меньше отнимет - всего 4.
А там уже и защита от дребезга, и все остальные плюшки .
Просто время, уже потраченное на изобретение велосипеда, явно гораздо дороже стоит чем комплект разработчика с мешочком чипов по ссылке…

Спасибо за ссылку, но у меня схем уже спаяна. И что либо менять уже нельзя. Только шаманить с кодом

[akegor]

Только шаманить с кодом

И такой вариант есть.
Столбцы - исходно все нули. Строки - прерывания. По прерыванию короткий опрос состояния клавы. Дребезг? Танивапрос. Повторный опрос, скажем, через 50 мс.

[supercelt]

понизил частоту камня до 24 мгц, как у прошлого чипа. Все-равно не пашет. Код такой же, частота уже такая же.... в чём же разница...

[estet]

supercelt, правильный вариант уже был назван

В вашем случае:
Считывайте значение по установленному в предыдущем такте таймера ряду, а затем меняйте его. Задержка будет не нужна

[supercelt]

supercelt, правильный вариант уже был назван

То есть я правильно понял что это будет выглядеть так:
for(прогон строк){
-устанавливаем 0 на 1 строке
-это первый прогон, поэтому не сканим колонки (выход из цикла)
for(скан колонок){
считываем биты с порта для первой строки, хотя по циклу прогона строк это уже вторая строка
}
}

П.С. Мне все-таки интересно, как такое может быть что условия одинаковые, просто разные чипы. И на одном пашет, на другом нет(

[mike-y-k]

supercelt, рогатый в мелочах кроется Тут уже только проверять весь полученный код в машинных командах в двух Ваших вариантах. Тут и интеллект компилятора, и умолчания, и разница в опциях,…

Кстати для 4x4 проще 4 раза вызвать функцию с параметром индекс порта и возвратом 4 бит состояния кнопок.

Отказ от гарантированного решения из-за копеечной по сути экономии на переделке - путь к будущим проблемам с клавиатурой.
У Вас наверняка пункт с нормальным тестированием отсутствует…

[H4LF]

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

[supercelt]

H4LF, да работало! Спасибо, прочитаю документ

[H4LF]

supercelt, Извиняюсь, не так спросил. Я не сомневаюсь, что работало, я хотел узнать - оптимизация была выключена при этом? Потому что со включенной не должно бы работать. Ну и так, на будущее...

[МВА]

как-то сложно всё это...

Я того же мнения. У меня есть вопрос. А может ли быть дребезг, если не трогать кнопки на клаве? Я думаю, что нет. Значит дребезг можно воспринимать как нажатую/отпущенную (в зависимости от того, что делает кнопка при замыкании контактов) кнопку. Если контакт замыкается, то сразу устанавливается нужный уровень, а если размыкается - проводим интегрирование до противоположного уровня.
Я так обычно и поступаю и никаких циклических прогонов не делаю. Интегрирование заменяет задержку, разве-что не тормозит программу.
Этот алгоритм работает хорошо в приборных энкодерах, в которых используется скользящий контакт. Там шум присутствует во всем диапазоне замкнутого контакта и интегрированием в верх и вниз от него так просто не избавится. А в случае этого алгоритма - просто время замкнутого контакта увеличивается на величину дребезга с двух сторон и величину интегрирования в момент размыкания.