Anyone have already reached more than 500kbps using USB?

[Eduardo__]

Anyone have already reached more than 500kbps(kilo data bits/second) using USB?

I´m currently using PIC18F26J50 at 48MHz, with internal peripheral USB. I used CCS USB driver, configured with usb_cdc driver.
I´m using the function usb_cdc_putc() in eternal looping for sending chars. I´m using windows Hyperterminal for receiving chars(921,6kbps 8N1). This CCS cdc driver is very interesting as it does not care whether you configure 921,6kbps or 110bps(or any other speed). It accepts any configuration and seems to not limit throughput. I confess that´s good for me!

I tried using usb_cdc_putc_fast() function for transfer data, but with just a little increase to 540kbps. It´s not enough for my project.

I checked with oscilloscope that USB bus is running at 6MHz, so i think it´s 12Mbps capable(12 mega bauds/s).

Anyone have ideas for increasing USB throughput?
I´m planning transfer the content of a SPI flash memory. I can drag Flash content at 6Mbps using SPI and pic DMA feature.

Thanks a lot for any ideas or information
_________________
Eduardo Guilherme Brandt

[Eduardo__]

It´seems that, for that, I need to do an USB "bulk transfer"(for more than 500kbps). Anyone knows whether is it possible to do this using CCS USB drivers?
_________________
Eduardo Guilherme Brandt

[Ttelmah]

You need to be looking at using bulk transfers, not interrupt transfers.
Interrupt transfers are designed to give reliable relatively 'smooth' transmission of data with only short gaps in the transmission. This is how a CDC device wants it's data to behave. Hence, small packets at reasonably quick intervals, but with no aim for really high speed.

Bulk transfers are needed to get the best performance, give the maximum bus performance for a short while, however they also can have quite large transmission 'gaps' when other devices are on the bus.

Isochronous bulk transfers are potentially a combination of both, with a pre-negotiated amount of bus time being allocated to the specific device at a regular interval, to give a defined latency.

You are misunderstanding what setting the baud rate 'does' with USB CDC. When you set the baud rate, all that is done is that a message is sent to the peripheral device saying 'this is the baud rate selected' If you are emulating a RS232 or similar peripheral, it is then up to the code in the device to change it's output settings to match. The CCS code in the PIC, receives this message, and passes it to you (set line coding is flagged). It is up to your code then to change speed if required. The 'driver' changes nothing itself in the communication up to the peripheral device.
There is actually no 'CCS driver' involved here - all CCS supply is a .inf file, which tells Windows to use it's own CDC driver.

You are using the wrong tool. A bit like trying to move snow with a teaspoon. Yes, it can be done, but a shovel will always be faster.

usb_desc_scope.h, is the example of setting up an _HID_ device (not CDC), to use bulk transfers.

Best Wishes

[Eduardo__]

Thank you very much Ttelmah.

I´ve just found some idea here, about bulk transfers: http://debusinnovations.blogspot.com/2008/03/usb-bulk-transfer-device.html


Despite of that, I´m going to see the example you suggested-me usb_desc_scope.h . I think it may be easier.
_________________
Eduardo Guilherme Brandt

[FvM]

I remember to have achieved around 1 MBPS in a CDC echo application. This has been with an AT90USB processor, but it's roughly in the PIC speed range.

Most issues have been with tuning the PC side accordingly.

[Eduardo__]

[FvM]

I've been operating the virtual COM interface with generic Windows SDK readfile() and writefile(), while observing comstat information. The behaviour has been slightly different between Windows versions.

The trick is to keep the TX buffer filled to make the driver send more than one 64 Byte packet per USB 1 ms tick. It's useful to have an USB software monitor that shows the bus activity.