На ftp залита презентация, посвященная новому семейству XMEGA

/upload/MCs/AVR/XMEGA_Intro.rar

Продублировано на рапидшаре

http://rapidshare.com/files/56659668/XMEGA_Intro.rar

Весьма интересные получились камни.

Интересно, почему в презентации график "CPU Usage vs USART baud rate (without DMA)" нелинейный? Или график специально загнули для усиления визуальной разницы между двумя кривыми? Ох уж эти маркетологи-пиарщики...
Знаю, сейчас скажете "а вдруг это логарифмический масштаб". Только естественно ли выражать линейные зависимости (например, закон Ома) на нелинейных сетках?

Да, очень весело получилось. Наконец-то чистый 3В АВР.

Блин, ну зачем еще один зоопарк разводить ? Есть и AT91x, LPC21xx, добавьте к ним 1% VRef и DAC, будет тоже но с лучшими параметрами. Пусть лучше расширяют линейку дешевых АРМов (например упакуют в ДИП), останется что-то типа ATMega8x, ATTiny, больше ничего не нужно...

Смеялсо...Сколько у АРМ время реакции на прерывание? В тактах, пжлст.

8 * USART - впечатляет.
Добавили бы еще хотя бы один CAN!

Atmel хочет построить забор без дырок (по производительности).
Пусть расцветают все цветы (Мао).

Вполне нормально, я поддерживаю

тоже поддерживаю... Буду ждать даташита на любой из кристалллов...

Зря. Смех без причины даже "блондинок" украшает недолго.

0. А у XMEGA какое?
1. Такты совершенно не интересуют. Интересует время.
2. Время реакции само по себе бесполезно - критический момент время ОТВЕТНОЙ реакции и/или исполнения обработчика прерывания. На уменьшении этого времени крайне положительно сказывается быстродейстаие ARMов и наличие отдельного банка регистров.
3. Количество тактов поменьше FastIRQ, может быть резко уменьшено неиспользованием команд групповых пересылок, вокруг которых собственно практически весь сыр-бор обычно и поднимают.

Ага, и еще хотелось бы сравнение лично от Вас, zltigo, по такому параметру как
Потребление vs Скорость реакции

З.Ы.Ваше негативное отношение к AVR всем уже давно известно, и ИМХО, как модератор данной
ветки, Вы должны соблюдать хотя бы минимально, пусть воинствующий, но нейтралитет...
Иначе, странный такой модератор получается, скорее цербер

FIQ 180ns
IRQ+VIC 220ns
Если посчитать сколько времени нужно для АВР ,думаю не будет повода для особого растройства
Если прикинуть насколько быстрее у АРМ будет выполнена подпрограмма обработки прерывания ,думаю будет повод даже порадоваться
Я уже не говорю про VIC (по идеологии типа таблицы прерваний АВР) где можно выставлять приоритеты и источники произвольно
Если кто то до сих пор думает ,что АРМ медленно шевелит ногами ,в частности LPC - это делает за 2 такта

Список еще можно продолжать ,просто реально нет интереса ,что либо сравнивать ,по мне сравнивать
АВР и АРМ ,тоже самое как запорожец с трамваем,разные они по классу задач.

Перед тем как чего-нить заявлять, таки придется все точно подсчитать
А кто Вам сказал что задача будет такой что потребует быстых 32битных вычислений ?
Этот вопрос без обсуждения конкретной задачки вобще безсмысленен...
А вот здесь я с Вами даже спорить не буду, задам тока один вопрос, при шевелении ногами
АРМ, вы сами четко себе представляете когда и как он ими пошевелит ?

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

я например еще не встречал задач где нужна точность программной выдачи сигналов лучше долей микросекунды (ну разве что экзотика типа генерации видеосигнала и т.п.).
Вот только непонятна жмотливость производителей на периферию - почему бы не сделать минимум 4-6 16-битных таймеров с неколькими каналами ШИМа на каждом - очень часто не хватает и приходится программно извращаться. Причем таймеры нужно сделать одинаковыми, а не так как в АВРах - каждый сделан по своему, ну и ШИМов бы побольше. ЦАПом аж теперь разродились - вроде ничего сложного, а очень часто бывает нужным. А недостатки системы команд и адресации таки не исправили.

