High speed USB

[guy]

Hello everyone, it's been a while...
Is there a [cost-effective hardware] solution to use CCS compiler with USB High Speed (2.0) ? Some interface chip maybe? I need to get as much bandwidth as possible.

Thank you!

[Ttelmah]

The problem will be how are you going to handle the data?.

Even the fastest PIC's using DMA, you won't be able to get the data to/from
an external memory, and the internal RAM would be too small for any
HS communication to really be worthwhile.
I've done USB PIC's giving just over 1MB/sec on the internal USB,
and even with the fastest PIC's, the problem is keeping up with handling
the data at this speed. The overhead of transferring in/out on another
port would negate any speed advantage of an external interface.

The fastest PIC USB is the 32MZ series, but these are full 32bit chips,
so not supported by CCS. None of the lesser CPU's deem it worthwhile
offering a faster interface, because they simply can't handle more than this.

[temtronic]

hmm....just how MUCH data ? You'll need a PIC with a LOT of RAM or maybe a huge FRAM ? BIG buffers for sure.
Does the 'data' need to be stored ?
Then there's 'processing the data'. Moving bytes is fairly fast but any 'math' on them will slow down the program, especially if ,ugh, floating point is involved

[guy]

Thanks for the support.
I don't have to get to the top speed USB 2.0, but USB 1.1 is not enough.
I worked with dsPIC33 series & CCS and things worked smoothly. As you mentioned, they don't support USB 2.0 so my question was, is there some interface chip that converts to USB 2.0 high speed and supports fast bulk transfers?
If you can estimate what will be the bottleneck and what throughput I can expect, that would be great. I see the dspics go up to 70-100MIPS (not sure they are all supported by CCS).

[temtronic]

something like the 'CP2102' USB2.0 <> TTL modules might work for you ?? They're $5 a pop, can be 3 or 5v. used them for years but honestly never worried about speed just that they connected to PC that don't have real comports in them !

[Ttelmah]

Problem still not answered is where this data is gong to go to or come from?.
Simply fetching a byte from an external memory takes time. If wired
really carefully you can use DMA, but this would then have to be to the
processors memory. Then a second DMA transfer would be needed to
the external port to feed the USB. The time involved for all this takes the
top speed way down.....
You could interface to a device like the FT120T. 8bit port plus chip select,
DMA and read/write controls. You can use the ping/pong buffers on this.
Potentially this could transfer a small block from the RAM of the PIC.
You'd still only get to about 1MB/sec, which the PIC with careful programming can already do.

I cannot honestly see any 8/16 bit PIC being able to prepare and send or
receive data faster than it can currently be done on the existing interface....

I can send 0.5MB files to a fast PC in under half a second from the PIC
using an isochronous USB transfer. The limit is how fast I can actually
read the data into the PIC's memory.

[guy]

The application is not a secret... I intend to read digital I/Os and fast internal/external ADCs and transmit them to a PC. There is no specific target bandwidth at the moment. In the past I used on-the-fly basic data compression which greatly improved speed but this is not always possible.

Take this beast for example: dsPIC33CK256MC506 - supported by CCS (let me know if have a status update - stable?), 100MIPS, A/D 3.5MSPS@12bits, and 20 multiplexed channels. With DMA+ping pong buffers+flow control and a touch of assembly code if required I believe I need the higher transfer rates...
CP2102N supports UART 3Mbaud (~300KB/sec), still not USB High Speed but not too bad.
If you have faster options please share them.

Thanks!

[temtronic]

hmm, looked and found the CP2104. Says it's FULL speed, USB2.0. several versions, I presume different FIFO buffers ?

I know in the past, it was better for me to use an external USB<>TTL module than the internal in the '4550'. Saved a lot of code space( USB driver), easy connections and cheap(added $1 per project)

[Ttelmah]

You are still an order of magnitude short on the performance needed
with the CP210x.

If you actually ran the ADC at 3.5meg samples per second, you would be
generating data at 42Mbps. Over ten times faster that the CP210x manages.
The USB interface this supports is identical to the PIC. So 64 byte buffers
and maximum 12Mbps. You need to be looking at an interface with larger
buffers and supporting FS mode to actually get beyond the rate that the
PIC natively supports. Also be very aware that often the PC itself will
become the limiting factor once you start to get to these sort of rates.

You can interface to the parallel connection on a FT2232H, and potentially
do small bursts at up to 8Mbps. Still only a quarter of what you potentially
need. Go to a USB3 to parallel interface, like the FT600Q, and use a 16bit
port to talk to this, and you could potentially get to the sort of rates
you'd need.

Also you need to be aware you will not get to 3.25Msamples/sec. This
is a maximum, and only achievable if the clock is selected to be an exact
division of the time needed. This sample rate is only achievable using the
8bit resolution mode, and with a very low impedance source. The quoted
maximum throughput in 12bit mode is 2.7MS/sec, and in fact you will
be lucky to get even 2M samples/sec. in a real system.

[guy]

Thank you both, esp. for reminding me of FTDI. They have a wide range of USB solutions incl. High Speed and USB 3.0 . Just what I needed!

[Ttelmah]

Be aware though (as I have just modified my post to say), you will _not_
get 3.5MS/sec. This is only available in 8bit mode.

[guy]

[newguy]

5.116 has the MP part in the devices folder, but not the MC part.

That processor looks to be relatively new, judging from the copyright date on its data sheet. My concern here is unknown errata biting you.

Anything the MC part has which the MP doesn't can be compensated for by writing your own low level (register setting) protocol. I've used dsPICs in the past quite a number of times and they just work, similar to any of their 8 bit brethren. The only minor difference comes down to interrupt priority and DMA, which not many (if any) 8 bit PICs have.

[Ttelmah]

Step back.

The MC releases of that chip have only just started to be supported by the
compiler. you could ask CCS, and they will probably be able to supply a 'beta'
library for these, but expect there to be some issues. As Newguy says you
also face the issue of effectively being a beta tester for the chip as well as
the compiler.
Consider an alternative approach. The fastest chips for doing two jobs like
this (so sampling and sending), are the multi-core units. More complex to
code, but you can have the secondary core actually retrieving and storing
data while the main core organises and transfers this,
On the fastest 33CH units you have a 100MIPS on the secondary core,
and 90MIPS on the primary. Nearly doubling the available processor
power. The ADC sample rates available are the same as the
dsPIC33CK256MC506 you are looking at.

[dyeatman]

I am a real fan of the 33CH PICs.
It was a little work to set up two ICD-64s and get things ready to debug (dual
terminal sessions etc), but the twin CPUs are really nice and passing data
between them via the MSI works nicely once you get it working (there
are some options here to consider). I typically use the secondary processor for
display and I/O (switch/indicator control) which offloads the main processor.
I ended up using a 32inch monitor to get both compiler debug sessions
side by side along with the associated terminal output windows under them.
_________________
Google and Forum Search are some of your best tools!!!!