Форум разработчиков электроники ELECTRONIX.ru

Помощь - Поиск - Пользователи - Календарь

Полная версия этой страницы: Эффективность DMA в SAM7

Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM

Страницы: 1, 2

zltigo

Sep 28 2008, 17:35

Цитата(singlskv @ Sep 28 2008, 19:32)

правда в разы..., это как-то слишком громко было
сказанно

)

Именно в разы +1 WS - в два раза +2WS в три раза...

aaarrr

Sep 28 2008, 17:36

Цитата(zltigo @ Sep 28 2008, 21:31)

А я ее просто не вижу, посему уверенным быть ну никак не могу.

Вам код выложить для проверки?

Цитата(zltigo @ Sep 28 2008, 21:35)

Именно в разы +1 WS - в два раза +2WS в три раза...

2WS не используются никогда.

zltigo

Sep 28 2008, 17:40

Цитата(aaarrr @ Sep 28 2008, 19:33)

А какое дело DMA до Неймана?

Это я ведь о Вашем выводе "Похоже, что Flash сидит на отдельной шине."

Цитата(aaarrr @ Sep 28 2008, 19:36)

Вам код выложить для проверки?

Проверить не начем, но почитать могу...

Цитата

2WS не используются никогда.

Возможно. У Atmel 36ns Flash??? Крутовато несколько, но не невозможно. При более ширпотребно-реальных 55ns в акурат 3WS.

singlskv

Sep 28 2008, 17:44

Цитата(zltigo @ Sep 28 2008, 21:35)

Именно в разы +1 WS - в два раза +2WS в три раза...

Выкладывайте тест когда будет как минимум в 3 раза, протестирую...

aaarrr

Sep 28 2008, 17:45

Цитата(zltigo @ Sep 28 2008, 21:40)

Это я ведь о Вашем выводе "Похоже, что Flash сидит на отдельной шине."

Да, т.е. никто не мешает процессору читать Flash, в то время, как DMA окучивает RAM.

Цитата(zltigo @ Sep 28 2008, 21:40)

Проверить не начем, но почитать могу...

CODE

u_int spi_buff[5000];

void test(void)
{
	u_int b;
	u_short a;

	AT91C_BASE_PMC->PMC_PCER = (0x01 << AT91C_ID_TC0);

	// Wave mode, MCK/8,  UP mode with automatic trigger on RC Compare
	AT91C_BASE_TCB->TCB_TC0.TC_CMR = AT91C_TC_CLKS_TIMER_DIV2_CLOCK | AT91C_TC_WAVESEL_UP | AT91C_TC_CPCSTOP | AT91C_TC_WAVE;
	AT91C_BASE_TCB->TCB_TC0.TC_RC = 0xffff;
	AT91C_BASE_TCB->TCB_TC0.TC_CCR = AT91C_TC_CLKEN;
	AT91C_BASE_TCB->TCB_TC0.TC_CCR = AT91C_TC_SWTRG;

	spi0_ini();
	for(b = 0; b < 5000; b++)
		spi_buff[b] = (0x07 << 0x10) | 0x55;
	AT91C_BASE_SPI0->SPI_TPR = (u_int)spi_buff;
	AT91C_BASE_SPI0->SPI_TCR = 5000;
	AT91C_BASE_SPI0->SPI_RPR = (u_int)spi_buff;
	AT91C_BASE_SPI0->SPI_RCR = 5000;

	dprintf("bla-bla\r\n");

	AT91C_BASE_SPI0->SPI_PTCR = AT91C_PDC_TXTEN | AT91C_PDC_RXTEN;

	a = AT91C_BASE_TCB->TCB_TC0.TC_CV;
	b = 0x100;
	do
	{
		__asm
		{
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
			nop; nop; nop; nop; nop; nop; nop; nop;
		}
	} while(--b );
	a = AT91C_BASE_TCB->TCB_TC0.TC_CV - a;
	dprintf("t=%d\r\n", a);

	while(0x01);
}

