Which USB mode for high speed transfer?

[carl2399]

Posted on November 29, 2014 at 04:36

Hi, I've been working with the STM32 for several years, but never done any USB related stuff. Just recently I've got working an example of USB-HS using the mass storage class.

In my application I have a 16Gbyte SD card, that has data in a propriety format. I want the ability to be able to download various ''views'' of the data. In essence the views are equivalent to queries on the data, although not quite simple enough to format into a virtual filesystem. A typical ''view'' of the data may be a 200Mbyte summary that's extracted from the 16Gbytes of data. (Assume that the indexing on the SD card means that this is not the speed limited interface).Due to the amount of data, I would like a transfer speed that is as fast as possible. So I think that I need to use bulk transfer end points (similar to the mass storage class), but do I do the actual transfer like a communications device class? Can I even do this? From the host PC end I would then have a serial port with an effective baud rate of 100Mbaud or even faster. But is this possible? Or, should I be looking at one of the other device classes?Any advice on this would be appreciated, as I'm still feeling a little lost when looking at all the USB options and documents.

[tsuneo]

Posted on November 29, 2014 at 19:17

> host PC

Do you mean Windows PC? Then, the feasible USB classes are, 1) WinUSB Device 2) MTP device 3) CDC device 4) Mass-Storage Class (MSC) ''WinUSB Device'' http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799%28v=vs.85%29.aspx is a device of vendor-specific class, which provides MS OS descriptors for PnP WinUSB installation on Windows. You may apply this feature since WinXP. http://www.microchip.com/forums/m790429.aspx MTP device is installed on Windows without any install package. Also, better than MSC, because its contents are overwritten without unmount/mount process. Unfortunately, there isn't good MTP device example for STM yet. CDC also provides bulk endpoints, but you need an INF file at installation, which requires expensive signing cost of installation package on Win8/8.1 MSC is the worst choice. To refresh its contents, the device requires unmount/mount process, which could take long period. Tsuneo

[Tesla DeLorean]

Posted on November 29, 2014 at 23:55

MSC is the worst choice. To refresh its contents, the device requires unmount/mount process, which could take long period.

One could fake a CDROM ISO9660 format pretty easily, linear runs of blocks over hundreds of megabytes... Or out-of-band SCSI commands.

[tsuneo]

Posted on November 30, 2014 at 08:23

> One could fake a CDROM ISO9660 format pretty easily, linear runs of blocks over hundreds of megabytes...

I believe the OP is looking for query-reply type communication over bulk endpoints. CD-ROM emulation couldn’t help it more than usual (PDT:0) MSC implementation.> fake a CDROM ISO9660 format pretty easily I posted USB CD-ROM emulation on Atmel AT91SAM7X in these threads, http://www.keil.com/forum/58452/usb-msc-class-and-cd-rom-subclass/ http://www.at91.com/discussions/viewtopic.php/f,24/t,19901/p,42763.html#p42763 In my experience, implementation of CD-ROM emulation, which just mounts/reads CD-ROM image on a device, was easy, though it took almost a half day for me to be aware of that MacOSX applies legacy format for READ TOC command ;)  Above posts show this level of implementation. But the complete implementation, which satisfies requirement of MMC spec fully, was troublesome. I finished just around 95% yet after another one week effort.> Or out-of-band SCSI commands. MS distribute SPTI example, ''SCSI Pass-Through Interface Tool'', which directly communicates with SCSI devices, including USB MSC devices, in WDK8.1 samples. https://code.msdn.microsoft.com/windowshardware/Windows-8-Driver-Samples-5e1aa62e SPTI doesn’t accept asynchronous (OVERLAPPED) call. It isn’t good for repeated large data transfers. Tsuneo

[carl2399]

Posted on November 30, 2014 at 10:47

Thanks Clive and Tsuneo for the responses, they've given me even more to think about. 

The WinUSB stuff looks particularly interesting, basically generic (almost driverless) USB pipes as I understand it. Tsuneo is right in that I'm looking for a query / response protocol, where the size of the response is unknown at the time of the request. I know how far I am though the request as a rough percentage, but not in terms of exact number of bytes. It seems like I can probably start the development as a VCP device, then ramp up the speed and finally get rid of the com port number by switching over to WinUSB. I did for a while think that MTP might be an option, but I think it possibly has the same requirement to know the size of the file before the transfer begins - I'm not sure. I may also then have to present all of my ''queries'' as files.Once again, thank you for your time and assistance!