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

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

RAM 0WS


FLASH 0WS


FLASH 1WS


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

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

RAM 0WS


FLASH 0WS


FLASH 1WS


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

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


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

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

существенно

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


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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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


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


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

+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 религию устраивать.

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