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

Да нет там в этой совместимости ничего сташно тормозящего прогресс. В больших процессорах поддержка x86 (читай 86,186,286) чисто небольшая заплатка. Сами старшие модели в защищенном режиме вполне себе нормальные 32bit процессоры. О чем можно спорить? О том, что они, напрмер, не RISC? Были-бы RISC вот тогда... что тогда гигагерцев больше выжали? Была-бы другая "супер архитектура" в два раза быстрее PC грузился? Никто на данный момент не может ничего предоставить в два раза "шустрее", не говоря уже о том, что-бы это было еще в два раза дешевле (старая истина о завоевании массового рынка - все удвоить а цену в два раза снизить).
AVR32 в своем сегменте никакими революциоными качествами не обладает - там снизили, там повысили, там пообещали, там несколько (в рекламных целях) новых "прогрессивных" абревиатур изобрели.
Не быть ему лидером. ARM во время своего появления тоже не блистал, но по крайней мере два революционных свойства содержал - открытость к выпуску сторонними производителями и экстремальная простота, позволяющая производить приличный контроллер на дешевом/устаревшем оборудовании.

В принципе согласен, но при одной оговорке. При правильном подходе можно вырваться в лидеры. Это сделать можно, но для этого звёзды должны красиво лечь. Ну каковы были шансы у Била Гейтса с его Microsoft стать компанией #1?

Здесь я неправильно выразился. Сам по себе проц как проц. Ну было на тот момент регистров 8 штук. Тогда это была норма. Сейчас ни одна контора с таким количеством регистров проц не выпустит. А сейчас добавлять - бессмысленно из-за СОВМЕСТИМОСТИ. (Вот вам пример, хотя и мелкий). Второй момент страничная адресация. Хотя и преодолена, но раком.
Но в принципе здесь я с Вами согласен.

В большей степени сам IBM/PC как таковой. Вот Вам список архитектурных хомутов которые тормозили и продолжают (пусть косвенно) тормозить прогресс. (Большенство устранено, но не вылезая за рамки - мы же понимаем, что с чистого листа таких решений бы не было).
- Структура памяти
- Структура памяти под внешние устр-ва и в первую голову под VIDEO
- адресация переферии
- система с BIOS и BIOSа различной переферии
- ISA переферия. И как результат шина PCI с оглядкой на ISA.
- IDE да и вообще файловая система фат с её четырьмя ревизиями (Это уже софт конечно, но я просто привожу пример как передовая технология при ИЗЛИШНЕЙ СОВМЕСТИМОСТИ может тормозить развитие новых технологий)
ну и так далее. И ведь все это понимают, но начать процесс наново ни у кого не хватает финансов-желания-возможности.


А вот здесь я с Вами не соглашусь. Вы уж простите. И AVR я выбрал не из-за флэши и частоты. На тот момент флэш была у той же 51 от той же Atmel, а частота AVR была 8МГц и они писали в ответах пользователям, что выше не будет!!!

Основным была система комманд. Грамотная, продуманная. И реализация прерываний. И на сегодня лучшая чем в ARM. Хоть и не безупречная. Колличество регистров. По началу действительно на асме практически все писали. Не то что к Си, - к инету доступ был нулевой. Ну и AVR Studio это был последний штрих.

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

Так что AVR Studio - это был колоссальный шаг на встречу разработчикам.



Теперь об AVR32. Посмотрите на систему команд этой однокристалки в свете моих признаний. Посмотрите и честно ответьте сами. Есть там что "революционное" или нет. Не всё ведь в мипсах выражается. Так в своё время при переносе одного изделия с х51 на AVR я с удивлением обнаружил, что она и по коду практически один в один. Хотя х51 8 бит код команды, а AVR - 16 бит. А по тактам совсем наголову. Причина - аккумулятор в х51. (Тоже кстати серьёзный тормоз х86 процов). Так что RISK-RISKу рознь. Если здесь я одной инструкцией две ARMовских заменю - то это как революционно? А если пятью - 15?

