Прерывания в 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 нельзя!

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

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

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


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

[777777]

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

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

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

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

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