void spi0_ini(void)
{
	AT91C_BASE_SYS->PIOA_BSR = SPI0_CS1 | SPI0_CS2 | SPI0_CS3;
	AT91C_BASE_SYS->PIOA_ASR = SPI0_CS0 | SPI0_MISO | SPI0_MOSI | SPI0_SPCK;
	AT91C_BASE_SYS->PIOA_PDR = SPI0_CS1 | SPI0_CS2 | SPI0_CS3 | SPI0_CS0 | SPI0_MISO | SPI0_MOSI | SPI0_SPCK;

	AT91C_BASE_PMC->PMC_PCER = (0x01 << AT91C_ID_SPI0);

	AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
	AT91C_BASE_SPI0->SPI_MR = AT91C_SPI_MODFDIS | AT91C_SPI_PS | AT91C_SPI_MSTR;	// Master, Variable mode

	AT91C_BASE_SPI0->SPI_CSR[0x03] = (0x01 << 0x08) | (0x00 << 0x04)
		| AT91C_SPI_NCPHA | AT91C_SPI_CPOL;								// Dummy: SPI Mode 2, MCK, 8 bits
}

Цитата(zltigo @ Sep 28 2008, 21:40)

Возможно. У Atmel 36ns Flash??? Крутовато несколько, но не невозможно. При более ширпотребно-реальных 55ns в акурат 3WS.

В документации написано:

Цитата

Single Cycle Access at Up to 30 MHz in Worst Case Conditions

singlskv

Sep 28 2008, 17:56

Цитата(zltigo @ Sep 28 2008, 21:40)

Возможно. У Atmel 36ns Flash??? Крутовато несколько, но не невозможно. При более ширпотребно-реальных 55ns в акурат 3WS.

zltigo я уже приводил пример в другой ветке когда доступ к флеш
у Renesas 12,5ns , сейчас у них уже 10ns, так что 36ns не есть что-то особенное,
на самом деле там вобще скорее всего ~30ns по максимуму, по крайней мере
у меня на SAM7A3 и на 65Мгц все работает(была ошибка в задании PLL

, предыдущего
программера

)

zltigo

Sep 28 2008, 18:01

Цитата(singlskv @ Sep 28 2008, 19:44)

Выкладывайте тест когда будет как минимум в 3 раза, протестирую...

Тестировать незачем. Это физическая сущность

. Нужны WS - стоим и ждем.

Цитата

В документации написано:
Single Cycle Access at Up to 30 MHz in Worst Case Conditions

Радует! LPC только за счет своей 128битности вытягивает скорость. Только интерсно тогда отчего они на числе 55MHz остановились?

Цитата

CODE...

Я тестику реализма прибавлю самую малость. Проверите?

Цитата(singlskv @ Sep 28 2008, 19:56)

zltigo я уже приводил пример в другой ветке когда доступ к флеш
у Renesas 12,5ns , сейчас у них уже 10ns, так что 36ns не есть что-то особенное,

Верю, верю, просто SAM7 совершенно массовый дешевый контролер, а массовая Flash нынче отнюдь не 10-12-30ns.

aaarrr

Sep 28 2008, 18:03

Цитата(zltigo @ Sep 28 2008, 22:01)

Мне тоже не понятно. Где-то случился затык, и отнюдь не во флеш. Предыдущие ARM7 у них были и на 66MHz.

Цитата(zltigo @ Sep 28 2008, 22:01)

Я тестику реализма прибавлю самую малость. Проверите?

Пожалуйста.

singlskv

Sep 28 2008, 18:19

Цитата(zltigo @ Sep 28 2008, 22:01)

Верю, верю, просто SAM7 совершенно массовый дешевый контролер, а массовая Flash нынче отнюдь не 10-12-30ns.

Дык вроде как и Xmega у Atmel теперь ~30ns доступ к флеш...
30Мгц для доступа к флеш у Atmel уже давно...
И вот меня это совсем не удивляет, возможно за это они и берут свой "лишний" бакс к цене...

