Сильно теоретически можно. Мешает та самая приоритетная система прерываний с правилом "прервать текущее прерывание может только более приоритетное". Нельзя прервать даже прерыванием того-же уровня. Теоретически можно поднять приоритет "соседа", но тогда в этом "соседе" надо анализировать собственный приоритет, что-бы не наделать глупостей.
Как ни странно, но простота системы прерываний AVR часто и есть его преимущество.

А плюс заключается в том, что иногда в прерывании можно разрешить прерывания еще до сохранения контекста. Хотя стоит сперва исключить возможность повторного попадания в текущее прерывание. Т.е. прерывания наинизшего уровня как в x51 эмулируются в AVR одной командой разрешения прерывания в начале обработчика (можно даже еще в таблице векторов).
А вообще - в любом длинном прерывании чаще всего есть критическая секция которую надо сделать "как можно шустрей" и "все остальное", которое уже можно обрабатывать при разрешенных прерываниях.

Ну, это к создателям GCC... Если им лень было учитывать особенности платформы и они предпочли сделать "как в х86", то кто им лекарь. А особенность заключается в том, что X и Y позволяют сделать честный стеки данных, а не играться со стековым кадром на стеке возвратов.

Обычно переключателю задач не атомарность SP до лампочки. Переключение задач обычно делают уже в прерывании т.е. при запрещенных операциях со стеком.

Не работай с регистрами таймеров в основном цикле программы (не самое удачное решение), не будет тебе этой "проблемы".



Если в обработчике появилась SEI, то все, что требовало "приоритетности" там уже выполнено. Остальной код по важности ниже необходимости обработки того-же EE_RDY....

И о таком в т.ч.. Хотя именно так я никогда не делаю. Разве, что тогда, когда меня интересует не само прерывание, а только его флаг. Обычно обработчик делится на приоритетную часть(которую прерывать нельзя) и остальную (после SEI)

Не совсем такие. У MCS51 разрулить выполнение прерываний с равными приоритетами - только последовательное исполнение. Поэтому там длинным обработчикам ПРИХОДИТСЯ ставить наинизший приоритет независимо от их важности т.к. разрешить выполнение ВСЕХ остальных прерываний посреди обработчика весьма непросто

Ага... Если только это прерывание "какого-нибудь таймера" само не вызвано таким-же способом из другого прерывания . Тогда вызвать прерывание "от аналогового компаратора" повышением его приоритета будет не суждено.

Приведу пример на примере обычного декрементирующего таймера. После возникновения этого прерывания необходимо как можно скорее установить новое значение счетчика (т.е. вроде как наивысший приоритет), а затем выполнить кучу работы которая накопилась за время между срабатываниями (пару десятков мс) и эта обработка не срочная и может занять несколько мс (т.е. надо разрешить остальные прерывания). Вот и попробуй выбрать че больше не нравится при использовании х51-й системы прерываний.

Зачем? Просто ставь пораньше SEI если не нужна дальше непрерывность кода. А "наименее приоритетные" вообще начинай с этой команды...
Не думаю, что это был совсем уж ляп. Скорее всего в погоне за ценой кристалла делали регистры "так как получилось". С переходом на более мелкую норму ресурсы по "устаканиванию" порядка регистров стали более незаметны вот в новых и поправляют.
ЗЫ. Как по мне - наиболее неудобное расположение регистров у Mega48(88/168), но у них и наилучшее соотношение цена/возможности.

"если нельзя, но очень хочется, то можно".


У меня таким образом прерывание от таймера с периодом 256 циклов процессора прерывало само себя - оно обычно быстренько всё делало, но раз в N входов работало долго, вместе с обычной работой - больше 256 циклов. Ну так входило, опять делало быструю часть и возвращалось в длинную, оттуда - в основную программу.

Ну так и делаю. Просто у AVR можно *только* так. А у MCS51 - не только. И я пользовался тем, что можно и так, и эдак, и смесь. Чаще всего я на "двухуровневых" MCS51 таким образом эмулировал третий уровень, на "четырёхуровневых" хватало имеющихся уровней и только несколько раз делал acall L_reti, чтобы прерывание могло прервать свою же длинную часть (ну и другие чтобы не ждали аж так долго).
Но всё равно я на AVR перешёл , по сумме баллов.

