ATMEL рекомендует ATmega32A и ATmega16A Опции

[elecelec]

ATMEL рекомендует ATmega32A и ATmega16A

ATmega16A при питании 2.7-5.5V частоты 0-16 MHz
http://www.atmel.com/dyn/products/product_...sp?part_id=2010

ATmega16A Datasheet полный - http://www.atmel.com/dyn/resources/prod_do...nts/doc8154.pdf

ATmega16A коротко - http://www.atmel.com/dyn/resources/prod_documents/8154S.pdf

Отличия ATmega16 и ATmega16A - апноут:
AVR522 Migrating from ATmega16 to ATmega16A Application Note
http://www.atmel.com/dyn/resources/prod_do...nts/doc8163.pdf

[ArtemKAD]

Вот отсутствие хотя бы двух уровней приоритета прерывания (хотя бы как в MCS51) - это бяка.

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

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

Где там у старых AVR "одинаковая периферия" кроме портов? Вот когда сделали в новых кристаллах по 5 UART-ов , вот тогда и начали "исправлять"...

Кто не дал сделать запрет прерываний на одну следующую команду при обращении к SPH (для время загрузки SPL),

А кто SPL вообще трогает?! Кто мешает, если уж сильно охота, запретить прерывания?

[ReAl]

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

А кто мешает у MCS51 точно так же "какие хочешь, такие в данном месте и"?
Рукопашное "какие хошь прерывания, такие в данном месте и разрешай" точно так же можно и у 51-го дёргать. Никаких плюсов у АВР тут нет, ни капли не "гибче".
Вы хоть поняли, о чём я? Вы хоть знаете/помните, как оно у 51-го сделано?
Объясняю медленно:
Вошли, например, в прерывание по INT0. Но у нас ещё UART, из которого побыстрее выбрать надо, и какой-нибуть АЦП, который может и подождать.
У 51-го можно просто поднять приоритет UART выше приоритета INT0 и тогда без никаких беганий по регистрам других устройств в обработчике INT0 (а часто преріваний гораздо больше, чем три) - сохранение состояния разрешения прерывания от АЦП и его запрет на входе и восстановление состояния при выходе - UART сможет прервать INT0, а АЦП - нет.
И два уровня - это только в начальных 51-ых, массово вообще 4 уровня было.

А кто SPL вообще трогает?!

GCC в прологах/эпилогах трогает. Любой переключатель задач трогает. Кроме SPL я ещё и словные SFR припомнил - очень весело при каждом обращении к 16-битным таймерным регистрам запрет прерывания дёргать.

Кто мешает, если уж сильно охота, запретить прерывания?

Ну да. Вместо поднятия приоритета важных прерываний "если уж сильно охота" дёргать биты по разным регистрам, вместо аппаратного запрета прерывания на одну команду (почему-то у i86-го не поленились такое при записи в SS для атомарного изменения пары SS:SP сделать) тоже вручную дёргаться.
Так можно вообще договориться до того, что команда умножения - фигня, "не знал, что гибкая система сложений и сдвигов - это хуже двух команд умножения". Никто не мешает.

[ArtemKAD]

А кто мешает у MCS51 точно так же "какие хочешь, такие в данном месте и"?
Рукопашное "какие хошь прерывания, такие в данном месте и разрешай" точно так же можно и у 51-го дёргать.

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

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

GCC в прологах/эпилогах трогает.

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

Любой переключатель задач трогает.

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

Кроме SPL я ещё и словные SFR припомнил - очень весело при каждом обращении к 16-битным таймерным регистрам запрет прерывания дёргать.

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

Если же уже начал работать обработчик, к примеру, SPI, то не имеет никакого значения факт "наиприоритетности" INT0 - оно не прервёт "менее приоритетный" обработчик SPI до тех пор, пока в том не будет выполнена команда SEI. Но сразу после неё резко так обработчик EE_RDY тоже сможет прервать обработчик SPI - т.е. коту под хвост пошло теперь уже то, что обработчик SPI якобы приоритетнее EE_RDY.

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

Конечно, можно поизвращаться и при входе в обработчик SPI сохранить состояние разрешения прерывания EE_RDY, запретить его, потом сделать SEI, порабтать, (по вкусу - выполнить CLI) и восстановить состояние разрешения EE_RDY. Именно о таком спочобе эмуляции приоритетной системы прерываний писал ArtemKAD.

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

Но это только программная эмуляция того, что у других бывает аппаратно.
В том же MCS51 имеется две или четыре таких цепочки, которая у AVR одна.

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

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

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

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

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

Зачем? Просто ставь пораньше SEI если не нужна дальше непрерывность кода. А "наименее приоритетные" вообще начинай с этой команды...

Да, в свежих AVR это дело потихоньку поправили, но изначально был такой ляп...

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

[ReAl]

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

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

Код

prog    segment    code
stack    segment    idata

    rseg  stack
    ds    10H

    cseg  at 0
    jmp start
    jmp IE0_vect
    
    org    1BH
    jmp TF1_vect

    rseg  prog
start:
    mov    SP,#stack-1
    mov    TMOD, #03H
    mov    TCON, #43H
    mov    IE, #89H
    setb    PT1
    sjmp $
    
TF1_vect:
    setb    P1.0
    setb    P3.2
    clr    P3.2; передёрнули INT0
    acall L_reti; очистка логики прерываний - теперь как после SEI у AVR
    nop
    nop
    nop
    clr    P1.0
L_reti:
    reti

IE0_vect:
    setb    P1.1
    clr    P1.1
    reti
    
    end

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем? Просто ставь пораньше SEI если не нужна дальше непрерывность кода. А "наименее приоритетные" вообще начинай с этой команды...

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