У меня ХОРОШЕЕ отношение к AVR, нет серьезно хорошее! Я только всегда выступаю за необходимость
знать, думать и выбирать. Это, к моему великому сожалению, как-то очень болезненно воспринимается массовыми любителями AVR (особенно AVR+ASM).
А аргументы в стиле "зато мы в области балета...", "Смеялсо..." я воспринимаю плохо вне зависимости от платформы и всегда стараюсь лично (а не как модератор) не пройти мимо.

А потом красоту логотипов на корпусах???



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

Разумеется, в каких временых пределах это произойдет у конкретной АRMовской периферии я представляю четко. Так-же четко представляю, что светодиоду, который у меня подключен к дрыгающейся ноге, это без разницы .

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

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

Заложил LPC2106. Доставали долго и по финишу 13.5$ в Минске. И все ходят хороводом - рассказывают как мне повезло! Залазишь на einfo - появились at32uc3a, с явно более красивыми характеристиками и за 10.5$. Но очевидно что это только старт. Думаю скоро увидим их за 8. Цена важна, но не главное. Теже меги достаются на раз и в любых количествах. Только появились - бери не хочу. Шаг влево - шаг вправо - заложил какой-нибудь ST - получил головную боль. Достать не могут - переплатил вдвое. Совместимость ARM7 семейства м/у собой тоже не бог весть какая. AT91 и тот же LPC друг от друга отличаются не на много меньше чем таже мега от ARM7. Если на Си писать.

Но в общем я не ратую за конкретный МП. Наоборот. Пусть их будет много. Именно в этом свобода выбора разработчика. К тому же если на пятки LPC будет какой нибудь at32 наступать, или какой нибудь dsPIC, то глядишь и цена на этот LPC припадёт немного. А это пользователям ARM тоже приятно.

Золотые слова.

Нет, извините, не понимаю.

Есть, очевидно, заповедные места, где платят деньги за разработку "контроллеров светодиодов" и "контроллеров кнопок" (пусть и очень быстрых), но я таких не знаю.

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

Да.

Ответный вопрос - намекните, что это за задачи, коих " подовляющее количество" которые являются критичными по времени входа в прерывание (десятки-сотни ns) и при этом ничем в обработчике прерывания собственно и не занимаются. При этом они работают, как я понял в устройствах с батарейным питанием.



Саша! ну по одной они цене или даже дешевле. Перестаньте просто заниматься покупками у себя в Витебске в гастрономе, в штучных колличествах через кучу посредников. Ну глянул даже на российский MT-System - - семь баксов (с налогом) они, 27285 штук на складе - бери не хочу. А если что-то типа "Залазишь на einfo" , то т явно меньше.....

Подтверждаю, очень лояльные цены на LPC (они партнеры Philips). Как с доставкой не знаю (это к ним), но люди там хорошие.
Они все время открывают магазины по бытовухе (Мир Техники), может у Вас уже есть.

Чего здесь не понимать?

разве не смешно?
Ножкой подрыгать точно-вовремя бывает очень нужно. И это не светодиод. А про время реакции 180нС на прерывание от тимера расскажите кому-нить другому. Или то были не вы, или не от тимера, ужо не вспомню. У него только текущая команда может исполняться не знаю, скока, тактов. У меня на штатных Атымельих частотах было, написал как. Это отстой.

Нет.

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

Насчет времени реакции на прерывания от внутреннего таймера, смею Вас заверить, Вы совсем не подумавши ляпнули, ибо оно значения особого не имеет, ибо это просто фазовый сдвиг от генератора фаза которого изначально не известна и соответственно любые задержки его фазы по барабану.
Так-что имеет физический смысл только время реакции НА ВНЕШНЕЕ ПРЕРЫВАНИЕ. Кроме того, разговаривать о десятко-наносекундных временах реакции на прерывание для сколь-нибудь маломальски сложной программы работающей с несколькими периферифнысм устройствами бесполезно, ибо появление нескольких источников прерываний и критических секций прикрытых запретом прерываний практически неизбежно.
Короче, хочется узнать, чего это такое все делают, чего я не знаю.

