Когда я пытался получить больше скорости чтения/письма для библиотеки Arpuss "USB Mass Storage" (Rogers Core) Я нашел здесь действительно интересную информацию:
https: // microtechnics.ru/en/stm32-i-usb ... e-sd-card/
Это может быть из -за интереса построить USB -массовое хранилище (SD -карта) для любого ядра HAL. (Теперь хорошие новости заканчиваются).
О суб -оптимальной скорости чтения/записи (для меня на синей таблетках около 300-500 КБ/с - 32 ГБ SDHC с SDFATEX (SPI) - но библиотека SDFAT не является проблемой!) Я нашел эту ветку где -то в середине комментариев стороны выше:
Спасибо за ваши усилия, я сделал проект, и он работает очень хорошо.
Проблема теперь в скорости, как я могу увеличить скорость чтения/записи, и я раните, почему скорость очень низкая ее’S obhere 200 kb/s запишите и прочитайте 600 кб/с ?
Спасибо

Авеал
27.04.2017 в 19:09 сказал:
Это’S Общая проблема, которую класс массового хранения в STM32 имеет медленную скорость ... Лучшая скорость, которую я видел, я получил с памятью NAND и 16 -битный FSMC, и это было около 500 кб/с для написания.

Ахмед
27.04.2017 в 20:12 сказал:
Я ранен, если я использую высокоскоростное ядро, скорость будет значительно увеличить, иначе это будет немного по-другому ?

John_r
28.04.2017 в 13:50 сказал:
У меня такая же проблема, я пытаюсь перенести файл 1 ГБ и получил 350 кб/с во время
Напишите и 500 кб/с во время чтения. Но я думаю, что DMA будет увеличить эту скорость.

Ахмед
28.04.2017 в 14:05 сказал:
Проблема в том, что DMA - это память -> Периферийные устройства, так как я могу настроить его на работу с USB и SDIO ?

Авеал
28.04.2017 в 21:35 сказал:
Вы можете использовать DMA только для SD -карты. Но я’Я не уверен, что скорость увеличится .. Так что, похоже, на самом деле нет диапазона вверх для увеличения скорости чтения/письма. (По крайней мере для F1)

Ну, я все еще в работе, чтобы попробовать это. Я еще не работал

Просто думая заранее с точки зрения скоростей, все еще есть проблема с USB -поворотом, я.эн.:
хост (отправить команду SCSI) -> USB -> STM32 (BP/MM) (команда SD)-> SPI -> SD -карта
хост (получение данных) (данные, полученные ack) <- USB <- STM32 (BP/MM) (DATA, ACK) <- SPI <- SD -карта (данные, ACK)
между этим последовательным поворотом
хост (получение данных) (полученные ACK) <- USB <-STM32 Поговорите с USB (данные, ACK) <- STM32 Поговорите с SD -картой (Data, ACK) <- SPI <= SD -карта (данные, ACK)
Этот поворот для STM32 впустую некоторое время, я.эн. Этот STM32 не может говорить как с интерфейсом USB, так и с SPI одновременно одновременно.

Я не слишком уверен, что USB или SPI включен DMA, E.глин. Если данные, полученные с SD -карты
но, тем не менее

Во -первых, что Mcu R U использует, как разные, имеют разные возможности.

DMA трансфер R всегда быстрее, чем переводы процессора.

Эти SD -карты могут быть связаны с несколькими различными режимами. SPI является самым медленным, он является 1 -битным сериалом с максимальной скоростью 25 МГц. Существует также режим SDIO 1_LINE, который также является 1 -битным последовательным, но со скоростью 50 МГц и использует на 1 меньше линии, которая не использует линию CS, а также SDIO 4_LINE, который имеет ширину 4 бита, а также при 50 МГц. скорость.

Я не уверен в том, какие библиотеки SD доступны для Arduino, так как я использовал только SD с настройкой куба MX с FATFS или с микропитоном

Строго говоря, это на самом деле не только DMA, так как DMA все еще остается последовательным процессом вокруг процесса
я.эн. Читайте с SD Card - отправьте на хост через USB
Каждое из этой деятельности занимает некоторое время и не произойдет одновременно, следовательно, время «потрачено впустую», так как время тратит на один конец E.глин. Чтение из карты не может быть использовано одновременно для обработки USB

