USB Mass Storage Device

[Koen]

With 32 blocks reads, 512 bytes wMaxPacketSize, 0x00 bInterval, dsigma ChibiOS version read speed is now 7MB/s like ST's template.

I do not understand why the read_buffer was doubled and why we switched from one to the other on every block read as the operations are sequential anyway :

Code: Select all

uint8_t buffer[2][512];

while(iterator++) {
  if (synchronous_bulk_read(buffer[iterator % 2])) {
    synchronous_usb_write(buffer[iterator % 2]);
  }
}

In the same vein, I'll try moving from "16 times 1 block write ping-pong" to "multi-block synchronous writes" another day. It seems simpler, easier to maintain and yields good results for ST. Yet obviously there was a good reason to code it this way at the time, what was it please ? I noticed pingpong runs in its own thread but aren't all operations synchronous and sequential ? Thank you.

[DeusExMachina]

Koen, what version of Chibios do you use? I have failed to run Dsigma's version on 16.x.x.

[Koen]

A snapshot of the repository trunk, a week or two old, for F765 support.

[Koen]

Hello,

I've modified a few of the existing codes and retained two for trials, results are in :

Code: Select all

High speed, 50MB sequential read/write, 512 bytes EP, 0x00 interval, -O3, F765 :

- ST       original : 7.130MB/s  (1 buffer  64 blocks synchronous) / 6.081 MB/s (1 buffer  64 blocks synchronous)
- ST       original : 6.711MB/s  (1 buffer  32 blocks synchronous) / 4.194 MB/s (1 buffer  32 blocks synchronous)

- dsigma   modified : 5.872 MB/s (1 buffer  32 blocks synchronous) / 3.894 MB/s (2 buffers 32 blocks read-ahead )
- dsigma   original : 1.048 MB/s (1 buffer  01 block  synchronous) / 2.516 MB/s (2 buffers 16 blocks read-ahead )

- barthess modified : 7.969 MB/s (1 buffer  64 blocks synchronous) / 6.710 MB/s (1 buffer  64 blocks synchronous)
- barthess modified : 7.550 MB/s (1 buffer  32 blocks synchronous) / 4.613 MB/s (1 buffer  32 blocks synchronous)
- barthess modified : 6.291 MB/s (1 buffer  16 blocks synchronous) / 2.516 MB/s (1 buffer  16 blocks synchronous)

- barthess modified : 8.388 MB/s (2 buffers 32 blocks read-ahead ) / 6.082 MB/s (2 buffers 32 blocks read-ahead )
- barthess modified : 7.131 MB/s (2 buffers 16 blocks read-ahead ) / 2,936 MB/s (2 buffers 16 blocks read-ahead )

Then I tried both modified barthess in Full Speed with PLLN/4 to see if read-ahead had more importance for smaller hardware :

Code: Select all

Full speed, 50MB sequential read/write, 64 bytes EP, 0x00 interval, -O3, F765 PLLN/4 :

- barthess modified : 0.838 MB/s (1 buffer  16 blocks synchronous) / 0.838 MB/s (1 buffer  16 blocks synchronous)
- barthess modified : 1.048 MB/s (2 buffers 08 blocks read-ahead ) / 0.838 MB/s (2 buffers 08 blocks read-ahead )

Synchronous is :

Code: Select all

while() {
  synchronous_bulk_read(buffer);
  synchronous_usb_write(buffer);
}

Read-ahead is :

Code: Select all

synchronous_bulk_read(buffer[i]);
while() {
  asynchronous_usb_write(buffer[i]);
  synchronous_bulk_read(buffer[i+1]);
  asynchronous_usb_wait_completion();
  i++;
}

[Koen]

A few fixes later and the discovery of [possible BUG] Bug 458 might not be fixed completely, here is where I stand :

Code: Select all

                                Read        Write
                               
Normal        16   blocks   :   08.17       02.57
Read ahead  2x08   blocks   :   05.87       01.47

Normal        32   blocks   :   11.12       05.24
Read ahead  2x16   blocks   :   08.80       02.98

Normal        64   blocks   :   12.58       09.44
Read ahead  2x32   blocks   :   14.05       06.32

Normal       128   blocks   :   13.21       09.44
Read ahead  2x64   blocks   :   14.68       08.39

Using a normal single larger buffer is consistently faster than a double smaller buffer read-ahead for writes.
Using a normal single larger buffer is faster than a double smaller buffer read-ahead for reads until 64 blocks where read-ahead is marginally faster.
Difference between 64 blocks and 128 blocks is marginal.

[DeusExMachina]

Koen
Could you share your demo project? I would like to check transmission speed with my F4 setup.

[jayalfredprufrock]

Koen
Could you share your demo project? I would like to check transmission speed with my F4 setup.

I too would love to see a demo project. I've been following this thread closely and am excited to see there is progress being made on this front. We are limited to 25Mhz SDIO clock on the F4 so I'm very curious to see how that effects the transfer speeds. I would be absolutely thrilled to get multi-MB read/write speeds.

[Koen]

The speeds in the first post above are with 25MHz SDIO, the second with 50MHz SDIO. I'll send you the modified files by the end of the week, there's a bit left to be tested/verified.

[Giovanni]

Just a question from me.

Would the "buffers queue" mechanism be useful in the MSD driver? it has been added recently to the HAL, it was not available when the code was being initially created.

Giovanni

[Koen]

I'll look into it.

I wonder about USB HS DMA too. I tried it with ST library and found two bugs before it started to enumerate. ST does not recommend it because of the alignment issues ,there is no example online and very few questions on ST community. It doesn't seem to be used much. It then worked but only with transfers of 1024 bytes or fewer. There's only a few lines of code about it in their hal_usb file but I don't have enough knowledge about DMA to understand it and fix it.