Лень - не лень, но странно выходит. Разработчиков AVR Вы защищаете, а у разработчиков AVR-GCC право иметь какие-то свои соображения отбираете.
Зато в тех функциях, в которых стековый кадр не нужен - у них Y вообще свободен для использования. А основной проигрыш IAR-у в размере кода у них отнюдь не на том, что нужно модифицировать SP, если у функции есть локальные переменные на стеке.

Да, это я увлёкся

Точнее "только в обработчиках прерываний до SEI" ?
Ну, случаи бывают всякие.

см. выше. Очень просто, цена вопроса - два байта и (на классике) четыре машинных цикла, что гораздо проще, чем на AVR сэмулировать работу системы прерываний 51-го. Из-за сложности эмуляции на AVR обходятся по другому, а не потому, что в этом нет своих прелестей.

Ну так не просто пробовал - отлично работало.


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

Оригинально, оценил.

У разработчиков компилятора возможностей максимально оптимизировать код под возможности платформы гораздо больше, чем у разработчиков камня (!)общего применения(!) оптимизировать систему фич, что-бы всех удовлетворило. Вот что-то типа твоего acall -> reti можно использовать для сброса текущего приоритета прерываний не смотря на то, что разработчиками камня такой фичи аппаратно не предусмотрено.
А тут разработчики камня выкручивались обеспечивая очень мощную фичу на спец.регистр (Y), а его используют просто как регистр общего применения.

Угу...
ЗЫ. Кстати, посмотрел я реализацию контроллера прерываний в ПЛИС - не сказал бы, что он проще умножителя 8х8. А если еще поставить условие принятия решения за 1 цикл, да еще и как в х51 - он получается однозначно сложнее.

На самом деле у вариантов исполнения стека данных в GCC и в IAR есть и положительные, и отрицательные стороны.

Решение с отдельными стеками данных и возвратов, кстати, не только на AVR применяется (и не только IAR'овское это изобретение). Для расширения кругозора рекомендую посмотреть на C166. Там тоже отдельный SP, а для указателя стека данных используется R0. И компилятор не IAR .

А еще в C166 есть супер-полезная комманда atomic #n, которая запрещает прерывания на время выполнения следующих n инструкций. Очень и очень удобно для всяких семафоров, многословной периферии и прочего.

Простите конечно, но что-то вы либо недопонимаете либо бред пишете либо выссказываетесь неточно.

МК это не лошадь. Его руками и головой делали. Здесь нет полутеней и всё предельно чётко. А посему:
1) Прерывания в AVR - аналог одного уровня прерываний в x51. Пускай вас не вводит в заблуждение описание порядка обработки прерываний в AVR при одновременном поступлении прерываний. На самом деле данный порядок не имеет никакого значения и ничем не поможет разработчику. С другой стороны x51 также имеет какой-то порядок обработки, - это ежу понятно. Просто разработчики на нём не заморачивались (и абсолютно правильно так как это один уровень)
2) В x51 введён аппаратный контроллер уровней прерывания, что очень удобно и постоянно используется (в AVR, к сожалению это приходится делать вручную. Точно также это можно делать и в x51 - никто не мешает). Более того введение банков регистров (с переключением) это тоже сделано для поддержки работы с прерываниями. Что, в свою очередь, говорит об обдуманном подходе разработчиков к решению этого вопроса. Таким образом при входе в прерывание необходимо было лишь сохранить PSW и выбрать банк, а при выходе - восстановить PSW и выйти.
3) В одной из первых статей разработчики AVR писали что работают на расширенном контроллером прерываний с поддержкой приоритетов и что данный вопрос "очень сложный" (Хотя несколько непонятно почему). Это было ещё на заре появления семейства megaAVR. Очевидно что их разработка воплощена в семействе xmega, где введено 4 уровня и есть "карусельный" вариант внутри уровня. Совершенно очевидно, что это серьёзный шаг вперёд и по сравнению с AVR и по сравнению с x51. Указано также что появилась возможность "программного вызова", отсутствие которого тоже была крайне неприятным моментом.