Насколько я понял, это последий "аргумент"

тоже весело

приходит синхросигнал и по его фронту/срезу надо выдать данные (отлов его тоже в прерывании, что добавило экстриму). Побитово. В фоне крутится задача. Обычный ССИ и СПИ не катят.

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

Да бога ради, например обычный последовательный интерфейс, жостко синхронизированный извне. На достаточно высокой скорости с нестандартным кол-вом бит.
И не надо напрягаться, что вы чего-то не знаете, "ибо" разборкой и пересылкой ТСП пакетов круг ембеддед задач не ограничивается. В этом смысле, вы имеете право многого не знать. ;О)

Это вывод.
Для этой и родственных задач. А так камушки как камушки. Но будь щас 32мипсовая мега, она бы уделала в этой задаче любого "8-бит реплаце" АРМа.

Ознакомился с презентацией. Сразу понравилось то, что побороли главный недостаток ATMEGA - низкую тактовую частоту на 3,3В. Из-за этого хотел переходить на ARM. Теперь при 32МГц, эта проблема отпадает.

Из-за чего спор?

Ну, выпускают новую линию AVR. Да, более точный RC генератор и опора позволят отказаться от внешних компонентов. Флеши, правда, многовато для применений, где это критично. Запихнули бы они это в нижние модели - было бы полезнее. Вообще IMHO если больше 64К флеши - нужно использовать 32-битные ядра. Да, наверное существует промежуточная ниша для таких кристаллов. Спорить о чем? Если в системе нужен ARM и с точностью до такта дерганье линиями - не грех в нее поставить и FPGA...

Не факт. У меня, например, девайс должен уметь работать с огромным количеством протоколов обмена. Благодаря наличию большого флеша эта задача просто решается. И конечный пользователь сам выбирает нужный протокол из имеющихся. В противном случае пришлось бы делать кучу разных прошивок для разных заказчиков. Не-е-е, большой флеш нужен обязательно.


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

Дык, и удивительно, о чём спорить? Посчитали маркетологи-инженегры-манагеры Атмела, что надо такое и столько, флаг им в руки. Они лучше знают кто, что и сколько у них покупает и чего хочет. А я куплю, если надо будет и ничьего аффтаритетного мнения спрашивать не стану. Это вопрос ихних и моих денег. А то:"зачем это, если есть то". Ездили б тогда на Камазах каких или Сканиях Ивековых по Риге-Москве-СПБ. Они вон скока всякого перевезти могут. И людей в кузов набить можно, ежли чего. Спальное место оборудовать можно, опять-же. А хош на мелком чём, так вот Запорожец. Давно придумано, проверено временем. ;О) Так нет же, подавай им на вкус и цет...
А ФПГА мне туда непокатит. Ни по прокорму, ни по месту. А то бы поставил и не заморачивался...Хотел ДСПик, так он жрёт, собака. ТМСы тонкие тоже...Вот такая вот загогулина, панимаишш...;О)

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

Размер этого неприемлимого джиттера огласите?

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

На какой-такой достаточно высокой? На достаточно высокой, простите программная реализачия сожрет все ресурсы контроллера, ну а на "недостаточно высоких скоростях", речь о десятках наносекунд совсем не идет.

Никакого напряга. Совершенно не напрягаясь жду ответов.

Пжалста. 100кбод, джиттер 1-2мкс. Плюс задержка от фронта строба примерно на 1-2мкс. Это что видно статически осциллографом. Итого: примерно на 100-200 циклов передачи имеем один-два неправильных. Видать, изредка выскакиваем за пол-бода. Есть есчо одно таймерное прерывание, но там только поднимается флаг для фона, копейки. Пролечилось тупым опросом в фоне и строба и флага таймера. Но таким образом уже давно и успешно работает устройство на м48@20MHz.

Поддерживаю встраивание FPGA (ну пусть CPLD) в uC. Но связь между ядрами по интерфейсу I 8085, а не как получится (AT94).

