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






А почему Вы думаете, что познакомившись с микроконтроллерами в 1984 году я за прошедшие годы не освоил не только "вышивание на машинке", но и вышивание без машинки, и без микроконтроллера , и не только вышивание....

А я ни разу в Вас не сомневался. Про "вышивание на машинке" - то я про себя, запас веселых приемов у меня немалый, и я их применяю без зазрения совести, с удовольствием и с удовлетворяющим всех результатом.

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

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

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

Я думаю позиционирование AVR32 расчитано на пользователей AVR8 которым надо чуть больше. Они начинают вертеть головой и, очевидно, что придут к ARM. А ARM это уже не только Atmel. Иными словами - задача - удержать часть пользователей, для которых сложные изделия - единичные.

Ага, у Атмеля денег дофига, что ему стоить потратиться на разработку ядра avr32 и начать промышленный выпуск. Или по Вашему они удачно пыль в глаза пускают? Тут 32х-битники потихоньку съёдают 8 битники, поэтому и у avr32 будет, по моему, такой же пик популярности как и у avr8, скорее свего, это да же не 2008, а как минимум 2009.

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

все проблемы Атмел начинаются и кончаются здесь:
http://www.advfn.com/nasdaq/StockPrice.asp?stockprice=ATML

Дела у них не столь плохи.
Это у всех американских компаний сейчас такая ситуация, связанная с падением USD...

В рецессии Америка...

Именно так. Ключ к успеху - маркетинг, а не техническая рациональность или изощренность.
А дальше - закон снежного кома. Помним историю х86? Сама Intel, понимая ее кривость, еще "в те времена" дважды пыталась перейти на другую архитектуру - не вышло.
Motorola с реально хорошими 68К - по большому счету пролетела. Мало сбыта - высокая цена - мало сбыта - нет средств на совершенствование - закрытие темы....
Я и про MIPS (наступавший на те же грабли - неумение продавать реально хороший товар) вспомнил здесь только потому, что
а) люди в MIPS Technology похоже, таки маленько поумнели (занялись периферией, "голый" проц редко кому нужен, как бы ни был сам по себе хорош), и, главное (!)
Б) за маркетинг взялся Microchip, а у них это поставлено всегда было куда лучше, чем у Atmel Соответственно, и развитие темы будет, и MIPS поможет

Только вот судя по лихорадке с маркетологами у Atmel просто никак . Ибо "-Девушка, что Вы делаете сегодня вечером? -Все" это не маркетинг , это другое...

Вот про такие ситуации, когда надо "не в принципе, а конкретно", Saymor Cray и любил говорить "Машина, про которую нельзя точно сказать, что она будет делать в каждый машинный такт - в реальном мире неконкурентоспособна по определению. Даже если она и быстра в принципе, то на практике часто подобна сороконожке в припадке эпилепсии" .
Именно поэтому ядра процов, где нет четких цифр и черт ногу сломит в оценке времен - применять стоит не всегда. К примеру, даже при чисто расчетных задачах компилятор запросто "ногу сломит" при оптимизации потоков через конвейеры и раскладке по регистрам при вычислении даже простейших последовательных операций типа

A=aaa;
for (i=xxx;i>=0;i--)
{
B=C[i]+D[i]*E[i];
A+=B;
};

и будет вынужден дожидаться прохода по конвейеру всего первого выражения перед переходом к следующему накапливающему суммированию.
В результате проц не покажет и 1/5 скорости от той, что мог бы в теории при параллельном запуске ветвей в конвейер и совмещению суммирований.
В процах Intel/AMD это пытается разгребать аппаратура. С переменным успехом и жутким (по сравнению с собственно АЛУ) энергопотреблением.
Плюс непредсказуемость точного времени выполнения вообще. Оно в рилтайме надо ?

p.s. в ядрах MIPS, как и во многих других, особенно DSP, но почему-то далеко не во всех ARM, "жесткая" диаграмма обеспечена.

А можно ссылочку на весь текст? Интересно, в контексте обсуждения какого вопроса он это говорил?

Да семидесятые годы прошлого века. Лобовое решение за государственные денюжки - 80Mhz 64Bit очень круто. Но давно мир переменился. Переменился даже спустя 10 лет - Cray2 был многопроцессорный и судя по цитате страдал не только эпилепсией, но и шизофренией с размножением личности .

Времена безумно давние, нас тогда на свете не было.
А говорил при ответе на вопрос, почему транзисторная CDC6600 1964 года работает быстрее микросхемной IBM360/91 68-го
IBM по указанию своего президента купила экземпляр CDC6600 для исследований. Но это не помогло - следующее детище CDC - CDC7600 - оставило всех "с носом" и держало "голубую ленту" 8 лет. Тоже чисто транзисторная была машина (10...30 Мфлопс в зависимости от задачи). Дальше были уже Cray.


