Перейти к содержанию
    

Динамический опрос клавиатуры

1 hour ago, Evgeny said:

Я планирую сразу же запрещать внешнее прерывание и запускать счетчик. А уж после того, как дребезг пройдет и опрос клавиш проведен, разрешать его вновь. Так тоже некорректно будет? 

Нет, за "корректность" сказать ничего не могу, тк для этого надо как минимум хорошо знать как работает система прерываний в конкретном контроллере. Это получается "событийность" на аппаратном уровне (сигнал воздействия на клавиатуру). Для уменьшения хлопот и повышения надежности имеет смысл аппаратно подавить или уменьшить дребезг на линии входа прерывания. Подавление дребезга от контакта - функция "задержка включения", реализуется одновибратором. Или даже RC цепью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, Evgeny сказал:

Я планирую сразу же запрещать внешнее прерывание и запускать счетчик. А уж после того, как дребезг пройдет и опрос клавиш проведен, разрешать его вновь. Так тоже некорректно будет? 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

42 минуты назад, jcxz сказал:

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

У меня изначально почти так и сделано, см. первое сообщение. :smile:

 

Наверное, нужно подробно описать что за девайс я делаю. Это генератор с функцией качания частоты на микре Si570, МК я уже писал какой используется - C8051F310. Ввод частоты я хочу сделать прямой (с клавиатуры) + механический энкодер. Вывод на семисегментный индикатор. Переключение частот при качании + управление ЦАПом для генерации пилы явно нужно делать по прерыванию таймера. Вот я и думаю, что запихивать динамическую индикацию + опрос кнопок + управление синтезатором в обработчик прерывания по таймеру будет не совсем правильно. Наверняка временнЫе интервалы тогда не будут выдерживаться. 

 

Вот мне и нужна помощь с алгоритмом - как грамотно распределить управление всем этих хозяйством. :pardon:

Изменено пользователем Evgeny

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

43 minutes ago, Evgeny said:

. . . Вот я и думаю, что запихивать динамическую индикацию + опрос кнопок + управление синтезатором в обработчик прерывания по таймеру будет не совсем правильно. Наверняка временнЫе интервалы тогда не будут выдерживаться. . . . 

Правило номер один - код обработчика аппаратного прерывания должен быть как можно короче. Все, что "хотелось бы сделать" - выносится в другое место программы (смотря какая структура) и запускается по установленному в обработчике флагу. По завершении - флаг сбрасывается. Не всегда по точно такой схеме, но "в-общем" так.

Хотя есть любители, которые в обработчик вписывают "прикладные" блоки кода, такая себе аппаратная многозадачная ОС.

Если у Вас динамическя индикация, то можно совместить управление засветкой разрядов и выдачу опросных уровней на матрицу клавиатуры. Так делалось в старых специализированных микросхемах (экономятся линии порта и время)

А что может помешать "выдерживать временные интервалы" если базовая частота задана кварцем (?) и используются аппаратные таймеры ?

А main() {} что из себя представляет, можно полюбопытствовать, если конечно это не страшно-зелено-бронированная военная тайна ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 минут назад, k155la3 сказал:

А main() {} что из себя представляет, можно полюбопытствовать, если конечно это не страшно-зелено-бронированная военная тайна ?

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

16 минут назад, k155la3 сказал:

Все, что "хотелось бы сделать" - выносится в другое место программы (смотря какая структура) и запускается по установленному в обработчике флагу.

Да, кажется, я понял свою ошибку. Буду переделывать. Попробую вынести функции в основной цикл.

Спасибо еще раз. И извиняюсь за глупые вопросы. :thank_you2:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 minutes ago, Evgeny said:

. . . Спасибо еще раз. И извиняюсь за глупые вопросы. :thank_you2:

Вопросы IMHO вполне нормальные-логичные. Тем более в этом разделе.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 часа назад, Evgeny сказал:

Вот я и думаю, что запихивать динамическую индикацию + опрос кнопок + управление синтезатором в обработчик прерывания по таймеру будет не совсем правильно.

