Pull to refresh

Comments 22

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

Если не ошибаюсь, тини2313 тоже моложе меги8
Действительно щас залез в даташиты… PCINT у 48/88 на все ножки) и прерываний на них всех не одно, а 4 =)
а как узнать какой вход вызвал прерывание?
как узнать состояние порта?
т.к. порты у МК могут быть разными я взял их за переменные X-название порта, Y- его номер. Если что-то непонятно, то винзу есть примеры рабочего кода.
Вот это:
DDRxy |= (0<<y);

не изменит значения DDR. Если нужно сбросить разряд в ноль, делают
DDRxy &= ~(1<<y);
эм..=) ты прав, но я как бы не сбрасывал, а показывал состояние порта которое должно быть, оно и так по дефолту нулю равно, ща подумаю как бы поточнее описать и переделаю начало.
Описать состояние разряда можно так:
DDRxy & (1<<y) == 1;
или
DDRxy & (1<<y) == 0;
ИМХО, нет нужды использовать прерывания для опроса кнопок, за исключением тех случаев, когда клавиатура выводит микроконтроллер из режима сна. Опрос кнопок — это самый некритичный ко времени выполнения процесс, и его всегда можно запихнуть в бекграунд вместе с алгоритмом подавления дребезга контактов.

"… МК не всегда быстро может реагировать на нажатие кнопки, т.к. проверка 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 (с примерами исходного кода).
По мне есть вопрос времени в кодинге, можно подстроить сложный код под опрос, тогда действительно получается некритично, но на это надо затратить силы и время, когда как прерывание внешнее, которое уже предусмотрено производителем можно заюзать сразу, зная как оно будет себя вести и код доделывать под опрос не надо, конечно это одна из самых простых задач в программинге МК, но и на этом можно время сэкономить, я же не говорю что это панацея) кому нужно — попробуют.
Не вижу никакой проблемы в скорости реакции на кнопки. Обычно, если МК выполняет более одной задачи, я предпочитаю решение с организацией тасков по таймеру. Опрос клавиатуры, например, можно делать фиксированно каждые 0.25 секунд, тогда с учетом устранения дребезга, опрос будет стабильно раз в 0.5 сек.
Мой скромный опыт подсказывает, что кнопки и прерывания несовместимы (за редким исключением): задержки в прерываниях (тем более в AVR, где нет приоритетов прерываний) идея крайне плохая — по вашей версии кода, после нажатии кнопки в течении секунды никакие другий прерывания обрабатываться не будут, главный цикл программы так же не будет выполнятся. Если активирован watchdog это гарантированно приведет к сбросу МК. Вообще такой подход, кроме как к миганию светодиодом более ни к чему не применим.
Механический конкакт (кнопка) и прерывания — так же плохо. Попробуйте, на досуге посчитать сколько прерываний приходит при нажатии, несколько сотен, минимум. А со временем (при износе кнопки) — на порядок больше
да, но простые программки, где не хочется делать счетчики, легко строются на принципе внешних перерываний, и то что тормозиться основноой цикл и др важные прерывания в основном не так уж и страшно.
Можно ездить по встречке, если задом: до определенного момента никто слова не скажет, но ведь неудобно же.
В обработчиках прерываний даже делить целые числа не стоит, не то что специально задержки делать. А обработать состояние пина, даже с антидребезгом проще по-таймеру, или в цикле в main()

Я пытался придумать, хоть одну задачку, где можно использовать ваш способ, но кроме моргнуть светодиодом ничего не придумалось. Подскажите?
а что мешает после срабатывания прерывания запустить проверу на дребезг? (постоянность принятого сигнала на протяжении скольких-то мс, чтоб не глючило на этот момент запретить это прерываение..)
Пока обрабатывается прерывания другие ждут в очереди, приоритетов в AVR нет. Поэтому выходить из прерывания нужно как можно быстрее иначе можно пропустить что-то важное.
Проще опрашивать кнопку по таймеру, если нажата инкрементировать какой-нить счетчик, если отпущена — сбрасывать. Как только счетчик дойдет до какого-то значения — обрабатываем нажатие. Чем плохо?
Прерывания еще клево использовать для экономии электроэнергии — например, повесить приемную ногу uart на INT и когда пойдут данные то контроллер пробудится и сможет принять данныые. Есть несколько режимов сна, есть те которые позволяют не терять данные в приемном буффере…
С описанием настройки в регистре MCUCR вы усложнили. И на чем это вы программу писали (просто я только с ассемблером работал)?
Sign up to leave a comment.

Articles