Нет, как раз не лобовое. Лобовое - это ILLIAC. И не на государственные денюжки (госзаказ из Ливермора пришел потом, после успешной демонстрации - более 100 Мфлопс на реальной задаче, при том что в описании обещалось "up to 80"). До этого Крэю пришлось все делать "на свои" (для чего пришлось продать свою долю в СDC). Все делали сами - и микросхемы (топологию ИС) рисовали, и схемы, и платы, и документацию. Весь коллектив создателей Cray1, при том, что это была разработка с нуля - от элементной базы включительно - меньше 20 человек, и денег было в обрез, экономили даже на рубилите (15 баксов лист - в 1975 году это были ДЕНЬГИ).
Зато продавались Cray как горячие пирожки именно потому, что цена выполненной полезной операции у машин Cray до начала 90-тых была наименьшей на рынке.
Плюс отличный компилятор, мало проигрывавший в циклах "ручному" коду, а местами и обставлявший его на распараллеливании.
До 90 года даже массовый ПК давал много меньше 1К флопс на доллар при несравнимых прочих характеристиках (у Cray Y-MP в те годы было ~ 800 флопс на доллар).
Сейчас самый дешевый полноценный (64-битный) флопс получается на MIPS64 и некоторых Power PC (IBM750СL ~$25 за Гфлопс).

p.s. Жесткая (предсказуемая) временная диаграмма - необходимое условие нормальной работы любого WLIW/EPIC процессора. Даже Intel такой сделала для серверов.

Посему не стоит серьезно относится к мемуарной литературе.

Даже самые продвинутые ошибаются (я про Saymor Cray). Не жёсткая и непредсказуемая временная диаграмма уже победила. Оглянитесь вокруг. Но это только начало долгого пути.

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

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

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



Ну если не видите причин...
Предлагаю Вам проект вывода графики на телик(телеметрия например...)
Какой АРМ выберем ? Как будем выводить ?

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

А насчет "сложности компиляторов" - к сожалению, дело не в "программных технологиях" как таковых (кстати, компилятор для практически любой машины уже давно научились писать за разумные сроки, особенно после работ Гриса, Ахо/Ульмана и появления Lex/Yacc). Компилятор чистого С на них делается не больше, чем за месяц, дальше - "раскрутка" (трансляция написанного на С С++), и пошло-поехало. Задачу оптимальной раскладки регистров решил еще Ершов И "параллельных" языков довольно много (см. по ссылке в конце).

Дело в другом - в конфликте парадигм - "последовательное" написание кода и сильно распаралленное/конвейеризованное исполнение. Т.е. в человеческих мозгах, наработках и тоннах уже написанного кода.

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

А прорыв, кстати, уже есть, и именно для WLIW/EPIC, где есть жесткая диаграмма, которую компилятор может учесть при планировании трасс. Началось все с проекта Multiflow в 1980-х, затем доведено до живого продукта Дитцелом и компанией в Transmeta.
Но важно не это, а то, что Intel вложила в это направление большие деньги, и провела много НИОКР. О результатах части из них я знаю, выигрыш в производительности на единицу мощности потребления/площади кристалла действительно огромный - на порядок-полтора при той же технологии.

Идея именно в том, чтобы убрать из процессора дающую большие задержки логику планирования команд/загрузок/отслеживания конфликтов и фактически оставить только набор АЛУ/память, все планирование выполняет компилятор, генерирующий "длинные" команды для прямого управления аппаратурой. Кстати, примерно так (и по тем же самым причинам) и были сделаны крэевские машины, особенно последние, разработанные при его непосредственном участии.
Так что идея не устарела и вполне здравая. Похожим образом делаются как самые мощные DSP TMS, так и "бытовые" зверушки PNX1300/1500/1700.

На рынок ПК эта технология в полной мере вряд ли придет скоро. Проблема и в маркетинге, и в технике. Первое, при таком подходе нет 100% бинарной совместимости. Нужна перекомпиляция (пусть даже и "невидимая" для пользователя). Но желательно, с анализом исходника. Техническая проблема - для реализации достигаемого выигрыша в быстродействии для больших объемов данных предъявляются более высокие требования к пропускным способностям подсистем памяти. Т.е. нужна куча DIMM, чтобы был эффект - кеши не всесильны, их грузить откуда-то надо и быстро. А если всего этого нет и хочется оставить х86 бинарную совместимость, без анализа исходников - то получится Crusoe со всеми его недостатками (экономичный, но более-менее быстрый только на "родном" коде).
Для мощных же контроллеров с большими вычислительными возможностями - вполне то, что надо. Собственно, упомянутые PNX - и есть такие контроллеры.

