Имеем K70 c внешней DDRAM.
Сравниваю скорость копирования блока памяти 500KB из одного места DDRAM в другое место DDRAM.
Оба метода работают в одинаковых условиях.

штатная memcpy: 12ms.
DMA (16-byte burst режим): 18ms.

DMA медленнее.
Как можно объяснить эти результаты.
Может что-то недоглядел/недонастроил в этом DMA.

P.S. По запарке не в тот раздел запостил.

Ну это уж давно известный эффект.
Начиная еще с ARM7 у ARM-ов DMA всегда работал медленней программной пересылки.
Но зато DMA не может больше чем на 50% замедлить прокачку данных и команд для процессора.
Кстати надо еще играться приоритетами портов коммутатора шин.

Ясненько. Спасибо.

А что у Вас в этот момент делал CPU? Может он шину загрузил (у него наверное приоритет доступа к шине выше чем у DMA?) крутясь в пустом цикле?

Убрал из idle задачи доступ к ОЗУ, скорость dma возрасла в 2 раза (9ms стало).
Повышение приоритета dma также уменьшает время до 9ms.
И, видимо, это предел, т.к. применение обоих условий, более не уменьшает время копирования.

Тут надо убедится, что memcpy работает с выровненными данными, а то иначе она медленней работает раза в два.

Лучшее решение - idle-задача состоящая из одной инструкции WFE в цикле!

Как-то (не помню уже на каком именно CPU) сталкивался с ситуацией, что у меня затыкался DMA (вообще, из-за таймаута доступа к шине)
из-за того, что CPU, ожидая флага о завершении DMA-транзакции крутился в пустом цикле. Размер этого цикла (команд) был очень маленький,
и сам цикл лежал ещё на границе элемента предвыборки инструкций (весь цикл нельзя было загрузить одним prefetch). Из-за этого шина
постоянно была занята непрерывными операциями выборки команд этого цикла и никакой другой bus master не мог получить доступа к ней.
Вроде это было на ком-то из LPC175/6x.
И самое поганое было в том, что при малейшем изменении кода (в любом месте) этот самый цикл сдвигался немного в памяти и всё чудесным образом начинало работать.
Но недолго, до след. модификации.

NXP небось и не в курсе что у них DMA "затыкается",
а еще есть где-то скрытый регистр со статусом "таймаута доступа к шине".

где? и зачем он?

Выравнивание на границу 16 байт. Здесь все в порядке.


Это само собой. Просто исходно idle задача была штатной от ОСи. Заменил на свою.

А как вы узнали про таймаут? В мануале на LPC17xx таймаут шины нигде не упоминается.



Тогда надо еще указать компилятор и опции компиляции потому как memcpy у всех сильно отличается.

А на какую задачу заменили. И зачем вообще включили MQX?
Там же сразу идет инициализация кучи периферии с прерываниями и системный тик включается. Оно надо для таких тестов?

Не "таймаут шины", а "таймаут доступа DMA-контроллера к шине".
Я сделал вывод из симптомов:
1. Перенос цикла в ОЗУ - решало проблему.
2. Выравнивание начала цикла на границу предвыборки - решало проблему.
3. Увеличение кол-ва команд в цикле - решало проблему.
4. Ранее на другом CPU (CC5502) сталкивался с подобной проблемой. Там генерилось прерывание ошибки, о котором так и говорилось "генерится после 512 (вроде) безуспешных попыток доступа к шине DMA-контроллера".
К тому-же у LPC175/6x приоритет доступа к шине CPU всегда выше чем у DMA и изменить это невозможно ((( Это исправлено только в LPC177/8x.

Ну так вы имеете просто нерешенную проблему.
Я тоже исследовал влияние выполнение кода на работу DMA.
И с простыми циклами и с Whetstone и с одновременным выполнением memcpy.
На STM32. И ничего подобного не наблюдал.

Может быть у вас DMA был плохо настроен, может еще что, но переносить этот неудачный опыт на K70 нет оснований.

IAR 7.20.2 High Balanced почти все опции включены.
MQX с работающими задачами нужна для того, чтобы оценить время копирования в реальных условиях. А предельное значение времени работы memcpy при остановленной MQX составляет те же ~12ms.

Хороший выбор.

А как время измеряете?