Теперь о самой системе команд. Да.... На асме там не попишешь.... Я бы сказал, что она ближе к Intellу. Только более продумана. Я о том, что команды разной длины, ортогональные (как они пишут) различные до безобразия. Объединены в разных немыслимых комбинациях. Есть и трёхадресные и двухадресные. Есть DSPишные.


Одним словом не так всё однозначно zltigo. Мне если чесно её пока некуда воткнуть, а вот Вам бы как раз я советовал бы присмотреться. Во всяком случае когда массово пойдёт.

Каким-таким "раком"? В protected или flat режимах обычнейшая линейная 32bit адресация.

Структура - 32bit линейная адресация. Какие проблемы?

Опять путаете с реалмодовым режимом???

Э... А как простите система грузиться/инициализироваться должна? Ну а после загрузки пользоваться BIOS никто не заставляет.

Много лет уже нет ISA, MCA, VESA, AGP, PCI помирает... Вы в каком мире живете?
PCI, кстати совершенно межплатформенный стандарт .... был....

Совершенно непонятно какое отношение это к x86 имеет, но SСSI, SATA не приходилось слышать?
И какой такой неизгладимый отпечаток x86 на IDE нанес?

Количество файловых систем ввиду их софтовости превышает все разумные границы, причем количество FATов исчезающе мало на общем фоне файловых систем. Тормоза от такого разнообразия имеют место быть, но причем опять здесь x86?

Вполне себе в лоб сделанная, поскольку ресурсы позволяли на тот момент уже более навороченное контроллерное железо, нежели почти десять лет назад. Думали там уже мало - можно уже было "просто
трясти". Вот и потрясли, потом мне помнится еще и утрясать пришлось

Попробуйте поработать. И, кстати, контролер прерываний от ядра не зависит и может быть и не от
ARM а и самодельный (у STR7 он полное дерьмо) и улучшенный.

Ну Вы же как раз меня понимаете. Прикидываетесь только.

Ясно что самой ISA уже давно в помине нет. И мой самопальный программатор под эту шину (Ээээ-эх) давно подарен пионерам. А то что Вы перечислили - это уход от данного решения. Посмотрите сами. Всё сделано с оглядкой на ISA. Для совместимости.

При обращении к ISA устройствам по сути происходит задержка(Точнее ожидается ответ PCI и если он не приходит ч/з нек. время операция на шине завершается). И по барабану что данная переферия в мат плату интегрирована. Система добросовестно выжидает ответ (PCI то ответит быстро - ISA никогда). Само устройство может и быстрее сработать, но шина не позволит. Разве это не пример того что передовое решение тормозит дальнейшее развитие из-за совместимости?

Да Вы правы память в защищённом режиме одним куском. Да и до этого было 10 решений того же плана. Но все эти телодвижения EMS, LIM и прочие, сама винда начальных этапов - это же только из-за необходимости совместимости. То есть опять начальное решение - передовое по тому времени из-за совместимости с какого-то этапа является тормозом.


Ну посмотрите, если бы сейчас проектировали процессор с чистого листа. Да ладно не сейчас - лет 20 назад. А процессор был бы предназначен для замены текущих офисных - мог бы появится монстр типа нынешних? Да не в жизнь. С точки зрения электроники - он был бы таким же. Но система команд, структура регистров были бы в корне отличными! Почему же такой монстр является основным процессором? Только из-за совместимости!

Посмотрите на процессоры Sony PS/3 или XBOX. Вот это процессор реализованный с чистого листа той же Intel. И отличается он от пня как небо от земли. А почему его применили? Почему не пень? Потому что игры или графика??? Нет! Основная причина, что совместимость поддерживать не надо! Всё равно всё придётся менять! И видеоподсистема организована совершенно по другому.



