Вот она, сила маркетинга!!! Возникает вопрос - а как часто мне необходимо все это "и сложить, и сдвинуть и условие проверить". Например, если только каждую пятую операцию - нафига же я тогда потратил 4*(2 лишних байта)=8 байт FLASH?

Это будет эффективно при жестком асмовом кодинге - но для ARM обычно так не принято

Ладно, спор ни о чем - идеальная CPU архитектура пока не создана.

Собственно, тогда к чему тогда весь разговор?
Лично для меня использование 8-битных AVR обусловлено только наличием "доступных" средств программирования и отладки. В случае 'X' этого преимущества не существует (в настоящее время).
К ламерью не отношусь , выше 16 бит ничего делать не хочу и не буду, но постоянно переключаясь между MSP430 и AVR в проектах хоть сколь-нибудь реального времени, вижу, насколько удобнее использовать 16-битные контроллеры.
XMEGA - всего лишь для узкой ниши.

Отдельный банк - это отдельный геморой. Его надо по особому обслуживать и т.д. А если весь необходимый буфер не влазит в отдельный банк - процом данные таскать?

В общем, я пока не встречал случаев, чтобы DMA проиграло по CPU load процессорной обработке.


Может, я чего не понял, но что мешает использовать AVR Studio + WinAVR для ATxmega? Ядро то то же самое, хидеры атмел вроде родил.

mkII денег стоит - ну не таких уж и страшных, что-то типа 8000р. Не думаю, что это критичная величина - покупается раз и на долгие годы. Спорный вопрос. If писать на С - мало волнует, как там код исполняется, лишь бы успевало. ASM кодинг - он только для малых проектов или небольших кусков сложных проектов эффективен. По размерам C код за счет грамотного написания, полного использования всех квалификаторов и #pragma для данного конкретного компилера можно всегда хорошо ужать.

[quote name='zltigo' date='May 18 2008, 17:48' post='413027']
Только вот.. кто-нибудь сможет назвать лучший в мире 4-бит процессор??? Набежало, похоже, понимешь ламерье и с воплями "8 лучше 4" затоптало


8-битный- объективная реальность в современном байт-ориентированном мире (лично я использую от 1 до 6МК и переходить на 16-32 не собираюсь- естественно аудио-видео потоки не обрабатываю)

Подсчитали недавно - на фирме больше десятка клонов JTAG ICE. Ведущему программисту, руководителю проекта, наладка, сервис, студенты и т.д. Для всех купить mkII? Не то, что невозможно, но цена вопроса другая и нужно все взвесить.


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

Я одного понять не могу. Почему-то Вы упорно забываете о том, что шина у AVR не занята постоянным потоком чтения комманд, ведь адресные простанства совсем отдельные, Гарвард все-таки (это я сравниваю с ARM7, ARM9 - там все пучком, там кеш есть). Поэтому на AVR DMA имеет полное право на жизнь, ведь запись-чтение из памяти данных происходит очень редко, пустого места по времени - море. Даже такой код

имеет на XMega 4 пустых цикла доступа на шину данных. Даже таким способом



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

Так что DMA тут рулит.

О! Вот с этого все и начинается! Ради чего я так и возбудился

Как учит теория TDD - лучший способ завалить проект - начать его сразу и по всем параметрам оптимизировать. Результат гарантирован .

В той идеологии, что я описал, и чему посвящена куча PDF в начале топика, вначале пишутся только дрова (они едва ли сожрут все место во FLASH), и затем они "телепортируются" на писюк.

Затем на писюке в синтетическом порту пишется целевой код, и проверяется на правильность решения целевой задачи.

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

В конце концов, может, все так ужмется, что и XMEGA будет не нужна

Естественно это увеличивает пользу от DMA. Если поднять мои давнишние выступления по DMA, то они относились прежде всего к SAM7 - сейчас это я так - "старое помянул" встретив старого знакомого.

А вообще, лично меня другой момент интересует...

Вот смотрим на таблицу комманд. Видим:

LD Rd,X+ - 2 такта
ST X+,Rd - 1 такт

Все понятно, во втором случае можно выполнить запись в процессе обработки следующей комманды. Так же понятно, почему STD X+disp,Rd - 2 такта, это происходит из-за того, что такт заняло вычисление адреса.

Но теперь очень интересный вопрос. Возле всех комманд LD стоит примечание 2. Оно гласит - "один дополнительный цикл должен быть добавлен при доступе во внутреннюю SRAM".... Причем, возле комманд ST этого примечания нет... Вот тут я чето совсем не понял...
И как это согласуется с утверждением в разделе 7.1 - "Single cycle access from CPU"? Почему в одну сторону (запись) действительно single, а в другую - double???

Ну про SBIS/SBIC я давно удивлялся, почему стало 2 такта минимум...

Полностью опробовав DMA SAM7 (для всей его периферии). Категорически несогласен с этим высказыванием.
Эффективность DMA каналов SAM7 очень значительная.

при передаче 100 байт по SPI, без DMA канала проц 100 раз войдет в прерывание для подгрузки очередного байта, т.о. 100 раз займет шину на перегонку байта, +100 раз произойдет немерянный оверхед на исполнение кода обслуживающего прерывание.
При передаче через DMA канал - DMA отминет только 100 циклов шины пямяти.
Так что эффективнее?

Что DMA работает именно так как я описал (захватывает шину когда периферий модуль "готов" принять, и отпускает когда периф. модуль не готов принимать), сомнений у меня нет, могу привести ссылки из Д/Ш.

Часто. Компилятор это пользует часто. Настолько часто, что на сколь-нибудь ральных задачах, написанных с умом и даже в общем-то не заточенных под 32 бита - обычные коммуникационные задачи.
Проигрыша в размере кода в общем-то нет - когда больше, когда меньше. Никакого "маркетинга" - чистая реальная СОБСТВЕННАЯ практика. Если мне не верите - то уже говорил - посмотрите на форуме.

Можно я отвечу? Эффективнее DMA+FIFO на отдельной шине кешированного процессора

Это, конечно, так, но уважаемый zltigo очень уж любит сгущать краски.

Вот после "если" и продолжим разговор. Пока старые ATMEGA стоят неразумных денег и меня терзают смутные сомнения, что XMEGA вдруг резко опустят по цене. Поднимть - не поднимут, скорее всего так и оставят. Посему лично для меня сколь-нибудь привлекательными будут что-то типа Тинек.

Неправда Ваша опять ОЗУ оно и в Африке ОЗУ. Если обильно использовать битовые переменные щедрой рукой отдавая по ячейке под каждую, то тогда да. Только вот RAM жрут больше байтовые буфера всякие. А прочие данные надо просто в структуры, поля и паковать. Тут всякие "ненужные" ARM команды вполне эффективно работают и RAM попусту не тратится. Единственно, что заметно больше кушает RAM это более широкий стек. Но в общем никакого сташного расхода RAM нет.

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

Да это все понятно.

Но я например не представляю как можно сделать DSP обработку звука (оцифровка 44.1kHz, обработка и выдача результата через DAC) на типа более эффективном с т.з. zltigo LPC (с MAM) не имея DMA каналов. Для SAM7 же такая задачка по плечу и только благодаря наличию DMA каналов. Плюс еще остается время на ethernet, консольки и прочую фигню.

Есть такое - несколько неадекватная реакция на достаточно частые повторения мантры "DMA-DMA-DMA-..." без особых на то причин