Из любопытства я посмотрел на некоторые документы о хранении USB-массы, я наткнулся на эту статью от Microsoft
https: // блоги.MSDN.Microsoft.com/usbcor ... ompliance/
Следовательно, хранение USB-массы в основном SCSI над USB

Есть эта вещь, называемая Queuing Команды SCSI TAGIN
https: // en.Википедия.org/wiki/tagged_command_queuing
https: // docs.Microsoft.com/en-us/window ... электронные запросы

Я не слишком уверен, является ли это частью поддерживаемой настройки в драйверах хранения Windows / Linux и Mac USB-массы
Но что если что -то такое доступно, необходимо было бы сделать DMA через SPI до SD -карты, и даже, возможно, нам нужно будет использовать «двойные буферы»
эн.глин. Мы говорим DMA, чтобы заполнить буфер A от SPI, пока мы отправляем буфер B (который имеет данные из предыдущего чтения) на хост над USB

Все это программирование может быть сложным и сложным, но если все это возможно, мы могли бы в значительной степени приблизиться к 1 Мбит / с с USB -хранилищем
Нам, возможно, даже не понадобится «Tagged» команды, если мы обнаружим, что после всего хоста (я.эн. Windows, Linux, Mac) SAID отправляет несколько последовательных команд чтения, поэтому мы выпускаем одни и те же команды SD на SD -карту и позволили DMA заполнить буфер SPI. Если это возможно, это было бы почти так же, как и выше, что мы сможем использовать полную полосу пропускания 10 Мбит / с USB USB. И если бы я помнил правильно, каждый кадр USB Bulk Transfers составляет 64 байта, так что обработка USB также была бы довольно занята.

Таким образом, эта схема является трубопроводом

[Flyboy74 - Чт 13 сентября 2018 г. 3:26 утра] - DMA трансфер R всегда быстрее, чем переводы ЦП.

Это довольно плохое обобщение. Если у вас нет высокой нагрузки прерываний, трансферы процессора быстрее DMA. Единственное преимущество DMA заключается в том, что процессора/периферийные устройства могут сделать что -то еще, пока происходит передача DMA - но приложение должно быть специально написано для этого.

[Хейсан - Чт 13 сентября 2018 г., 7:28 утра] -

[Flyboy74 - Чт 13 сентября 2018 г. 3:26 утра] - DMA трансфер R всегда быстрее, чем переводы ЦП.

Это довольно плохое обобщение. Если у вас нет высокой нагрузки прерываний, трансферы процессора быстрее DMA. Единственное преимущество DMA заключается в том, что процессора/периферийные устройства могут сделать что -то еще, пока происходит передача DMA - но приложение должно быть специально написано для этого.

Я - нуб и изучаю новые вещи каждый день, но я понимаю, что DMA был быстрее, чем процессор для переводов https: // elcedds.com/Использование памятной памяти ... -Проекты/

Использование новой версии SDFAT DMA включена по умолчанию с помощью SDFATEX . Я не могу вспомнить свои результаты. Вот почему я сказал, что это не проблема (SD <> MCU)
AG123 попал в точку: хост (отправить команду SCSI) -> USB -> STM32 (BP/MM) (команда SD)-> SPI -> SD -карта
хост (получение данных) (данные, полученные ack) <- USB <- STM32 (BP/MM) (DATA, ACK) <- SPI <- SD -карта (данные, ACK)
между этим последовательным поворотом
хост (получение данных) (полученные ACK) <- USB <-STM32 Поговорите с USB (данные, ACK) <- STM32 Поговорите с SD -картой (Data, ACK) <- SPI <= SD -карта (данные, ACK)
Этот поворот для STM32 впустую некоторое время, я.эн. Этот STM32 не может говорить как с интерфейсом USB, так и с SPI одновременно одновременно. Кроме того, мы должны уважать наши аппаратные ограничения - например, синяя таблетка: 20 КБ ОЗУ, 72 МГц и предел 10 Мбит / с. Я не исследовал, если у F107 или F4XX будет лучшая производительность
Пример F107: USB 2.0 Полно скоростное устройство/хост/OTG-контроллер с On-Chip Phy, который поддерживает HNP/SRP/ID с 1.25 кбайт выделенного SRAM VS F103: USB 2.0 Полноскоростной интерфейс Но я предполагаю, что единственная разница-это функция OTG, и в качестве раба нет пользы с «внедорожником»