Я стараюсь делать совместимые вещи. Я же не являюсь законодателем. Но когда совместимость является тормозом, то пусть болезненно, но умирает, а на её место приходит новая технология.



Конечно возьмём наладонники. Как туда воткнуться AVR32. Да для этого необходимо полностью переписать несколько тысяч программных продуктов! Но всё-таки это значительно проще чем переписать десятки миллионов под PC. Так что шанс есть. Если будет грамотная политика фирмы, поддержка со стороны крупных фирм ПО + звёзды лягут грамотно. Хотя шанс и невелик.

Единственно, чего я понимаю, что Ваши познания кончились в 90м году на IBM PC-AT286 c мегабайтом памяти . Не обижайтесь, пожалуйста, так есть

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

Это Вы батенька последний раз на 386 машинах видели в BIOS настроечки частот да вайтстейтов для
клавиатурных и прочих контроллеров. А потом они исчезли начисто, ибо стали именно интегрированными и вполне себе шустрыми.

Абсолютно правильное поведение для обращения к периферийному устройству - таймаут должен быть.

было и закончилось еще в 80x годах прошлого века с появлением 386 процессора.

Был-бы другим, как стал другим AVR8 по отношению к 51,85,PIC. Но при этом ни он, ни AVR8 не стали автоматически много быстрее и много дешевле.

Ну и какими? Где сейчас (уже спустя еще 20 лет), хоть в проектах и высоконаучных статьях это в корне отличающееся чудо?

Как небо от земли отличался "EE" процессор Sony PS/2 вот тот был немеряно крут - 128битный по тестам вдвое делал современный ему PIII. Где это чудо техники? Что выросло из этой новейшей хреновины?
НИЧЕГО.
Что имеем сейчас? Имеем круто завязанную многоядерную хреновину из вполне себе привычного ядра PowerPC. Программирование это хренядерного чуда отдельная песня - переписывать можно и не пытаться - все с чистого листа.

Основная причина в том, что совместимоть с PC будет смерти подобна Нужна именно несовметимость.
Рынок таких домашних мультимедийных консолей (игрушки даже дело второе) явно будет очень велик - надо его столбить и выпихивать разных там "безродных" подражателей всеми силами. Даже сами процессоры поштучно вроде и продавать и не собираются - только готовое изделие.

Ну лягут AVR32 в наладонник фирмы X или мобильник фирмы Y, как Cell лег в игровую консоль фирмы S, это ведь не сделает его лидером рынка 32bit-ников.

Я не обижаюсь. Я упрощаю. Я просто прошу признать, что совместимость вначале приводит к рывку, а потом, ч/з определённое, время является тормозом. Ответьте только на этот вопрос. Да или нет?

Не могу сказать, что прекрасно знаю что именно эмулируется в новых матерях , а что нет, но не думаю что кто-нибудь знает реально намного больше. По простой причине. Сейчас сложно влазить в переферию. Даже те кто делает платы под PC врядли владеет полной информацией где что и как там работает. Ну уж не до такой степени я отстал как Вы считаете. Я тем не менее экспериментировал (хотя и чисто для любознательности) как работает та или иная переферия. В частности soft и hard модемы, звук, клава, порты и т.п. Хотя признаю что знаю здесь мало. Сейчас совсем времени на самообразование недостаточно. Но я стараюсь.

Ну ответьте тогда Вы. Почему на Ваш взгляд у этого камня нет никаких шансов? Чем он так плох? И неужели Вы считаете, что система комманд вообще ни чего не решает? А что тогда? Почему именно Вы не хотите его применять я понял конечно сразу. Признаю. Ваша позиция в этом вопросе прояснилась для меня ещё на обсуждении PICов.

Я не буду больше плодить флуд и флейм. Простите за этот. И остановимся на Вашем ответе.

Успехов! Я просто использую индустриалки в своих системах в некоторых случаях со своей старинной операционкой писанной на, черт побери, ASM - приходится копаться