aaarrr

Sep 28 2008, 18:31

Цитата(zltigo @ Sep 28 2008, 22:28)

Легко. Посмотрю на дальнейшее развитие и разделю тему.

ИМХО, имеет смысл отделить бенчмарки и кинуть в раздел ARM. Тема сама по себе интересная получается.

zltigo

Sep 28 2008, 18:37

Цитата(aaarrr @ Sep 28 2008, 20:03)

Пожалуйста.

Как скучно оказывается всухую писать

. Просьба для начала заменить nop-овский цикл на такое:

Код

volatile u_int b = 0x800;
volatile u_int c = 0;
volatile u_int d = 0;
    do
    {
        c = AT91C_BASE_TCB->TCB_TC0.TC_CV;
        d += c;

    } while(--b );
    a = AT91C_BASE_TCB->TCB_TC0.TC_CV - a;
    dprintf("t=%d\r\n", a);
    d = d;

Интересен Flash, 55MHz, ARM mode.

Цитата(aaarrr @ Sep 28 2008, 20:31)

Тема сама по себе интересная получается.

Естественно!

aaarrr

Sep 28 2008, 18:52

Цитата(zltigo @ Sep 28 2008, 22:37)

Как скучно оказывается всухую писать

. Просьба для начала заменить nop-овский цикл на такое:
Интересен Flash, 55MHz, ARM mode.

Сделано.

Flash 1WS:

Код

ошибка

RAM 0WS:

Код

ошибка

Числа - это количество тактов на выполнение (выход * 8).
Время симулятора для случая RAM 0WS PDC Idle: 16382

zltigo

Sep 28 2008, 19:20

Цитата(aaarrr @ Sep 28 2008, 20:52)

Сделано.

Очень интересный результат! Похоже сегмент шины с Flash как-то изолируем, что позволяет по хозяйски распоряжаться неизбежным 50% простоем ядра при доступе к Flash для доступа DMA к RAM.
А 30MHz и 0WS из Flash еще пожалуйста!

aaarrr

Sep 28 2008, 19:30

Результат еще интереснее. Как я уже писал, очень похоже, что шина Flash отделена.

Flash 0WS:

Код

ошибка

Незначительное ускорение не случайное, повторяется стабильно.

Расхождение результатов с симулятором связано с обращением к периферийному регистру, но не очень понятно, почему возникает именно такое замедление.

singlskv

Sep 28 2008, 19:41

Цитата(zltigo @ Sep 28 2008, 23:20)

То есть 3 раза это уже фантазия ?(ну это про разы...)

Цитата(aaarrr @ Sep 28 2008, 23:30)

Результат еще интереснее. Как я уже писал, очень похоже, что шина Flash отделена.

Мне вобще кажется что это почти всегда на современных мк.
Нет никагого смысла располагать флеш на той же шине...

zltigo

Sep 28 2008, 19:48

Цитата(aaarrr @ Sep 28 2008, 21:30)

Результат еще интереснее. Как я уже писал, очень похоже, что шина Flash отделена.

Странее! Не покидает мысль, что что-то не то. А разделить буфера приема передачи и организовать в тесте хоть какую-то рекцию(обработку) на окончание цикла работы DMA? И вообще, при исполнении IDLE из RAM на 55MHz получаем скорость РАВНУЮ до такта! скорости исполнения из FLASH на 30MHz. Что это c тестом?

Цитата(singlskv @ Sep 28 2008, 21:41)

Нет никагого смысла располагать флеш на той же шине...

Это понятно, что слова Нейман/Гарвард почти пустой звук по нынешнмм временам, но предполагал, что это все-же пока не для достаточно простых ARM7 ядер.

Цитата(singlskv @ Sep 28 2008, 21:41)

То есть 3 раза это уже фантазия ?(ну это про разы...)

50% это замедление в ДВА раза при ОДНОМ WS.Чего непонятного? Никаких фантазий.

aaarrr

Sep 28 2008, 19:59