Ну а теперь правда.
Если стремимся к минимальной interrupt latency, то используем FIQ а не IRQ. При этом для ARM7DTMI-S ядра с АRM-овским же PL-192 контроллером затраты на вход в прерывание составляют 7 тактов + длительность исполнения самой длинной прерванной команды LDM сохраняющей 16 регистров в память,
что составляет при памяти работающей с 0ws 20 тактов. Такие длинные групповые команды можно просто не использовать, тогда самя длинная это 8 тактов. Итого, при необходимости быстрой реакции на прерывание получаем 15 тактов.
Ну а дальше можно считать сколько времени займет вход в обработчик FIQ у типичного 60MHz ARM. Считаем. Максимальная задержка = 250ns, ну джиттер соответственно 7 тактов (причем независимо от IRQ/FIQ) = 117ns.
При этом не следует забывать, что ARM, в отличие от многих других архитектур имееет собственные банки регистров для FIQ и IRQ, что позволяет очень сэкономить время на сохранении регистров стеке для обработчика прерывания.
Так как Вы "получили" 2mks? Чего Вы там говорите добились на 20MHz контроллере, пусть и с всего 4-5 тактами latency, но и с десятком тактов затрачиваемых на сохранение регистров в стеке? А?

Зачем же в прерывании, которое почти ничего не делает, сохранять десяток регистров в стеке? У АВР достаточно регистров, чтобы пару из них выделить для эксклюзивного использования в "узком" обработчике. И вообще, мсе писал, что решил задачу поллингом. Получить время отклика 250 нс при поллинге на 20 МГц АВРке - не проблема. Именно на это обстоятельство он справедливо указывает. То есть, обошлись однобаксовым чипом.
Жаль только, что х-меги уйдут из ниши "проворных восьмилапов", и даже "20-лапов".

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

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

Ну а ниша для AVR есть и будет. Это очевидно. Я думаю atmega8 применяется в количественном выражении чаще чем какой-нибудь ARM отдельно взятый.
_____________________________________________________

Если обратится непосредственно к теме данного топика, то ....
1) Похоже Atmel учло все нарекания. В том числе по порту, по уровням прерываний, по потреблению и точности генерации, по АЦП и опорному, страничная запись в EEPROM.
2) Заложило даже то чего от неё не ожидали... ПДП контроллер, AES и DES дешифратор, АЦП 12бит 1Mbps, поддержка SDRAM немыслимых размеров.

Думаю для тех кто использует эти камни (а я отношусь к числу пользователей) это приятная новость. И чего совсем уж не ожидал от Atmela, что в нарушение всех традиций отладочные средства старые подойдут!!!

Да это более чем приятная новость!
Теперь важно чтоб цена осталась на уровне m128

Пожалуста считайте на здоровье это FIQ,для IRQ+VIC закоментированые строчки стоит убрать ,прервание по ИНТ1


Окей ,пускай не будет 32битных вычислений.
Давайте такого плана вычисления
R0=R1+R2
это делается одной командой за один такт
ADD R0,R1,R2
Я уже не говорю о том что это может быть выполнено по условию и со сдвигом второго операнда.
Тоесть самих асм команд у АРМ может быть гораздо меньше.

Наверное плохо представляю ,проверьте сами

кстати шевелить можно сразу несколькими произвольными пинами,не трогая остальные ,сколько АВРу требуется для подобных маневров?

ЗЫ я уже писал ,тут нету смысла сравнивать - это разные по классу задач контроллеры.

А может. после , будут и Х-Тини ?

Ах да, я все время забываю, что контроллер по условиям задачи на самом деле собственно ничего не
делает ..... Тогда да, и регистров хватит... И регистровых пар.

Уважаемые господа!

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

у меня появились даташиты на одну из веток XMega, а именно на A1
мне как - объявить здесь, или открыть новую тему ?

Суда по описанию в XMEGAx можно будет делать то же самое



Давай здесь. Будем немного посмотреть.

Здесь, конечно. Лично я обещаю больше не "мусорить", так-что начинаем новую жизнь!

ну дык и сколько тактов мин/мах у Вас получилось ?
zltigo уже вроде привел расчеты, 60Мгц АРМ оказался вполне конкурентноспособен
по сравнению с AVR на 20Мгц.
хороший конечно пример, тока ни о чем...
В ХОРОШЕМ прерывании вобще по возможности нужно без вычислений стараться обходится.