Уже дважды писал - монопольное ядро в нынешних времена массовым не будет. Под массовостью имеется ввиду не количество (запихнут в Nokia мобильники уже будет немало) чипов а количество разработчиков и производителей его использующих.

Да не плох он, он ОБЫЧЕН.

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

Да вобщем никто не говорил о лидерстве. Тему я вообще создал из интереса к новому ядру, это просто интересно как программисту, а не как аналитику по развитию рынка. Однако сам думаю - кристалл некоторый кусок рынка захватит, и вообще... поживем-увидим.

Малое количество регистров x86 сильно ограничивало скорость выполнения программ, а попытки это исправить были очень непростыми с точки зрения железа (введение большего количества "фантомных" регистров и хардовой манипуляции ими с предсказаниями потоков данных, перестановкой инструкций и т.д. - то, что реализовано в 32-битных пнях)
В 64-битных пнях. Там всё по-другому.

Они стали не совместимыми с 86? Все "по другому" с точки зрения набора команд, стало уже в 386.
С точки зрения архитектуры все "по другому" на каждом новом чипе делают. Так-что поминать 86..286 в качестве неправильных процессоров можно, но распространять их проблемы на все совместимые чипы и поминать поддержку совместимости команд в качестве чего-то жутко обременительного право не стоит.

Оптимальный скомпилированный код для 386 оставался почти оптимальным для всех x86 вплоть до Pentium-4. А вот на новых 64-битных процессорах для получения адекватной производительности придётся программу перекомпилировать. То есть, на уровне бинарников совместимость присутсвует, но весьма сомнительна ("для галочки").

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

Оправдание этому - обилие софта и его дороговизна. Почему большинство юзеров покупали PC-совместимые компы? Потому что под них уже было написано много полезного и нужного софта, это важнейшая причина их популярности. Несовместимость могла убить серию x86. А вот в случае с МК несовместимость не фатальна, имеет смысл ставить на первый план вопросы себестоимости и быстродействия, а отдавать предпочтение совместимости лишь при прочих равных условиях.

Мы это о чем? Зачем "плавно" полезли в качество работы старого набора команд?




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

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

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

Не угадали. Я 15 лет занимаюсь программированием, в том числе есть большие проекты на x86 ассемблере. И очень хорошо знаю, чего стоит разработчикам ограничение в 8 регистров. Некоторые предпочитают не видеть эту проблему, отказавшись от ассемблера и ваяя в ЯВУ. Но проблема-то останется Кстати, большинство оптимизирующих компилятров пользуется стеком лишь когда не хватает регистров. Вероятно, Вы никогда не заглядывали в ассемблерный листинг PC-программ.

Аналогично, только лет побольше и проекты бывали очень большие.

Для профессионального писательства на АSM и с 32бит регистрами и полным (в отличие от охремонно регистровых архитектур ничего кроме пересылок регистр-память не имеющих) набором команд для работы с памятью ограничение вполне мягкое.
За плечами проект тянущийся со 286 процессора. Порядка 200K кода, исходники до размера всех трех томов Войны и Мира не дотянули правда, операционка, виртуальные машины, Ethernet, всякой хрени включая шустрые поиски в базах....
На момент перехода на 486 досаду от нехватки регистров испытывал максимум пару раз.
Досада от сопровождения всего этого дерьма на ASM ни в какое сравнение с проблемами нехватки регистров не идет.

Не заглядывал - я с ними работаю.

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

Легко. Опыт есть.
Уже писал - система команд x86 позволяет нормально работать с памятью, в отличие от обычного явления для простых многорегистровых архитектур (в том числе и ARM) в которых нихрена не сделаешь не распихав предварительно "большие числа" по многочисленным регистрам с последующей обратной пересылкой в память.

Кушйте на здоровье .

