example interfacing a STM32F4 with libusb

[Giovanni]

The thread would be triggered by interrupts.

About this varying results, I am not sure how it would possible to proceed nor if it is an issue with the driver. Probably you should try the ST library and see if you get similar results.

No plans about OTG or Host yet, there is no bandwidth for this currently.

Giovanni

[kjellhar]

About this varying results, I am not sure how it would possible to proceed nor if it is an issue with the driver. Probably you should try the ST library and see if you get similar results.

Giovanni

The last couple of weeks I've been working on more or less the same problem on a different platform at work (AVR32UC3A based). I did notice some performance loss the other day, but didn't think too much of it as I was working on some other issue. But here's the point. About a week ago, I started to connect the device directly to the computer instead of a hub. With the STM32 issue in mind I did some testing, and my AVR card got the same problem. This is a different chip that rund FreeRTOS and the USB FW is home made. The only thing in common is in fact libusb. For this project I use the same libusb version, but I have written a different application around it.

With that in mind, I don't think Chibios or STM32F4 is to blame for the performance loss. I'm guessing that Giovanni is not using libusb (dd was mentioned).

Kjell

[Giovanni]

Correct, I am using "dd" as suggested earlier in this thread. In order to write on USB now the shell has a command "write".

About USB Host, it is a possibility in the future, right now I am not sure how an Host API should look like, probably libusb itself could be a starting point.

Giovanni

[kjellhar]

Just wanted to say this.

This thread has really shown how dedicated Giovanni is. The response has been fast and positive, and he is very open for suggestions and discussion. Also the spirit of the entire community is very friendly and helpful. I haven't used Chibios for anything real yet, but there is no doubt that this will be my first choice in the future, both for work and hobby, and hopefully I can contribute more on these forums when I get more real life experience on the system.

Cheers,
Kjell

[Mathias]

Now this is definitely weird: When I use the testhal/USB_CDC I can dd at 1.1MB/s with and without a hub. I could understand when my code has some flaw that reduces speed, but the difference between hub/direct makes me wonder. On the other hand, maybe the hub is out of spec tolerant while the port is not. I will have a look into that.
Thanks again Giovanni for this nice improvement! I'm eager to seeing your threaded implementation.
BTW: I want the host mode to implement the Android Accessory specification, controlling the hardware from your phone But its just a toy sideproject, so don't feel pushed on that one.

[Badger]

I would be interested in helping out with a host driver. My motivation is to implement the PTP protocol so that I can control my DSLR over USB. This would be a long term project, I don't have the time at present.

Thanks for the fix Giovanni, it is always nice to resolve problems like these!

[kjellhar]

Mathias,

Since we have very different systems Mac vs Linux, probably different hubs, and I have experienced the same problem on different uC-system, it would be very strange if the problem is anything hardware related. I will try to compile something on Windows, probably tomorrow, and see how it goes.

BTW, I tried to use libusbx instead, latest version, but no difference. Maybe some experiements with libusb-0.1 would be intersting.

Kjell

[Mathias]

It was indeed a problem with libUSB, I only allocated a buffer of one packet, so there was a huge overhead. The benchmark.c now hovers around 1MB/s, even without a hub. Its still 10% below what the CDC example does, I wonder if that's a measuring error or a real difference...

[kjellhar]

Now I have tested Mathias solution on my Mac.

I'm using chibios trunk r4566 and Mathias' benchmark.c slightly changed to measure time in ns the OSX-way.

I'm getting very good results. Transfer rates above 1MBytes/sec both with and without hub. The performance is slightly better using the hub, typically 1.08MBytes/sec with hub and 1.01MBytes&sec without. This performance was measured with Chibios transfer buffer size = 64*128, and libusb transfer buffer = 64*8192.

I tried different libusb buffer sizes, starting on 64*128, and there was a significant performance gain in increasing it further when nit using a hub.

My theory is that the loss happens each time the libusb function returns after receiving a full buffer. If the next transfer is not started very fast, the usb system will put everything on hold until the next SOF. When using a hub, the latency is a bit longer, which gives the benchmark program time to execute the loop and call libusb again before the opertation times out. Without the hub, everything happens faster, and the operation is put on hold until the next SOF.

My guess is that this issue will find its ultimate solution in using the asynchronous libusb interface since that will enable you to queue USB transfers in the background. That is, if it really matters. Some simple applications will do just fine, while others need the extra performance (and the non locking behavior).



Kjell

[Giovanni]

News,

I committed the threaded implementation of the USB (OTG) driver. Now all the data movement is performed by a dedicated thread buried inside the USB low level driver.
This is quite an important change because the previous implementation performed the move operation from an ISR and that caused a lot of added latency making the RT response time much much worse when USB was in use. Now all the operation is performed by a thread whose default priority is just a step up the idle thread.

There are three new configuration option that should be considered when using this driver. Please if you have a chance give this driver a try, except for possible bugs now I am satisfied with the current design and implementation.

Giovanni