ARM или AVR32, На чем остановить выбор Опции

[paskal]

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

[elman]

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

[defunct]

Вообще если вариант 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) применять не имеет смысла.

[Methane]

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

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

[Rst7]

Весьма богатая переферия

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

Пиксельный векторный сопроцессор заточенный под видео и набортный DSP, два EMAC'а (AP7000), встроенные audio кодек с стерео DAC и видео контроллер делают AVR32 очень привлекательным.
Бесплатные тулзы под AVR32 - AVR-Studio32 + GCC. Порт линукса есть. Так, что вполне юзабельно.

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

[paskal]

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

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

[Methane]

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

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

[zltigo]

Любая, даже самая удачная платформа когда то сходит со сцены.

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

[Mahagam]

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

[Methane]

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

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

[Rst7]

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

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

[Mahagam]

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

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

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

[Methane]

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

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

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

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

[singlskv]

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

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

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

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

[Mahagam]

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

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

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

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

[Rst7]

и на удивление очень хорошая поддержка линукса

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

[zltigo]

то Blackfin - наш выбор

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

[Methane]

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

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

[Rst7]

Тогда уж и без TCP/IP.

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

[Mahagam]

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

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

[Methane]

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

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

[Rst7]

Расширений сейчас в иксах понаделали

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

[Methane]

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

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

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

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

Причина редактирования: Дублирование содержимого сообщения.

[defunct]

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

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

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

[zltigo]

что в нём такого быстрого снаружи? сорок линий до DDR SDRAM ? так они ж коротенькие. и всего-то до 133MHz.

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

в простейшем случае (без внешней памяти) запросто на двух слоях ложится.

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

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

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

обвеска памятью - один чип за 5-6 баксов,

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

[Rst7]

А если ядро специально заторможено и лишено каких-то вкусностей

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

то зачем себя любимого ограничивать GCC тулчейном

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

[Mahagam]

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

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

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

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

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

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

[zltigo]

2 слоя - это и есть радиолюбительство.

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

[Dog Pawlowa]

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

[defunct]

Насчет лишения вкусностей - вроде то все на месте. Аля-джазели и MMU нет.

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

Насчет затороможенности не очень понял.

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

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

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

[Rst7]

Это хорошо что IAR уже его поддерживает

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

[dch]

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

[singlskv]

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

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

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

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

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

[defunct]

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

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

[singlskv]

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

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

[defunct]

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

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

[DRUID3]

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

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

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

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

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

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

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

Требований к многослойности для 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) с другой есть извесный компилятор и сетевая ОС. А еще у него не плохо с русским - мелочь а приятно.

[Methane]

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

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

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

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