gnupic@linuxhacker.org

Mark J. Dulcey said:
> Is that true even if you have a USB bus with only low speed devices on
> it?

I think so. There may be an additional restriction in the host-controller
software, but I think it has to do with the low-speed signalling protocol,
and how often low-speed frames are permitted on the bus. Remember that
low-speed frames are only allowed a maximum of 8 data bytes, and you can
only do Control and Interrupt transfers.

With a simple data generator app, I was able to get ~2.5 Kbytes/sec
sustained from PIC to PC. I don't have the calculations handy, but I think
that's the same order of magnitude as the theoretical maximum rate.

> It is frequently possible to arrange that. PCs typically have
> multiple USB ports, and in at least some of them, each port is on a
> separate bus. And if you're designing some sort of dedicated thing, you
> can just keep other USB devices out of the picture.

I did all of my testing on a completely empty bus (except for the
device-under-test).

> Still, your point is valid: the usefulness of the 16C765 is rather
> limited by the fact that it only does low speed; that pretty much
> restricts it to low data rate devices like keyboards and mice.

Right. It is fairly low-latency, though (~2 ms if your OS has a decent
scheduler), so if that's a design requirement, you might be in luck.

> The
> USB-enabled members of the 18F family seem to have disappeared from the
> Microchip web site (they're not listed either in the web pages
> summarizing the 18F series, or in the PDF file of future products), so
> it's not clear whether they will ever see the light of day - perhaps
> there just wasn't enough demand from Microchip's customers for them.

Bummer. From the look of the prelim data sheet, those parts also had some
nice support for external endpoints (i.e. reading from an ADC or some
other parallel device).

FWIW, the EZ-USB chips have "fast read/write" strobe pins for this
purpose, and the EZ-USB FX chips build on that concept.

Or, if you want to leverage existing PIC code, you could use any number of
USB device controller chips that have a "register file" or FIFO interface.
This won't give you blazing speed, but it's better than starting from
scratch (since most PIC projects seem to be written in assembly, not C).

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/