[Evgeny_CD 0]

Ну так уж и только сложить :) не передергивайте и сводите систему команд ARM "к сложить" - и сложить, и сдвинуть и условие проверить и все это - за одну команду в 4 байта. В формате 32-бит команды указываеся до 3х регистра/константы, проверяются 4 флага и дополнительный сдвиг до 32 бит. А что у нас у AVR - сколько там Flash кушать придется? А адресоваться подальше 256 байт?

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

 

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

 

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

[DogPawlowa 0]

Как я уже писал, именно 16 битная система команд является оптимальной для большинства современных задач - AVR, CF, Cortex, SH, ... Она дает возможность эффективно манипулировать разумным количество регистров, и достаточно экономична.

Собственно, тогда к чему тогда весь разговор? :)

Лично для меня использование 8-битных AVR обусловлено только наличием "доступных" средств программирования и отладки. В случае 'X' этого преимущества не существует (в настоящее время).

К ламерью не отношусь :) , выше 16 бит ничего делать не хочу и не буду, но постоянно переключаясь между MSP430 и AVR в проектах хоть сколь-нибудь реального времени, вижу, насколько удобнее использовать 16-битные контроллеры.

XMEGA - всего лишь для узкой ниши.

[Evgeny_CD 0]

И FIFO тоже эффективен вполне. А FIFO + отдельный банк вообще прилично.

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

 

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

 

 

Лично для меня использование 8-битных AVR обусловлено только наличием "доступных" средств программирования и отладки. В случае 'X' этого преимущества не существует (в настоящее время).

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

 

mkII денег стоит - ну не таких уж и страшных, что-то типа 8000р. Не думаю, что это критичная величина - покупается раз и на долгие годы.

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

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

[svs39 0]

Только вот.. кто-нибудь сможет назвать лучший в мире 4-бит процессор??? Набежало, похоже, понимешь ламерье и с воплями "8 лучше 4" затоптало :)

:)

 

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

[DogPawlowa 0]

mkII денег стоит - ну не таких уж и страшных, что-то типа 8000р. Не думаю, что это критичная величина - покупается раз и на долгие годы.

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

 

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

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

Да и чего стоит обращение к многобайтовым переменным. Мелочь, но неприятно.

[Rst7 5]

Не устаю замечать, что DMA на контроллерах без кэша или каких-либо специализированных архитектурных наворотов штука малоэффективная. А то, что сделано у помянутого всуе ARM7 LPC, это как раз и есть эффективное использование DMA, поскольку он работает НА ОТДЕЛЬНОЙ ШИНЕ с ОТДЕЛЬНЫМ банком. Что позволяет не тормозить контролер "контроллером DMA"

 

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

LOOP:
LD R16,X+
ST Z+,R16
DEC R17
BRNE LOOP

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

 

 LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
LD R16,X+
ST Z+,R16
....

 

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

 

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

[Evgeny_CD 0]

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

Да и чего стоит обращение к многобайтовым переменным. Мелочь, но неприятно.

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

 

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

 

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

 

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

 

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

 

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

[zltigo 1]

Гарвард все-таки...

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

[Rst7 5]

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

 

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

 

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 такта минимум...

[defunct 0]

Не устаю замечать, что DMA на контроллерах без кэша или каких-либо специализированных архитектурных наворотов штука малоэффективная.

 

то они относились прежде всего к SAM7 - сейчас это я так - "старое помянул"

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

Эффективность DMA каналов SAM7 очень значительная.

 

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

При передаче через DMA канал - DMA отминет только 100 циклов шины пямяти.

Так что эффективнее?

 

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

[zltigo 1]

Возникает вопрос - а как часто мне необходимо все это "и сложить, и сдвинуть и условие проверить".

Часто. Компилятор это пользует часто. Настолько часто, что на сколь-нибудь ральных задачах, написанных с умом и даже в общем-то не заточенных под 32 бита - обычные коммуникационные задачи.

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

[aaarrr 69]

Так что эффективнее?

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

 

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

[zltigo 1]

Чем XMEGA то не устраивает? Всё в цену упирается и если она пойдёт с сопоставимой ценой, то будет очень приятно.

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

Мелкие армы при той же структуре флэш/озу оказываются не так уж и привлекательны

так как озу, как минимум требуется больше. AVR эффективнее использует.

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

Совершенно не понятно почему вы не хотите финансировать Atmel. :) То есть NXP и STM и ARM вы финансировать согласны, а вот Atmel - нет. :) Не вижу разницы.

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

[defunct 0]

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

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

 

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

[zltigo 1]

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

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