Quote:
Originally Posted by philpem
Which is pretty much why I've been using a PIC18F4550. USB is a host-centric protocol. That basically means the PC does *everything* -- the device can't just say to the PC, "Hello, I've got some data for you", it has to wait for the PC to poll the device.
All RS232 controllers fire an interrupt when data arrives. On top of that, the 16550 UART used in most PCs has a 16-entry FIFO buffer...
|
Right but the UART inside most PCs multi-io chips doesn't even have register settings for that kind of data rate (I think?) - if it did, I'd suspect that the level shifters and EMI stuff on the signal inputs is going to knacker us at that kind of speed.
Mostly though most modern laptops don't have serial or parallel port at all, so most people are using a USB-serial converter, so in real terms you've got nowhere. ;-)
Yes, with USB being a polled protocol we still have a bunch of buffering to do for sure; there is the possibility of buffer overflow but it's rather remote; with 64KB of RAM we can buffer nearly the whole track (depending on various factors). If a track read fails due to overflow we just reread, and a track write doesn't have to even start until we have about 80% of the track data. At that point we need to ensure get the rest of it in less than about 180ms, which I am expecting to be fine. We can also compress the data of course, cos the ARM's fast enough.
We're only running USB 2.0 'full speed' (12mbps) but I don't expect it to be an issue because of our reasonable buffer size.
The ARM talking USB with 64k ram is roughly equivalent to using an FTDI uart-usb chip with a 64kbyte buffer, and it appears that FTDI's come with a lot less than that.
Interesting to see if there will be problems with USB overruns but I am guessing probably not.
Rich