Вот и приходится работать с памятью, временно загоняя туда регистры, чтобы потом через несколько инструкций их оттуда читать. Увеличение количества регистров в два раза значительно бы ускорило выполнение кода. Железо в идеале может сделать обращение к памяти таким же быстрым, как к регистру, но не может уменьшить количество бесполезных пересылок туда-сюда. Из 8 регистров один указатель стека, другой указатель фрейма стека, дальше нужны пара указателей на буферы в памяти, один счётчик цикла, и остаётся для собственно самих вычислений почти ничего. Так что "легко" не получается. Меня каждый раз душит жаба, когда приходится тратить драгоценные такты на временное сохранение в память из-за нехватки регистров. Можно, конечно, на всё положить и писать не задумываясь о тактах, как Вы наверное и делаете, но это "лишь бы написать код", а не "написать эффективный код". Архитектура должна давать возможность (по крайней мере, не препятствывать) написанию эффективного кода, а тут получается прокрустово ложе. Ф топку! Собственно, уже там (с переходом на 64-битники).

Ну не надо ТАК делать - работайте сразу с памятью как раз НЕ гоняя тупо во многих случаях вообще ничего между мамятью и регистрами.
Типа:

Когда с ARMом начинал работать как раз скомпилил кусочек AES алгоритма IAR-ом под ARM и Watcom-ом под 486 для общего ознакомления. По количеству команд 486 был где-то 190 команд и 500 байт размер. У
ARM более 250 команд и соответственно размер боле 1000. C оптимизацией я естественно разобрался до эксперимента. Работа была с матрицей, вот уж где пересылок туда-сюда у ARM насмотрелся . Регистов IAR из всего богатства использовал семь, Watcom - пять.

Это конечно ДА! но не надо забывать что как правило на CISC машинках эти 190 команд будут значительно медленне для заданной частоты конвеера чем 250 RISC команд, за что и платится в общем случае большим объемом кода (собсна платится за простоту и скорость RISC ядра)

А на счет удобства... это вопрос не конкретный. Комуто вообще WLIW лучше, мне так многорегистровые архитектуры нравятся больше. А кто асма не видел ему и вообще плевать.
По мне так все зависит от конкретной задачи.

А вы посмотрите, сколько тактов займёт прямые операции с памятью без загрузки в регистр. Видимо, вы вместо быстродействия кода заботитесь об удобстве программирования. Это разные вещи.

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








В данном случае мы как-то отклонились от общих случаев к конкретно старшим x86, а в них уже многое и успешно сделано для нарушения этого "правила". Да конвеер и предсказатель много сложнее и не однозначнее, чем для RISCов с ограниченным набором команд фиксированного размера. Но эти узлы не являются определяющими сложность нынешних процессоров и что самое главное - работают. Я лично уже не понимаю как, но РАБОТАЮТ!

Солидарен, ув. SasaVitebsk.

Сам немного скептически относился к рождению сего чуда, однако AVR32 найдет своего покупателя, это уж точно, и свои вложения Атмел окупит с лихвой. Продуманная архитектура, высокая производительность, богатая система команд (особенно порадовал набор DSP инструкций - аж 23(!!!), для сравнения - в ARM966 - всего 5.), низкое энергопотребление, богатейшая периферия - разве этого мало? А если прибавить к этому низкую стоимость чипов(если таковая будет)? Почему русский разработчик боится новшеств, вот это непонятно. Конечно есть и такие, кто с 51 на AVR перейти не желает, даже наблюдая 100% выгоду от этого (был у нас один такой фрукт). Но ведь в большинстве своем мы с вами люди творческие, и консерватизм в сознании - это самый большой вред, ибо конкурент не дремлет. Соглашусь, что не в каждом проекте можно использовать "вещь в себе", однако не стоит этим злоупотреблять и пытаться унифицировать все разработки в рамках отдела, например. Зачастую это бывает крайне нелогично и невыгодно.

