Вот назрела необходимость перехода на более современные контроллеры. Желательно на 32 разряда. Но огромный выбор вызывает чувство растерянности.
Критерии простые: бесплатная среда разработки (сойдет один ассемблер), бесплатный софт для программирования, разумная цена (не обязательно совсем дёшево, в пределах 10$ - разумно). И ещё очень важно - долгоживучесть платформы. То есть чтоб лет через 5 не пришлось переучиваться по новому на другую серию.
Пока мне симпатичны AVR32, но не исключаю и какого то представителя семейства ARMов.
А вы что посоветуете?

По живучести платформы и росту наворочености разработок - однозначно ARM. Вообще если вариант ARM рассматривается то помойму вопрос об AVR32 стоять не должен вообще.

Вообще с Вами согласен лучше остановиться на ARM,
но только AVR32 не такое уж и г чтобы вот так его сразу.

AVR32 AP7xxx рвет ARM9 на одинаковой частоте по производительности как тузик грелку.
Пиксельный векторный сопроцессор заточенный под видео и набортный DSP, два EMAC'а (AP7000), встроенные audio кодек с стерео DAC и видео контроллер делают AVR32 очень привлекательным.
Бесплатные тулзы под AVR32 - AVR-Studio32 + GCC. Порт линукса есть. Так, что вполне юзабельно.
Единственное, с отладчиком и с ценой проца ждет облом. Для полноценной работы нужен как минимум JTAGICE-MK2 за ~300-400$, да и сам проц гораздо дороже 10$ плюс BGA.

Мелкие же AVR32 (серия UC3) применять не имеет смысла.

Кто вам сказал? Весьма богатая переферия, мало жрет, куча DMA итд.

Периферия там от SAM7, насколько я понимаю. ^C^V, так сказать. Ядро продвинутое, тут спору нет. Цены на полбакса больше, чем на аналогичные LPC (ориентировочно по дигикею просмотрел пару-тройку камней, в партии 100 штук).



Я вот неспешно думаю, а не слепить ли на таком камне тонкого клиента. Чисто X11 катать. Например, для этого - http://www.nomachine.com/

Я полагаю, что под живучестью понимается то что ARM уже долгое время находится в употреблении? Но меня то интересует перспектива. Любая, даже самая удачная платформа когда то сходит со сцены. Вот в этом ключе мне интересно, у какой платформы прогноз больше просуществовать - ARM или AVR32? Ведь AVR32 более новые, хоть и менеее распространены сейчас.

У Атмела сейчас некоторые проблемы с бизнесом. Даже микрочипу хотели продаваться. Но штука очень прикольная. Я не видел сам7, но по сравнению LPC22?? переферия ну очень гораздо более развитая.

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

если поднять ценник чуть-чуть выше (до $15). то Blackfin - наш выбор. развивается, появляются новые модели, быстрый (если прижмёт - то или 750MHz или двухядерник дадут жару), DSP-заморочки (вполне поддерживаемые gcc).

Вроде как тормозит безбожно на не DSPэшных заморочках. К примеру на tcp/ip. /* не помню где слышал */

Не продаваться хотели, а некрочип их купить хотел. Был послан набуй, причем не один раз. И у кого после этого проблемы?

у него одна проблема - дюже большой контекст для сохранения (что-то около 136 байт).

вполне нормально он обрабатывает всяческие переходы.

34 слова. Что-то сильно дофига.


А приёмные буфера ethernetа могут в SDRAM находится?

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

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

Ну а перспективы конечно пока нафиг не ясные...