РЕДАКТИРОВАТЬ: Я немного сыграл с буферами (есть много ): Даже они находятся на своем пределе (SCSI...) или их повышение не приведет к лучшей производительности.

Но мы нывываем на высоком уровне: 300-400 кб/с/с не так уж плохо для такого маленького MCU. Если есть необходимость перенести XX ГБ за короткое время, лучше вытащить SD -карту и использовать USB 3.0 Адаптер для ПК.

Вы должны жить с этой производительностью, если вы не реализуете двойную буферизацию, по крайней мере, к одному из процессов (SDFAT или USB COMM) и не делаете его асинхронным, чтобы позволить (E.g) Читать с SD -карты в один буфер, пока USB отправляет предыдущий буфер.

[Flyboy74 - Чт 13 сентября 2018 г. 8:06 утра] -

[Хейсан - Чт 13 сентября 2018 г., 7:28 утра] -

[Flyboy74 - Чт 13 сентября 2018 г. 3:26 утра] - DMA трансфер R всегда быстрее, чем переводы ЦП.

Это довольно плохое обобщение. Если у вас нет высокой нагрузки прерываний, трансферы процессора быстрее DMA. Единственное преимущество DMA заключается в том, что процессора/периферийные устройства могут сделать что -то еще, пока происходит передача DMA - но приложение должно быть специально написано для этого.

Я - нуб и изучаю новые вещи каждый день, но я понимаю, что DMA был быстрее, чем процессор для переводов https: // elcedds.com/Использование памятной памяти ... -Проекты/

Память к памяти DMA действительно быстрее, но с SPI/SDIO/USB/и т. Д. ЦП достаточно быстрый, чтобы сохранить аппаратные буферы, так что вы можете достичь полной скорости аппаратного обеспечения без накладки настройки DMA.

[Хейсан - Четверг 13 сентября 2018 г., 11:31 утра] - Память к памяти DMA действительно быстрее, но с SPI/SDIO/USB/ETC ЦП достаточно быстрый, чтобы сохранить аппаратные буферы, поэтому Вы можете достичь полной скорости аппаратного обеспечения без накладных расходов на настройку DMA.

Это зависит от количества байтов для доступа и на SW. Мой опыт в SPI показывает, что для более чем ~ 200 байт накладные расходы DMA окупаются (@36/42 МГц).
CPU может (будет) прерван IRQS, так что в долгосрочной перспективе вы не можете приблизиться к производительности DMA при использовании высоких тактовых частот.

[Стивестронг - Четверг 13 сентября 2018 г. 11:40 утра] -

[Хейсан - Четверг 13 сентября 2018 г., 11:31 утра] - Память к памяти DMA действительно быстрее, но с SPI/SDIO/USB/ETC ЦП достаточно быстрый, чтобы сохранить аппаратные буферы, поэтому Вы можете достичь полной скорости аппаратного обеспечения без накладных расходов на настройку DMA.

Это зависит от количества байтов для доступа и на SW. Мой опыт в SPI показывает, что для более чем ~ 200 байт накладные расходы DMA окупаются (@36/42 МГц).
CPU может (будет) прерван IRQS, так что в долгосрочной перспективе вы не можете приблизиться к производительности DMA при использовании высоких тактовых частот.

ОК - у меня есть только Systick IRQ. Трансферы процессора были быстрее для полных обновлений (~ 150 КБ), чем DMA, работая SPI на 36 МГц (SysClock/2). Разница невелика, хотя ~ 10 мс для 1000 кадров.

@Heisan, какое ядро ​​вы используете? Можете ли вы показать мне простой пример, где передача DMA медленнее, чем не-DMA?