Некоторые приписывают старый добрый AVR к аутсайдерам - ну зачем же самому себе врать? Да будь это так, Атмел давно бы свернул это направление, а нет же, наоборот развивает! Недавно анонсированные MCU на основе AVR32 выглядят особенно привлекательно, и, полагаю, составят серьезную конкуренцию MCU на основе ARM. Ждать осталось не долго.

Совершенно случайно наткнулся при поиске AMD чипов:
http://hard.compulenta.ru/cpu/pda/
Ну что тут сказать - "В очередь, сукины дети, в очередь!" Абсолютно этои cегментом не интересовался и не ожидал такого количества желающих залезть и уже залезших в эту нишу. Причем это реально первый попавшийся явно не полный (AVR32 даже нет )русскояэычный ресурс.


Это случайно не про меня?
Повторюсь - AVR8 не аутсайдер, он победитель на ныне сужающемся ( прежде всего в ценовом отношении) рынке восьмибитовиков. Буде лично мне потребуется в новой разработке восьмибитовик, то с наибольшей вероятностью я выберу AVR. Поблема (для Аtmel ) в том, что пока не потребовалось и вероятность этого события для меня не велика.

О нет, Вы не так сильно задели судьбу AVR в своих рассуждениях, был другой выступающий. Но суть не в этом. Рынок 8битных MCU по количественной характеристике не сужается, задачи для них как были, так и будут еще долго. А вот в процентном соотношении конечно сужается за счет того, что появляются новые архитектуры и увеличивается разнообразие существующих, так как потребитель требует решения под новые задачи. Поэтому мы наблюдаем как бы вытеснение процента 8разрядников, хотя на самом деле их доля выпуска не сокращается.

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

Забавно.



И вот такой вот маленький довесок.



AVR32 Studio!



Ну и судя по ценам они начали очень агрессивную политику на рынке. Я, к примеру не думаю что такие цены на STK будут постоянно. Раньше ценами на STK Atmel не баловала. И совместимостью отладочных средств - не злоупотребляла. Чего стоит только JTAG под at91sam7, который не работает с другими ARMами. А знаменитый Dragon? Да и к JTAG ICE2 у меня в этом контексте есть претензии. При его то стоимости.

Внесу некоторую ясность. У Атмеля есть 2 линейки с ядром avr32. Первая - серия AP7 и вторая UC3. Я так понимаю, UC3 - это облегчённая версия AP7, т.е. малобюджетный вариант. Исключены некоторые модули, которые есть только в AP7 и более низкая тактовая частота, благодаря этому в кристалл впихнули 512кБ флэш памяти, т.е UC3 это уже линейка контроллеров с ядром avr32.
По поводу AVR32 Studio. Это чистой воды eclipse + gcc, т.е. те, кто работал на arm без проблем освоят Studio.

Один вопросик...
Чем этот AVR32 программировать и чем отлаживать? Если только JTAG ICE 2 за 300 баксоф то в гробу я этот avr32 видел...

Осмелюсь предположить, что в серийных образцах будет загрузчик, что-то типа SAM-BA.

300 баксов за дебаггер не так уж и много в масштабах предприятия или его подразделения. Более того, давайте вспомним сколько стоил JTAG-дебаггер на заре ARM?

Доброе время суток, собрался отсваивать авр32 ) ну нада же с чего-то начинать, и почему бы не с нового чипа, имхо.
поставил АВР32Студию, но на простую студию она немного не похожа скажем так.. может кто нибудь уже что либо пробовал писать в студии и эмулировать там.. вопщем обрадуйте любым примером как создается проект в этой среде...

может быть вы мне поможете...

или лучше искать IAR а студию ф топку?

никак не арзберусь с этим компилятором.. уже выдрал библиотеки из IAR-а, и пример кода оттуда же но компилироваься оно не хочет... просит файл test.elf, test - имя проекта.. а вот откуда этот файл взять и что он из себя представляет?

