Lpc2000

> Eek.  Very expensive.

Indeed, it would seem the FTDI chip solution is still the best 
solution for product runs of up to several hundred total units, or 
where time-to-market is critical.

You can buy a lot of FTDI chips and the attendant board space for 
the cost of one of those development systems.  And the PC and 
peripheral side drivers are (or can be) reduced to nothing more 
complicated than the serial protocols we came to understand in
simpler times.

Even without the convenience of end points, the FTDI "direct" D2XX 
drivers are capable of sustaining many hundreds of kilobytes/second.  
The trick is, at the peripheral side let those FTDI internal buffers 
fill up a bit before reading a block of data, and don't get bogged 
down in interrupt-per-character data handling. Enable the USB 
interrupt.  When the first USB interrupt hits, disable the USB 
interrupt and set up a timer interrupt to occur tens or hundreds of 
microseconds later when the buffer is nearly full.  When the timer 
hits, soak up the buffer all at once, and re-enable the USB 
interrupt.  It helps speed things along if you arrange the pins so 
the FTDI handshake pin states appear in the same data word as the 
byte data.

At the PC end, attach the D2XX driver handshake to a thread that 
maintains buffers filled and emptied by your Windows application 
code.  FTDI has good docs on the drivers and some PC example code.  
On a gHz+ machine XP often services such threads at over 1mHz!

Or you can just use the serial port driver, which is not quite as 
fast as the D2XX driver, but in every other way a piece of cake!

Bill T.
http://www.kupercontrols.com