Читаю рекламные материалы по AVR32. Понравилась серия AVR32 uC3B. В принципе на него есть все и практически даром. Даже Linux. Планируется к выпуску в 2008 году.
Стоит ли рассчитывать на этот МК?

Ну это как-бы не вопрос для форума ну разве кто-то сможет хоть сколь-нибудь объективно ответить на этот вопрос?! Ну "так" - тенденции реального выпуска новых продуктов у Atmel как-то не очень радуют.

А в практическом смысле. Я вот, к примеру, даже денег немного хочу на это дело потратить. Усилия приложить какие-никакие. Может не стоит? По крайней мере пока?
И еще интересует оценка этого МК уважаемым сообществом в техническом плане.
В рекламке, к примеру, есть данные тестирования AVR32 в сравнении с ARM9 и ARM11.

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

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

Встречается упоминание каких-то новых камней с суффиксом ES.
В даташитах про них ничего нет, чем отличаются непонятно.

ES == engineering sample

Анатолий.

Лично я при погоне за минимальным энергопотреблением и производительности порядка 70...100 DMIPS при 32-битной архитектуре ориентировался бы на MIPS 32 или Strong Arm (серия PXA). Есть еще Renesas. AVR32 по описанию архитектуры хорош, но сложнее вылизанного десятилетиями MIPS, а, значит, больше вероятность засад и глюков.
Еще немаловажный момент - качество компиляции. Компиляторы явно лучше справляются с оптимизацией для простых процов с регулярной архитектурой, поэтому неудивительно, что, к примеру, GCC одни из самых лучших результатов демонстрирует при генерации кода для MIPS. Важна ведь не сама по себе тактовая частота или миллиамперы на мегагерц, а то, сколько будет потреблять система, на которой идет код. Сам процессор может быть и медленнее, зато эффективность кода для него может быть высокой и наоборот.
До сих пор помню шок от скорости работы сишного расчетного кода (типа DSP обработки) на холодном невзрачном 250-МГц MIPS64 - получилось около 200 (!) реальных мегафлопс (у этого процессора 64-битное FPU и целочисленное устройство могут работать параллельно, конвейер короткий, и компилятор умеет собирать целочисленные команды в пару с плавающей запятой, так что процессор исполняет их вместе за один такт). Это заслуга и архитектуры процессора, и компилятора - качество кода едва ли не выше, чем среднего "ручного". Для сравнения запустили ту же программу на PC. Р4 2,8 ГГц на хорошей мамке работал всего раза в три-четыре быстрее (получилось 580-700 мегафлопс при всех флагах компилятора), хотя, конечно, при ассемблерной оптимизации из P4 (а тем более Core Duo) можно выжать намного больше.

А что тогда можно сказать о M4K MIPS архитектуре с MIPS16e?

Хороший, "проверенный временем" 32-битник. Самый распространенный (по числу выпускаемых) 32-bit RISC. Единственная проблема - более доступен в виде IP-блока, а не в виде удобного кристалла, т.к. очень широко применяется в массовой аппаратуре, где любят ASIC. Код для него компилятор делает хорошо. Но, конечно, это не такой "зверь", как MIPS64. Популярная серия их была у AMD - Aureon, кажется. Сейчас за дело взялся Microchip, сделал МК с этой архитектурой (PIC32), жалко, нет пока на борту Ethernet/USB.

Ой, а я думал что Ренесас все-таки здесь рулит, по числу выпускаемых...
Хотя у них конечно вход в тему стои недешево...
хотя можно, вроде как и дешево обойтись ....

GNU тулчейн на основе GCC для MIPS есть (даже здесь klen выладывал), PIC32 для начала легко доступен. На нем и можно попробовать.
Для ассемблерных вставок, если хочется попробовать - Mipster+PCspim.
DSP у них сделано своеобразно, с "несимметричным" (но более экономичным) MACC 16х32, это оправдано тем, что очень редко и исходные данные, и коэффициенты фильтра должны иметь больше 16 бит, обычно что-то одно.
Кстати, вот справочник программиста на MIPS4K.
Ну и обратите внимание на мощности потребления - понятно, почему эти процы так любят производители крупных серий чего-нибудь встроенного.

А вот такая забавная выдержка из статьи http://www.russianelectronics.ru/review/2192/doc4909.phtml



Похоже лоханулись или имели ввиду ARM всёже.