У вас в проекте должен быть Makefile в каталогах Debug и Release. Дык вот, находясь в том каталоге, где Makefile, дайте команду make, а то, что она выдаст - сюда, смотреть будем.

Я конечно "дико извиняюсь" ( и сам приложил немало "усилий" для увода этой темы с первоначального пути ), но уж не слишком-ли это? Что мешает отдельную тему создать для обсуждения?

Насчёт студии ничего не скажу, а вот что касается IAR - напишите мне в приват, посмотрим что можно сделать.

IgorKossak а Вы что думаете по поводу данного камня?
Особенно нового подсемейства UC3? Похоже ему можно будет найти применение. Корпус и остальные характеристики вроде вполне. Правда в продаже Q4Y2007.
Будете пробовать применять?

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

IAR выпустил новую версию среды.
Если кому интересно. Проект судя по всему прогрессирует.

Интересно... А еще интересней, где бы в Украине купить самих процов... Парочку... Троечку...

рано еще процов, в питер еще не привезли набору гейтвэя... а камни тои подавно я думаю...

IgorKossak, там что-то существенное изменилось ? смотрели?

Выкладываю релиз ноуты, судите сами, что для Вас существенно.

У www.biacom.com можно заказать ... Тянуть будут из склада из Германии ... Если Парочку... Троечку ... чтобы больше 50 долярей могут и взяться ...

Тю, блин...какая Германия? В ЭФО $15,5 в розниццу.

UC3 бы баксов по 10. Ну ладно по 12.

UC3 в виде образцов появится после лета, так что облизываться пока рано.

Интересный ресурс Atmel выпустил для продвижения avr32 avrtv.com

AVR32UC3С будет содержать Ethernet или нет?

Недавно вышел подробный анонс AVR32 UC3 microcontrollers ( http://atmel.com/dyn/resources/prod_documents/doc7919.pdf )
И хоть это уже релиз G (а внутри написано H), он примечателен тем, что открыл подробности будущей серии AVR32UC3С (с буковкой C на конце)
Смотрю на табличку "Product Selector Guide" (на стр. 15) и вижу у серии UC3C среди периферии Ethernet/MAC.
Читаю описание серии на странице 14 - никакого Ethernet'а нет и в помине:

The AVR UC3 C Series is designed for industrial and automotive
control applications, including high-speed communication and
motor control. The devices feature single or dual CAN interfaces,
a full speed USB with OTG, NAND flash and SDRAM interface,
PWM with dead-time insertion, two 1.5 MSPS 12-bit ADC with
16 channels and dual sample-and-hold circuitry for synchronized
sampling of 2 signals, two 1.5 12-bit analog DAC with dual
outputs. Designed with the multi-layered AVR32 databus, 68
KB on-chip SRAM with triple high-speed interfaces, and multichannel
Peripheral and memory to memory DMA controller, the
AT32UC3C offers outstanding data throughput.
The AT32UC3C Peripheral Event System provides a connection
between on-chip peripherals to off-load the CPU, reduces power consumption and provides a deterministic
response to external and internal events.

В прошлом релизе ( http://www.ebv.com/fileadmin/products/Prod...32_Brochure.pdf ) Ethernet/MAC был только у серии A (UC3A), а у других серий его не было. А вот сейчас Ethernet появился в табличке и у серии C (UC3C).
Это опечатка или решение компании добавить Ethernet в промышленный МК?

Если судить по заголовочникам из AVR32 Studio 2.6
То в UC32C0/1/2 MACB есть.
Есть еще заголовочники, которые помечены, как REVC, там нет.

А откеда у вас студия AVR32 Studio 2.6? На сайте последняя из раздающихся - 2.5.

Не заработал, надо полагать

От верблюда
http://www.atmel.no/beta_ware/

ЗЫ: Новый фрэймворк
http://asf.atmel.no/

Скорее наоборот, собираются добавить. Старую ревизию оставили для совместимости.