AT91RM9200: быстрая пересылка память-память, ПДП- то для этого нету :( Опции

[Ruslan1]

Думаю, проблема популярная.
Нужно как можно быстрее скопировать данные из одной части адресного пространства в другую.
Можно придумать что-то, работающее быстрее, чем memcpy() ?

Еще конкретнее: есть устройства с 8- и 16- битной организацией, расположенные в пространстве адресов контроллера StaticMemory. Хочется наиболее оптимально обменяться данными с массивом, расположенным в SDRAM.

[aaarrr]

Можно придумать что-то, работающее быстрее, чем memcpy() ?

Едва ли: функция memcpy, как правило, очень хорошо оптимизирована.

[Ruslan1]

Можно придумать что-то, работающее быстрее, чем memcpy() ?

Едва ли: функция memcpy, как правило, очень хорошо оптимизирована.

Ну ладно, я уже смирился и приспособился.
Чтение страницы из NAND Flash в память (2112 байт, 8-битная шина) при тактовой шины MCK=25.3MHz, Fcore=101MHz на AT91RM9200 продолжается 2750 us. Из них собственно внутренние дела NAND Flash занимают 23 us, остальное- именно пересылка двух килобайт.

Вот еще прочитал в одном документе, описывающем драйвер NAND Flash (одно из моих устройств тоже NAND-Flash). Пишут о наличии нужного DMA в платформах на базе ядра ARM7TDMI. Только непонятно, речь идет о случае "память-память" или "NANDflash-память". Да и что за камни это имеют, интересно.

Написано следующее:

Код

Below is an example for a platform based on
ARM7TDMI core:
#ifdef DMA_ENABLE
do
i=*(volatile udword*) (GDMACON0);
while ( (i&0x2) != 0);
*((volatile unsigned int*) (GDMASRC0)) = Base_Address;
*((volatile unsigned int*) (GDMADST0)) = (udword)Buffer;
*((volatile unsigned int*) (GDMACNT0)) = udLength[0];
*(volatile unsigned int*) (GDMACON0) = 0x0081;
udIndex+=udLength[0];
#endif

А, вот, нашел, о ком это они: Samsung KS32C50100.
Это конкретно NAND Flash можно на DMA повесить. Круто.

Интересно, а все-таки существуют камни с ядром ARM7 или ARM9, имеющие просто DMA для передач "память-память"? Странно, если нету- ведь очень востребованная вещь.

[doomer#gp]

Вот memcpy (GCC 4.1.0, -Os optimization)

Код

00008278 <memcpy>:
    8278:    e3a0c000     mov    ip, #0; 0x0
    827c:    ea000002     b    828c <memcpy+0x14>
    8280:    e7dc3001     ldrb    r3, [ip, r1]
    8284:    e7cc3000     strb    r3, [ip, r0]
    8288:    e28cc001     add    ip, ip, #1; 0x1
    828c:    e2522001     subs    r2, r2, #1; 0x1
    8290:    2afffffa     bcs    8280 <memcpy+0x8>
    8294:    e12fff1e     bx    lr

А вот что приведено в ADS Assembler manual в качестве примера демонстрации эффективного использования команд ldm stm при блочном коприровании - двумя последовательными командами копируем 8 двойных слов.

Код

                      AREA Block, CODE, READONLY; name this block of code
num                EQU 20; set number of words to be copied
                      ENTRY; mark the first instruction to
start
                     LDR r0, =src; r0 = pointer to source block
                     LDR r1, =dst; r1 = pointer to destination
                     MOV r2, #num; r2 = number of words to copy
                     MOV sp, #0x400; Set up stack pointer (r13)
blockcopy       MOVS r3,r2, LSR #3; Number of eight word multiples
                     BEQ copywords; Less than eight words to move?
                     STMFD sp!, {r4-r11}; Save some working registers
octcopy          LDMIA r0!, {r4-r11}; Load 8 words from the source
                     STMIA r1!, {r4-r11}; and put them at the destination
                     SUBS r3, r3, #1; Decrement the counter
                     BNE octcopy; ... copy more
                     LDMFD sp!, {r4-r11}; Don't need these now - restore
                                                  ; originals
copywords      ANDS r2, r2, #7; Number of odd words to copy
                     BEQ stop; No words left to copy?
wordcopy       LDR r3, [r0], #4; Load a word from the source
                     STR r3, [r1], #4; store it to the destination
                     SUBS r2, r2, #1; Decrement the counter
                     BNE wordcopy; ... copy more
stop               MOV r0, #0x18; angel_SWIreason_ReportException
                     LDR r1, =0x20026; ADP_Stopped_ApplicationExit
                     SWI 0x123456; ARM semihosting SWI

                    AREA BlockData, DATA, READWRITE
src                DCD 1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4
dst                DCD 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
                     END

[aaarrr]

Ну ладно, я уже смирился и приспособился.
Чтение страницы из NAND Flash в память (2112 байт, 8-битная шина) при тактовой шины MCK=25.3MHz, Fcore=101MHz на AT91RM9200 продолжается 2750 us. Из них собственно внутренние дела NAND Flash занимают 23 us, остальное- именно пересылка двух килобайт.

Что-то уж слишком медленно получается. По-моему, где-то ошибка.

Интересно, а все-таки существуют камни с ядром ARM7 или ARM9, имеющие просто DMA для передач "память-память"? Странно, если нету- ведь очень востребованная вещь.

Навскидку: ARM7 - S3C44B0X, ARM9 - EP93xx

[zltigo]

Странно, если нету- ведь очень востребованная вещь.

Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....

[Ruslan1]

Ну ладно, я уже смирился и приспособился.
Чтение страницы из NAND Flash в память (2112 байт, 8-битная шина) при тактовой шины MCK=25.3MHz, Fcore=101MHz на AT91RM9200 продолжается 2750 us. Из них собственно внутренние дела NAND Flash занимают 23 us, остальное- именно пересылка двух килобайт.

Что-то уж слишком медленно получается. По-моему, где-то ошибка.

Надеюсь, что так. Сам удивился. Пошуршу еще.

[Ruslan1]

Странно, если нету- ведь очень востребованная вещь.

Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....

Да пусть хоть совсем стоит и ждет, пока две железяки быстро обменяются с помощью его DMA-контроллера. Цикл шины на источник плюс на приемник и слово передано. Что должно быть не хуже, чем под управлением АЛУ- это очевидно.
А насчет "DMA для маркетологов"- совсем не согласен. Скажу про себя- разгружает сильно. Для вссяких там UART/SPI/I2C- это просто спасение. Да и для USB/Ethernet думаю тоже.

[vmp]

А насчет "DMA для маркетологов"- совсем не согласен. Скажу про себя- разгружает сильно. Для вссяких там UART/SPI/I2C- это просто спасение. Да и для USB/Ethernet думаю тоже.

Это точно. Можете смеяться, но я сделал один проект на SAM7S вообще без использования прерываний - мне вполне хватило возможностей PDC. Причем там был даже обмен пакетами по UART.

[aaarrr]

Для вссяких там UART/SPI/I2C- это просто спасение. Да и для USB/Ethernet думаю тоже.

Я бы приоритеты поставил наоборот: спасение для USB/Ethernet, а для всяких UART'ов - приятная мелочь.

Можете смеяться, но я сделал один проект на SAM7S вообще без использования прерываний - мне вполне хватило возможностей PDC. Причем там был даже обмен пакетами по UART.

А вот мне кажется, что атмел череcчур упорно лепит повсюду свой PDC, забывая, что некоторой периферии желательно еще и FIFO.

[MemoryTest]

А вот мне кажется, что атмел череcчур упорно лепит повсюду свой PDC, забывая, что некоторой периферии желательно еще и FIFO.

+1
Я бы от PDC + FIFO не отказался

А насчет PDC память-память, я согласен с zltigo.
тут по любому
1 нужно произвести чтение из памяти, кудато во внутрь процессора
2 это что прочитал записать куда надо.
если этим будет заниматься ПДЦ то процессор будет стоять ждать доступа к EBI.
мое ИМХО всё это он может сделать сам.

[zltigo]

Скажу про себя- разгружает сильно.

Это Вы на чем? На Pentium M? :-)))))
Вообще попробуйте как-нибудь попробовать аккуратно реализовать (там, де возможны варианты) и померить.

