STM32H743 mass storage

[korotaev 0]

8 minutes ago, mantech said:

Я на стмовском "недо"усб что-то делал лет 6 назад, на сколь знаю, они родили пару моделек с встроенной физикой HS, но с такими работать не удалось, а все остальное с FS в 21м веке считаю позором этой конторы...

STM32H743 без встроенного HS, я подключаю внешний HS PHY по ULPI. Претензий к USB нет. Я получаю пропускную способность USB примерно 26 МБайт/сек. 

Вся загвоздка в работе с SD картой. DMA механизм использует так называемый internal DMA, который в работе с SD использует только память AIX SRAM (только её!!!), на которую надо натравить USB device. 

[jcxz 5]

1 час назад, korotaev сказал:

Вся загвоздка в работе с SD картой. DMA механизм использует так называемый internal DMA, который в работе с SD использует только память AIX SRAM (только её!!!), на которую надо натравить USB device. 

Если проблема с SD, то этот участок и надо отлаживать. Отделив его от всяких USB, FatFS и пр. Сперва добиться нужной скорости low-level-обмена с SD-картой на уровне чтения/записи секторов карты. И только потом этот нижний уровень скрещивать с остальным кодом.

[Andreas1 0]

3 часа назад, korotaev сказал:

Andreas1, можно задать Вам несколько вопросов на личную почту? 

Пишите сюда в личку, но я не пользуюсь HAL и кубом, врядли смогу помочь. Выше уже посоветовали по очереди отлаживаться и искать в чем затык. Я тоже сначала тестировал чтение на разной величины кусках, потом запись и только потом подключил УСБ. У меня не было никаких проблем именно с SDMMCи ее дма(кроме кеширования), с усб да, были, но к скорости отношения не имели.

1 час назад, korotaev сказал:

Вся загвоздка в работе с SD картой. DMA механизм использует так называемый internal DMA, который в работе с SD использует только память AIX SRAM (только её!!!), на которую надо натравить USB device. 

Я использую только AXI SRAM. Если бы в используемой мной оси была возможность выделения статической памяти, я бы просто отвел в линкере кусок и в MPU обозначил его как некешируемый, но и без этого скорость только  чтения на 100М около вышла около 35мбайт/с. При этом на каждый блок примерно 100..200мкс между командой чтения и началом передачи картой(вне зависимости от размера блока ессно) и всего 10мкс на сброс 16к кеша.

 

 

[AlexandrY 0]

3 hours ago, mantech said:

Чтение блоками по 16кбайт - 22-25Мбайт\сек (процессор IMX6S EHCI контроллер)

А че так слабо-то? 
Обычный STM32H747I на базе дешевого STM32H747I-DISCO с 400 МГц
без всяких специальных оптимизаций, прям из коропки, в демке Azure RTOS 
читает 300 Мбайт файл на скорости 21 Мбайт в сек. Пишет 8 Мбайт в сек.
Надо только опцию поставить - USE_SD_HIGH_PERFORMANCE.

На компьютере та же карта имеет соответственно 86 и 20 Мбайт в сек.

[mantech 1]

1 час назад, AlexandrY сказал:

На компьютере та же карта имеет соответственно 86 и 20 Мбайт в сек.

Чего?? Еще раз подумайте, что пишете, а если сравниваете с усб 3.0, так для справки в IMX6S его нет, и у стм подавно...

1 час назад, AlexandrY сказал:

читает 300 Мбайт файл на скорости 21 Мбайт в сек. Пишет 8 Мбайт в сек.

И чем тут мои 22-25 маловато? Или считаете, что скорость усб зависит от частоты проца? 

И вообще цитата была про работу УСБ контроллера.

Для СД карты, скорость >10мбайт в сек возможна только в uhs-1 режиме на 1.8 В, МК тоже должен "уметь" работать в данном режиме.

Edited March 24, 2021 by mantech

[Andreas1 0]

50 минут назад, mantech сказал:

Для СД карты, скорость >10мбайт в сек возможна только в uhs-1 режиме на 1.8 В, МК тоже должен "уметь" работать в данном режиме.

Почему? В режиме High Speed возможен клок 50М и предел 25мбайт/с. После подачи команды чтения идет небольшая задержка, поэтому реальная скорость будет ниже, но на больших блоках будет приближаться к этому пределу.

[mantech 1]

26 минут назад, Andreas1 сказал:

клок 50М и предел 25мбайт/с.

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

[Andreas1 0]

38 минут назад, mantech сказал:

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

Какая еще служебная инфа? Подали команду чтения, карта через 100..200мкс начала передавать непрерывный поток данных, ФСЕ! Если блок велик или идет двойная буферизация(что предусмотрено в DMA), то и скорость будет приближена к теретической. Практически без двойного буфера на блоках 64к выходила скорость чтения  около 18 мбайт/с без передачи в комп и 12..14 с массториджоми УСБ.

[mantech 1]

28 минут назад, Andreas1 сказал:

Какая еще служебная инфа? Подали команду чтения, карта через 100..200мкс начала передавать непрерывный поток данных, ФСЕ!

Время на передачу команды чтения, затем ждете иногда более 200 мкс, затем в след блоке та же задержка и т.п. вот и набегает. Вы в рамках ФС работаете, а значит читать одним блоком по мегабайту не получится, ФС предполагает работать в рамках кластера (4-32кбайт). Попробуйте сделать тест на чтение в течении секунды и увидите, что там далеко не 25 мб\сек...

 

