Home arrow Support arrow Forums

Luminary Micro Forums

<< Start < Prev 1 2 Next > End >>

richard.irving

Junior Boarder
Click here to see the profile of this user

2008/06/10 16:04

usb_dev_bulk bits per second

Hi, I'm using an LM3S3748 eval kit (keil). I have modified the usb_dev_bulk/usb_bulk_example codes to do a looping IN transfer (ARM to PC), and am getting ~2 Mbit/second speeds.
I was hoping for a bit more, maybe 6 or 8 Mb/s.
Does the 2 Mb/s sound correct or am I doing something wrong? I have not done anything to optimize the transfers on the ARM side; it is still doing synchronous writes (via SendUSBPacket in the example code), and the PC side (w2k) is doing synchronous reads (via the WinUSB driver stack, which i have not used before either...).
Anyone have a speedier example using async i/o, double buffering or DMA or anything else on the ARM side?
Any thoughts, comments welcome.
Thanks,
Richard

login or register to reply

cb1

Platinum Boarder
Click here to see the profile of this user

2008/06/12 09:45

Re:usb_dev_bulk bits per second

Hi-

Interesting issue - how are you determining/measuring ~2Mbit/sec?

Wonder if you could implement a PC to PC transfer - and measure that? If faster - this would serve as your "rabbit" against which you race your LMI device.

Does your loop code allow you to transfer the maximum number of data elements before testing for "completion?"

login or register to reply

richard.irving

Junior Boarder
Click here to see the profile of this user

2008/06/12 14:05

Re:usb_dev_bulk bits per second

Hello,
I am calculating the bps on the PC side. I'm reading 64 byte blocks 20480 times [20480 = (10 * 1024 * 1024)/(64 bytes X 8 bits/byte)] in order to read a total of 10Mbits, then divide by the elapsed time. Assuming the PC to be faster than the ARM, this should be OK to a first approximation.
The ARM code is a "slight" modification of Luminary's usb_dev_bulk.c example for the Keil EVK. It is admittedly a synchronous (write, wait for done, write, wait for done...) loop, so it not going to be as fast as double buffered, or DMA, etc. I'm hoping some code-angle (or is that monkey?) will volunteer a working example (did YOU write the Sellaris USB ROM?).
And yes, I need to validate the PC code and the PC WinUSB.sys driver. I have an old cypress fx2 dev kit in the closet somewhere. A bus monitor would be nice, too.
Thanks for the reply,

Richard

login or register to reply

cb1

Platinum Boarder
Click here to see the profile of this user

2008/06/12 14:26

Re:usb_dev_bulk bits per second

Hi back,

Good, thorough write-up - thank you.

No - I'm ex educator, humble LMI/ARM user
like you. Do have interest in China Lcd firm and am working on combined SPI, I2C and USB "live monitor."

The 16 bit SPI frame size limit - imposed by LMI and other ARMs - is severely limiting use with more modern, capable ICs in any number of disciplines. My firm is writing our own ASM version to try and expand SPI capability/utilization...

By the way - have you encountered any, "USB device Not Recognized" messages
from your PC - especially should you "unplug" and then "replug" your Usb connection? This seems to be a big deal for some.

Wish you success - keep us posted.

Post edited by: cb1, at: 2008/06/12 14:28

login or register to reply

richard.irving

Junior Boarder
Click here to see the profile of this user

2008/06/12 15:06

Re:usb_dev_bulk bits per second

Well, it seems I must eat humble pie. It was the PC side that had the problem. Always be aware of your assumptions. I told the WinUSB API to just do one read of 10Mbits, instead of 20480 reads of 64 bytes, and now I get 7.5Mbps. I am happy now. LMI is off the hook.

I haven't had my board long enough to try the unplug/replug tests, but I will give it a try. Bus enummeration can a problem with some other devices.

Thanks, and good luck with SPI,

Richard

login or register to reply

SourceTwo

Expert Boarder
Click here to see the profile of this user

2008/06/12 21:26

Re:usb_dev_bulk bits per second

Hello CB1,

I noted with interest your mentioning the 16-bit frame limit on LMI's SSI. My previous SSI applications had been with the QSPI on the MC68332 - which allowed continuing/ concatenating transfers up to huge lengths. When using the LMI SSI, I too needed to communicate with devices requiring >16 bits (19 bits and 24 bits, for example), and thought I was out of luck.

Only recently, I saw that TWO of the four possible Freescale/Motorola SSI modes DO allow transfers longer than 16- bits! This is not apparent from a quick skimming of the data sheet, but it is there. I have verified the ability to transfer 19-bits to various Allegro chips via a logic analyzer.

I hope this is useful to you.

Regards,
Dave

login or register to reply
<< Start < Prev 1 2 Next > End >>