Архитектура MIPS - самая старая, поэтому стоит практически во всем сетевом железе, лазерниках/копирах и т.п. плюс огромное количество ASIC. Поэтому итоговые тиражи и самые большие (чего нельзя сказать о выручке - за IP платежи много меньше, чем за готовые изделия), приближается к ним ARM за счет хорошего маркетинга и большого числа семейств под одним именем. Но сейчас благодаря активизации производителей сетевого железа и гаджетов MIPS (если учитывать их в составе ASIC) опять выплывает "по штукам".
Денег больше всего на рынке 32-битных процессоров зарабатывает Renesas.
Отсутствие упоминаний о MIPS по ссылке объясняется тем, что "негоже продавцу кока-колы говорить про пепси". ARM и MIPS - основные конкуренты в мире IP.

Вот что пишет про MIPS более независимое бизнес-издание:
http://www.primetimetechnology.com/busines...ons/32-bit-mcu/

The company enjoys a commanding lead in embedded SOC design wins and has quietly built a portfolio of well over 100 patents awarded for SOC design IP. MIPS embedded SOC architecture market share is far reaching with:
- 72% of VoIP applications
- 76% of cable set-top boxes
- 70% of DVD recorders
- 95% of cable modems


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

Давай - очень интересно. Хотя я на MIPS переходить не планирую. Каждое изделие свою нишу занимает. Ну и у AVR или даже AVR32UC3 ниша явно не таже самая что у MIPS. Вот AVR32UC3 и скажем ARM в виде at91sam или lpc2000/1000 - похоже близкая.

Вот об этом я и говорил, да и процы у них есть очень интересные и не очень
дорогие, то с чем пока довелось поиграться (SuperH 7201 и 7203) очень понравилось.
Правда отладочные средства стоят безумных денег...

У PIC32 (это контроллер на базе MIPS32) - примерно та же ниша, что и у AVR32UC3 (32-битный MCU с производительностью 70-100 DMIPS и минимальным энергопотреблением). Причем, в отличие от AVR он реально есть в продаже, старшая модель 10-13 долларов. А полноценный MIPS32 - будет конкурентом скорее AVR32С7000, и то пошустрее за счет бОльшей тактовой. Так что назначение близко.

1) Запустите einfo.
AT32UC3B1256-AUT = 11.08$
AT32UC3B1128-AUT = 09.5$
Но думаю что эти цены припадут к осени.
2) Это раньше - сложная система комманд для компилятора являлась непреодолимым препятствием. Теперь я бы этого не сказал. Кроме того существуют библиотеки, где максимально используются все навороты проца. А они, для AVR32 достаточно впечатляющи. Хотябы DSP фичи для не DSP камня.
3) Переползать на PIC32 по меньшей мере глупо. Всё таки я бы выбрал ARM по совершенно очевидным причинам.

Дык, и для PIC32 это все имеется (DSP фичи) + GUI + TCP/IP.


А у меня фирменный ICD2 уже есть. Все, что надо, включая полноценный С компилятор ( с ограничением в 64 кб кода) тоже уже скачал. Операционок тоже валом. Так, что очевидных причин здесь нет. Другое дело, если бы ARM уже был освоен, тогда PIC32 смысла бы не имел. А так...

Я не сопоставлял и не собираюсь сопоставлять PIC32 и AVR32. Для этого надо поработать с ними обоими определённое время. А оценивать по картинкам и сухим строчкам текста я не готов. Но при беглом просмотре это камни из одной ниши (оно и понятно - борьба за выживание). Причины почему нет смысла использовать PIC32 (для меня) следующие.
1) У меня имеются отладочные которые подойдут для AVR32. Плюс для AVR32 сохранены некоторые подходы. Для PIC32 мне необходимо будет приобрести новые отладочные/ компиляторы и среды. Въехать в новую идеологию построения проца и переферии. И получить то же самое (а если честно, то даже не совсем то, - например семейство avr32 кроме корпусов 64/100 имеет и 144, набор переферии выглядит побогаче в UC3A имеются кристаллы с 64к памяти - ну да ладно - будем считать что всё это наживное и PIC32 догонит и перегонит AVR32 по этим параметрам)
2) При переходе на ARM я избавлюсь от зависимости от Atmel, при переходе на PIC я сменю зависимость от Atmel на зависимость от Microchip.
3) ARM не мёртвое семейство, а очень живое, которое развивается усилиями и вложениями разных фирм, что приводит к развитию как очень мощных кристаллов (где он уже похоже доминирует) так и появлению весьма слабых кристаллов этого семейства. А это в свою очередь даёт широту охвата.