Edited March 24, 2021 by mantech

[Andreas1 0]

12 минут назад, mantech сказал:

Время на передачу команды чтения, затем ждете иногда более 200 мкс, затем в след блоке та же задержка и т.п. вот и набегает. Вы в рамках ФС работаете, а значит читать одним блоком по мегабайту не получится, ФС предполагает работать в рамках кластера (4-32кбайт). Попробуйте сделать тест на чтение в течении секунды и увидите, что там далеко не 25 мб\сек...

Заполнение буфера 64к это это около 2.5мс.  200мкс задержки чтения, плюс 10мкс сброса кеша это всего около 10% от времени заполнения буфера, время передачи 48битов команды пренебрежимо мало. Т.е в идеале можно и ПРАКТИЧЕСКИ получить более  20мб/с чтения, но я работаю в рамках ОС, поэтому есть накладные расходы времени,  которые снижают производительность до именно реальных 18мб/с и ессно тест я делаю в течении десятков - сотен секунд.

Речи о ФС не было, не надо менять условия на ходу.  Тем более, что при работе с компом работа с ФС на стороне компа и при чтении непрерывных больших файлов в фат32 размер запрашиваемых данных равен максимально возможному.

[jcxz 5]

47 минут назад, mantech сказал:

Время на передачу команды чтения, затем ждете иногда более 200 мкс, затем в след блоке та же задержка и т.п. вот и набегает. Вы в рамках ФС работаете, а значит читать одним блоком по мегабайту не получится, ФС предполагает работать в рамках кластера (4-32кбайт).

Ну это если совсем не думать. А если немного подумать, то окажется, что прослойка между вызовом ФС "прочитать кластер" и интерфейсом карты - это не обязательно простая операция чтения по шине. В этом месте может находиться кеш с упреждающим чтением. Запросила ФС чтение кластера -> low-level драйвер сперва проверяет наличие этого кластера в кеше, а если его нет - запускает чтение кластера, но не ограничиваясь размером кластера, а читая ещё N последующих кластеров в кеш в одной транзакции.

При наличии достаточно большого объёма ОЗУ под кеш и учитывая, что с большой вероятностью следующим потребуется читать следующий по порядку кластер, а не какой-то другой - так и достигается высокая скорость обмена. К тому же обмен с картой будет идти параллельно с обработкой внутри ФС - это тоже даст общее ускорение работы.

 

[mantech 1]

4 часа назад, Andreas1 сказал:

Речи о ФС не было, не надо менять условия на ходу. 

И зачем тогда это тупое чтение в RAW куда-то, часто такой режим используете?

4 часа назад, Andreas1 сказал:

которые снижают производительность до именно реальных 18мб/с и ессно тест я делаю в течении десятков - сотен секунд.

Т.е. у вас в реальном тесте с ФС на клоке 50МГц показатель 18МБ\сек? Если так, то поздравляю!

4 часа назад, jcxz сказал:

А если немного подумать, то окажется, что прослойка между вызовом ФС "прочитать кластер" и интерфейсом карты - это не обязательно простая операция чтения по шине.

 

4 часа назад, jcxz сказал:

К тому же обмен с картой будет идти параллельно с обработкой внутри ФС - это тоже даст общее ускорение работы.

И какое ускорение получили? Не в теории, а по факту?

ЗЫ. Не знаю, как в вашем случае, а в моем больше времени занимает чтение мелких файлов (5-100Кбайт), а мегабайт и более довольно редко, так что ваш алгоритм тут будет чаще промахиваться и часто читать лишнее...

Edited March 24, 2021 by mantech

[jcxz 5]

16 минут назад, mantech сказал:

ЗЫ. Не знаю, как в вашем случае, а в моем больше времени занимает чтение мелких файлов (5-100Кбайт), а мегабайт и более довольно редко, так что ваш алгоритм тут будет чаще промахиваться и часто читать лишнее..

Ну, во-первых: чтение мелких файлов (если их нужно читать кучей) - это также очень часто чтение рядом расположенных на диске файлов.

Во-вторых: те скорости копирования под виндой, о которых вещает Ажуре-гуру, они тоже достигаются как правило при чтении больших файлов.

[Сергей Борщ 0]

9 часов назад, mantech сказал:

И зачем тогда это тупое чтение в RAW куда-то, часто такой режим используете?

USB Mass storage только этот режим и использует.

[mantech 1]

10 часов назад, jcxz сказал:

Ну, во-первых: чтение мелких файлов (если их нужно читать кучей) - это также очень часто чтение рядом расположенных на диске файлов.

Это в случае кэширования с большим объемом ОЗУ, будет заметен прирост скорости, причем тут даже не в чтении с СД дело, а в том, что закэшируются списки ФАТ и с диска будут вычитываться только данные. Если просто сделать акцент на чтении больших блоков, но не кэшировать таблицы ФАТ, то толку будет мало. Резюмируя все это, ИМХО получить большие скорости чтения и записи можно только в случае, если будет совместно использоваться кеш и чтение больших блоков, в скорости выиграем, но потеряем в безопасности при откл. питания в частности. Мне лично такие задачи не ставили (макс. ускорение работы с диском) поэтому я использую методы "по-старинке", кому надо макс. ускорение - нужно будет заботится и о недостатках...

1 час назад, Сергей Борщ сказал:

USB Mass storage только этот режим и использует.

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