Kinetis K70, DMA, memcpy: сравнение скорости копирования., DMA почему то проигрывает Опции

[shreck]

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

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

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

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

[shreck]

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

[jcxz]

Убрал из idle задачи доступ к ОЗУ, скорость dma возрасла в 2 раза (9ms стало).

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

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

[AlexandrY]

Как-то (не помню уже на каком именно CPU) сталкивался с ситуацией, что у меня затыкался DMA (вообще, из-за таймаута доступа к шине)

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

[jcxz]

а еще есть где-то скрытый регистр со статусом "таймаута доступа к шине".

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

[AlexandrY]

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

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

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

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

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

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

[jcxz]

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

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