Так зачем PIC32 для меня? Ярко выраженное преимущество где? Для тех кто работает с PIC это имеет смысл, но также не имеет смысла переползать на AVR32.

нет их в продаже, не лукавьте. И реальных цен тоже еще нет. Есть только стартер киты. Цена заявлена 5.30$ @ 10K за старшую модель с 512К флеши и 32K SRAM. Начало серийного производства заявлено на 2 квартал 2008, тогда и будут известны реальные оптовые и розничные цены.


нет их и не будет как минимум до августа 2008. и отодвигают сроки запуска пром партий уже второй раз. Имхо, я бы просто тупо побоялся зачинать на нем проект при таких подвижках атмеля.


Очевидных причин никаких не вижу. Единственная - это один дебаггер на NXP/Atmel/STM/.../... и одна среда разработки (последнее правда у нас покупать не принято, так что остается только дебаггер =)
Весь остальной бред об "одном ядре", куче middleware, широкого выбора сред разработки и прочих прелестях давайте оставим маркетингу. Ну и естественно цена - а это уже совсем другой вопрос, который часто все прелести какой-то одной архитектуры убивает в пользу другой


подходы чего? АVR? это абсолютно другой камень, какие там подходы? Про отладочные средства совсем не понял... делать ставку на камень только потому что в столе ICE mkII за 300 баксов лежит?


Не повторяйте маркетинговых анонсов. Куда вы избавитесь? сможете поставить вместо Atmel в то же посадочное место STM32? Или код обслуживания периферии Luminary перепишете за полчаса для обслуживания перифери LPC2468? Точно такая же завязка на конкретное семейство. Абсолютно.


Аналогично 2) - ну и что? чего в ядро-то уперлись?

вообще говоря, для нормальной конторы с нормальными сотрудниками может иметь значение только доступность в регионе, цена, опыт работы с поставщиком. Все остальное не так важно. Любая среда/компилятор и любой отладчик осваиваются довольно быстро по примерам и учебным проектам. Тонкости - в процессе работы. Библиотеки обслуживания периферии у любого вменяемого производителя есть. middleware - то же самое.
Про железо я вообще молчу - в этом сегменте достаточно тупого опыта (меня все время смешат вопросы о "типовой схеме включения LPC/STM/бебебе").
В общем доводы как бы не понятны.

Избавлюсь, например, от желания Аtmel держать повышенные цены для своих приверженцев.

За полчаса не за полчаса, но время на изучение нюансов компилятора конкретной платформы сэкономлю. Листинги читать и на ASM немного писать смогу сразу. Некоторая очень немаловажная системообразующая периферия, типа контроллера прерываний на ARM платформе тоже часто используется от ARM (а остальная в моих случаях особо и не инетесует - она большей частью внешняя - FPGA и прочие немалые чипы). В общем есть причины без особой причины не бросаться платформы на платформу а в качестве базовой выбирать наиболее распространенную, масштабируемую и независящюю на 100% от жизненных обсоятельств единственного производителя.

Вот только вменяемости в этих библиотеках маловато - так "Hello World" .

2 Alex B._ ну давайте я с вами соглашусь на 95% без флейма. Скажем я чуть приукрашал, а вы, соответственно, чуть приупростили.

Банально приведите мне задачу или ситуацию, при которой мне бы пришлось перейти на камень PIC32 и это был бы совершенно очевидный выбор.

Ну это не значит, что периферия не волнует других. Может быть немаловажно наличие CAN, USB, Ethernet, а это уже по сути начинать с начала - даташит, аппноты, ерраты, framework производителя и т.д. А если изделие массовое то тут вопрос о замене даже основного ценообразующего компонента вряд ли встанет, пока этот компонент будет производится. Т.е. лично у меня "случаи" немножко другие.


Для многих этого достаточно чтобы начать. А у ST, например, библиотеки конечно параноидальные и очень тяжелые, но довольно вменяемые. У sharp-а, которые купил NXP - тоже. В общем наличие такого рода софта скорей не минус, а плюс.


да не надо мне одолжений делать


