MP3 Player USB Details

I'm sure this section will be useful to a lot of people.  The USB controller chip is here, along with all of it's associated components.  I wish I'd have found this chip a long time ago.  It would've made a BIG difference in the way my current player works.

I don't have too much information on this setup.  This schematic is pretty much a copy of what the datasheets/application notes say to use.  It looks like it works, so it must, right?

Found this chip at FTDICHIP.  Beauty of a chip.  Takes a USB input and swaps it over to an addressable bidirectional byte wide FIFO port.  Combine that with the Windows drivers that FTDICHIP provides, and you've got USB connectivity.  The drivers they provide don't make instant USB pieces/parts available to Windows in any way shape or form that you want though.  What you end up with after loading the drivers is another COM port, say COM5 (as in my case).  BUT...you don't have to set baud rates, parity, or any of that stuff.  In Visual Basic, you just treat the COM5 as a normal COM port and use Visual Basic's MSCOMM control to access it, or I suppose you could even access it in QBasic using COM5: if need be.  The drivers ignore all baud rate/parity/etc setting functions and you just send and receive data as needed, just like a...well...COM port.

The small EEPROM on the left is for setting your own USB ID if needed.  I'm guessing you'd have to set some sort of ID so that a USB command/transfer/whatever will go to your device and not out to everything connected to the USB port.

So, from what I can gather, operation of this thing goes like this.  For getting data off the USB, you send a byte out the COM port on the PC, the byte goes down the USB wires, hits this chip, gets stored in the buffer.  The chip's RXF* line goes low indicating there's data in the buffer, you pull the RD* line low, read the data on the lines.  When the onboard FIFO buffer is empty, the chip's RXF* line goes high again, indicating no more data.  If you're streaming data to the chip, the line will probably stay high until you pull all the data out of it.  And if the USB is sending data faster than your project can receive it, the USB does it's own speed negotiating, halting the data transfer until the onboard buffer gets emptied out a bit.  When sending data out to the USB port from the project, the sequence is almost the same, the other way around in reverse.  You check the TXE* line, making sure it's low, indicating that the chip's transmit buffer is empty enough to take more data, put the data you want to send out on the lines and strobe the WR* line.  The data gets all the neccessary converting and gets sent to the PC.  The PC's drivers catch the data, and you pull it off the virtual COM5 port using whatever software you've written.  After the device has written a byte, you go back and make sure that the TXE* line is still low and repeat the process.

Sounds simple yes?  Well, it may be just that simple.  I don't know yet.  Or there may be a zillion timing issues and you have to get the PCB just right to keep out any unwanted interference.  Also, the datasheets don't say if this circuit will run at low (1.5MB/sec) or high (12MB/sec).  I'm assuming it'll run at whatever speed it can get, but I'm probably wrong.  I'll keep you posted after I get a few of these chips and try them out.