Мой опыт уменьшается для передачи данных из памяти в ILI9341 и передавать данные с/на SD-карт через SPI с использованием Libmaple Core, в котором я могу самостоятельно оптимизировать как DMA, так и не DMA SPI. Порог ~ 200 байтов, где DMA быстрее является эмпирически определенным значением, действительным для тактовой частоты SPI при 36 МГц (F1)/42 МГц (F4).

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

[Стивестронг - Чт 13 сентября 2018 г. 13:16] - @Heisan, какое ядро ​​вы используете? Можете ли вы показать мне простой пример, где передача DMA медленнее, чем не-DMA?

Стандартная синяя таблетка с ядром Роджера и включена библиотека ADAFRIT_ILI9341_STM. Только дисплей и Stlink подключились. Я впервые заметил это, когда вычисленные пиксели (Direct SPI без DMA) рендеринг быстрее, чем FillRect (). Прокомментировал путь DMA в FillRect (), и скорость были одинаковыми.

[Хейсан - Чт 13 сентября 2018 г., 13:47] - и скорости были такими же

Ах, это может произойти, потому что LIB использует SPI в 16 -битном режиме, и, как я уже сказал, я оптимизировал процедуры передачи SPI, в значительной степени я мог.
В 16 -битном режиме процессору удается предоставить следующие данные для записи, когда интерфейс завершает текущую передачу (DR Register Emply) в течение 16 часов SPI. Накладные расходы DMA могут учитываться в этом случае, добавляя дополнительное время по сравнению с версией без DMA.

ЦП не будет постоянно управлять тем же в 8 часов (режим 8bt при 36 МГц), где накладные расходы DMA быстро потребляются (время передачи ~ 200 байт). Это видно в случае доступа к SD -карте, просто попробуйте запустить SD Benchmark Sketch с DMA и без него.
Вы увидите разницу, хотя она использует те же функции SPI, что и ILI9341 LIB, только в 8 -битном режиме на этот раз на этот раз.

[Стивестронг - Чт 13 сентября 2018 г. 9:13 утра] - Вы должны жить с этой производительностью, если вы не реализуете двойную буферизацию, по крайней мере, к одному из процессов (SDFAT или USB COMM) и не делаете его асинхронным, чтобы позволить (E.g) Читать с SD -карты в один буфер, пока USB отправляет предыдущий буфер.

Я думаю, что Стив прав в этом, я бы сначала попытался заставить свою настройку работать, и я бы это изучил, но мне еще предстоит узнать больше о USB или DMA на SFM32F103, если оборудование может позаботиться об этих буферах

Речь идет о SW, которое должно позаботиться об этом, а не HW. DMA помогает считывать данные быстрее, но узкое место находится при сериализации передачи данных между доступом SD -карты и передачей USB.
Можно адаптировать SDFAT LIB для проведения асинхронных переводов (E.глин. Запустите процесс записи и немедленно верните, пусть DMA работает, не ожидая конца), но это возможно, только если другое устройство не подключено (или активируется), что порт SPI.

HM, на самом деле это должно работать на сегодняшний день, если кто -то заменит функцию dmasend () на dmasendasync (). Spi lib позаботится о том, что на автобусе SPI не будет инициировано никакая другая передача, поскольку предыдущий все еще будет работать.

[Стивестронг - Чт 13 сентября 2018 г., 14:14] -

[Хейсан - Чт 13 сентября 2018 г., 13:47] - и скорости были такими же

Ах, это может произойти, потому что LIB использует SPI в 16 -битном режиме, и, как я уже сказал, я оптимизировал процедуры передачи SPI, в значительной степени я мог.
В 16 -битном режиме процессору удается предоставить следующие данные для записи, когда интерфейс завершает текущую передачу (DR Register Emply) в течение 16 часов SPI. Накладные расходы DMA могут учитываться в этом случае, добавляя дополнительное время по сравнению с версией без DMA.

ЦП не будет постоянно управлять тем же в 8 часов (режим 8bt при 36 МГц), где накладные расходы DMA быстро потребляются (время передачи ~ 200 байт). Это видно в случае доступа к SD -карте, просто попробуйте запустить SD Benchmark Sketch с DMA и без него.
Вы увидите разницу, хотя она использует те же функции SPI, что и ILI9341 LIB, только в 8 -битном режиме на этот раз на этот раз.