Зачем? я что, тут кого-то агитирую? просто хочется донести свое имхо о приоритетах в выборе линейки на сегодняшнее и на будущее. И эти приоритеты - не архитектура, однозначно. Потому как все эти 32-битники с набортной флешой и тактовой ~70 МГц по возможностям примерно одинаковы. Явного лидера и аутсайдера просто нет.

Напомню суть темы. Все началось с выбора AVR32 в качестве базового 32-битного МК. В итоге выяснили, что это ядро не подходит ввиду его малой доступности. Потом последовал совет использовать ядро MIPS32 или ARM.
Уважаемый SIA, аргументированно изложил доводы в пользу MIPS32 и как один из вариантов PIC32MX. Понятно, что PIC32 выигрывает у AVR32 хотя бы потому, что основан на популярной и распространенной архитектуре, а AVR - на уникальной.
Что же касается ARM vs MIPS, то здесь вопрос открытый. И столкнуть меня, как потребителя в ту или другую сторону может любая мелочь, наличие ICD2 в частности, более простая система команд, RISC архитектура, наличие бесплатного программного инструментария. А если учесть, что в арсенале MIPS наряду с сопроцессором С0, есть еще С1, который вполне может оказаться на борту у PIC-ов в дальнейшем, то выбор будет не в пользу ARM.

Угу ARM9, ARM11 и сопроцессоров как-бы не существует, и объявлено о том, что дальнейшего развитя линейки не будет, пока Microchip не подтянется .

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

В каждом конкретном случае взвешиваются свои маленькие + и - и делается конкретный выбор.

А причем здесь Microchip? Просто пример...
ARM9 - целочисленный процессор, а ARM11 - 4 тех же целочисленных процессора.
У MIPS все несколько иначе:
CP0 - системный сопроцессор, как правило есть у всех МК,
CP1 и СP3 - разновидности сопроцессоров с плавающей точкой.
Соответствующие команды включены в набор команд MIPS32.

Иначе? Вот прямо сейчас в кармане лежит дрееевний девайс на http://en.wikipedia.org/wiki/Texas_Instruments_OMAP
Какие проблемы с сопроцессорами?
Правучка - так и родная:
http://www.arm.com/products/CPUs/architecture.html
http://www.arm.com/products/CPUs/VFP9-S.html
http://www.arm.com/products/CPUs/VFP10.html

Да, до промышленных экземпляров ещё далеко, но образцы и uc3a, и uc3b доступны. Пока сделаете свой девайс на uc и отладите код промышленный выпуск контроллеров avr32 уже будет запущен. Не так всё и плохо как кажется.

Ну длительность разработки устройств на такого уровня контроллерах может начинаться с нескольких месяцев. Успеет Atmel-то . Особенно интересно будет постфактум узнать, сколько сей контроллер будет стоить реально. Образцы это на самом деле имеют смысл для офигенно крупных потребителей, которые оговорят и сроки, и стоимости и санкции при срыве сроков... Ну а поскольку выпуск откладывается и откладывается, то скорее всего никто из монстров пока не клюнул.

Ладно, соглашусь с Alex B._ - особых преимуществ у одной архитектуры перед другой нет.
Набор потенциальных возможностей у обоих конкурентов стандартный - видео ускорители, плавающая арифметика, сигнальные процессоры и т. д.
Тем более, что PIC32 еще нет толком. А все остальное, присутствующее на российском рынке с архитектурой MIPS, пока "не внушает". Разные Мультикоры от Элвис.
Придется согласиться с мэтром. На текущий момент времени в России для МК с 32 битной архитектурой альтернативы ARM нет.

тю, я не делал такого вывода, не надо за меня додумывать. Единственный мой вывод - архитектура это критерий из последней десятки.

А можно первых пару десятков огласить? Любопытно.

Ещё плюс в сторону длительности процесса разработки - новизна архитектуры. Допустим, над дизайном pcb для ap7000 придётся постараться, разводя bga256, а вот с uc3b значительно проще будет с tqfp64. Образцы продаются ~$12-20. Причём не обязательно быть офигенно крупным потребителем, для физ лиц так же доступны образцы.

Вот уж действительно странно слышать…
А почему же тогда AVR стали так популярны?
Сидели бы все тогда на 51-х и не дергались.

