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

[Дон Амброзио]

А в чём проблема-то? Озвучьте

[Kuzmi4]

2 elecelec - так а чего кипиш подымать ?

Я что-то не нашёл каких либо больших отличий в 16 и 16А кроме 30~40 % уменьшения жрачки...

К слову - вот 1281А - вроде частоту подняли до 32-х ( где то линк встречал ) - вот тут есть на что слюни попускать...

[defunct]

2 elecelec - так а чего кипиш подымать ?

А где "кипиш"-то? Нам спокойно преподнесли инфу со ссылками на документы.
(Я например, узнал об этих новых чипах только из этой ветки).
За что большое спасибо!

[Дон Амброзио]

А где "кипиш"-то? Нам спокойно преподнесли инфу со ссылками на документы.

А вопрос то где? Его автор так и не задал по-моему.

А если это реклама то зачем? Если бы меня интересовали новые чипы от Atmel, то чтобы мне помешало заглянуть на сайт производителя? Зачем здесь-то это писать?

[IgorKossak]

Сообщаю для непонятлвых.
На форуме публикуются не только вопросы, но и информация. Кому она не интересна, не обязаны реагировать.
Кстати, многие полезные новости узнаются именно здесь, избавляя пользователей от нудного, зачастую, серфинга.

[Дон Амброзио]

Сообщаю для непонятлвых.
На форуме публикуются не только вопросы, но и информация. Кому она не интересна, не обязаны реагировать.
Кстати, многие полезные новости узнаются именно здесь, избавляя пользователей от нудного, зачастую, серфинга.

А размещать сообщения так.. Для информации....Разрешено только избранным?

Помню когда я один раз разместил сообщение "для информации" меня сразу же забанили на месяц с формулировкой "за флуд"

Сообщение отредактировал Дон Амброзио - Jul 2 2008, 17:10

[proba]

кажется атмел переводит самые популярные аврки с 0.35um на =<0.25.

[defunct]

раз разместил сообщение "для информации"

Информация не по теме видать была?

Вообще-то запостить в спец форуме информацию о вышедшей новинке или новой тулзовине соответсвующей специфике форума это нормально и полезно, видел много таких веток и никого никогда не банили. Выходы новых версий AVR-Studio / WinAVR / IAR и проч. только по форуму и отслеживаю. Обсуждение само вокруг вырастает если появляется надобность.

кажется атмел переводит самые популярные аврки с 0.35um на =<0.25.

Жаль частоту не подняли, хотя б до 20mHz...

[Александр Куличо...]

Жаль частоту не подняли, хотя б до 20mHz...

Жаль конечно, но по сравнению с mega16L/32L подняли-то в 2 раза!

[haker_fox]

Жаль конечно, но по сравнению с mega16L/32L подняли-то в 2 раза!