Цитата(zltigo @ Sep 28 2008, 23:46)

Странее! Не покидает мысль, что что-то не то. А разделить буфера приема передачи и организовать в тесте хоть какую-то рекцию(обработку) на окончание цикла работы DMA?

Тогда нужно время теста укорачивать, у меня нет столько свободной памяти. Попробую.
Могу еще проконтролировать время окончания цикла DMA.

Цитата(zltigo @ Sep 28 2008, 23:48)

И вообще, при исполнении IDLE из RAM на 55MHz получаем скорость РАВНУЮ до такта! скорости исполнения из FLASH на 30MHz. Что это c тестом?

Я и считаю такты. А они одинаковые, хоть на 30, хоть на 55MHz.

С более скоростым доступом к периферии со стороны DMA все понятно - процессор имеет доступ через медленную APB, в то время как DMA подключен с одной стороны к ASB, а с другой напрямую к периферийным модулям.

singlskv

Sep 28 2008, 20:00

Цитата(zltigo @ Sep 28 2008, 23:48)

Это понятно, что слова Нейман/Гарвард почти пустой звук по нынешнмм временам, но предполагал, что это все-же пока не для достаточно простых ARM7 ядер.
50% это замедление в ДВА раза при ОДНОМ WS.Чего непонятного? Никаих фантазий.

в 2 раза в худшем случае - согласен ! (в реальности, когда еще иногда
встречаются регистр-регистр, намного лучше...)

Цитата

Дык видать основная борьба и проходит в данный момент по этому флангу...(у производителей)

zltigo

Sep 28 2008, 20:09

Цитата(aaarrr @ Sep 28 2008, 21:59)

Я и считаю такты.

Тьфу, привычка по другому организовывать тесты

Цитата

...а с другой напрямую к периферийным модулям.

Как-бы да, в действительности каналы DMA у SAM7 не общего назначения разделяемые ресурсы, а исключительно интимные узлы периферии.

singlskv

Sep 28 2008, 20:18

Цитата(zltigo @ Sep 29 2008, 00:09)

А у SAM9 или AVR32 они что, что-то совсем обособленное ?
конечно они нифига не разделяймые ресурсы, а очень было надо ?

aaarrr

Sep 28 2008, 20:30

Цитата(zltigo @ Sep 28 2008, 23:48)

Не покидает мысль, что что-то не то.

Вы правы, что-то не то при работе из flash. Разбираюсь сейчас.

zltigo

Sep 28 2008, 20:33

Цитата(singlskv @ Sep 28 2008, 22:18)

...конечно они нифига не разделяймые ресурсы, а очень было надо ?

На Atmel свет клином не сошелся

. Cуществуют оба варианта Dedicated/General, обычно вместе. Кроме жестких и относительно простых каналов DMA заточенных под переферийное железо, используются и "общего назначения" более сложные DMA с наворотами, например, типа организации обслуживания кольцевых буферов, burst, fifo, big/little endian трансляцией... Они подключаются к периферийным устройствам по необходимости, в том числе и не к у устройствам, а для пересылки память-память. И между устройствами.
Надо.

singlskv

Sep 28 2008, 20:40

Цитата(zltigo @ Sep 29 2008, 00:33)

в том числе и не к у устройствам, а для пересылки память-память.
Надо.

Согласен, про память-память не подумал, просто для ARM7 это вроде как не актуально...
Для АРМ9 итд. может быть действительно актуально...

zltigo

Sep 28 2008, 20:46

Цитата(singlskv @ Sep 28 2008, 22:40)

Согласен, про память-память не подумал, просто для ARM7 это вроде как не актуально...

Актуально, у ARM7 LPC23/24 кроме локальной еще 2 AHB шины со своми банками памяти.

singlskv

Sep 28 2008, 20:54

Цитата(zltigo @ Sep 29 2008, 00:46)

Актуально, у LPC23/24 кроме локальной еще 2 AHB шины со своми банками памяти.

