Внешние прерывания у 8-bit avr, использование кнопок

[Ocelot]

Нет большой проблемы в том, что прерывание срабатывает по любому изменению уровня (any logical change). В обработчике прерывания всегда можно проверить состояние порта, и определить нужное нам событие. То же самое касается прерывания PCINT, которое одно на все 8 ног. Всегда можно легко узнать, какой именно вход вызвал прерывание.

[VRV]

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

[ploop]

Зато в более новых сериях 48/88/168 — есть.

Если не ошибаюсь, тини2313 тоже моложе меги8

[VRV]

Действительно щас залез в даташиты… PCINT у 48/88 на все ножки) и прерываний на них всех не одно, а 4 =)

[Warlock2]

а как узнать какой вход вызвал прерывание?
как узнать состояние порта?

[kmeaw]

Что такое 0<<y?

[VRV]

т.к. порты у МК могут быть разными я взял их за переменные X-название порта, Y- его номер. Если что-то непонятно, то винзу есть примеры рабочего кода.

[Ocelot]

Вот это:

DDRxy |= (0<<y);

не изменит значения DDR. Если нужно сбросить разряд в ноль, делают

DDRxy &= ~(1<<y);

[VRV]

эм..=) ты прав, но я как бы не сбрасывал, а показывал состояние порта которое должно быть, оно и так по дефолту нулю равно, ща подумаю как бы поточнее описать и переделаю начало.

[Ocelot]

Описать состояние разряда можно так:

DDRxy & (1<<y) == 1;
или
DDRxy & (1<<y) == 0;

[Derailed]

ИМХО, нет нужды использовать прерывания для опроса кнопок, за исключением тех случаев, когда клавиатура выводит микроконтроллер из режима сна. Опрос кнопок — это самый некритичный ко времени выполнения процесс, и его всегда можно запихнуть в бекграунд вместе с алгоритмом подавления дребезга контактов.

"… МК не всегда быстро может реагировать на нажатие кнопки, т.к. проверка 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 (с примерами исходного кода).

[VRV]

По мне есть вопрос времени в кодинге, можно подстроить сложный код под опрос, тогда действительно получается некритично, но на это надо затратить силы и время, когда как прерывание внешнее, которое уже предусмотрено производителем можно заюзать сразу, зная как оно будет себя вести и код доделывать под опрос не надо, конечно это одна из самых простых задач в программинге МК, но и на этом можно время сэкономить, я же не говорю что это панацея) кому нужно — попробуют.

[Weageoo]

Эх, пунктуация…

[truepb]

… и опечатки…

[Int_13h]

Не вижу никакой проблемы в скорости реакции на кнопки. Обычно, если МК выполняет более одной задачи, я предпочитаю решение с организацией тасков по таймеру. Опрос клавиатуры, например, можно делать фиксированно каждые 0.25 секунд, тогда с учетом устранения дребезга, опрос будет стабильно раз в 0.5 сек.

[bevice]

Мой скромный опыт подсказывает, что кнопки и прерывания несовместимы (за редким исключением): задержки в прерываниях (тем более в AVR, где нет приоритетов прерываний) идея крайне плохая — по вашей версии кода, после нажатии кнопки в течении секунды никакие другий прерывания обрабатываться не будут, главный цикл программы так же не будет выполнятся. Если активирован watchdog это гарантированно приведет к сбросу МК. Вообще такой подход, кроме как к миганию светодиодом более ни к чему не применим.
Механический конкакт (кнопка) и прерывания — так же плохо. Попробуйте, на досуге посчитать сколько прерываний приходит при нажатии, несколько сотен, минимум. А со временем (при износе кнопки) — на порядок больше

[VRV]

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

[bevice]

Можно ездить по встречке, если задом: до определенного момента никто слова не скажет, но ведь неудобно же.
В обработчиках прерываний даже делить целые числа не стоит, не то что специально задержки делать. А обработать состояние пина, даже с антидребезгом проще по-таймеру, или в цикле в main()

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

[serafims]

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

[bevice]

Пока обрабатывается прерывания другие ждут в очереди, приоритетов в AVR нет. Поэтому выходить из прерывания нужно как можно быстрее иначе можно пропустить что-то важное.
Проще опрашивать кнопку по таймеру, если нажата инкрементировать какой-нить счетчик, если отпущена — сбрасывать. Как только счетчик дойдет до какого-то значения — обрабатываем нажатие. Чем плохо?

[serafims]

Прерывания еще клево использовать для экономии электроэнергии — например, повесить приемную ногу uart на INT и когда пойдут данные то контроллер пробудится и сможет принять данныые. Есть несколько режимов сна, есть те которые позволяют не терять данные в приемном буффере…

[Ryav]

С описанием настройки в регистре MCUCR вы усложнили. И на чем это вы программу писали (просто я только с ассемблером работал)?