Ну а теперь правда.
Если стремимся к минимальной 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 послужит хорошим генератором псевдослучайных чисел

Сообщение отредактировал CD_Eater - Sep 20 2007, 20:52

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

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

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