AVR32 uC3B, Стоит ли рассчитывать на него? Опции

[Прохожий]

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

[proba]

Ну против Renesas-овских чипов я вроде ничего не говорил . Разве что поддержки никакой и не особенно быстрые они - максимальная тактовая не выше 200 МГц.

кажется Вы не особо в курсе с развитием SH. старшие из них IP core, как и MIPS. поэтому, корректно сравнить mips64 с SH5 ( 64bit IP core)
http://www.renesas.com/fmwk.jsp?cnt=sh5_ch...&title=SH-5
или SH4A. представитель: SH77850.
http://www.renesas.com/fmwk.jsp?cnt=sh7785...s/sh7785_group/
что касается подержки то тут SH и MIPS равны, gcc/gnu и linux имеют оба.
но мне кажется это дискуссия давно вышел за пределы началного вопроса так как микроконтроллеров с такими ядрами нет.

[SIA]

кажется Вы не особо в курсе с развитием SH. старшие из них IP core, как и MIPS. поэтому, корректно сравнить mips64 с SH5 ( 64bit IP core)
http://www.renesas.com/fmwk.jsp?cnt=sh5_ch...&title=SH-5
или SH4A. представитель: SH77850.

Если Вы заметили, в контроллерном контексте я говорил про SH2(А) и MIPS32, как самые экономичные. Кстати, официальные удельные производительности - 1,5 DMIPS/МГц у них как раз одинаковы, так что получается, что моя оценка подтверждается и официальными данными. Тактовую частоту в 200 МГц оценил навскидку, не смотря на roadmap, просто из очевидных особенностей реализации системы команд. Смотрю - для SH2, судя по roadmap, так и есть.
Про старшие SH4/SH5, к сожалению, могу только посмотреть картинки, подробной доки нет и шансов на ее приобретение тоже немного, тем более что это скорее "индпошив". Что же касается сравнения SH4/5 и MIPS64, то не очень высокочастотные чипы MIPS64 (RM5231/61, 400 МГц, не более 1.2 Вт, реально меньше) - вполне доступны и документация на них есть. Это не контроллер, но embedded вычислитель сделать на них можно. Достать и запустить SH7785, вероятно, тоже можно. FPU у него выглядит поспециализированнее на графике и подохлее на обычной полноразрядной математике, остальное - примерно баш на баш с учетом тактовой. Периферия побогаче у Renesas.

http://www.renesas.com/fmwk.jsp?cnt=sh7785...s/sh7785_group/
что касается подержки то тут SH и MIPS равны, gcc/gnu и linux имеют оба.
но мне кажется это дискуссия давно вышел за пределы начального вопроса так как микроконтроллеров с такими ядрами нет.

Нет "полноформатных" SH4/SH5, но MIPS-контроллеры есть. У PMC есть как экономичные 400 МГц MIPS32 - микроконтроллеры (MSP8110|20), так и более быстрые (до 1 ГГц) суперскалярные с FPU - MSP8510, это процессоры-контроллеры со встроенными 10|100|1000EthernetMAC, SDRAM int, нормальным контроллером прерываний, UART с FIFO, Watcdog/timers/SPI и т.п.. Еще Cavium делает быстрые и экономичные, в том числе многоядерные контроллеры с архитектурой как MIPS32, так и MIPS64 с кучей интерфейсов, правда, без FPU - а оно-то, IMHO, и представляет самую сильную сторону MIPS64.
Т.е. микроконтроллеры с быстрыми MIPS ядрами и встроенной периферией в виде готовых ИС есть.

[singlskv]

Если Вы заметили, в контроллерном контексте я говорил про SH2(А) и MIPS32, как самые экономичные. Кстати, официальные удельные производительности - 1,5 DMIPS/МГц у них как раз одинаковы, так что получается, что моя оценка подтверждается и официальными данными. Тактовую частоту в 200 МГц оценил навскидку, не смотря на roadmap, просто из очевидных особенностей реализации системы команд. Смотрю - для SH2, судя по roadmap, так и есть.