1. В свое время лидеры в производстве FLASH сделали дешовый контроллер c FLASH на борту. И большое спасибо им за это.
2. С тех пор, как п.1 перестал быть отличительной особенностью AVR - популярность стала отнюдь не безграничной.
3. И уж AVR точно не вытеснили и уже не вытеснят открытую архитектуру 51 контроллеров выпускаемых множеством производителей.

я писал несколькими постами выше - читайте

1. Российский рынок - это вообще особая статья, на нем x51 до сих пор самые продаваемые. Народ до сих пор на них со всеми ухищрениями лепит системы, когда давно проще взять более мощный камень.

2. Я при сравнении AVR32UC3 и PIC32 говорил, что поскольку их основные характеристики близки, и имеет смысл рассматривать такие "второстепенные" вещи, как архитектура. Ясен пень, что линейка синтезабельных ядер и тулчейн на MIPS за 20 лет отлажены лучше, чем на только что выкаченную архитектуру. Единственный плюс "только что выкаченной" - есть шанс, что легче/дешевле получить техподдержку. Но глюков неизбежно будет больше, а развитие - медленнее, т.к. разнообразные ядра MIPS УЖЕ давно написаны и отлажены (см. http://www.mips.com ), перенос их на кремний - вполне рутинная задача. Для AVR32 - это еще не факт.
Т.о. если начинать с "чистого листа", и нужно получить результат в предсказуемые сроки - риск меньше на MIPS. Тем более, если работать в рамках GNU-GCC, при необходимости проект для подстраховки можно портировать и на ARM.

3. ARM vs MIPS - так вопрос и не ставился, и это все же немного разные классы - MIPS (в целом, я не про PIC32) тяготеет к "монстрам", типа RM11200, и больше заточен на максимально эффективный прогон большого кода из-под компилятора, а ARM - все же более "контроллерная" линия. Но GCC один

4. Есть еще "второстепенные" (но важные для реальной производительности) вещи, типа пропускных способностей, длин конвейеров для заданных тактовых частот и латентностей переходов - по этим свойствам MIPS оптимизирован пока лучше большинства ARM и AVR (квазигарвардская архитектура, большой регистровый блок, относительно короткие конвейеры и т.п.). Соответственно и реальная производительность получается ближе к теоретической максимальной. Но это уже разница (при прочих равных) в пределах 10...40%, не в разы.

Пример того, как все это влияет - см. приложенный файл (результаты EEMBC - сравнение LPC3180 - ARM926 со всеми наворотами на 208 МГц и всеми включенными опциями (+FPU) и старенького MIPS на 400, в варианте 32 бита без FPU (Au1100) и 64 бита c FPU (RM5261)). Разница несколько больше, чем в 2 раза. Вот и наглядно видна "второстепенность влияния архитектуры". Для справки, БИХ фильтры MIPS, несмотря на то, что это процессор общего назначения, считает заметно быстрее (!), чем BlackFin BF533 на той же частоте, и не сильно отстает на БПФ. Все коды из-под компилятора. Потребление у MIPS 32 на 400 МГц меньше, чем у выполненного по более жестким нормам LPC на 208.

p.s. Сам применял и x51, и AVR, и LPC. Так что подход вполне "потребительский" :-)
p.p.s. AVR32 и PIC32 тоже смотрим. Конкретно их пока еще не освоили, но прошлый опыт разработчика процессоров позволяет сделать некоторые выводы..


Не стоит так категорично камни от Fufitsu, Renesas, ColdFire (а-ля MC68000) еще есть, ну и TMS320F28 никто не отменял

А я не очень категорично. Все вышеперечисленное, безусловно, широко доступно, но ARM9 от ATMEL, я могу приобрести прямо сегодня в представительстве ЭФО в нашем городе или от NXP. За сущие копейки.
К "японцам" отношение особое в связи с загадочной японской душой и не менее замысловатой документацией.
Что касается TI, то продукция этой фирмы в большинстве случаев доступна очень слабо. К примеру, их PGA309 я ждал около 3-х месяцев.

Не так продвинута адресация; внешняя шина кастрирована, подключить внешнюю память можно, но выполнить код в ней код нельзя, только для хранения данных; урезанный MMU - это у pic32. В общем, надо говорить, не проиграет ли pic32 контроллеру uc3 в той или иной задаче. Сравнивать архитектуры pic32 и avr32 вообще неуместно.