Я должен сделать еще несколько тестирования... Но, глядя на это логически, 8 бит не должен быть проблемой. SPI работает не более 1/2 часа процессора, поэтому для 8 бит у вас есть 16 часов процессора. Цикл должен быть четырьмя инструкциями:
1) LD (Post Index)
2) str (немедленная)
3) Сравните
4) филиал

Даже при худшем случае ожидания ожидания и промахи предварительного переключения, это должно соответствовать 16 часами?

[Стивестронг - Чт 13 сентября 2018 г. 14:31] - Можно адаптировать SDFAT LIB для проведения асинхронных переводов (E.глин. Запустите процесс записи и немедленно верните, пусть DMA работает, не ожидая конца), но это возможно, только если другое устройство не подключено (или активируется), что порт SPI.

Я комментировал это в предыдущей ветке... В идеальном мире библиотека SPI будет проверять/ждать завершения предыдущей операции при входе в следующую... Таким образом, все приложения смогут эффективно использовать/обмениваться шиной SPI. Но, как вы указали, это может нарушить некоторые приложения (если они ожидают, что устройство SPI начнет что -то делать непосредственно до возвращения вызова). Очень жаль, что так много оригинальных API ARDUINO так сильно обдумывались.

@heisan, если вы действительно хотите копать глубоко, пожалуйста, посмотрите на текущую реализацию функций SPI.
Нет, 16 часов процессора не достаточно (всегда) достаточно. Есть 2 состояния ожидания для вспышки. И вам также нужны инструкции по обеспечению и отключению глобального прерывания.
Я сомневаюсь, что вы можете сделать его более эффективным (в C), если вы не кодируете его в ASM, что я бы определенно приветствовал, все сообщество может извлечь выгоду из этого.

Завтра уезжаю в отпуск и попробую играть еще немного, когда вернусь. Cortex M3 имеет примитивный механизм предварительного вычинения, поэтому вы должны заплатить только 2 штрафа на ожидание максимум дважды за цикл... Сможет сказать только в тестировании, хотя.

@Хейсан
Я думаю, что Стива на самом деле не о SPI (в одиночестве), я сделал немного Google и наткнулся на эту статью
https: // www.микрон.com/~/media/документ ... ueuing.PDF
Реализация двойной буферизации была бы очень похожа на реализацию схемы трубопровода, аналогичной странице 8 Рисунок 9
где вместо #define D2 PA6 #define D3 PA7 void setup() { pinMode(D2, OUTPUT); pinMode(D3, OUTPUT); digitalWrite(D2, LOW); digitalWrite(D3, LOW); } void loop() { digitalWrite(D2, LOW); digitalWrite(D3, HIGH); delay(1000); digitalWrite(D2, HIGH); digitalWrite(D3, LOW); delay(1000); digitalWrite(D2, LOW); digitalWrite(D3, LOW); delay(2000); digitalWrite(D2, HIGH); digitalWrite(D3, HIGH); delay(1000); }

Кстати, разве нет много * медленных * дешевых считывателей SD -карт? не говоря уже о STM32

[AG123 - Чт 13 сентября 2018 г., 16:31] - Кстати, разве нет много * медленных * дешевых считывателей SD -карт? не говоря уже о STM32

...Просто подождите минуту, я открою свой читатель CHEPO SD-карты (но быстро бежит)

Редактировать:
ОК, только один чип:
CP8121N
1729-h
Quick Google (как и ожидалось): только несколько китайских результатов даже не один таблица данных.
Честно говоря: я не собираюсь перестроить читателя SD-карты Но STM32FXXX может быть очень потенциальным устройством Audio/WAV/MP3/OGG/FLAC (воспроизведение и запись), поэтому приличная SD-карта<>Скорость USB была бы хорошей вещью (но даже 1 МБ было бы довольно медленным).

