Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: AT91RM9200: быстрая пересылка память-память
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Ruslan1
Думаю, проблема популярная.
Нужно как можно быстрее скопировать данные из одной части адресного пространства в другую.
Можно придумать что-то, работающее быстрее, чем memcpy() ?

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

Едва ли: функция memcpy, как правило, очень хорошо оптимизирована.
Ruslan1
Цитата(aaarrr @ Nov 17 2006, 00:23) *
Цитата
Можно придумать что-то, работающее быстрее, чем memcpy() ?

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

Ну ладно, я уже смирился и приспособился. smile.gif
Чтение страницы из 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
Цитата(Ruslan1 @ Nov 17 2006, 10:06) *
Ну ладно, я уже смирился и приспособился. smile.gif
Чтение страницы из NAND Flash в память (2112 байт, 8-битная шина) при тактовой шины MCK=25.3MHz, Fcore=101MHz на AT91RM9200 продолжается 2750 us. Из них собственно внутренние дела NAND Flash занимают 23 us, остальное- именно пересылка двух килобайт.

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

Цитата(Ruslan1 @ Nov 17 2006, 10:06) *
Интересно, а все-таки существуют камни с ядром ARM7 или ARM9, имеющие просто DMA для передач "память-память"? Странно, если нету- ведь очень востребованная вещь.

Навскидку: ARM7 - S3C44B0X, ARM9 - EP93xx
zltigo
Цитата(Ruslan1 @ Nov 17 2006, 09:06) *
Странно, если нету- ведь очень востребованная вещь.

Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....
Ruslan1
Цитата(aaarrr @ Nov 17 2006, 16:02) *
Цитата(Ruslan1 @ Nov 17 2006, 10:06) *

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

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


Надеюсь, что так. Сам удивился. Пошуршу еще.
Ruslan1
Цитата(zltigo @ Nov 17 2006, 16:40) *
Цитата(Ruslan1 @ Nov 17 2006, 09:06) *

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

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

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


Это точно. Можете смеяться, но я сделал один проект на SAM7S вообще без использования прерываний - мне вполне хватило возможностей PDC. Причем там был даже обмен пакетами по UART.
aaarrr
Цитата(Ruslan1 @ Nov 17 2006, 17:41) *
Для вссяких там UART/SPI/I2C- это просто спасение. Да и для USB/Ethernet думаю тоже.

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

Цитата(vmp @ Nov 17 2006, 18:28) *
Можете смеяться, но я сделал один проект на SAM7S вообще без использования прерываний - мне вполне хватило возможностей PDC. Причем там был даже обмен пакетами по UART.

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

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

А насчет PDC память-память, я согласен с zltigo.
тут по любому
1 нужно произвести чтение из памяти, кудато во внутрь процессора
2 это что прочитал записать куда надо.
если этим будет заниматься ПДЦ то процессор будет стоять ждать доступа к EBI.
мое ИМХО всё это он может сделать сам.
zltigo
Цитата(Ruslan1 @ Nov 17 2006, 16:41) *
Скажу про себя- разгружает сильно.

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


Цитата(aaarrr @ Nov 17 2006, 17:59) *
А вот мне кажется, что атмел череcчур упорно лепит повсюду свой PDC

Ага, причем если у новых LPC 128bit MAM есть и отдельный банк памяти на отдельной шине для DMA нужд, то у Atmel PDC не бог весть как эффективен, естественно по сравнению с простым FIFO а не по сравнению с совсем тупой железкой без ничего.
Ruslan1
Цитата(zltigo @ Nov 17 2006, 21:28) *
Цитата(Ruslan1 @ Nov 17 2006, 16:41) *

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

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

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

Цитата(zltigo @ Nov 17 2006, 21:28) *
Вообще попробуйте как-нибудь попробовать аккуратно реализовать (там, де возможны варианты) и померить.

Что-то я не горю желанием "аккуратно" переписывать, скажем, работу с восьмью разными SPI устройствами. Или обмен на 115200 по Modbus-RTU, чтобы при каждом байтике прерывания возникали. Я заранее уверен, что лучше, чем с использованием PDC, у меня не выйдет. И даже осмелюсь подумать такую крамольную мысль, что выйдет хуже. У меня, разумеется. За других не скажу.
zltigo
Цитата(Ruslan1 @ Nov 20 2006, 00:34) *
Я заранее уверен, что лучше, чем с использованием PDC, у меня не выйдет.