Всё это говорит что разработчики также воспринимали эти моменты, как отрицательные и работали над их исправлением.

PS: Вот вам в догонку раскладка прерываний х51 внутри уровня (аналог уровней)

1. IE0 (highest)
2. TF0
3. IE1
4. TF1
5. RI + TI
6. TF2 + EXF2 (lowest)

В AVR уже этого не будет. При большом количестве регистров (а здесь именно такой случай) затраты памяти и времени на "вход-выход" значительны. Даже выигрыш времени, получаемый от неожидания события, будет "скомпенсирован".
А в основном (за редким исключением), проблемы приоритетов разрешимы, если не напрягать uC непомерными задачами.

Не совсем аналог. Еще проще. AVR это аналог x51 вообще без единого уровня, но с автоматически взводимым флагом глобального запрета прерываний при вызове прерывания. С уровнями у x51 сложнее - при вызове прерывания определенного уровня МК запоминает текущий уровень и блокирует прерывания этого уровня и ниже. Т.е. для разрешения всех прерываний в прерывании надо не один такт как в AVR, а 4 цикла (на классике - почти 50 тактов).

И что? Я что-то не пойму?
Если оставить все прерывания одним уровнем - и вот вам AVR. По этому показателю AVR как раз менее удобна. Если делать полный аналог системы прерываний x51 на AVR, то затраты будут куда как более серьёзные.

Спасает только то, что для МК как правило достаточно одного высокоприоритетного прерывания, что можно путём SEI сделать. Но так бывает отнюдь не всегда.

А если делать полный аналог системы команд x51 на AVR, то затраты будут еще больше.
ЗЫ. А зачем делать "полный аналог"?

Затраты будут небольшие. Тут уже упоминалось, что я, и как оказалось, не только я выполнял такую работу при переходе с камня на камень. При этом просто тупо переписывал ASM операторы. И всё сразу заработало. Система команд AVR мощнее и удобнее чем x51.

Я надеюсь, вы не считаете что разработчики Intel, просто тупы и не знали что творили? При этом архитектура x51 и по сей день (по-моему) лидирует в области восьмибитников. Что указывает на её удачность. Кроме того, косвенно, на удачность системы прерываний указывает система прерываний xmega, которая заимствует и расширяет принципы системы прерываний x51. Впрочем, это общепринятые подходы к уровням прерываний.

А, собственно, в чем прерывания AVR вы считаете лучше чем x51? Что такого можно сделать на AVR, чего нельзя на x51? Или удобнее на AVR чем на x51?

Арифметика. ;О) Можно подобрать условия, что 51 физически не сможет чего-то посчитать в отведённое время. А АВР - лехко. ;О) Или речь о прерываниях?

Мускулистые 51 это 100MIPS, есть и 251. Так что все отнюдь не однозначно, даже если говорить не только "о прерываниях".

Так давайте мой JPEG-кодер для 51го соберем. И поглядим

Блин. Да я только о прерываниях. Я же не в целом о камне.

Это намек на то, что разработчики Atmel просто тупы и не знали что творили?

xMega слегка крупнее остальных AVR, что предъявляет к ней новые требования (задачи становятся объемнее, прерывания усложняються). Вы же не считаете, что к примеру в 8-битнике класса AVR и х51 должны быть средства реализации вытесняющей многозадачности (а-ля Intel x386). Вы вполне понимаете, что "за удовольствие придется заплатить". AVR упростила систему прерываний, а в замен дала очень функциональные таймера - на каждый по 2-3 прерывания, а не только одно переполнение как в х51.
Так стоит ли повторять систему прерываний x51? Существующая в AVR Вам сильно не нравится (не дает работать)?

Почти ничем. Но тем не менее их почти всегда хватает. Так стоит ли их для этого класса МК расширять?

Сообщение отредактировал ArtemKAD - Jul 10 2008, 19:40