угу. меня тоже поразило. основные регистры, указатели, два ожиревших 40-битных аккумулятора, DAG`и, кучка регистров для организации аппаратных циклов, статусные всякие. набирается


того не ведаю. DMA там точно будет.

Не, это фтопку. Я собираюсь свой X-сервер сделать. Без всяких линухов.

DSP, это DSP - не только быстый внутри но и быстый снаружи - требования к питанию, разводке, многослойности плат, загрузочные флешки, при использовании, как контролера общего назначения быстро кончится набортный RAM - опять обвеска памятью .....
Не нужны DSP навороты - надо ооочень крепко думать по поводу использования DSP. Нужны DSP навороты - тоже думать, ибо парочка 32bit контроллер + массовые FPGA с теми-же умножителями на борту очень на многое способны. Была несколько лет назад мысль на переход на BlackFin - сделаны прототипы, все достаточно нормально, но теперь лежат пылятся - для моих применений по любому свое железо в FPGA нужно, вот и вступлением того-же Cyclone-2/3 в майнстрим DSPшная ветка замерзла.

Тогда уж и без TCP/IP. Чего уж там, мелочиться.

Совершенно непонятна Ваша ирония. Можно подумать, что X11 - неподъемная вещь. В лайт-варианте реализовывал еще в 97'м году, не умер. А сейчас-то экспиренса некисло прибавилось

что в нём такого быстрого снаружи? сорок линий до DDR SDRAM ? так они ж коротенькие. и всего-то до 133MHz. жрёт немного - просто тёплый, а вот плисину кстати можно довести до состояния "очень горячая" - так у кого требования к питанию больше будут?
в простейшем случае (без внешней памяти) запросто на двух слоях ложится. загрузочные флешки в более менее современных камнях - почти любые. обвеска памятью - один чип за 5-6 баксов, зато потом можно писать не напрягаясь.

Расширений сейчас в иксах понаделали, что "мама не горюй".

Да я не спорю. Я ж не зря про NX разговор завел. Например тут - http://www.nomachine.com/documentation/pdf...-strategies.pdf - можно почитать про стратегию портирования. Достаточно обозримо.

Достаточно. Но зачем от Linuxа отказываться, я не могу понять. По моему более логично сделать на уровне ядра framebuffer и дальше работать через него. Там тоже какие-то хардверные ускорители присутствуют кажись. Там только с лицензиями проблема - все что включено в ядро, должно быть в исходниках. А nvidia и ati исходников не дают. Поэтому такое и получилось.

Кроме просто рисования линий, там возникнут проблемы со шрифтами, с переключателем раскладок клавиатуры, с мышами всех мастей итд.

Хотя, я не знаю что вы задумали.

Это я говорю. Для малого потребления и богатой периферии чем не подходит ARM с ядром Cortex-M3? И тулчейнов больше и дешевле они и надежнее. Периферию Atmel использует абсолютно одинаковую для своих линеек 32-х битников (ARM(SAM) и AVR32). Выбор тулчейнов и отладочных средств под ARM гораздо шире...

Остается искать преимущества только в ядре. А если ядро специально заторможено и лишено каких-то вкусностей (UC3), и легко можно найти подходящий более дешевый ARM на замену, то зачем себя любимого ограничивать GCC тулчейном, AVR32 Студией и JTAGICE-MK2? Получается, что смысла использовать кастрированные AVR32 нет.

Тем не менее это уже не специально заваленные фронты, как у контролеров общего применения.

Ложится, ложиться, так и сделано в прототипах, ибо было достаточно только SPORT-ов, SPI и UAT. Только вот тот-же JTAG c другими обьединить надо уже изголяться.

Но защита идет лесом....

Ага и + 2 слоя разводки. Да-да "у кого-то работает в двух", но мне хотелось-бы без радиолюбительства....

Насчет лишения вкусностей - вроде то все на месте. Аля-джазели и MMU нет. Первое - так точно не нужно, второе - ну, полезно, но на небольших камнях и без него ниче жить. Насчет затороможенности не очень понял.



Логично. Есть EWAVR32

на таких расстояниях - никаких проблем не наблюдается.


2 слоя - это и есть радиолюбительство.
компромиссы - они везде. но факт есть: на 2-х слоях блекфины прекрасно работают.


идёт. AD некий LockBox придумала. не знаю - может и поможет.

ПЛЮС два слоя.

В группе embedded related lpc2000 аналогичная война. А автор вопроса и не предполагал, что тут баталии

+ Частоту понизили в 2.5 раза, vectored multiplier убрали.


сделали его медленнее, что не понятного то?


Это хорошо что IAR уже его поддерживает, но нет и никогда не будет поддержки RVDS'ом, Keil'ом..

Он его от рождения поддерживает. Причем отлично (я про качество компилируемого кода). Там, видимо, опять консилиум предварительно некисло позаседал в составе IAR'овцы+AVR'овцы.

S3C4530 7 баксов, одно врема даже звездочкой маркировался

Флаг Вам в руки, причем без всяких и ...(те без танков на встречу...)

Если реально сможете поднять, снимаю шляпу...

Там просто ИМХО до первых разумных результатов, пол года работы в одиночку.

Хотя результат может быть очень красивым ...

Если человек знаком с Atmel'овской периферией, то задача упрощается на порядок.
А если еще и подобный готовый проект под Atmel'ный 9-й ARM имеется, тогда это IMHO вообще вопрос недели максимум.

Видимо я что-то упустил...
Где-то есть открытый проект X сервера под 9-й ARM без линукса ?

Возможно у Rst7 есть.

? это как ? И какой стек? AD или Linux? Но, скорее всего, у кого-то были просто проблемы с геометрией рук...


А где им еще быть))).


X-сервер? OK! Дадите потестить? Насколько помню именно "сервер" - это мега-пупер необозримый проект с безбашенной архитектурой. Даже Танебаум был вынужден "взять готовый" хотя по этому поводу "скрипели" адепты 10kloc в minix. Кстати, если не загоняетесь - советую дать знать сообществу minix что работаете над "облегченной" версией...


Требований к многослойности для bf 531/2/3 в QFP корпусе практически никаких. 400Mhz ядро + 100MHz SDRAM вполне по силам с "радиолюбительским" подходом. Очень плохо, то, многие контроллеры особенно со специфической периферией представлены только в BGA. Это далеко не так маловажно как может показаться - ведь как раз у маленьких, фирм ничем кроме бюджета (в том числе на монтаж) не ограничен полет фантазии , да и студенту в 100 раз легче спаять и освоить "на практике". Вот сейчас ожидается новая серия bf 51x - при всех "+"-х предшественников (QFP-включительно) еще меньшее энергопотребление(!), аппаратные Ethernet(не у всех моделей) и flash(!, правда тоже не у всех) на борту!
А на счет DSP. Так DSP DSP'у рознь . Если floatpoint то он курит в сторонке относительно того же ARM9. И Linux там не настоящий, многопоточный но не многозадачный. Кстати это очень важный момент - если стоит задача приобщиться ко всему многообразию доступных на сей момент GNU Linux исходников (приложения, библиотеки и т.д.) для embedded(не десктоп и не сервер) - то здесь собственно другой альтернативы кроме ARM9(MMU & fp coprocessor) просто нет. Уже для того же bf многие исходники придется долго перерабатывать. У blackFin'а своя ниша - обработка видео, звука с качеством mp3, спецмодемы и прочая заказуха. Linux для bf - это отличная возможность небольшой фирме(малый коллектив разработчиков) практически честно выйти на рынок - с одной стороны множество исходников под bf на сайте самого производителя(но требуется напильник для применения их в GCC) с другой есть извесный компилятор и сетевая ОС. А еще у него не плохо с русским - мелочь а приятно.

Оно из флеша тормознуто работает. И переключение контекста тоже довольно тормознуто происходит в ихнем порте freertos.


GCC работает не хуже. Они всей толпой заседали.