Комментарии 22
Нет большой проблемы в том, что прерывание срабатывает по любому изменению уровня (any logical change). В обработчике прерывания всегда можно проверить состояние порта, и определить нужное нам событие. То же самое касается прерывания PCINT, которое одно на все 8 ног. Всегда можно легко узнать, какой именно вход вызвал прерывание.
+3
Что такое 0<<y?
0
ИМХО, нет нужды использовать прерывания для опроса кнопок, за исключением тех случаев, когда клавиатура выводит микроконтроллер из режима сна. Опрос кнопок — это самый некритичный ко времени выполнения процесс, и его всегда можно запихнуть в бекграунд вместе с алгоритмом подавления дребезга контактов.
На сайте Atmel есть замечательные апноуты, которые закрывают абсолютно все вопросы по поводу подключения кнопок к микроконтроллеру — AVR243: Matrix Keyboard Decoder on tinyAVR and megaAVR devices, AVR245: Code Lock with 4x4 Keypad and I2C LCD on a tinyAVR, а также AVR252: TV Control Touch Keyboard (с примерами исходного кода).
"… МК не всегда быстро может реагировать на нажатие кнопки, т.к. проверка PINа стандартно осуществляется в бесконченом цикле и если программа доостаточно большая — это может затормозить опрос ножки… "— справедливо только для быдлокодеров.
На сайте Atmel есть замечательные апноуты, которые закрывают абсолютно все вопросы по поводу подключения кнопок к микроконтроллеру — AVR243: Matrix Keyboard Decoder on tinyAVR and megaAVR devices, AVR245: Code Lock with 4x4 Keypad and I2C LCD on a tinyAVR, а также AVR252: TV Control Touch Keyboard (с примерами исходного кода).
+5
По мне есть вопрос времени в кодинге, можно подстроить сложный код под опрос, тогда действительно получается некритично, но на это надо затратить силы и время, когда как прерывание внешнее, которое уже предусмотрено производителем можно заюзать сразу, зная как оно будет себя вести и код доделывать под опрос не надо, конечно это одна из самых простых задач в программинге МК, но и на этом можно время сэкономить, я же не говорю что это панацея) кому нужно — попробуют.
0
Эх, пунктуация…
0
Не вижу никакой проблемы в скорости реакции на кнопки. Обычно, если МК выполняет более одной задачи, я предпочитаю решение с организацией тасков по таймеру. Опрос клавиатуры, например, можно делать фиксированно каждые 0.25 секунд, тогда с учетом устранения дребезга, опрос будет стабильно раз в 0.5 сек.
+2
Мой скромный опыт подсказывает, что кнопки и прерывания несовместимы (за редким исключением): задержки в прерываниях (тем более в AVR, где нет приоритетов прерываний) идея крайне плохая — по вашей версии кода, после нажатии кнопки в течении секунды никакие другий прерывания обрабатываться не будут, главный цикл программы так же не будет выполнятся. Если активирован watchdog это гарантированно приведет к сбросу МК. Вообще такой подход, кроме как к миганию светодиодом более ни к чему не применим.
Механический конкакт (кнопка) и прерывания — так же плохо. Попробуйте, на досуге посчитать сколько прерываний приходит при нажатии, несколько сотен, минимум. А со временем (при износе кнопки) — на порядок больше
Механический конкакт (кнопка) и прерывания — так же плохо. Попробуйте, на досуге посчитать сколько прерываний приходит при нажатии, несколько сотен, минимум. А со временем (при износе кнопки) — на порядок больше
0
да, но простые программки, где не хочется делать счетчики, легко строются на принципе внешних перерываний, и то что тормозиться основноой цикл и др важные прерывания в основном не так уж и страшно.
0
Можно ездить по встречке, если задом: до определенного момента никто слова не скажет, но ведь неудобно же.
В обработчиках прерываний даже делить целые числа не стоит, не то что специально задержки делать. А обработать состояние пина, даже с антидребезгом проще по-таймеру, или в цикле в main()
Я пытался придумать, хоть одну задачку, где можно использовать ваш способ, но кроме моргнуть светодиодом ничего не придумалось. Подскажите?
В обработчиках прерываний даже делить целые числа не стоит, не то что специально задержки делать. А обработать состояние пина, даже с антидребезгом проще по-таймеру, или в цикле в main()
Я пытался придумать, хоть одну задачку, где можно использовать ваш способ, но кроме моргнуть светодиодом ничего не придумалось. Подскажите?
0
а что мешает после срабатывания прерывания запустить проверу на дребезг? (постоянность принятого сигнала на протяжении скольких-то мс, чтоб не глючило на этот момент запретить это прерываение..)
0
Пока обрабатывается прерывания другие ждут в очереди, приоритетов в AVR нет. Поэтому выходить из прерывания нужно как можно быстрее иначе можно пропустить что-то важное.
Проще опрашивать кнопку по таймеру, если нажата инкрементировать какой-нить счетчик, если отпущена — сбрасывать. Как только счетчик дойдет до какого-то значения — обрабатываем нажатие. Чем плохо?
Проще опрашивать кнопку по таймеру, если нажата инкрементировать какой-нить счетчик, если отпущена — сбрасывать. Как только счетчик дойдет до какого-то значения — обрабатываем нажатие. Чем плохо?
0
Прерывания еще клево использовать для экономии электроэнергии — например, повесить приемную ногу uart на INT и когда пойдут данные то контроллер пробудится и сможет принять данныые. Есть несколько режимов сна, есть те которые позволяют не терять данные в приемном буффере…
0
С описанием настройки в регистре MCUCR вы усложнили. И на чем это вы программу писали (просто я только с ассемблером работал)?
0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Внешние прерывания у 8-bit avr, использование кнопок