Это я чуть отколонился :-(.
Речь вел не о том, что без DMA лучше - с DMA безусловно лучше чем без ничего. А о том, что а Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO. Ну а буде была
реализована пересылка память-память и вовсе бесполезна - не горюйте!.
Ruslan1
Цитата(zltigo @ Nov 19 2006, 22:41) *
Цитата(Ruslan1 @ Nov 20 2006, 00:34) *

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

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

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

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

Хм... Чем дольше думаю, тем больше сомнений. Можете привести пример, когда FIFO позволит сэкономить количество обращений с памятью? А если я в качестве буферов для PDC назначу набортное RAM контроллера?
SpiritDance
Цитата(aaarrr @ Nov 17 2006, 15:59) *
А вот мне кажется, что атмел череcчур упорно лепит повсюду свой PDC, забывая, что некоторой периферии желательно еще и FIFO.

+1
Что самое смешное с USB ситуация как раз прямо противоположная.
sergeeff
Как-то наткнулся у Intel на статейку, где сравнивается использование FIFO и DMA. Советую почитать.
zltigo
Цитата(Ruslan1 @ Nov 20 2006, 09:07) *
При приеме- тоже грустно. из FIFO обязательно нужно выгребать,

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

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

См. Выше.


Цитата(sergeeff @ Nov 20 2006, 10:55) *
Как-то наткнулся у Intel на статейку, где сравнивается использование FIFO и DMA. Советую почитать.

Реально много работал с AMD186CC, тот-же UART (кстати много более продвинутый нежели от
Intel и 32bit интерфейсом и прочими вкусностями) имеет и FIFO и DMA. Пробовал, думал....
в результате работает с FIFO. Причины изложены выше.
vmp
Цитата(zltigo @ Nov 20 2006, 12:29) *
А свой тему топика поднятую Вами помните? Что-то мне подсказывает, что DMA положил Вам
куда-то совсем сырой поток данных, потом Вы захотели с ним слегка разобраться, ну там фреймы выделить, контрольные суммы подсчитать, битые пакеты выринуть, перезапросы сделать....

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


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

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

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

Повторюсь :-( Ни FIFO, ни DMA сами по себе не лучше и не хуже, просто довольно часто приходится слышать о DMA (в случае простых контроллеров!) как о чем-то абсолютно прекрасном, так вот это не так, к сожалению.
Ruslan1
Цитата(zltigo @ Nov 20 2006, 12:29) *
А свой тему топика поднятую Вами помните?

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


Цитата(zltigo @ Nov 20 2006, 12:29) *
Что-то мне подсказывает, что DMA положил Вам
куда-то совсем сырой поток данных, потом Вы захотели с ним слегка разобраться, ну там фреймы выделить, контрольные суммы подсчитать, битые пакеты выринуть, перезапросы сделать....

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


Цитата(zltigo @ Nov 20 2006, 12:29) *
А уж только после этого положить не тольлько куда надо, но и то, что надо. Обработка сырого потока
так или иначе нужна почти всегда, с DMA получаете дополнительные пересылки память-память буквально на ровном месте.

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


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

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



Цитата(zltigo @ Nov 20 2006, 16:05) *
Далеко и ходить не надо - SLIP - хороший, стандартный и правильный пакетный протокол и будет "туши свет".....

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

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

Это да. Нет в мире совершенства. Кому что нравится. Мне- PDC, Вам- FIFO.
cheers.gif
zltigo
Цитата(Ruslan1 @ Nov 21 2006, 11:39) *
Да. Напоминаю:
Я: спросил, как можно быстрее передать данные, чем через memcpy(), и еще посетовал на отсутствие PDC для этого процесса.

Тогда ВЫНУЖДЕН напомнить свой ответ ПОЛНОСТЬЮ:
Цитата
Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....

Это похоже?????? на Вашу интерпретацию моего ответа:
Цитата
Мне: PDC- это фигня по сравнению с FIFO.


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

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

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

Нравится/не нравится это НЕ МОЙ ПОДХОД. Если есть выбор, то я выбираю наиоптимальнейший вариант не руководствуясь понятием "нравится" и стереотипами ( например, по отношению к затронутому здесь
DMA).
Чего и Вам желаю!
Ruslan1
Цитата(zltigo @ Nov 21 2006, 13:38) *
Цитата(Ruslan1 @ Nov 21 2006, 11:39) *

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

Тогда ВЫНУЖДЕН напомнить свой ответ ПОЛНОСТЬЮ:
Цитата
Прежде чем 'требовать' подумайте а чем занимается контроллер, когда у него отобрали память?
В памяти оно конечно 'само все пересылается' а процессор просто стоит, если у него конечно нет
кэшей немеряно и продвинутой системы предсказаний для загрузки кэшей.... Ну а чем стоять - мог и пересылать... Короче, DMA в микроконтролерном мире во многих случаях это просто словечко для маркетинга.....

Это похоже?????? на Вашу интерпретацию моего ответа:
Цитата
Мне: PDC- это фигня по сравнению с FIFO.


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

Цитата(zltigo @ Nov 19 2006, 22:41) *
Речь вел не о том, что без DMA лучше - с DMA безусловно лучше чем без ничего. А о том, что а Atmel-овской архитетуре DMA отнюдь не более, а менее эффективна, чем "банальные" FIFO.

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

Цитата(zltigo @ Nov 21 2006, 13:38) *
Цитата(Ruslan1 @ Nov 21 2006, 11:39) *

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

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

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


Цитата(zltigo @ Nov 21 2006, 13:38) *
Цитата(Ruslan1 @ Nov 21 2006, 11:39) *

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

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

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

Цитата(zltigo @ Nov 21 2006, 13:38) *
Чего и Вам желаю!

Спасибо!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.