Ну, по большому счету внешняя память програм и MMU микроконтроллеру нужны как собаке пятая нога (фанаты Линукса могут взять для него специально заточенные камни). А вот по остальным показателям согласно моим прикидкам АВР32 уделает ПИКа32 раза эдак в 1.5..2 - благодаря весьма эффективной системе команд и ряду оригинальных архитектурных решений. Я буду весьма огорчен, если Atmel окажется неспособной довести АВР32 до стабильной серии - к сожалению, финансовые дела Атмела сейчас близки к плачевным

По остальным показателям Renesas SH-2(SH-2A) чипы легко уделают и MIPS и AVR32,
причем именно из-за эфективной системы команд и очень эфективной системмы прерываний,
только загадочная японская душа не может их продвигать в массы, они предпочитают их продавать
массово...
Кстати, к даташитам на Renesas, лично у меня претензий почти нет...
Может я немного японец ?

P.S. Это не рекламма, я пробую чипы разных производителей.
Например SH7201,SH7203,AP7000...
И AVR32 мне тоже понравились, хотя Renesas чуть больше...

А это один из базовых показателей, как справедливо отметил Alex B._ . Если кто-то хочет все и сразу, то это его проблемы.


Фото в студию. Обсудим...

А как у Renesas дела с доступностью средств разработки? Или тоже цены на все заоблачные?

Нужны, тем более маленькому контроллеру. Это большому можно навешать памяти, распределить статически и почивать в нирване. А вот контролеру с небольшим RAM качественный менеджер памяти способный динамически нефрагментированно перераспределять память в очень даже не помешает. Ситуация один контроллер - один программист тоже в общем-то исскусственна и четкое разграничение ресурсов и прав при совместной работе оочень не помешает.

и Linux со своими требованиями к памяти дело второе.

В том то и дело что у них проблем нету, они их продают многомиллионными тиражами,
например производителям японских авто... ну и еще производителям ксероксофф, принтерофф,
факсофф итд...
Правда время от времени у них видимо возникает желание исчо увеличить свою долю на рынке
и тогда они начинаю делать всякие маркетинговые акции, только по сравнению с Атмел например,
они это делают как то неубедительно, видимо менеджемент у них принципиально хочет
сразу миллион и не меньше...
Доступность хорошая, цены заоблачные....
Ну это конечно для "интересных" чипов, для многих есть варианты отладки через просто UART.
Есть Gcc, есть линух...
Ну и есть конечно свой неплохой компилер, это наследство Hitachi
Ну а раз есть компилер, то и есть его лекарство ...

про SH2(A).
есть достоинства так и недостатки.
+ ядро
+ прерывания
+ таимеры
+ gcc ( kpit ) и HEW (renesas)

- дорогие отладочные средства
- потребляемыи ток
- узкии диапазон тактовои частоты , похож что ядро там динамическии
- довольно странныи выбор периферии, например в многих нет быстрого SPI,
или чип с питанием 3,3V а встроенныи ацп с отделным питанием 5v

доки неплохие но уровен апликации низкии - как настроить порт итд. но примеров rtos, fat или законченных примеров нет.
активного форума, посвещенного саита или широкои общины ползователеи нет.

И это все на уровне существенно выше среднего
действительно ужасть как дорого, но для многих чипов таки есть возможность
отладки через UART, даже для некоторых "продвинутых" процов есть вариант встроенного в
прогу монитора который очень прилично умеет работать как отладчик/эмулятор, для
этого у процов есть спец отладочный модуль.
здесь не сравнивал, но по моему если поделить на реальную производительность то
будет весьма достойно.
вот что есть, то есть, быстрый SPI есть не всегда, зато могут взамен
пару аппаратных CAN воткнуть.
Вобщем нужно тщательнее чип выбирать под проект.

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

А если все-таки в числах ... про миллион. Не могли бы Вы на пальцах рассказать про минимальный комплект отладочных средств для МК SH2(A) с возможностью отладки через UART?

Если на пальцах, то нужен чип, UART->PC и библиотека к HMON(внутренний монитор).
Монитор есть(у меня например) не ко всем чипам, для SH7201 например есть, а для SH7203 нету...

Все средства программирования качаются с сайта производителя..
Защита стоит только на компиляторе, а если точнее на линкере,
первые 60 дней все бесплатно, потом ограничение по длинне слинкованного модуля,
но мы же знаем что это не проблемма....
Ну и конечно есть бесплатный gcc, только на сайте нужно зарегестрироваться.

Более подробные ответы при более подробных вопросах...