Я вижу, что DMA используется все больше и больше на этом форуме, и одна тема, которая время от времени упоминается, заключается в том, что при использовании DMA не блокирует, он разделяет шину памяти с процессором и ухудшит производительность (как упомянуто в справочном руководстве. ).

Тем не менее, мы никогда не знали, сколько это замедлится, поэтому я решил сделать некоторые измерения.

Настройка: я взял код Dhrystone, который вы можете найти на форуме (я взял Zip из первого поста) и запустил его на Maple Mini, который у меня был рядом со мной. Это дало мне рейтинг 35,87 Vax MIPS. (Что немного ниже, чем в первом посту темы упоминается, что они получили 48, но это просто базовый уровень & интенсивный тест, кажется достаточно хорошим).

Затем я провел различные тесты с установкой SPI1 в круговой передаче DMA & получение данных в 2 буфера 256bytes большие. и повторял каждый тест 5 раз (цифры, однако, всегда были последовательными, вообще никаких отклонений)

Вот результаты:
Нет DMA: 35,87 VAX MIPS
Spi1 @div16: 36.08 VAX MIPS (по какой -то причине немного быстрее, чем без DMA)
Spi1 @div8: 34.8 Vax Mips
Spi1 @div4: 34.32 VAX MIPS
Spi1 @ div2: 33.93 VAX MIPS
SPI1 & SPI2 оба в Div2: 33.61 Vax Mips

Это всего лишь первоначальный тест, но это кажется очень обнадеживающим. Вряд ли нет штрафа за производительность, даже при использовании оба порта SPI на полной скорости. Чтобы убедиться, что DMA действительно работал, я проверил с помощью своего логического анализатора, что они на самом деле что -то делали, не проверял приемную часть, но передача наверняка работала .
Я использовал свою собственную библиотеку DMA, так как у меня был код легко доступен, и я знаю, как он работает .

Очень интересно...

Интересно, есть ли другие тесты скорости, которые вы можете пробежать на пожарном зале, E.глин. Доступ к оперативной памяти должен быть замедлен DMA, поэтому простой тест будет запустить Memcoy, чтобы скопировать 4K -блок от оперативной памяти, несколько раз.

Вы могли бы сделать тот же тест, выполняя MEMCOY от Const Array in Flash до Ram.

Но предположительно, результат RAM был тем, на что должно повлиять DMA

КСТАТИ. Вам может понадобиться написать свой очень простой Memcpy, чтобы быть уверенным в том, что он делает

Да тест с Memcpy.

После этого тестируется с DMA Mem2mem, это наверняка нанесет ущерб производительности.

Хорошо, первое следующее наблюдение в попытке забросить производительность с использованием DMA: Maple Mini имеет только 1 DMA -контроллер, и он имеет конечную полосу. 2 SPI вместе (в 8 -битном режиме SPI) довольно хорошо работают вместе. Я вижу небольшую деградацию в их производительности, когда я включаю оба (небольшой недостаток в часах между каждым байтом), но ничего драматического.
Однако, как только я включил перенос MEM2MEM, контроллер DMA перегружен, и один из обоих SPI должен будет дать... другой все еще будет функционировать хорошо, но один из обоих вряд ли сможет больше передавать данные. Даже когда я запускаю это, я не вижу большой разницы в тестах Dhrystone. Документы STM32 также упоминают, что все, что вы делаете, оба процессора & DMA в равной степени поделится контроллером памяти, поэтому даже если я затоплен DMA, в процессоре все еще будет 50% контроллера памяти для себя.

Следующие тесты: Memcpy.

Реданьяк написал:Однако, как только я включил перенос MEM2MEM, контроллер DMA перегружен, и один из обоих SPI должен будет дать...

Реданьяк написал:
Следующие тесты: Memcpy.

Даниэфф написал:Реданьяк написал:Однако, как только я включил перенос MEM2MEM, контроллер DMA перегружен, и один из обоих SPI должен будет дать...

Отличный

Хорошо, делали несколько времени на следующем фрагменте кода (My 'Memcpy'): #include "SPI.h" #include "SdFat.h" const uint8_t chipSelect = PA4 SdFat sd(1); void setup() { if (!sd.begin(chipSelect, SD_SCK_MHZ(50))) { sd.initErrorHalt(); } ... }