За чисто параллельные и многопроцессорные вещи - это скорее в www.parallel.ru

Такой как тут - http://www.jandspromotions.com/philips2005...55_abstract.pdf
Справится с этим АВР?

Числа с 15 могу заняться. Задание за Вами, условия оплаты моего труда назову.

Зависит от задания. Если речь идет о том, что AVR по плечу - врезке монохромной растровой картинки,
то, например, любой LPC23xx/24xx c фифофированным SSP на борту создаст отличный битовый поток. Более серьезные вещи - надо присмотреться, например, к BlueStrike (тоже недорого - баксов от 6-7)- у меня как раз вся ARM7 линейка в качестве образцов есть. Поскольку телек вобще-то избыточное усройство, то вывод прямо на панель явно более предпочтителен, то тогда
BlueStrike точно.

А на фига такой, простите, маразм ? Если задача реальная, а не "демо" и нужна графика, то на телик лучше нормальный простенький графдисплей забабахать, типа 320х200 или около того, как в первых ПК (commodore, AppleII etc) было. На простенькой ПЛИС + ОЗУ, если не хватает накристального в ПЛИС. Функциональность больше, да и в разработке едва ли не дешевле будет - не нужно будет такты высчитывать при каждой коррекции кода. Клок опять-таки независимый будет - можно подстраиваться к телесети и врезать картинку без влияния на проц.

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

Похоже, Atmel тоже не вспомнит толком Новые архитектуры на сегодня, похоже, и на микроконтроллерном рынке просто экономически не оправданны. "Старые" бы "проредить", чтоб типов меньше, а продаж каждого - поболе.


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

Как-то такой падение не согласуется с последними новостями: Atmel to Acquire Quantum Research Group
Напомню, Quantum ведущий разработчик по сенсорным интерфейсам.

Это ничего - разделю на несколько тем, как только минутка свободная появится.

to jasper:
акционера интересует прибыл, и прибыл от сенсоров виднее ( на основе экомонических отчетов QuantumG) чем от AVR32uc3, которому еще рынок наити нaдо. кроме того, продукции QG тепер будет болще на базе avr8 ( там и microchip и renesas сеичас), т.е. этим шагом и дополнительныи рынок получили.

А причём здесь многопоточность. Работал с ней до и после появления двухядерных CPU. К железу это отношение имеет слабое. Просто так ОС построена. Грубо говоря это и на AVR8 реализуется в какой то степени. О каких проблемах речь?

Это я к тому, что компания с финансовыми проблемами вряд ли будет заниматься подобными приобретениями.
Рынок у AVR32 будет, если выставят привлекательные цены на камни. Основания к тому есть, им ведь не надо платить отчисления ARM.

ЗЫ: Кстати, производством чипов по технологиям Quantum сейчас занимается ST, конкурент Атмела.

Здорово! А своим разработчикам железа и инструментального софта, типа не надо? Или они их в России за еду наняли ? Остальные производители видимо не догадываются о таком крутом способе экономии, как "сделай сам". Кстати, у NXP, как совладельцев ARM, пожизненные лицензии.

А кто вам сказал что атмель купил квантум в феврале 2008? =) есть мнение, что это произошло в начале осени 2007.

Дык и Renesas тоже. Договоренность у них с Quantum

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

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

Я использую UC3A0512 в проекте беспроводной видеокамеры. До этого работал с ARM7 чуть-чуть. По моему мнению микроконтроллеры от Atmel на ядрах AVR32 и ARM отличаются в основном... ядром Периферийные блоки, такие как SPI, I2C и наверное многие другие реализованы аналогично, регистры управления у них одинаковые!
В комплекте поставки AVR32Studio (GNU лицензия) имеется масса драйверов. По-моему так вообще на всю периферию. Причём демонстрируется это на РАБОЧИХ примерах. Я проверял работу таких устройств и периферии: ethernet, usb, SD, SPI, I2C, UART, DMA, ЖКД, GPIO, ШИМ. Реализован стек tcp/ip lwIP под freeRTOS, на нём подымается ftp, www сервер. Очень радует то, что все примеры запускались без косяков.

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

М-да, не густо, это что-ж получается, на этом форуме только один человек взялся использовать AVR32.
Неужели всё так бесперспективно с семейством AVR.

Вот только слез не надо. Ну я собираюсь в 2 проекта сейчас заложить UC3A0512.

Мгновенно вспомнилось бессметнтое "Кому и кобыла невеста".
Если кому-то, то что в примерах идет есть "рабочее", то тогда и редькинское гуано (даже так - отборнейшее гуано) несомненно шедевр.