Не знаю толком этих семейств, но это("еще 2 AHB шины со своми банками памяти")
уже не очень похоже на ARM7, подходы совсем другие,
вероятно нечто промежуточное между ARM7 и ARM9.

aaarrr

Sep 28 2008, 21:01

Друзья мои, я опечален ©

Во-первых, из-за ошибки в скрипте линкера у меня клинило DMA при работе из Flash;
а во-вторых, SPI как-то криво работает на частоте MCK/1

Поток SPI пришлось сократить в 2 раза.

RAM 0WS

Код

PDC Idle: 9224
PDC TX: 9832
PDC TX+RX: 11472

FLASH 0WS

Код

PDC Idle: 9216
PDC TX: 9840
PDC TX+RX: 11472

FLASH 1WS

Код

PDC Idle: 15368
PDC TX: 16392
PDC TX+RX: 16400

~~Тем не менее, можно видеть, что не так уж все и плохо~~

Дополнительно попробовал запустить 2xMCK/2 SPI. Не тянет уже.

RAM 0WS

Код

PDC Idle: 9224
PDC TX: 10928
PDC TX+RX: 12136 (DMA передача не уложилась по времени - 141%)

FLASH 0WS

Код

PDC Idle: 9216
PDC TX: 10928
PDC TX+RX: 12136 (DMA передача не уложилась по времени - 141%)

FLASH 1WS

Код

PDC Idle: 15368
PDC TX: 16392
PDC TX+RX: 19120 (DMA передача не уложилась по времени - 149%)

Такие вот пирожки с котятами.

zltigo

Sep 28 2008, 21:37

Цитата(singlskv @ Sep 28 2008, 22:54)

уже не очень похоже на ARM7, подходы совсем другие,

Отнюдь, какая разница на одну или две шины дешифрировать адресное пространство - ядро знать не знает. Все достаточно архитектурно просто. В приложении простенькая картинка.

Цитата(aaarrr @ Sep 28 2008, 23:01)

Такие вот пирожки с котятами.

Тем неменее внесена определенная ясность, и это уже хорошо, ибо даже если не все радужно, то praemonitus praemunitus!

aaarrr

Sep 28 2008, 21:41

Итого:
С одной стороны нас никто не обманывает, и запись/чтение периферии через DMA занимает 1/2 такта соответственно, ядро не тормозится.
Но с другой стороны, от шины получилось отгрызть без последствий только 1/8 полосы (что не так уж и плохо - 27.5Мбайт/с).
Очень неприятен момент с торможением DMA-передачи, лучше бы вставало ядро.

zltigo

Sep 28 2008, 21:44

Цитата(aaarrr @ Sep 28 2008, 23:41)

ядро

существенно

Цитата

не тормозится.

aaarrr

Sep 28 2008, 21:47

Цитата(zltigo @ Sep 29 2008, 01:37)

Тем неменее внесена определенная ясность, и это уже хорошо, ибо даже если не все радужно, то praemonitus praemunitus!

Ну да, не все радужно, конечно

Но пользоваться вполне можно. Тем более, что перелопатить такой поток, на котором встал DMA, процессор все равно не сможет.

Цитата(zltigo @ Sep 29 2008, 01:44)

существенно

По мне так лучше бы оно вставало совсем - у меня процессор стоит в качестве дешевой замены FPGA, думать ему особо не приходится

zltigo

Sep 28 2008, 22:04

Цитата(aaarrr @ Sep 28 2008, 23:47)

Тем более, что перелопатить такой поток, на котором встал DMA, процессор все равно не сможет.

Ну и последний эксперимент увеличить число DMA каналов с 4x до 6-8, какой предел пропускной способности одного канала?

Цитата

Тем более, что перелопатить такой поток, на котором встал DMA, процессор все равно не сможет.

Ну насколько я понял, у Вас, как и у меня, одна из задач пропускать поток частично и мимо контроллера, просто используя его MAC? У меня это, правда, задача вспомогательно-опциональная, но и потоки потоньше - 64Kbit, хотя их побольше - до 16.