А вот мне кажется, что атмел череcчур упорно лепит повсюду свой PDC

Ага, причем если у новых LPC 128bit MAM есть и отдельный банк памяти на отдельной шине для DMA нужд, то у Atmel PDC не бог весть как эффективен, естественно по сравнению с простым FIFO а не по сравнению с совсем тупой железкой без ничего.

[Ruslan1]

Скажу про себя- разгружает сильно.

Это Вы на чем? На Pentium M? :-)))))

Нет, я про многострадальный AT91RM9200.

Вообще попробуйте как-нибудь попробовать аккуратно реализовать (там, де возможны варианты) и померить.

Что-то я не горю желанием "аккуратно" переписывать, скажем, работу с восьмью разными SPI устройствами. Или обмен на 115200 по Modbus-RTU, чтобы при каждом байтике прерывания возникали. Я заранее уверен, что лучше, чем с использованием PDC, у меня не выйдет. И даже осмелюсь подумать такую крамольную мысль, что выйдет хуже. У меня, разумеется. За других не скажу.

[zltigo]

Я заранее уверен, что лучше, чем с использованием PDC, у меня не выйдет.

Это я чуть отколонился :-(.
Речь вел не о том, что без DMA лучше - с DMA безусловно лучше чем без ничего. А о том, что а Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO. Ну а буде была
реализована пересылка память-память и вовсе бесполезна - не горюйте!.

[Ruslan1]

Я заранее уверен, что лучше, чем с использованием PDC, у меня не выйдет.

Это я чуть отколонился :-(.
Речь вел не о том, что без DMA лучше - с DMA безусловно лучше чем без ничего. А о том, что а Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO.

Плохость FIFO в том, что:
1. "резиновых" FIFO пока не наблюдается. Сколько байт дали (обычно меньше чем нужно)- через столько и прерывайся. DMA позволяет этого не делать. Одно прерывание на посылку.
2. PDC позволяет не перегружать данные из памяти в FIFO передатчика каждый раз полностью. Например, если у меня PDC и я опрашиваю по петле одно устройство- то просто запускаю еще раз передатчик, так как буфер у меня нетронут. Либо меняю несколько байт в передаваемом пакете и все. Либо просто указываю контроллеру новые указатели для буферов приема/передачи.
В случае простого FIFO- все нужно заливать по новой перед каждой передачей.

При приеме- тоже грустно. из FIFO обязательно нужно выгребать, а PDC уже сразу кладет данные туда, куда мне нужно.

Хм... Чем дольше думаю, тем больше сомнений. Можете привести пример, когда FIFO позволит сэкономить количество обращений с памятью? А если я в качестве буферов для PDC назначу набортное RAM контроллера?

[SpiritDance]

А вот мне кажется, что атмел череcчур упорно лепит повсюду свой PDC, забывая, что некоторой периферии желательно еще и FIFO.

+1
Что самое смешное с USB ситуация как раз прямо противоположная.

[sergeeff]

Как-то наткнулся у Intel на статейку, где сравнивается использование FIFO и DMA. Советую почитать.

Прикрепленные файлы

 27242701.pdf ( 43.56 килобайт ) Кол-во скачиваний: 77

 

[zltigo]

При приеме- тоже грустно. из FIFO обязательно нужно выгребать,

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

а PDC уже сразу кладет данные туда, куда мне нужно.

А свой тему топика поднятую Вами помните? Что-то мне подсказывает, что DMA положил Вам
куда-то совсем сырой поток данных, потом Вы захотели с ним слегка разобраться, ну там фреймы выделить, контрольные суммы подсчитать, битые пакеты выринуть, перезапросы сделать....
А уж только после этого положить не тольлько куда надо, но и то, что надо. Обработка сырого потока
так или иначе нужна почти всегда, с DMA получаете дополнительные пересылки память-память буквально на ровном месте.

Можете привести пример, когда FIFO позволит сэкономить количество обращений с памятью?

См. Выше.

Как-то наткнулся у Intel на статейку, где сравнивается использование FIFO и DMA. Советую почитать.

Реально много работал с AMD186CC, тот-же UART (кстати много более продвинутый нежели от
Intel и 32bit интерфейсом и прочими вкусностями) имеет и FIFO и DMA. Пробовал, думал....
в результате работает с FIFO. Причины изложены выше.

[vmp]

А свой тему топика поднятую Вами помните? Что-то мне подсказывает, что DMA положил Вам
куда-то совсем сырой поток данных, потом Вы захотели с ним слегка разобраться, ну там фреймы выделить, контрольные суммы подсчитать, битые пакеты выринуть, перезапросы сделать....

Реально много работал с AMD186CC, тот-же UART (кстати много более продвинутый нежели от
Intel и 32bit интерфейсом и прочими вкусностями) имеет и FIFO и DMA. Пробовал, думал....
в результате работает с FIFO. Причины изложены выше.

У меня получилась противоположная ситуация (UART на SAM7S). Мой протокол (который я разрабатывал еще под MSP430) идеально лег на PDC.
Хитрость следующая: обмен идет пакетами данных. Данные внутри пакета идут без пауз, между пакетами вставляются паузы длиной не менее одного символа. В итоге я просто программирую UART на прием с тайм-аутом (регистр US_RTOR), а PDC - на прием максимально допустимой длины пакета. Дальше, обнаружив в основном цикле программы флаг RX_BUFF или TIMEOUT в регистре US_CSR я проверяю правильность принятого пакета (стартовый байт, совпадение длины и контрольной суммы). Вся дальнейшая обработка принятого пакета идет по месту, без лишних пересылок. Передача - аналогично, в памяти формируется пакет и скармливается PDC.
Разумеется, можно придумать вариант протокола, который будет более оптимален при работе с FIFO. Достаточно добавить к нему какой-либо вариант байт-стаффинга или убрать паузы между пакетами.

Сообщение отредактировал vmp - Nov 20 2006, 15:54

[zltigo]

Разумеется, можно придумать вариант протокола, который будет более оптимален при работе с FIFO.

Обычно протоколы "придумывают" совсем с другой целью :-)

Достаточно добавить к нему какой-либо вариант байт-стаффинга или убрать паузы между пакетами.

Далеко и ходить не надо - SLIP - хороший, стандартный и правильный пакетный протокол и будет "туши свет".....

Повторюсь :-( Ни FIFO, ни DMA сами по себе не лучше и не хуже, просто довольно часто приходится слышать о DMA (в случае простых контроллеров!) как о чем-то абсолютно прекрасном, так вот это не так, к сожалению.

[Ruslan1]

А свой тему топика поднятую Вами помните?

Да. Напоминаю:
Я: спросил, как можно быстрее передать данные, чем через memcpy(), и еще посетовал на отсутствие PDC для этого процесса.
Мне: PDC- это фигня по сравнению с FIFO.
Я: не вижу, чем FIFO лучше чем PDC.

Что-то мне подсказывает, что DMA положил Вам
куда-то совсем сырой поток данных, потом Вы захотели с ним слегка разобраться, ну там фреймы выделить, контрольные суммы подсчитать, битые пакеты выринуть, перезапросы сделать....

Как? Где Вы экономите? Я так и не понял. Конкретный пример приведите, как FIFO экономит пересылки при подсчете контрольной суммы? Или как FIFO помогает определить битый пакет?

А уж только после этого положить не тольлько куда надо, но и то, что надо. Обработка сырого потока
так или иначе нужна почти всегда, с DMA получаете дополнительные пересылки память-память буквально на ровном месте.

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

Реально много работал с AMD186CC, тот-же UART (кстати много более продвинутый нежели от
Intel и 32bit интерфейсом и прочими вкусностями) имеет и FIFO и DMA. Пробовал, думал....
в результате работает с FIFO. Причины изложены выше.

Ну что ж. А у меня ситуация обратная. Мой протокол хорошо ложится на PDC, вот и все. И FIFO ну никак не облегчит мне жизнь.

Далеко и ходить не надо - SLIP - хороший, стандартный и правильный пакетный протокол и будет "туши свет".....

Ну а если у меня постоянно MODBUS-RTU, который хорошо ложится на имеющийся PDC? Что мне теперь, протокол менять, чтобы неудобно было?

Повторюсь :-( Ни FIFO, ни DMA сами по себе не лучше и не хуже, просто довольно часто приходится слышать о DMA (в случае простых контроллеров!) как о чем-то абсолютно прекрасном, так вот это не так, к сожалению.

Это да. Нет в мире совершенства. Кому что нравится. Мне- PDC, Вам- FIFO.

[zltigo]

Да. Напоминаю:
Я: спросил, как можно быстрее передать данные, чем через memcpy(), и еще посетовал на отсутствие PDC для этого процесса.

Тогда ВЫНУЖДЕН напомнить свой ответ ПОЛНОСТЬЮ:

Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....

Это похоже?????? на Вашу интерпретацию моего ответа:

Мне: PDC- это фигня по сравнению с FIFO.

Мой протокол хорошо ложится на PDC, вот и все.

Зачем тогда сожаление об отсутствие пересылок память-память? Я полагаю (уже писал), что имеет место быть необходимость после того, как отработало DMA c железом наконец переслать несколько обработанную принятую информацию в "правильное" место. Есть еще какие-то причины? Я лично могу назвать еще только одну - ошибки в проектировании системы приводящие к необходимости такой лишней пересылки.

Кому что нравится. Мне- PDC, Вам- FIFO.

Нравится/не нравится это НЕ МОЙ ПОДХОД. Если есть выбор, то я выбираю наиоптимальнейший вариант не руководствуясь понятием "нравится" и стереотипами ( например, по отношению к затронутому здесь
DMA).
Чего и Вам желаю!

[Ruslan1]

Да. Напоминаю:
Я: спросил, как можно быстрее передать данные, чем через memcpy(), и еще посетовал на отсутствие PDC для этого процесса.

Тогда ВЫНУЖДЕН напомнить свой ответ ПОЛНОСТЬЮ:

Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....

Это похоже?????? на Вашу интерпретацию моего ответа:

Мне: PDC- это фигня по сравнению с FIFO.

Тогда ВЫНУЖДЕН привести еще один Ваш ответ:

Речь вел не о том, что без DMA лучше - с DMA безусловно лучше чем без ничего. А о том, что а Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO.

Извините, Вы действительно не говорили, что "PDC- это фигня по сравнению с FIFO". Вы сказали, что "в Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO".
Вероятно, моя интерпретация этой фразы оказалась слишком вольной.

Мой протокол хорошо ложится на PDC, вот и все.

Зачем тогда сожаление об отсутствие пересылок память-память? Я полагаю (уже писал), что имеет место быть необходимость после того, как отработало DMA c железом наконец переслать несколько обработанную принятую информацию в "правильное" место. Есть еще какие-то причины? Я лично могу назвать еще только одну - ошибки в проектировании системы приводящие к необходимости такой лишней пересылки.

Ну зачем так прямолинейно? Предствьте себе более сложную картину мироздания. У меня для работы с некоторой периферией есть PDC, которые я успешно использую. Но также есть и другие устройства, для которых этих PDC нет, а правила работы с устройствами навязаны их производителем.
Конкретно- NAND FLASH. Вот для нее-то мне и не хватает аналогичного контроллера, облегчающего жизнь. Еще пример- пересылка больших объемов (размером с экран) из SDRAM в контроллер дисплея. Тоже очень помогло бы наличие аппаратного "насоса". Вышеупомянутое- пример устройств, так или иначе отображенных на память, и если бы у меня был аппаратных контроллер для пересылок "память-память", он бы довольно хорошо уменьшил требуемое на эти операции время.
О тривиальных пересылках внутри той же SDRAM я не говорю- это действительно вызвано часто не необходимостью, а применением плохого программиста.

Кому что нравится. Мне- PDC, Вам- FIFO.

Нравится/не нравится это НЕ МОЙ ПОДХОД. Если есть выбор, то я выбираю наиоптимальнейший вариант не руководствуясь понятием "нравится" и стереотипами ( например, по отношению к затронутому здесь
DMA).

Согласитесь, под "нравиться" можно подразумевать комплекс причин, влияющих в том числе и на "оптимальность". А под "оптимальностью" можно подразумевать и банальную скорость достижения результата, что запросто может определяться личными предпочтениями программиста. Но это философский вопрос, не будем развивать.

Чего и Вам желаю!

Спасибо!