хм. Пост раньше был просто шуткой, но, возможно, это возможно (меньше усилий) «угон» такого чипа. Таким образом, через USB у вас есть приличный считыватель SD -карты, и внутренне он используется в качестве модуля SD STM32 SD. (Диаграмма PIN -кондиционера этого чипа CPXXX была бы неплохо).
РЕДАКТИРОВАТЬ: ЗДЕСЬ! Только 0.35 евро для одного чипа (с некоторыми аддонами для удаления):
https: // www.aliexpress.com/item/high-qu ... 10436.HTML

Да, тоже не смог найти номер детали
Я думаю, что в эти дни есть много ASIC, которые являются USB2.0 высокоскоростных устройств
Некоторые из примеров, которые не оказались такими устройствами ST
Cypress Cy7c68013a-56ltxc
https: // sigrok.org/wiki/armfly_mini-logic
оказалось популярным в использовании в качестве анализаторов Sigrok Logic

Эти доски довольно дешевые
https: // www.aliexpress.com/оптом?калифорнийский ... CY7C68013A
Я не слишком уверен, можно ли запрограммировать некоторые из них как читатели SDCARD

Что касается STM32 USB2.0 высокоскоростного устройства, я не мог найти что -то «дешевое»
Близкий - использовать Ulpi USB 2.0 высокая скорость Phy, как USB3300
https: // www.aliexpress.com/оптом?калифорнийский ... XT = USB3300
Но эти цены совсем не «дешевые» (модуль, который стоит около 7 долларов США на ebay/aliexpress)

В конце концов, некоторые из читателей SD -карт могут быть Asics, которые предназначены для этой SD -карты для интерфейса USB (USB 2.0 Высокая скорость) и прошивка предварительно запрограммирована.

Но есть также некоторые считыватели SD -карты, которые подтягиваются только USB -устройствами с полной скоростью 10 Мбит/с, я думаю, что для этих производительности может быть сопоставима с «неоптимизированным» STM32 BP/MM SDADER SDARDER. Разница на этот раз в том, что мы могли бы оптимизировать его, если бы мы действительно хотим
Но это оставляет нас с USB 2.0 Полная скорость в качестве предела (10 Мбит / с)

Мне только что удалось получить USB Mass Storage и SD Reader успешно компилировать.
Поскольку я работаю в Eclipse, а не Arduino IDE, интеграция их будет возникнуть в проблемах, так как все это включает, определяет, каждый из них должен быть настроен вручную в IDE Eclipse. Преимущества этого - это поддержка CDT (завершение кода, синтаксисные моменты, прыжки на ссылки) и различные инструменты. Я также использую плагины GNU Arm Eclipse IDE https: // gnu-mcu-eclipse.GitHub.io/

Я на самом деле не собрал «оборудование», но следовательно, это просто успешная компиляция.
Я посмотрел на некоторые из композитных кодов USB и понял, насколько это обширно, я бы хотел поблагодарить Apruss, Libarra, Greiman, ET.ал.
ViewTopic.PHP?f = 13&t = 2926
ViewTopic.PHP?f = 13&t = 576
за то, чтобы собрать все это вместе

Несколько прискорбно, что STM32F103 не связывайте USB2.0 высокоскоростная связь и то, что более высокая серия, которая поддерживает его E.глин. STM32F40X требует ULPI USB 2.0 высокая скорость Phy подключена, чтобы получить USB2.0 высокоскоростное соединение

Изменить: нашел интересную сеть, объясняющую простой способ различий между USB 2.0 Полная скорость против USB 2.0 высокая скорость 480 Мбит / с
https: // www.Ренезас.com/us/en/solutions ... SB2-0.HTML
Согласно Википедии, эффективная пропускная способность ниже при 280 Мбит/с или 35 МБ/с
https: // en.Википедия.org/wiki/usb#usb_2.0

Я предполагаю, что STM32F103 BP/MM могут иметь проблемы, справляющиеся с этими скоростями, даже с ULPI, и STM32F405/407, скорее всего, соответствуют счету
Просто для использования F4 все еще требуется внешний Ulpi USB 2.0 Высокоскоростной приемопередатчик, я думаю, что отчасти являются электрические различия 400 мВ (высокая скорость) против 3.3V (полная скорость) и скорость сигнализации