aaarrr

Sep 28 2008, 22:18

Цитата(zltigo @ Sep 29 2008, 02:04)

Попробуем, но уже не сегодня.

Цитата(zltigo @ Sep 29 2008, 02:04)

Не совсем так. У меня постоянно передаются один или два потока по 20Мбит/с, но данные для них меняются только при смене фрейма раз в 13мс. Процессору за это время нужно перепаковать и откорректировать (через LUT) данные, полученные из Ethernet'а, и его производительности хватает почти в любом случае.

Shuuura

Sep 29 2008, 11:31

Цитата(zltigo @ Sep 27 2008, 22:32)

Да нет, не как у всех

- c STM32 работаю. Глюков чрезмерно много - в стиле ST

(традиция в ряду STR7/9xx)и само ядро V1 с багами, кривыми усеченными "библиотеками" латается отсутствие внятной документации

и неполность erratа... Но с точки зрения использования малоногих и шустрых (кому еще и малопотребляющих) чипов альтернатив им нет. Буду использовать, ибо LPC1300 уже не дождусь, а LPC210x не вытянут желаемого. Если и начинать с Cortex-M3, то уже почти доступны LPC1700. Там и ядро V2, и периферия от LPC23xx отлаженная и цену на ..дцать процентов меньше обещают.

Можно поподробнее про глюки STM32? А то уж слишком красиво на новый проект ложатся. Кардинальные отличия между версиями Cortex-M3 есть?

zltigo

Sep 29 2008, 11:49

Цитата(Shuuura @ Sep 29 2008, 13:31)

Можно поподробнее про глюки STM32?

Errata для начала. Дальше - дальше хуже

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

.
Вместо документации, блин, "библиотеки". Если свобода творчества в пределах ограниченных "библиотеками" устравивает, то наверное и проблем особых вообще не будет.

Цитата

А то уж слишком красиво на новый проект ложатся.

Пользуйте, как-нибудь обойдете.

Цитата

Кардинальные отличия между версиями Cortex-M3 есть?

Есть

Где-то 5 багов в ядре постепенно от подверсии к подверсии исправлявниеся, но все известное исправленно во второй версии (но это будет только в LPC + несколько новых команд). Компиляторы латают.
По Corteх есть отдельная ветка - продолжите там.

defunct

Sep 29 2008, 16:12

Цитата(zltigo @ Sep 27 2008, 21:32)

Вы мне пытаетесь объяснить, что без DMA совсем труба? - согласен. Для помянутого тупого заглатывания по UART 256 байтовых пакетов формально DMA типа меньше ресурсов потребит, нежели 16байтовое FIFO у LPC, только вот что-то я никогда не писал алгоритмов по заглатыванию 256 байт всякой всячины и возможного мусора и последующем ДОЛГОМ в нем копании.

Насчет заглатывания UART'a - поддерживаю. Байт-ориентед удобнее побайтово принимать и разгребать.

А вот такая задачка: оцифровка с последущим анализом (FFT) и воспроизведение звука с минимальным джиттером между семплами, скажем так Fd= 44.1kHz, mono. С SAM'овским DMA задача решается на ура без интервенции процессора, получаем сразу подготовленные для FFT выборки требуемого размера. Жрет на SAM'е эта задачка процентов 10 ресурсов проца. Будет ли такая же эффективность на LPC без DMA? И вообще можно ли ее решить на LPC, если учесть что эта задача - не самоцель, а есть еще и другие функции выполяемые МК (FIQ то только один)?

aaarrr

Sep 29 2008, 17:01

Цитата(defunct @ Sep 29 2008, 20:12)

Будет ли такая же эффективность на LPC без DMA?

Дык на новых LPC есть DMA.

Посмотрел Atmel'овские статейки. Очень мило пишут про PDC, типа:

Цитата

The device easily supports 25 Mbps SPI or TWI transfers, and still has 96% of it resources available to execute embedded control functions.

