У меня возникла парочка вопросов по прерываниям, смотрел в документации - не нашел. Если сможете - подскажите, пожалуйста.
Как я понял из документации, при входе в обработчик прерывания все остальные прерывания запрещаются, ведь так? То есть неявно выполняется инструкция cli. А что происхоит в случае, если за время обработки происходит внешнее прерывание, INT0, к примеру? Информация о нем отбрасывается или остается где-то? Дело в том, что я пишу обработчик и мне надо знать было ли за время работы обработчика прерывание. Если было, то после выхода вызвать другой обработчик...
И ещё вопрос: как я понял, приоритет у всех внешних прерываний одинаковый, ведь так? А назначить приоритет можно только программно, правда?
Спасибо.

Это произойдет само по себе. Сразу после выхода из текущего прерывания.


Приоритетов в АВР нет. Есть псевдоприоритеты - если два прерывания произойдут одновременно, то первым будет обработано то, адрес вектора у которого меньше. Возможно правда сделать вложенные прерывания - вставить sei в обработчик.

Сообщение отредактировал Qwertty - Jun 3 2008, 21:18

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

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

Возвращайтесь из обработчика прерывания не по команде RETI, а по команде RET. Разница в том, что RETI насильственно устанавливает флаг I в регистре SREG, а команда RET -- флаги в регистре не трогает вообще. И не забудьте про регистры, которые вы в начале обработчика сохранили в стеке.

А флаги конкретных прерываний (которые имели наглость установиться за это время) снимайте сами, как это посоветовал dENIM.

Сообщение отредактировал zhevak - Jun 6 2008, 06:13

Небольшое уточнение, насколько я знаю в контроллерах АВР есть два типа прерываний:
1 флаги которых защелкиваются, после возникновения причин прерываний и сбрасываются либо после перехода по вектору соответствующего прерывания либо программно
2. прерывания, флаги которых действуют только когда присуствтует причина прерываний (по-моему как раз ИНТ0 можно настроить в режим когда флаг прерывания действуе пока на входе соответствующий лог уровень)

Есть ещё флаги которые снимаются только по условию выполнения каких либо действий.
Например флаг UART RTX снимается только если произвести выборку из регистра принятых данных UDR

Это и делает GNUтый С-компилятор. Кстати, вопрос к знатокам, а можно ли запретить прерывания в обработчике? Т.е. не с помощью вызова cli() в начале, а уговорить компилятор не вставлять там sei.

Возвращаться из обработчика по команде RET нельзя!

Вот именно! А их надо восстанавливать. Что тебе насчитает основная программа, если прерывания будут периодически портить регистр состояния?

Да, почему нельзя? Если ты пишешь код и четко понимаешь как он исполняется, то какие проблемы?

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

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


А вообще, беспредметно спорить, только время терять.

Проблема в том, что это только сегодня ты четко знаешь, что происходит, через неделю будешь смутно вспоминать, а через месяц вообще забудешь. А код понадобится модернизировать. А если это будет делать другой программист? Думаешь он разделит твой восторг от отношения к программированию как к искусству? А твой работодатель, боюсь, вообще будет категорически против. Потому что ему не видно твоего искусства, он видит только как работает устройство, есть там глюки или нет, и если они есть, то хвалится красотой исходного кода бессмысленно - никто не оценит. Да и пользы от всяких хитроумных трюков обычно никакой нет - даже если экономится 10-20% памяти, все равно оставшуюся неиспользуемую память ты никуда не денешь. И даже когда программа не помещается в памяти, выгоднее вместо ATmega8535 поставить ATmega16, чем мудрить с разного рода программистскими трюками - в конце концов они тебе выйдут боком.
Так что, с точки зрения бизнеса, к программированию надо относиться как к серийному производству, смотреть на устройство глазами пользователя, а не искусствоведа, приходящего в восторг от красиво написанного исходного кода.

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

Сообщение отредактировал 777777 - Jun 9 2008, 04:39

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

Да, да, да. Это все так. Только, разумеется, сложные для понимания места обильно комментируем.



Точки зрения бывают разные.

У меня, например, если я не вписываюсь в энергетику потребляемой мощности, то можно считать, что девайс не получился.

Мне нужно сделать МК-девайс с потреблением не более 150 мкА. Дело не простое, так как мне нужно получить на УФ-датчике напряжение 300 В. Габарит -- не более размера батарейки "Крона". Питание устройства -- та же "Крона" В. Эти данные привожу, что бы Вы прочувствовали "пресс" требований, которые выдвигает заказчик.) Поэтому мне глубоко наплевать, что код будет не читабельный. Комментарии никто не отменял. Мне нужно обязательно получить результат, а уж как я его добиваюсь, заказчика это не волнует. Деньги он платит не за читабельность кода, а за конечный продукт. Это только один пример. Могу привести другой пример, из своей же практики. Пример, с точностью до наоборот.

Так что, конкретно можно говорить только по конкретной ситуации. Все остальное -- философия.



Еще раз: беспредметный спор == потеря времени. Предмета спора у нас нет. (По сути, разговор идет о гипотетическом устройстве и придуманной проге.)

А у меня не зависает. Проверено.
Вы пишите на ассемблере, отлаживайте. И тогда всё будет нормально, хоть с вложенными прерываниями, хоть с выложенными

И превед глюкодром!
Лучше не давать бестолковых советов.

Из обработчика прерывания следует возвращаться командой RETI.



А вы уверены, что это действительно то, что Вам нужно?
Обработчики прерываний можно сделать максимально короткими, тогда не придется сбрасывать "очереди отложенных прерываний". Все будет успевать отрабатываться как положено.

Например:
прерывание от UART - принять байт, взвести флаг "есть" данные и выйти.
прерывание таймера - увеличить внутренний счетчик (дергуть ногой если надо) и выйти.
прерывание от АЦП - сохранить результат АЦП (переключить на другой канал если требуется) и выйти.
и т.п.

Основную же обработку - вести в основном цикле программы (тобиш в main).


И будут преведы, да еще и на ассемблере.
Потом попробуйте к такой программе прилепить новую функциональность. (например еще один протокол обмена).

AVR со своим одноуровневым контроллером прерываний избавляет пользователя от множества проблем, бери да спокойно работай. Глубина стека прогнозируемая, overload прогнозируемый и легко расчитываемый. Карандаш в руки - просчитать нагрузку обработчиков прерываний и все - можно спасть спокойно. Неспешно расширять функционал программы не боясь что система загнется (не трогая обработчиков прерываний).

почему многие так и рвутся получить проблему (через одно место работая с прерываниями)? А потом эту проблему исправлять опять же через то же самое место?!