Прерывания в 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 прогнозируемый и легко расчитываемый. Карандаш в руки - просчитать нагрузку обработчиков прерываний и все - можно спасть спокойно. Неспешно расширять функционал программы не боясь что система загнется (не трогая обработчиков прерываний).

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

[Maik-vs]

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

Преведы бывают хоть на ассемблере, хоть на с хоть на чём! Если руки не оттуда.
Функциональность программы для МК - гм, изначально несколько более строго задаётся, чем функциональность программы для большого компьютера. Брать куски из одного проекта для другого - да. Расширять функциональность - это если плохое ТЗ.

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

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

[defunct]

Преведы бывают хоть на ассемблере, хоть на с хоть на чём! Если руки не оттуда.

На ассемблере преведов на порядок больше, и руки тут не при чем.
Зерно примитивов меньше - текста больше, сложность программы выше.
Программа получается ДУБОВАЯ - практически не подлежащая вразумительному расширению.

Функциональность программы для МК - гм, изначально несколько более строго задаётся, чем функциональность программы для большого компьютера. Брать куски из одного проекта для другого - да.

У кого как, мне важнее time-to-market и возможность заливать в одно и тоже железо разное ПО. Постепенно наращивать функциональность приходится - допустим выпустят новый Сепам или МРЗС и еще какую-то байду, добавить их к уже имеющейся прошивке нет проблем, и все управляющие устройства сразу умеют с ними работать. Надо только обновить прошивку.
За примерами далеко ходить не надо -
DVD/CD-RW - поддержка дисков разных производителей часто добавляется уже после выхода привода в продажу;
Wireless AP / Router'ы - добавление различных режимов и служб тоже происходит после.
и т.п.

Расширять функциональность - это если плохое ТЗ.

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

Потому что многих жмёт пространство и время.

Пространство меня не жмет. Хоть в медном тазу можно клепать, лишь бы крепилось на дин-рейку.
А про время, я вас умаляю. Ассемблеру с C не тягяться в этом.
Улыбнуло. ;>

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

Мне не нужен генератор врезки текста, но например в IP router я смогу при необходимости легко добавить telnet консольку или http сервер или фильтр какой-нить хитроумный.

[galjoen]

На ассемблере преведов на порядок больше, и руки тут не при чем.
Зерно примитивов меньше - текста больше, сложность программы выше.
Программа получается ДУБОВАЯ - практически не подлежащая вразумительному расширению.
У кого как, мне важнее time-to-market и возможность заливать в одно и тоже железо разное ПО. Постепенно наращивать функциональность приходится - допустим выпустят новый Сепам или МРЗС и еще какую-то байду, добавить их к уже имеющейся прошивке нет проблем, и все управляющие устройства сразу умеют с ними работать. Надо только обновить прошивку.

А я наоборот как наполучал преведы на С (для АВР), так на асм перешёл. И С для АВР забыл как страшный сон (для компьютера конечно на С++ пишу). У АВР 80% работы - это работа с USART, CAN, SPI, таймерами, портами др. устройсвами. А в этом С только мешает. Напишешь на С и понимаешь, что написал программу на ассемблере с помощью С. Всё равно приходится весь получившийся ассемблерный текст контролировать.
А насчёт расширяемости:
1. Я сначала USB-HID написал и обращение через него к специфическим задачам.
2. Самопрограммирование через USB.
3. Всякие модбасы и др. USARTовские дела.
4. Mass Storage.
5. FAT (при работе без подключения к компьютеру).
6. SLEEP (работа от ионистора).
7. CAN.
Всё это работает в разных проектах в разных вариантах. В т.ч. и всё это в одном устройстве (на AT90CAN128). И прошивки без проблем через интернет обновляются самими пользователями. Причём они даже об этом иногда не знают.
Я всё это к тому, что и на асме и на С можно как плохо, так и хорошо писать.

[777777]

А я наоборот как наполучал преведы на С (для АВР), так на асм перешёл.

Вместо того, чтобы найти их причину?

[galjoen]

Вместо того, чтобы найти их причину?

Нашёл несколько причин. Одна из них - несохранение С некоторых регистров в прерываниях. Искал долго т.к. вылезало редко, не во всех режимах, вылезало совсем в другом месте (в том месте которое было прервано после возврата с испорченными регистрами) и приводило к тому, что процессор выдавал на шину 1, а устройство 0. При этом происходило замыкание, срабатывала защита по питанию, срабатывал BOD, процессор перезапускался. Столько времени я бесполезно потерял... Понимаю, что в новых версиях это исправлено, но у меня уже какая-то аллергия на С для АВР выработалась. Мне всё кажется, что это глюк не мой, а С. А когда на асме пишу, то между мной и процессором никого нет... Макрокоманд для стандартных случаев понаписал. Если надо быстро сделать (и можно неоптимально), то макрокомандами пользуюсь. В принципе что-то типа своего языка на макрокомандах получилось.
ЗЫ Прошу прощения за офтоп.