Может быть, небольшая модификация MEMCOPY покажет другой результат: if (!sd.begin(SD_CHIP_SELECT, SPI_SPEED)) { sd.initErrorHalt(); ////////////////////////////////////////// insert this to see error code }

пытаться
#define Serial Serial1 #include "SPI.h" #include "SdFat.h" const uint8_t chipSelect = PA4; SdFat sd(1); void setup() { Serial.begin(115200); while (!Serial.available()){ Serial.println("wainting"); } delay(100); if (!sd.begin(chipSelect, SD_SCK_MHZ(4))) { sd.initErrorHalt(); // sd.initErrorPrint(); } } void loop() {}

Стив - мы пересекаем, опубликовано с практически идентичным кодом

Я бы также попробовал разные размеры указателей

Моя версия более интенсивно использует шину памяти, делая 8 последовательных доступа.

Стивестронг написал:Моя версия более интенсивно использует шину памяти, делая 8 последовательных доступа.

Стивестронг написал:Может быть, небольшая модификация MEMCOPY покажет другой результат: 16:26:02 : Some flash sectors are write protected. The write protection will be disabled then restored after flash programming in case there is no option bytes segment within the file. 16:26:05 : Programming error @ 0x0800001C!

Я думаю, было бы интересно увидеть тестовое программное обеспечение от Виктора (http: // www.STM32duino.com/viewtopic.PHP ... 811#P24989) в сочетании с вашими измерениями.

То, что также может быть интересным тестом, является большим STM32. У CBT6 есть только 1 контроллер DMA, но более крупные имеют 2. Если я поработаю над обоими, каждый получает 1/3 автобуса памяти, так что это, вероятно, окажет большее влияние на процессор (если только для тех моделей они также увеличивают емкость шины памяти).

Перед тем, как сделать эти тесты сам, я выполнил быстрый поиск в Google, чтобы увидеть, смогу ли я найти существующие тесты, не нашел много, за исключением этого очень хорошего документа от STM: http: // www.ул.com/content/ccc/resource/ ... 160362.PDF

С тестами на скорость, я думаю, что @stevestrongs код является худшим возможным случаем.

эн.G вы обычно не писали бы так, если у вас не было небольшого буфера известной длины и не хотели абсолютно лучшую скорость.

Я думаю, что в нормальной работе, что -то вроде Memcpy или, возможно, моего кода, с большей вероятностью будет использоваться.
И возможно, что DMA может переплетать, когда процессор выполняет сравнение адресов указателя и разветвление. Таким образом, возможно, что передачи DMA из RAM не окажут никакого влияния на Memcpy и т. Д., Если они возьмут только один цикл, чтобы получить из RAM

Rogerclark написал:С тестами на скорость, я думаю, что @stevestrongs код является худшим возможным случаем.

эн.G вы обычно не писали бы так, если у вас не было небольшого буфера известной длины и не хотели абсолютно лучшую скорость.

Я думаю, что в нормальной работе, что -то вроде Memcpy или, возможно, моего кода, с большей вероятностью будет использоваться.
И возможно, что DMA может переплетать, когда процессор выполняет сравнение адресов указателя и разветвление. Таким образом, возможно, что передачи DMA из RAM не окажут никакого влияния на Memcpy и т. Д., Если они возьмут только один цикл, чтобы получить из RAM

У меня не так много времени, но у меня есть множество других MCU F103, до RFT6.
Если вы опубликуете полный набросок в GitHub и какие связи мне нужно сделать (например, цикл в SPI Miso Mosi или что -то еще, за исключением логического анализатора на 36 МГц, как у меня нет), я могу запустить его в разных mcus в серия с большим количеством оперативной памяти и контроллерами.

До сих пор я думаю, что вывод состоит в том, что DMA не голодает на процессор, но процессор может голодать DMA, и DMA может сам голодать. Поэтому, если вы хотите параллелизм на более чем 1 периферийном порядке, может быть полезно, чтобы устройства DMA были меньше, чем их полная скорость, чтобы убедиться, что ничто не голодает для доступа.

Еще один тест, который я не видел в потоке, это то, помогает ли использование 16 -битного режима в порте SPI, так как теоретически он уменьшит доступ к оперативной памяти до 1/2 за байт.

[victor_pv - Пн 26 июня 2017 г. 15:08] - У меня не так много времени, но у меня есть множество других MCU F103, до RFT6.
Если вы опубликуете полный набросок в GitHub и какие связи мне нужно сделать (например, цикл в SPI Miso Mosi или что -то еще, за исключением логического анализатора на 36 МГц, как у меня нет), я могу запустить его в разных mcus в серия с большим количеством оперативной памяти и контроллерами.

До сих пор я думаю, что вывод состоит в том, что DMA не голодает на процессор, но процессор может голодать DMA, и DMA может сам голодать. Поэтому, если вы хотите параллелизм на более чем 1 периферийном порядке, может быть полезно, чтобы устройства DMA были меньше, чем их полная скорость, чтобы убедиться, что ничто не голодает для доступа.

Хм, также интересный тест: сколько может продумать процессор. Они в равной степени разделяют шину памяти, поэтому я не ожидаю, что ЦП будет иметь в состоянии оказать гораздо большее влияние на DMA, чем наоборот (хотя DMA, вероятно, даже более зависит от памяти, чем ЦП, так что будет приятным тестом ). Но действительно, DMA может, по крайней мере, полностью голодать сам по себе ^^ '.

Я посмотрю на обмен кодом.

Вот мой код:

Тест DMA.молния

(12.78 киб) скачано 18 раз

Я вижу «dma_mem_2_mem | dma_circ_mode» в коде. Согласно RM0008 13.3.3, «Режим памяти к памяти не может использоваться одновременно с круговым режимом»

[Даниэфф - Пн 26 июня 2017 г., 17:21] - Я вижу «dma_mem_2_mem | dma_circ_mode» в коде. Согласно RM0008 13.3.3, «Режим памяти к памяти не может использоваться одновременно с круговым режимом»

Ну, это, казалось, сработало как минимум ^^ '
Но это довольно бессмысленно, я думаю, и, как наблюдается, полностью голодает DMA для других периферийных устройств.