Всюду они эти 25Мбит суют. А TWI приплетен вообще непонятно каким боком, ибо к PDC подключения не имеет, а 25Мбит передавать не может по определению.

Easily, блин. А за easily сразу кирдык

defunct

Sep 29 2008, 19:03

Цитата(aaarrr @ Sep 29 2008, 20:01)

Дык на новых LPC есть DMA.

Это в новых, а в тех что нет? Задачка в защиту "полной непотребности" SAM7 DMA.

Цитата(aaarrr @ Sep 29 2008, 20:01)

А TWI приплетен вообще непонятно каким боком, ибо к PDC подключения не имеет, а 25Мбит передавать не может по определению.

опечатка вестимо. доки пишут иногда люди далекие от все этого.

aaarrr

Sep 29 2008, 19:15

Цитата(defunct @ Sep 29 2008, 23:03)

Это в новых, а в тех что нет?

Вместо старого NXP лучше взять новый NXP, а не старый Atmel. О чем спорить-то?

Цитата(defunct @ Sep 29 2008, 23:03)

Задачка в защиту "полной непотребности" SAM7 DMA.

Ну, о полной непотребности говорить уже не приходится. Хотя некоторая непотребность/недодокументированность есть.

Цитата(defunct @ Sep 29 2008, 23:03)

опечатка вестимо. доки пишут иногда люди далекие от все этого.

Это из статьи. Опечатка забавная - вспомнили самый глючный модуль, которому этого PDC весьма, кстати, не хватает.

VslavX

Sep 30 2008, 08:08

Цитата

джиттером между семплами, скажем так Fd= 44.1kHz, mono. С SAM'овским DMA задача решается на ура без интервенции процессора, получаем сразу подготовленные для FFT выборки требуемого размера. Жрет на

+1 - использую я PDC для АЦП на SAM7 - _очень_ удобно. На LPC пришлось для тех же целей все "ручками" делать.
+1 - еще PDC использую для SPI - у меня второй абонент более 4мбит не жрет, так что ни о какой блокировке шины речи не идет.
-1 - для MMC/SD по SPI PDC не очень хорошо подходит - удобнее побайтно, параллельно считая CRC
-1 - еще пытался использовать PDC для USARTа (протоколы на RS-485) - не понравилось, код распух, хотя ресурсов немного меньше от процессора отожралось. В итоге вернулся к "побайтовому" разбору - SAM-овский UART очень рулит - не понадобился допонительный таймер.
P.S. А вообще потихоньку переходим с SAM7A3/S/X/SE на LPC214x/23x8/24x8 - быстрее, честные RTC, номенклатура больше (есть 144-ногие). И по большому счету - уже пофиг LPC или SAM - HAL-ы под наши задачи понаписаны на оба семейства, все максимально абстрагировано получается. Как "партия" (рыночная коньюнктура) прикажет - такой проц и заложим

, нефиг из LPC или SAM религию устраивать.

aaarrr

Sep 30 2008, 11:15

Цитата(VslavX @ Sep 30 2008, 12:08)

-1 - еще пытался использовать PDC для USARTа (протоколы на RS-485) - не понравилось, код распух, хотя ресурсов немного меньше от процессора отожралось. В итоге вернулся к "побайтовому" разбору - SAM-овский UART очень рулит - не понадобился допонительный таймер.

А необходимость мгновенной реакции на прерывание не напрягает? ИМХО, для UART'а как раз он очень удобен.

Dron_Gus

Sep 30 2008, 11:45

Раз уж пошел оффтопик полный. Предлагаю высказаться по поводу реализации DMA (да и FIFO) в STR912FAW**. На мой скромный взгляд, очень качественно и гибко. Это, конечно, уже ARM9...

VslavX

Sep 30 2008, 12:32

Цитата(aaarrr @ Sep 30 2008, 14:15)

А необходимость мгновенной реакции на прерывание не напрягает? ИМХО, для UART'а как раз он очень удобен.