Никак не могу разделить вашей иронии. В своём коммерческом проекте задействовал большое число реализованных модулей, а именно: SPI, UART(debug), LCD(debug), GPIO, блок питания и тактирования, DMA. Если бы мне всё это пришлось реализовать самому, с изучением всех регистров и тонкостей периферийного блока, я бы не уложился в срок. Хотя думаю,не стоит объяснять что значит наличие примеров под платформу.
А вот за книгу мне просто обидно. Неужели вы думаете, что даже просто перевести 800 страниц документации на микроконтроллер, да ещё и организовать эту информацию в своём видении плёвое дело? А результат - это "отборнейшее гуано". Или я вас не правильно понял?

Пока публикаций по семейству мало, она не придёт в массы. Хотя я считаю, что она может составить достойную конкуренцию ARMу в техническом плане.

Степень комерциализации проекта не слишком коррелирует с тем, как он написан.

Поняли совершенно правильно. Автор Редькин есть настоятельная рекомендация не покупать книгу. Поищите по этому форуму по "Редькин".

Я не думаю, я знаю, что ничего более БЕСПОЛЕЗНОГО нежели перевод документации быть не может.

ну еще меня посчитать можно ... 3 железяки на UC3A512 сварганили ...
из фреймворка править только драйвер macb пришлось , дабы реагировать на появление линка ... А так - почти все сразу завелося ... Грабли только с evk1100 были , пока es на нормального не переставили




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

ЗЫ про редькина не спрашиваю - доку предпочитаю в оригинале читать

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

Я увидел прожорливость только по памяти - стандартные структуры включают в себя наборы всех регистров периферийного блока.
Когда захотел оптимизировать модуль spi по скорости, то понял, что ассемблер там не даст весомого ускорения. Код написан на Си, и я считаю очень качественно. Единственное что там можно было ускорить, так это организацию потоковой передачи. А нахрена? Врубил DMA и радуйся Так что насчёт кавычек я всё же в корне не согласен. Оптимизация под конкретный проект в любом случае остаётся прерогативой разработчика. Если он хочет потра?аться и изобрести велосипед, который поедет на 20-30% быстрее (ну ладно в два раза, и такая скорость всё равно будет не востребована) фирменного и при этом у него останется свободное место на заднем колесе, то это его дело Но я думаю это никак не касается UC3. Железка интересная и поддержка исходниками присутствует.

Перевод даташита - это в основном для общего ознакомления и для обучения.

если не секрет - почему именно их? а не кортекс-арм?

Пусть "разработчик", если он в кавычках, лепит, как может. Это по нынешним временам действительно стало обычным явлением. Пусть тот-же "писатель" Редькин лепит в меру своего полного непонимания, что творит "книги"... Это тоже стало обычным явлением. И на этом делают деньги. Только я не могу согласиться, что это нормальное явление и так и надо жить.

В одном проекте нужен камень с поддержкой SDRAM в более-менее вменяемом корпусе (заказчик хочет не хуже xQFP144) с >=256К набортного флеша и Eth.

В другом - именно тот самый выигрыш в быстродействии, который на Load/Store. Там просто алгоритм O(log2(N)), соответственно, небольшая прибавка к производительности сильно прибавляет N. Собственно камень там будет заниматься банальным поиском по бинарному дереву, перевешивать сегменты из очереди приема в очередь передачи MAC и патчить одно поле в пакете по результатам поиска. Будет такой себе роутер Циске на зависть

Вчера (!) выпущен AT32UC3L (в анонсах он был объявлен ранее). Пико-токопотребление (0.48 mW/MHz), 48 ножек, $1.96 (64K flash) и $1.47 (16K flash) в партии 10 тыс. шт. Источник - http://finance.yahoo.com/news/Atmel-Introd...ml?x=0&.v=1 , даташиты здесь -
http://www.atmel.com/dyn/products/product_...sp?part_id=4591

Не , ну я малость по нудю Что в драйверах из sf писано "левой ногой" Хотя-бы пару примеров можно ? Может я и лох полный , но я предпочитаю собрать из готовых кирпичиков макет , малость попинать его , а потом уж заниматьмся оптимизацией всего щасться .... И как-то пока получалося ... Но бороться в основном приходилось торько за память - производительности и размера флеша заглаза хватало ... А камушки приятственные IMHO
PS вот завтра плату на живучесть в печке бум гонять поглядим какой он Сухов .....

Хорошо звучит Особенно, с тремя ревизиями в даташите



Ну это завлекалочка для инвесторов. Хотя, меня бы очень устроил такой камень. Если бы наши торгаши по $2.5 за 64к-версию его привозили, я бы закладывал вместо ATMega88/168 с удовольствием.

И чего народ так еррат боится? Их надо рассматривать не как недостатки процессора, а как недостатки даташита .