Речь все-таки шла не о тупом ногодрыганье,
прикинте сколько тактов min/max пройдет у арм от прерывания на INT и реакцией
в прерывании с выдачей чего-нить в порт.
Кстати, Вы смотрели на осциле с какой частотой меандр получается на ножке проца
при такой последовательности (STR, STR...) ?

Ну новую жизнь, так новую жизнь

Итак

ATXMEGA256A1, ATXMEGA128A1, ATXMEGA64A1
Advance Information
и
XMEGA A MANUAL Preliminary

/upload/MCs/AVR/ATXMEGA_A1.rar
/upload/MCs/AVR/XMEGA_A_Manual.rar

Продублировано на рапидшаре

http://rapidshare.com/files/57065647/ATXMEGA_A1.rar
http://rapidshare.com/files/57066068/XMEGA_A_Manual.rar



Кстати, судя по всему официально чипы будут объявлены в следующем месяце

Есть такая информация

TechTrends 2007
11.10.2007 08:00 - 19:00
Duisburg,
AVR Xmega Redefines the 8-bit World
Atmel is presenting the new 8-bit ‘XMEGA‘ device able to perform 32 MIPS @ 32 MHz with an outstanding analogue capability; this device will be code-compatible with the existing MEGA & TINY on which we will give you an update, followed by a presentation on the ATMEL Zlink solution, a 2.4 GHz radio bundled with the AVR of your choice.

http://www.ebv.com/services/events/techtre...dbb8df0d049f444

Ваши требования взаимно противоречивы.

1) Если критичным параметром является время реакции на внешнее событие, и мы говорим о величинах порядка 250 нс, то обработчик прерывания фактически должен "ничего не делать".

2) Если же Вы завели разговор о сохранении в стеке десятка регистров, то забудьте про 250-наносекундное время отклика (регистры сохраняли в стеке неспроста, видимо, сначала будет выполнен нехилый кусок кода, и лишь затем сможем дать корректный ответ на внешнее событие).

Выберите что-нибудь одно.


Upd.
Как классно в Xmega-х сделали I/O Memory !!! Отвели нижние 16 регистров (побитово адресуемых) для нужд юзверя! Фактически, вдобавок к РОНам теперь есть ещё 16 почти-регистров с однотактовым доступом.

Upd2
А однотактовый DES послужит хорошим генератором псевдослучайных чисел

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

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

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

Да, раньше на экспорт были разрешены только криптосистемы с не более чем 40-битными ключами. Не знаю, как сейчас обстоит дело с 56-битным DES. Возможно, уже разрешили.
Кстати, как наличие этих криптофункций отразится на цене чипа? Это было бы желательным расширением периферии, только если оно на халяву...

Я сам такой умный, но не могу пользовать ФИКу. Оно совмещено с РХ ССИ. И там у меня висит АЦП. А что получил, так то факт. М48 точно так-же всё обстукивает программно, как щас стчит 7S32 и ни в какие прерывания не входит, ессно. Просто 32 щас гораздо больше времени тратит на околачивание, по сравнению с.
Очень хотелось аналоговую часть частично впихнуть внутрь. Но, видать, малой кровью не выйдет. ;О) Не все иогурты таво...

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

Разумеется! Отдельные повара из любых ингридиентов способны легко приготовить блюдо которое "таво...".


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

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

Я это написал ,в первый двух строчках,в первом посте ,к которуму вы придрались.

Ну покажите класс ,как можно без вычислений сделать TWI-master-slave как положено с проверкой статуса и решением что делать дальше или хотя бы USART с простейшим буффером.

Ну так я же выше и дал пример с прерываниями,там первая команда идет дерганьем портом
В АРМ в прерывании не нужно сохранять регистры и SREG ,как у АВР.

Что ,невериться Или думаете осциллографа с такой полосой нет
На самом деле периферийная шина VPB может работать на тойже тактовой ,что и шина AHB,тоесть на 60Мгц,периферийные устройства LPC это позволяют.По умолчанию она стоит 1\4 ,вот народ и чешет репу ,чего так медленно