STM32F746 Discovery Board. How to get the maximum write speed for USB Host MSC. I have managed to get 7.5 MBytes/s. It is possible to get 10MBytes/sec

[AWood.1]

Using the Cube generated code for FATFS and USBH-MSC I can connect to an external 500G SSD drive using USB 2.0 HS.

With the USB drive I can get 38MBytes/sec from my PC.

With the Discovery board I have only been able to get up to 7.5MBytes/sec.

Disk is formatted FAT32.

The FIFO buffers in the USB_OTG had to be adjusted for more TXFIFO space to get that speed.

investigating the data path I can see that the hardware has it's own DMA that looks to be able to handle 65536 words at a time.

However the usbh_msc_bot.c file seems to only pass on one sector ( 512 bytes ) at a time to the DMA controller. I have tried modifying the code in this area but have not been able to keep the system working. Is it worth trying to get the write code to use the full size of the DMA or is there a technical reason ( USB spec or chip design ) that makes this not worthwhile?

[TDK]

It's definitely possible to get 80 Mbps out of USB HS, but you may need to write your own drivers. The HAL drivers are written for user flexibility and not really for performance. FATFS adds a bit of overhead but if you're only writing to a single file or several large files it shouldn't be much.

I can get 170 Mbps in certain scenarios with the F4. I would expect the F7 to be at least as capable.

[AWood.1]

I have managed to peak at 18MBytes/second by by-passing the os and calling the BOT_DATA_OUT_WAIT code from the USBH_LL_NotifyURBChange in the interrupt reoutine.

I can see room to make it go faster, but would require a lot more time and care.

Thanks for your help

[Tesla DeLorean]

Isn't there an MSC_MEDIA_PACKET define controlling the max transfer size?

To an SDRAM-DISK ? Where are you sinking the data?

[Piranha]

> The HAL drivers are written for user flexibility

Where exactly is the HAL's flexibility? IMHO HAL is not stable, not fast, not compact and also not flexible.

1. Structures and many functions differ for different series.
2. Normal continuous and asynchronous USART reception is not possible. It just isn't there at all.
3. Callbacks for a single peripheral are scattered to a bunch of separate functions making implementation of processing them a nightmare.
4. Even for simple GPIO you always have to use port+pin pair with two separate defines. A flexible design would merge those into one define/integer.
5. GPIOs are configured by modifying a structure members and calling a configuration function for almost every pin. A sane design can use a pin configuration array(s) and configure any amount of pins with a single call.

All of this and other bad design decisions makes compiling a single HAL based code for multiple MCUs, boards and/or projects a nightmare.

[TDK]

> Where exactly is HAL’s flexibility?
Are you actually interested in an answer? It feels like your mind is already pretty made up regarding HAL and ST in general.
Do you have experience with other MCUs whose software architecture you prefer more? And if so which ones?

[Piranha]

My mind is based on objective arguments. =) I've worked with some PICs and LPC2xxx, but that is irrelevant. I don't care if and how many other bad examples there are. I compare things to a better examples and ideas. I implemented my lwIP based networking platform first on CMSIS-Driver, then SPL, then HAL and then replaced it with my own developed driver library. Now I'm actually building it for multiple MCUs, boards and projects in different combinations. With HAL it would be a ton of workarounds and redundant code because of the points I mentioned.