Давайте, так, остановимся толко на "контроллерных" чипах,
официальными для SH2A являются 2,4DMIPS/МГц, ну и это конечно сильно завышено, но 1,8-2.0
это уже где-то ближе к реальности...
Хотелось бы услышать Ваши коментарии конкретно про чипы 7201,7203,7263,7265.

[SIA]

Давайте, так, остановимся толко на "контроллерных" чипах,
официальными для SH2A являются 2,4DMIPS/МГц, ну и это конечно сильно завышено, но 1,8-2.0
это уже где-то ближе к реальности...
Хотелось бы услышать Ваши коментарии конкретно про чипы 7201,7203,7263,7265.

1. По поводу ядер и реальной производительности - я ее нашел только на SH2, на SH2А пока стороннего результата нету. Учитывая разницу 2 и 2А плюс доработку кодогенератора, ~1.8 DMIPS/МГц при небольшой "доводке" компилятора вполне реальны.
К примеру, для того же MIPS, даже самого простенького ядра 4Kс, в той бумаге, что я выкладывал, приведены как "тупые" 1.39 DMIPS/МГц, так и при разрешенной компилятору глубокой оптимизации, 1.8DMIPS/MГц. Для более сложных ядер там есть и 2.2, и 2.4 DMIPS/МГц для кода из-под компилятора (не "ручного").

По частотам и отчасти архитектуре на MIPS32 больше похоже более совершенное (чем SH2) семейство SH4, у них (с сайта Renesas) http://www.renesas.com/fmwk.jsp?cnt=sh4_ch...&title=SH-4
....
SH-4 family performance
The SH-4 family delivers impressive performance across a range of multimedia applications.
Benchmark Performance
Dhrystone 2.1 1.5 DMIPS / MHz (SuperH gcc)
.....
Недостаток - маловато регистров в FPU, из-за чего трудно использовать полную производительность FPU при цепочечных операциях в цикле, особенно при двойной точности, т.к. для этого нужно примерно 2,5...4*(длина конвейера) регистров.

Введение в качестве базовой операции FPU умножения матрицы на вектор - весьма рационально, у меня самого так было сделано в 1989 году. Выигрыш - существенное снижение запросного отношения (отношения числа доступов к памяти к числу полезных - алгоритмических - операций) при преобразованиях координат, выполнении ДКП/ДПФ/БПФ (особенно комплексного или вещественного с основанием 4) и на матричной алгебре типа решения СЛАУ (чем контроллер вряд ли будет заниматься).

Общее резюме - архитектура целочисленных ядер SH переусложнена, что снижает эффективность ее реализации.
Пока по рациональности архитектуры, похоже, что лучше MIPS ядер реально нет.

2. На 7265 доки пока нет, комментировать пока нечего. Выигрыш от двуядерности в среднем порядка 1.5, но иногда может быть даже больше двойного, если удается разрезать задачу поровну, за счет сокращения числа переключений контекста.
3. 7263 - "Все в одном", вплоть до CD-ROM декодера. Детально периферию не смотрел, видно, что он заточен под аудио-функции (необязательно суперкачественные, но чтобы было все - и прием данных с Toslink/AES, и с CD, и передискретизация, и всевозможные пролоджики/декодирования - 5.1 на процессоре).
4. 7201 - в целом вполне симпатичный камень. Только шин многовато - сложнее управление периферией, а так вполне.
Вообще, нужно смотреть по задаче. Если реально ничего особенного в именно вычислительном отношении не требуется - то что SH, что MIPS - это пальба из довольно громоздкой и прожорливой пушки по воробьям. При аккуратном подходе для преимущественно логических задач хватит недорогого и беспроблемного ARM, а то и быстрого х51. Реакция на прерывания у них быстрая. Лично был свидетелем того, что замена кода с кучей проверок и switch на табличноуправляемый конечный автомат позволила С8051F131 на неполной тактовой справиться с задачей, которую откровенно не успевал отрабатывать PC104
5. Все упомянутые Вами процы Romless и работают от SDRAM, так что это (как и упомянутые мною MIPS) уже не совсем контроллеры, скорее встраиваемые процессоры. Более существенно то, что в описании, наскоро глянув с экрана, я не нашел (может и есть, но не заметил) или принудительного удержания в кэше команд кода обслуживания прерываний или наоборот, блокировки кэша для предотвращения замены его содержимого. Если это так, то из-за этого не только будет замедляться реакция на прерывание, но и увеличатся потери на замещение кэша после прерываний. Перезагрузка линеек кэша вносит задержку переключения контекста куда больше, чем время загрузки/сохранения регистров.

