Someone asked me the other day how an FTDI USB to serial UART works, and I realized I didn't know. I looked at the datasheet for the FT232R and the block diagram didn't really help me. Can anyone explain or link me to a good explanation?
\$\begingroup\$
\$\endgroup\$
3
-
3\$\begingroup\$ More of an explanation than it implements the device side of a USB CDC device? en.wikipedia.org/wiki/USB_communications_device_class \$\endgroup\$– kennyMay 16, 2011 at 22:29
-
2\$\begingroup\$ @kenny, actually, it doesn't. It uses a proprietary profile, which is why you need to install drivers to use it (at least on Windows). \$\endgroup\$– avakarMay 17, 2011 at 5:57
-
3\$\begingroup\$ @avakar, it uses drivers on all OSs, some just come preloaded. \$\endgroup\$– KortukMay 17, 2011 at 8:04
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
3
The FTDI chips implement the USB protocol stack. The responsibility of this hardware is to tell your PC what it is (using some identification information) such that your computer can load the right driver for it, and also to manage the data transactions with the PC there-on after - look up USB endpoints for a better explanation of these processes.
Once those drivers are loaded, this would specify a command set that your PC can use to query the chip. This hardware takes care of one side of the equation (communication with your PC). The other side of it would be some dedicated hardware to manage the UART protocol which includes logic, buffers and line drivers and the sorts. The command set mentioned earlier would be used to read from or write to the UART hardware. It should probably be mentioned that USB devices are polled by the PC, so in instances where you are using code which is event based, your PC is actually doing some polling to determine that new data has arrived - this may be different than a native serial port, I wouldn't know.
The above logic can be implemented either as a dedicated ASIC or by using a stripped down microcontroller core which executes firmware on ROM. If it is indeed a microcontroller core, then I imagine the UART is connected to it as a peripheral.
-
1\$\begingroup\$ And how certain are you that there isn't a firmware program being executed? Microcontrollers usually require fewer logic gates than the equivalent ASIC dedicated-hardware implementation. It's really hard to tell a microcontroller from an ASIC, if the microcontroller firmware isn't user-accessible. \$\endgroup\$ May 17, 2011 at 23:02
-
1\$\begingroup\$ @Ben: You know what? I probably shouldn't have said that. Answer has been edited due to my ignorance. I went with my gut assumption after looking at the block diagram, but I suppose it would be better to abstract any potential uC details anyways. I suppose only those at FTDI would know, and I suppose it comes down to core licensing costs vs in house development time. \$\endgroup\$– Jon LMay 18, 2011 at 1:24
-
2\$\begingroup\$ Usually, when you have a "protocol" you end up with a "program" to handle it... even if it's running on an engine buried deep in an ASIC or FPGA. The exception would be things where blindingly fast speed trumps complexity, where you are likely to see a state machine or massive parallelism. In between are engines where the compute path is built out of proportion to the control logic - sort of the original idea behind DSP processors \$\endgroup\$ May 19, 2011 at 6:48
\$\begingroup\$
\$\endgroup\$
There's a USB microcontroller inside which talks a proprietary protocol over USB (hence the need for drivers) and converts that into "normal" UART signals and back again.
answered May 17, 2011 at 13:43