Все таки кривизна в архитектуре есть... целых 32 регистра, но полноценна только старшая половина...(
Хотя сейчас уже мало что изменишь, только частотой и можно выиграть, а в противном случае - потеря совместимости.

[Kuzmi4]

2 haker_fox - объясните пожалуста что вы имели ввиду , а то я что-то не въехал...

[aaarrr]

целых 32 регистра, но полноценна только старшая половина...(

И чем Вам так невозможность работы с immediate в младших регистрах досадила, что аж архитектура кривой кажется?

[Александр Куличо...]

Все таки кривизна в архитектуре есть... целых 32 регистра, но полноценна только старшая половина...(

И ldd/std только +63, а не +/-32768
МНе, например, счетчика циклов микроконтроллерера не хватает(эдак, бит на 48+). но это уже периферия.

[sensor_ua]

похоже, старые JTAG ICE не подойдут - все на дракошу - и нехорошо (...с партизанами получилось(С)), и вроде не больно

усилитель в АЦП впихнули...

[MrYuran]

усилитель в АЦП впихнули...

А вроде бы всегда был.. разве нет?

[sensor_ua]

А вроде бы всегда был.. разве нет?

точно. не заметил за столько лет

[defunct]

похоже, старые JTAG ICE не подойдут - все на дракошу - и нехорошо

Подозреваю, что это можно будет обойти. Выбрать в отладчике старый m16/32.

[Александр Куличо...]

похоже, старые JTAG ICE не подойдут - все на дракошу - и нехорошо

А откуда такая информация?

[sensor_ua]

А откуда такая информация?

нехорошие предчувствия из отсутствия цифирек
Table 24-1. JTAG Version Numbers
ATmega16A revision TBD

[ReAl]

Все таки кривизна в архитектуре есть... целых 32 регистра, но полноценна только старшая половина...(
Хотя сейчас уже мало что изменишь, только частотой и можно выиграть, а в противном случае - потеря совместимости.

Это как раз не самое противное.
Вот отсутствие хотя бы двух уровней приоритета прерывания (хотя бы как в MCS51) - это бяка.
Изначально плохо продуманное распределение SFR-регистров по адресам (например, TIFR & Co в битово-неадресуемой области, EEDR/ADCW/... в битово-адерсуемой) - бяка.
Неоднородное расположение регистров сходных узлов (одинаковых таймеров, UART), делающее невозможной естественную обработку одинаковой периферии через передачу указателя на начало блока регистров - начали исправлять в свежих кристаллах, но ... Ведь это не новинка, просто атмел где-то заснул. Что-то в духе horisontal windowing от MCS196 кто мешал сделать?

Кто не дал сделать запрет прерываний на одну следующую команду при обращении к SPH (для время загрузки SPL), я уже не говорю про такое для всех словных SFR? Места много не заняло бы, а удовольствия...
Причём это даже на совместимость не сильно влияет, можно было бы просто для новых кристаллов под условную компиляцию код упрощать.

На этом фоне несимметричность регистров не самое страшное.

[Dog Pawlowa]

Это как раз не самое противное.
...
На этом фоне несимметричность регистров не самое страшное.

У каждого свои претензии. Меня вот огорчает жесткая привязка функциональных выводов. Для того, чтобы использовать некоторые драйверы моторов с ШИМ, нужно внешнюю логику использовать, чтобы сигналы направления с ШИМ объединить.
Но это уже оффтопик, пожалуй

[SasaVitebsk]

Соглашусь полностью с последними двумя авторами. Но... в xmega все эти проблемы устранены уже.

Осталось только дождаться.
Особенно радует наличие от 16 до 36 каналов ШИМ. Из стандартных камней только atmega640 подходит, но она дорога и избыточна для меня. Плюс корпус...

[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 сделать) тоже вручную дёргаться.
Так можно вообще договориться до того, что команда умножения - фигня, "не знал, что гибкая система сложений и сдвигов - это хуже двух команд умножения". Никто не мешает.

[defunct]

У каждого свои претензии.

Справедливости ради следует отметить, что все же претензий к чипам значительно меньше чем
к 51м и PIC'ам.
Балланс памяти (флеш, ОЗУ, eeprom), периферии, регистров и проч., прямая адресация всего ОЗУ, "TRUE" однотактовые порты, делает претензии к КПП, к урезанному банку регистров, к неполноценному SP мизерными. А больше претензий вроде бы как и нет.

Можно жить (хорошо жить) с одноуровневым КПП.
Можно жить без полноценного SP (на кой он нужен вообще (полноценный), если стек данных можно организовать самостоятельно.)
Можно жить и с 16-тью регистрами, можно и с 8-ю, кастрированный банк можно расценивать как бонус.

[haker_fox]

2 haker_fox - объясните пожалуста что вы имели ввиду , а то я что-то не въехал...

Просто хотел сказать, а потом и другие уважаемые участники форума подтвердили, что можно было бы иметь лучше, чем имеем.

Справедливости ради следует отметить, что все же претензий к чипам значительно меньше чем
к 51м и PIC'ам.

Что верно, то верно!
Для многих решений AVR самое то!

[ReAl]

Справедливости ради следует отметить, что все же претензий к чипам значительно меньше чем к 51м и PIC'ам.
Балланс памяти (флеш, ОЗУ, eeprom), периферии, регистров и проч., прямая адресация всего ОЗУ, "TRUE" однотактовые порты, делает претензии к КПП, к урезанному банку регистров, к неполноценному SP мизерными. А больше претензий вроде бы как и нет.

Несимметричные регистры меня как-то не сильно раздражают, особенно после появления lpm R,Z+. Иногда удручает "неполноценность" указательной пары X. Ну а если бы ещё и пара R25:R24 (W) указательной была, так и вообще прекрасно было бы , причём если выбирать что-то одно, то даже тяжело так навскидку сказать - лучше было бы иметь пару W такой же "неполноценной" как X, или пусть лучше W не будет указательной, зато X получит адресацию со смещением.
Отсутствие ldi/andi/.. у младших 16 регистров - последнее, на что обратил бы внимание.
А вот хотя бы два приоритета прерываний, пусть даже хотя бы в относительно крупных кристаллах (т.е., где оно нужнее, где самих прерываний больше, ну, например, во всех мегах) - сильно кристалл не раздули бы. Как и запрет прерываний на одну команду при обращении к соответствующим половинкам словных регистров (включая "большой" SP) - опять таки, чем больше кристалл, тем это нужнее. А места заняло бы ну точно меньше, чем умножитель, который в мегах же есть.
Я не говорю, что без этого кристалл никудышним стал :-)
Но жаль, что они об этом не подумали.

Можно жить (хорошо жить) ....

Ну так живу же 10 лет уже. С 51-ых как раз и перешёл. ПИК16 как-то не пропёрли. Попробовал pic16c64 (заказчик даже пикстарт какой-то покупал, я пару своих pic16c64, зашитых пикстартом в комплекте с дискеткой "что именно зашито" отдавал на Квазар-Микро на растерзание, чтобы они в свой программатор "Унипрог" добавили) и pic16f84 после чего с радостью встретил 90s8515 и 90s4433.

[Andrew O. Shadou...]

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

Как ни странно, в аврах приоритетов гораздо больше, чем 2…

Изначально плохо продуманное распределение SFR-регистров по адресам (например, TIFR & Co в битово-неадресуемой области, EEDR/ADCW/... в битово-адерсуемой) - бяка.

Для EEPROM и ADC битовость наоборот более удобна, ибо позволяет производить проверку завершения операции одной командой.

--
WBR, Andrew

[ReAl]

Как ни странно, в аврах приоритетов гораздо больше, чем 2…

Прошу прощения, а Вы хоть поняли, о чём я? Мой ответ ArtemKAD выше читали? Как вообще устроена система прерываний хотя бы у MCS51 знаете?
Ещё раз медленно:
Да, у AVR все запросы прерываний выстроены в цепочку, запрос от того устройства, которое расположено дальше от ядра, маскируется тем, которое стоит ближе. Ну без такой цепочки в той или иной форме просто нельзя, надо же как-то выбрать того, кто сейчас будет обслуживаться.
В некотором смысле это можно называть "приоритетами". Но работают такие "приоритеты" только в случае одновремённого анализа этих прерываний, т.е. при строго одновремённом их возникновении либо при их возникновении в любом порядке во время запрещённых прерываний. Если же уже начал работать обработчик, к примеру, SPI, то не имеет никакого значения факт "наиприоритетности" INT0 - оно не прервёт "менее приоритетный" обработчик SPI до тех пор, пока в том не будет выполнена команда SEI. Но сразу после неё резко так обработчик EE_RDY тоже сможет прервать обработчик SPI - т.е. коту под хвост пошло теперь уже то, что обработчик SPI якобы приоритетнее EE_RDY.
Конечно, можно поизвращаться и при входе в обработчик SPI сохранить состояние разрешения прерывания EE_RDY, запретить его, потом сделать SEI, порабтать, (по вкусу - выполнить CLI) и восстановить состояние разрешения EE_RDY. Именно о таком спочобе эмуляции приоритетной системы прерываний писал ArtemKAD. Но это только программная эмуляция того, что у других бывает аппаратно.
В том же MCS51 имеется две или четыре таких цепочки, которая у AVR одна. И битиками можно перемещать запросы между цепочками, не меняя порядка. У цепочек есть свои приоритеты. Запрос из более приоритетной цепочки может прервать уже работающий обработчик из всех менее приоритетных цепочек. Запрос из менее приоритетной цепочки будет ждать, пока не закончатся все обработчики из его и более приоритетных цепочек.
В этом случае, например, можно прерывание от аналогового компаратора переместить в самую приоритетную цепочку и сработка компаратора сразу же вызовет его обработчик - без ожидания, пока
работающий уже в данный момент обработчик какого-нибудь таймера расщедрится на сохранение контекста, для прерываний от UART да ADC сохранит состояния и запретит их, разрешит глобальные прерывания.
В ещё более продвинутом случае у процессора в статусе может быть несколько битов, задающих "приоритет процессора". Только запросы из более приоритетных цепочек могут прервать данный участок кода, остальные подождут.

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

Для EEPROM и ADC битовость наоборот более удобна, ибо позволяет производить проверку завершения операции одной командой.

Товарищ А.Накойхер интересуется - зачем для "проверки завершения операции одной командой" в битово-адресуемой области находятся регистры EEARH, EEARL, EEDR, ADCH, ADCL ? И за компанию с ними UBRR, UDR, SPDR, TWDR, TWAR ?
Господин К.А.Кого-Фига также интересуется - а не лучше ли было бы вместо них в битово-адресуемую область опустить регистры TIFR, TIMSK, GICR, GIFR, а у кого и тот же TWCR (это вообще 5 баллов - у меги8 TWDR "внизу", TWCR "вверху" !!!).

Я где-то выше сказал хоть слово про то, надо было переместить "вверх" регистры EECR, ADCSR ?

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

[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 если не нужна дальше непрерывность кода. А "наименее приоритетные" вообще начинай с этой команды...

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

[ArtemKAD]

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

Код

    acall L_reti; очистка логики прерываний - теперь как после SEI у AVR
...........
L_reti:
    reti

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

Лень - не лень, но странно выходит. Разработчиков AVR Вы защищаете, а у разработчиков AVR-GCC право иметь какие-то свои соображения отбираете.

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

"обработчик как можно короче" читать как "критическую часть как можно короче, после чего перейти на уровень приоритета основной программы".

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

[Rst7]

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

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

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

[SasaVitebsk]

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

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

МК это не лошадь. Его руками и головой делали. Здесь нет полутеней и всё предельно чётко. А посему:
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)

[alexander55]

В одной из первых статей разработчики AVR писали что работают на расширенном контроллером прерываний с поддержкой приоритетов и что данный вопрос "очень сложный" (Хотя несколько непонятно почему).

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

[ArtemKAD]

1) Прерывания в AVR - аналог одного уровня прерываний в x51.

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

[SasaVitebsk]

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

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

[ArtemKAD]

Если делать полный аналог системы прерываний x51 на AVR, то затраты будут куда как более серьёзные.

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

[SasaVitebsk]

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

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

ЗЫ. А зачем делать "полный аналог"?

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

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

[mse]

...Что такого можно сделать на AVR, чего нельзя на x51? Или удобнее на AVR чем на x51?

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

[zltigo]

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

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

[Rst7]

Так что все отнюдь не однозначно

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

[SasaVitebsk]

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

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

[ArtemKAD]

Я надеюсь, вы не считаете что разработчики Intel, просто тупы и не знали что творили?

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

Кроме того, косвенно, на удачность системы прерываний указывает система прерываний xmega, которая заимствует и расширяет принципы системы прерываний x51.

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

А, собственно, в чем прерывания AVR вы считаете лучше чем x51?

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

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

[SasaVitebsk]

Так стоит ли повторять систему прерываний x51? Она Вам сильно не нравится (не дает работать)?

Если бы Атмеловцы создали в целом неудачный камень, или переферия была бы неудачна, то я бы не переходил на AVR. Поскольку я здесь, то ответ очевиден. Но это совершенно не значит, что им некуда двигаться. Я просто отметил, что система прерываний слишком уж упрощена. Это не значит, что ей невозможно пользоваться, но это значит, что с более мощной системой прерываний удобнее работать. И в целом я доволен, что в xmega устранили данный недочёт.

[defunct]

А, собственно, в чем прерывания AVR вы считаете лучше чем x51?

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

Все равно что на вопрос чем периферия 80C51 (напомню, из периферии там всего два таймера, один из которых используется для тактирования UART'a и собсно UART способный дать максимум 57600 на 11.0592 если тактироваться от таймера ) лучше периферии ATMega16, сказать - почти ничем.

Надо все-таки смотреть правде в глаза, по сравнению с m16 в 80C51 вообще нет периферии.

Так и с КПП. Я конечно высказался, что доволен AVR'ом и его КПП. Но раз уж пошла такая петрушка.
КПП AVR не почти ничем не лучше КПП x51, а совсем ничем. Более того он хуже - в нем всего один уровень приоритета, это же очевидно. Но это не делает его неполноценным - им можно пользоваться и с ним можно прекрасно жить.


Самый простой и наглядный пример того когда может понадобиться 2 уровня приоритетов - это если в системе есть DRAM с программным контроллером. Регенерацию DRAM нельзя отложить иначе - капец всей системе. Вот тут второй уровень приоритета как нельзя кстати - т.к. позволяет без раздумий прервать все что можно и регенерировать память во-время.