"Мгновенность" критична только на приеме. У меня максималка 115200 -~100мкс (пользую два стопа почти всегда) примерно в запасе есть, чтобы забрать байт. В 99.9999% байты успешно забираются, а если какие-то проблемы - это все решается протоколом на канальном уровне - ретрансмитты и прочее.
Без таких "решающих" протоколов вылазить на RS-485 бессмысленно, ну и заодно они "решат" проблему если кто-то "не успел".
Вообще я иногда тестирую свои системы на realtime - как правило время реакции на прерывание - не хуже 15-20мкс на TNKernel на 48МГц SAM7. На LPC-ях пока не гонял, должно быть еще веселее.
И даже взял моду "сложные" прерывания (типа USB, EMAC) обрабатывать в отдельном высокоприоритетном потоке - время переключения считанные мкс, а структура программы становится линейной и упрощается чуть ли не в разы, на синхронизацию доступа к регистрам оборудования можно вообще забить.

defunct

Sep 30 2008, 13:23

Цитата(aaarrr @ Sep 30 2008, 14:15)

ИМХО, для UART'а как раз он очень удобен.

+1 для TX бесспорно.
для RX куда приятнее побайтово, будь-то пакетный протокол или консоль с упр. символами.

Цитата

А необходимость мгновенной реакции на прерывание не напрягает?

А зачем мгновенная реакция? Проц 55Mhz, частота прерываний uart'a at max - 11.52kHz (на 115200).

Цитата(aaarrr @ Sep 29 2008, 22:15)

Вместо старого NXP лучше взять новый NXP, а не старый Atmel. О чем спорить-то?

В таком ключе пожалуй не о чем ;>

А вместо старого SAM'a, стоит ли брать новый NXP?

VslavX

Sep 30 2008, 13:53

Цитата(defunct @ Sep 30 2008, 16:23)

+1 для TX бесспорно.

Не-а, для сколько-нибудь сложных протоколов для TX тоже приятнее побайтово - не надо заводить отдельный буфер, копировать туда куски разных полей, потом вычислять сумму пакета за один проход.
А "побайтово" - генерируешь многие куски пакета "на лету" и вычисление суммы "размазывается" по времени. Реализация "моего" протокола без PDC мне больше понравилась. Хотя - "случаи - они разные бывают".

aaarrr

Sep 30 2008, 14:10

Цитата(defunct @ Sep 30 2008, 17:23)

А зачем мгновенная реакция? Проц 55Mhz, частота прерываний uart'a at max - 11.52kHz (на 115200).

Ну, в основном их заводят на 48MHz. И UART бывает не только на 115200, особенно если это RS-485.

Цитата(defunct @ Sep 30 2008, 17:23)

А вместо старого SAM'a, стоит ли брать новый NXP?

ИМХО, стоит.

defunct

Sep 30 2008, 16:14

Цитата(VslavX @ Sep 30 2008, 16:53)

У меня обычно любой протокол сводится к
xx_SendPacket( U8 *pData, int size);
Просто и дубово, считать CS удобнее.
Заводить отдельный буфер не надо, можно использовать буфер принятого пакета для формирования отправляемого.

Цитата(aaarrr @ Sep 30 2008, 17:10)

И UART бывает не только на 115200, особенно если это RS-485.

Угу, бывает и 9600 особенно 485.
Насчет же скоростей выше 115200, есть и более подходящие для этого интерфейсы (eth/usb)

zltigo

Sep 30 2008, 16:52

Цитата(defunct @ Sep 30 2008, 15:23)

А вместо старого SAM'a, стоит ли брать новый NXP?

Без вариантов. На самом старом семействе типа LPC211x/22xx/210x там выбор может быть очень труден, для LPC213x/4x - ну только если чего-то типа I2S требуется, или совсем в масть что-то ложится. А на LPC23xx/24xx просто без вариантов. Тем более,что новые семейства дешевле и старых, и SAM7. http://mt-system.ru/index.php?store_search=lpc2&id=5

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.