ChibiOS Free Embedded RTOS

You mean something like Wireshark? Wireshark helped me quite a lot in the beginning, when I didn't get the device registered at all. But I'm not sure if any analyzer can help to improve the speed. Either the hardware gets the packets stuffed into a frame or not... well maybe the timing could tell you something.

Hi,

I committed changes to the STM32 USB-OTG driver which *should* enable higher speeds. Basically it implements what has already been discussed in this thread (note there is an extra field in the EP configuration structure).

Being in vacation I have only access to my "portable lab" with no way to confirm if the driver is indeed faster thanks to the deeper FIFOs but apparently it works correctly.

Any help in testing the driver would really be welcome.

Giovanni

A quick run through Mathias' code is all I can do right now. As far as I can tell, the speed is 64kBytes/sec. I set the buffer multiplier to 3.

Kjell

If you use serial_usb you have to increase the queue size too or the transaction will still be "short".

Giovanni

I haven't checked lately, but I always thought Mathias used usb, not serial_usb.
Need to look closer at the code before I conclude in any direction.

Kjell

Hi,

I forgot I have Linux on the laptop, I can use the "dd" command.

I am getting 128KB/sec using the multiplier set to two, which is the expected value. Now I am going to try with deeper FIFOs.

Giovanni

Using 4 as multiplier yields 256KB/Sec, it scales correctly with FIFO depth.

I added an "usbblast" command to the demo shell in order to output data at high rate, any key stops the transmission and returns control to the shell (the demo is defaulted to a multiplier of 4 for the IN bulk endpoint).

Amazingly the changes to the driver were quite limited.

Giovanni

Giovanni wrote:Hi,

I forgot I have Linux on the laptop, I can use the "dd" command.

I am getting 128KB/sec using the multiplier set to two, which is the expected value. Now I am going to try with deeper FIFOs.

Giovanni

Ah, but that is what I think is wrong. As long as the FIFO size for the IN endpoint is equal to, or larger than 2x max packet size, and the interrupt is set to trigger on FIFO half empty, the speed should be more than that. If there is no other traffic on the USB bus, it should approach the 12Mbps (minus USB overhead). 1Mbyte/sec should be possible.

The problem as far as I can tell is that the interrupt is not triggered by the FIFO source for some reason. Even if the OTG_FS_DIEPINTx->TXFE is set, I cannot see that the ISR is called until the SOF is detected.

kjellhar wrote:Ah, but that is what I think is wrong. As long as the FIFO size for the IN endpoint is equal to, or larger than 2x max packet size, and the interrupt is set to trigger on FIFO half empty, the speed should be more than that. If there is no other traffic on the USB bus, it should approach the 12Mbps (minus USB overhead). 1Mbyte/sec should be possible.

The transmission is split in "transactions", the driver cannot push the packets of the next transaction in the TXFIFO until the previous transaction is over and the application submits the next transaction buffer.

So the worst between FIFO size and transaction size is what limits the usable bandwidth.

I don't think there is a workaround for this, it is how the USB peripheral works (and may be intrinsic to the USB protocol).

Giovanni

Ok, after thinking a bit about it now I think you are right, it should scale with the transaction size as long the multiplier is at least 2.

This does not happen, something is still hiding in there.

Giovanni