Отчего-же? Если частоты событий одинаковые или кратные (с небольшой величиной кратности), то вполне нормальное решение. Главное - чтобы предыдущий ISR успел завершиться до возникновения нового прерывания.

Цитата

Наверняка временнЫе интервалы тогда не будут выдерживаться. 

Непонятно - откуда такой вывод.   :unknw:

3 часа назад, k155la3 сказал:

Правило номер один - код обработчика аппаратного прерывания должен быть как можно короче. Все, что "хотелось бы сделать" - выносится в другое место программы

Необязательно. Для ISR главное - чтобы обработка предыдущего события успела завершиться до возникновения нового. И чтобы менее важная и срочная работа не мешала более важной и срочной (разделение задач по приоритетам).

Если это выполняется, то хоть вообще весь код в ISR можно засовывать. Давным-давно у меня был коммерческий проект, где вообще почти вся работа производилась в одном единственном периодическом прерывании. А там было: и обслуживание АЦП/ЦАП; и сигнальная обработка: несколько тяжёлых КИХ-фильтров, тяжёлый БИХ-фильтр и много другой сигнальной обработки; и программно-эмулируемый UART (до 115200 бод) - там же. В некоторых режимах работы устройства, в общей сложности до 30-35% всего процессорного времени DSP выполнение находилось внутри этого гигантского ISR (а может даже больше - точно уже не помню). И ничего - нормально работало и продавалось.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

49 minutes ago, jcxz said:

Необязательно. Для ISR главное - чтобы обработка предыдущего события успела завершиться до возникновения нового. . . .

.... Если это выполняется, то хоть вообще весь код в ISR можно засовывать. . . .

Не спорю. Это вопрос (высокого) уровня-квалификации и предпочтений. Для начинающих лучше "начинать" с минимального кол-ва кода в ISR IMHO.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, Evgeny сказал:

Да, кажется, я понял свою ошибку. Буду переделывать. Попробую вынести функции в основной цикл.

Если не поздно, то схемотехнику переделайте, как Вам советовали: RC-цепочка, триггер Шмитта и т.д.

Эта мера улучшит работу клавиатуры и у упростит код. Прерывание INT0 - это серьёзная встряска для MC51.

А я бы всё-таки посоветовал не прибегать к прерываниям по такому пустяку в таком простом устройстве.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот материал от Ti - клавиатура с режимом экономии энергии, с использованием аппаратного прерывания (общее описание + блок-схема алг-ма).

Low Power Hex Keypad Using MSP430   slaa773  (код по линку, там много примеров кроме клавиатуры)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 часов назад, k155la3 сказал:

материал от Ti - клавиатура с режимом экономии энергии

Да, с английским дружу. Изучу материал. 

Правда, мне попадался подобный, только более "дубовый" метод от Cypress. https://www.infineon.com/dgdl/Infineon-AN2034_PSoC_1_Reading_Matrix_and_Common_Bus_Keypads-ApplicationNotes-v07_00-EN.pdf?fileId=8ac78c8c7cdc391c017d073254b85689

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Клавиатура по прерываниям - это глупость. Ну если только нужно выходить из спящего режима.
По моему уже говорили. В прерывании (или без) получаем системный тик, по которому в лупе синхронизируем опрос клавиатуры. Так получается красиво, лаконично и без побочек (от дребезга). В т.ч. и длинные нажатия, автоповтор и пр.

On 5/31/2022 at 10:13 PM, byRAM said:

Если не поздно, то схемотехнику переделайте, как Вам советовали: RC-цепочка, триггер Шмитта и т.д.

К чему этот огород? Зачем платить больше? Вы можете представить себе всё это в ПК клавиатуре?)

Изменено пользователем v05

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

38 минут назад, v05 сказал:

К чему этот огород? Зачем платить больше? Вы можете представить себе всё это в ПК клавиатуре?)

Какой ещё огород, что вы несёте?

Думаю, что в контроллере клавиатуры ПК на входах триггеры Шмитта. Во всяком случае, ничего не мешает им там быть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну конечно, это я "несу")). Ну КАК контроллер матричной клавиатуры может быть без триггеров Шмитта? И RC-цепочек, КАК? Это нереально! "Профессионал"... Ужос.(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...