[singlskv]

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

Romless, но все же, оптимально держать обработку прерываний в SRAM, а там кеш
не играет никакой роли...
Вы пропустили в своем описании чип 7203, а он ИМХО, как раз самый интересный.....

[SIA]

Romless, но все же, оптимально держать обработку прерываний в SRAM, а там кеш
не играет никакой роли...
Вы пропустили в своем описании чип 7203, а он ИМХО, как раз самый интересный.....

Если процессору можно запретить при этом трогать кэш, чтобы не было вытеснения - то да, это оправданно.
Завтра внимательнее посмотрю, гляну 7203 - но ядро у него на первый взгляд вроде такое же как у 7201, разница в периферии.
Но честно, не зная задач оценивать трудно. А как "универсальный процессор на все случаи жизни" - таких, IMHO, не бывает.
Нелишне припомнить, что "Буран" успешно был посажен 16-битным (если мне не изменяет память) процессором с производительностью менее 10 MIPS и памятью 128К.

[singlskv]

Если процессору можно запретить при этом трогать кэш, чтобы не было вытеснения - то да, это оправданно.

Не очень понимаю о чем речь, для SRAM работающей на частоте проца наличие/отсутствие
кеша абсолтно пофиг... или я в чем то заблуждаюсь ?

Завтра внимательнее посмотрю, гляну 7203 - но ядро у него на первый взгляд вроде такое же как у 7201, разница в периферии.

ядро одинаковое, разные переферия и частоты ядра, ИМХО, просто очень правильный
чип/"контроллер" из топовых и при этом относительно недорогих...

Но честно, не зная задач оценивать трудно. А как "универсальный процессор на все случаи жизни" - таких, IMHO, не бывает.
Нелишне припомнить, что "Буран" успешно был посажен 16-битным (если мне не изменяет память) процессором с производительностью менее 10 MIPS и памятью 128К.

Дык и AVRом наверное можно было бы посадить
Ну а если говорить о задаче, пусть это будет замена промPC...
То есть не промПЦ в чистом виде, а замена промПЦ+(ну то что удасться впихнуть)....

[SIA]

Не очень понимаю о чем речь, для SRAM работающей на частоте проца наличие/отсутствие
кеша абсолтно пофиг... или я в чем то заблуждаюсь ?

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

Ну а если говорить о задаче, пусть это будет замена промPC...
То есть не промПЦ в чистом виде, а замена промПЦ+(ну то что удасться впихнуть)....

А смысл ? Разработка в целом будет долгой и соответственно достаточно дорогой, при тираже до ~50-100 шт. рентабельнее найти недорогую плату PromPC. Они более-менее приличные от $300-400 начинаются, и потребляют не так уж много. Если задача не слишком сложная - PTS DOS и вперед, при грамотной собственной программе машина виснуть не будет, и деньги от заказчиков пойдут быстрее, чем если возиться со своим железом.

[singlskv]

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

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

А смысл ? Разработка в целом будет достаточно дорогой, при тираже до ~50-100 шт. рентабельнее найти недорогую плату PromPC. Они от $300-400 начинаются.

Разработка софта что к ПромПЦ что к своей плате стоит намного больше чем стоимость одной
платы, так что здесь мало что съекономишь, но можно сделать просто более "правильное"
решение.... ну и тиражи не обязательно ограничиваются 50-100шт.....