Mehdi,

At least for this sort of application, Windows will prove to be more of a hindrance than a help under most circumstances. I'd recommend using an old version of DOS at the outset, at least until your transfer rate is determined and your hardware is proven.

If, somehow, you can persuade Windows to let you communicate directly with hardware, as with some sort of driver software, that might be of some help. There are driver packages that will support various sorts of I/O. If you use something like the FTDI USB/FIFO hardware (DLP245M), that will probably work under Windows if you use the manufacturer-provided driver. However, you'll have to provide some sort of hardware buffering, i.e. a deeper FIFO, (the on-board FIFO is not very deep, though it would keep up with the 1 MHz transfer rate mentioned earlier) as the USB interface to Windows often has to wait nearly a second between services. You may find that Windows can be made to service it often enough to allow you to avoid adding a large external buffer memory. That would be VERY convenient.

The sad thing is that there's no DOS support for that USB interface, so if you choose that hardware, which is very easy to use, you can't use DOS for development.

If you put in a deep enough buffer memory, which could easily be accomplished with a CPLD or FPGA and a large SRAM, or an SDRAM (you'll have to work the timing vs. memory depth/width relations, of course), the transfer rate to the PC won't matter much. OTOH, if you find a fast-enough MCU, e.g. one of the 100 MIPS SiLabs parts, you may find you can attach external SRAM and still manage the MCU => PC transfer concurrently with data acquisition from the CCD to avoid any data loss. Keep in mind, that you can slow the SRAM access via the external bus down if necessary.

In the event that you're only building one of these units, you might consider using DRAM, as that is pretty easy to synchronize with tasks of this type and rate and you can find it in old PC's in large enough size to enable you to provide an adequate buffer memory.

RE