Прерывания в Atmel 8535 Опции

[DMD]

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

[DMD]

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

[zhevak]

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

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

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

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

[777777]

Возвращайтесь из обработчика прерывания не по команде RETI, а по команде RET.

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

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

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

[zhevak]

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

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

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

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


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

[defunct]

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

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

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

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

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

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

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

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

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

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

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