Цитата(ReAl @ Jul 4 2008, 21:47)
А кто мешает у MCS51 точно так же "какие хочешь, такие в данном месте и"?
Рукопашное "какие хошь прерывания, такие в данном месте и разрешай" точно так же можно и у 51-го дёргать.
Сильно теоретически можно. Мешает та самая приоритетная система прерываний с правилом "прервать текущее прерывание может только более приоритетное". Нельзя прервать даже прерыванием того-же уровня. Теоретически можно поднять приоритет "соседа", но тогда в этом "соседе" надо анализировать собственный приоритет, что-бы не наделать глупостей.
Как ни странно, но простота системы прерываний AVR часто и есть его преимущество.
А плюс заключается в том, что иногда в прерывании можно разрешить прерывания еще до сохранения контекста. Хотя стоит сперва исключить возможность повторного попадания в текущее прерывание. Т.е. прерывания наинизшего уровня как в x51 эмулируются в AVR одной командой разрешения прерывания в начале обработчика (можно даже еще в таблице векторов).
А вообще - в любом длинном прерывании чаще всего есть критическая секция которую надо сделать "как можно шустрей" и "все остальное", которое уже можно обрабатывать при разрешенных прерываниях.
Цитата(ReAl @ Jul 4 2008, 21:47)
GCC в прологах/эпилогах трогает.
Ну, это к создателям GCC... Если им лень было учитывать особенности платформы и они предпочли сделать "как в х86", то кто им лекарь. А особенность заключается в том, что X и Y позволяют сделать честный стеки данных, а не играться со стековым кадром на стеке возвратов.
Цитата(ReAl @ Jul 4 2008, 21:47)
Любой переключатель задач трогает.
Обычно переключателю задач не атомарность SP до лампочки. Переключение задач обычно делают уже в прерывании т.е. при запрещенных операциях со стеком.
Цитата(ReAl @ Jul 4 2008, 21:47)
Кроме SPL я ещё и словные SFR припомнил - очень весело при каждом обращении к 16-битным таймерным регистрам запрет прерывания дёргать.
Не работай с регистрами таймеров в основном цикле программы (не самое удачное решение), не будет тебе этой "проблемы".
Цитата(ReAl @ Jul 5 2008, 18:06)
Если же уже начал работать обработчик, к примеру, SPI, то не имеет никакого значения факт "наиприоритетности" INT0 - оно не прервёт "менее приоритетный" обработчик SPI до тех пор, пока в том не будет выполнена команда SEI. Но сразу после неё резко так обработчик EE_RDY тоже сможет прервать обработчик SPI - т.е. коту под хвост пошло теперь уже то, что обработчик SPI якобы приоритетнее EE_RDY.
Если в обработчике появилась SEI, то все, что требовало "приоритетности" там уже выполнено. Остальной код по важности ниже необходимости обработки того-же EE_RDY....
Цитата(ReAl @ Jul 5 2008, 18:06)
Конечно, можно поизвращаться и при входе в обработчик SPI сохранить состояние разрешения прерывания EE_RDY, запретить его, потом сделать SEI, порабтать, (по вкусу - выполнить CLI) и восстановить состояние разрешения EE_RDY. Именно о таком спочобе эмуляции приоритетной системы прерываний писал ArtemKAD.
И о таком в т.ч.. Хотя именно так я никогда не делаю. Разве, что тогда, когда меня интересует не само прерывание, а только его флаг. Обычно обработчик делится на приоритетную часть(которую прерывать нельзя) и остальную (после SEI)
Цитата
Но это только программная эмуляция того, что у других бывает аппаратно.
В том же MCS51 имеется две или четыре таких цепочки, которая у AVR одна.
Не совсем такие. У MCS51 разрулить выполнение прерываний с равными приоритетами - только последовательное исполнение. Поэтому там длинным обработчикам ПРИХОДИТСЯ ставить наинизший приоритет независимо от их важности т.к. разрешить выполнение ВСЕХ остальных прерываний посреди обработчика весьма непросто
Цитата
В этом случае, например, можно прерывание от аналогового компаратора переместить в самую приоритетную цепочку и сработка компаратора сразу же вызовет его обработчик - без ожидания, пока работающий уже в данный момент обработчик какого-нибудь таймера расщедрится на сохранение контекста,
Ага... Если только это прерывание "какого-нибудь таймера" само не вызвано таким-же способом из другого прерывания
. Тогда вызвать прерывание "от аналогового компаратора" повышением его приоритета будет не суждено.
Приведу пример на примере обычного декрементирующего таймера. После возникновения этого прерывания необходимо как можно скорее установить новое значение счетчика (т.е. вроде как наивысший приоритет), а затем выполнить кучу работы которая накопилась за время между срабатываниями (пару десятков мс) и эта обработка не срочная и может занять несколько мс (т.е. надо разрешить остальные прерывания). Вот и попробуй выбрать че больше не нравится при использовании х51-й системы прерываний.
Цитата
Да, без этого можно жить. Можно стараться обработчики прерываний делать покороче, чторбы задержка в них не была существенной, можно, как это часто обсуждается, в нужных обработчиках запрещать "менее приоритетные" и после этого разрешать прерывания
Зачем? Просто ставь пораньше SEI если не нужна дальше непрерывность кода. А "наименее приоритетные" вообще начинай с этой команды...
Цитата
Да, в свежих AVR это дело потихоньку поправили, но изначально был такой ляп...
Не думаю, что это был совсем уж ляп. Скорее всего в погоне за ценой кристалла делали регистры "так как получилось". С переходом на более мелкую норму ресурсы по "устаканиванию" порядка регистров стали более незаметны вот в новых и поправляют.
ЗЫ. Как по мне - наиболее неудобное расположение регистров у Mega48(88/168), но у них и наилучшее соотношение цена/возможности.
ATMEL рекомендует ATmega32A и ATmega16A
Jul 1 2008, 16:49
