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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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

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

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

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

--
WBR, Andrew

Прошу прощения, а Вы хоть поняли, о чём я? Мой ответ 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 - это не так дорого стоит, гораздо дешевле умножителя. Без которого тоже можно жить

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

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

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