Do FTDI serial port chips use a soft UART, or a hardware UART?

Question

I'm considering using an FTDI cable for RS-485, and I'm wondering who controls the driver enable and how. Is it in a hardware UART, a soft UART, or by the PC the USB is plugged into (very unlikely).

I'm thinking I've heard the chip has a very fast processor inside to implement the serial protocol and it can even receive downloads over the USB port. I know their chips can work in many modes, SPI, I2C, JTAG, etc. I'm thinking this is not all hardware.

Or maybe I'm thinking of another brand like Prolific.

Answer 1

The cable you are talking about uses an FT232RQ chip. Based on the cable schematics the chip is set to RS-485 mode, where a separate TXEN line is used to enable the RS-485 PHY transmit mode, instead of a handshake pin. So you should be looking at the FT232RQ datasheet to find out how it works; the cable just uses that chip.

The FT232RQ datasheet says all handshake lines are handled in hardware.

To you, it is a hardware chip that implements a UART - if it even is a UART chip because FTDI make a lot of chips, and the FT245 has a parallel interface for example.

How it is internally implemented is irrelevant. It is likely that it is a hardware block instead of software, but why would it matter? There is a universal serial interface engine which can do a lot of things for you, so you don't need to bit-bang the interface yourself.

The FTDI can have the RS-485 driver-enable controlled by the chip itself or using the standard RTS handshake signal for it.

So based on the FT232RQ data sheet it has a hardware UART with hardware handshake. Nowhere is it mentioned that there is an MCU that runs code, but there still can be an MCU running code in there, to handle how the hardware blocks interact with each other.

The question may be relevant in theory, but there is no practical relevance how it works. PCs have been used for RS-485 communication before USB was even invented, and they have used hardware UARTs such as 8250 and 16550, and they don't even have hardware handshaking implemented for the transmitter enable. All practical protocols don't depend on that, and if making a new protocol, the protocol should have reasonable timing for transmitter enable and packet turnarounds, as there can be so many different devices all implementing their UART and transmitter enable a bit differently.

For example microcontrollers implementing half-duplex RS-485 typically listen on the bus, and when they need to transmit, they wait for bus being idle for long enough, turn transmitter enable on with a GPIO pin, and after a suitable delay, they start trasmitting a sequence of bytes to bus, having a suitable delay after last byte before transmitter is disabled via GPIO.

So having the FT232R chip hardware to only enable the transmitter for one bit time before start bit and disable at the same time as stop bit, without being able to configure the timing at all, is a bit extreme.

Answer 2

Your question seems muddled due to mixed up terminology.

Here are what the words actually mean:

Hardware UART: There is a dedicated peripheral in a controller that contains dedicated register and timing circuits to manage the UART. Management includes things such storing incoming UART bits into a receive buffer register, sending outgoing bits from a transmit buffer register, as well as flow control. In other words, the central processing unit in the controller does not have to manually manage each and every individual bit and control line.

Software UART: A software UART is bit-banging which means it just uses the general purpose I/O and having the central processing unit in the controller run code to emulate a UART by manually toggling the I/O lines to produce outgoing bits and reading incoming bits based on a timer.

Neither of these precludes the presence of a controller. In fact, they both necessitate the use of a controller.

So this bolded part of your question is irrelevant:

Is it in a hardware UART, a soft UART, or by the PC the USB is plugged into (very unlikely).

But then you say this:

I'm thinking I've heard the chip has a very fast processor inside to implement the serial protocol and it can even receive downloads over the USB port. I know their chips can work in many modes, SPI, I2C, JTAG, etc. I'm thinking this is not all hardware.

So, instead, it sounds like what you're really asking is:

Is it in there an onboard controller driving lines or by the PC the USB is plugged into (very unlikely).

And the answer is that there is an onboard controller. The FTDI-USB bridge contains a controller sitting between a USB-transceiver and an RS-422/485 transceiver. The controller is required because USB packets and the UART signals upon which RS-422/485 are based are not 1:1 compatible. Therefore, something needs to packetize the incoming UART bits into USB packets to send to the PC, as well as depacketize and interpret the USB packets from the PC to know what UART bits to send out.

Obviously more data can be passed through these USB packets than just the incoming and outgoing UART bits. These things include the baud rate that the USB-UART bridge should be using, whether flow control or handshaking should be used, what kind of flow control should be used, and the states that outgoing control lines should be placed into, and the state being read for incoming control lines (such as RTS and CTS).

Whether this onboard controller is driving the UART lines via bit-banging with a dedicated UART peripheral is irrelevant to us as outside users. As a commercial product in ASIC form, I would expect the FTDI USB-UART bridge to be using dedicated peripherals for its UART, JTAG, SPI, and I2C interfaces rather than bit-banging. It's just silly not to do so.

Answer 3

With so much emotional energy going in comments and answers, has anybody (including OP) bothered to read the datasheet?

"With RS485, the transmitter is only enabled when a character is being transmitted from the UART. The TXDEN signal CBUS pin option on the FT232R is provided for exactly this purpose and so the transmitter enable is wired to CBUS2 which has been configured as TXDEN.
...
Note that the TXDEN is activated 1 bit period before the start bit. TXDEN is deactivated at the same time as the stop bit. This is not configurable."

It is as simple as that.

Note, that RS-485 is a hardware specification. It does not define any provisions for collision avoidance or communication protocol. So, you have to do it yourself on all nodes on the bus. And if your node happens to be a PC with this adapter, you have to live with latency inherent in USB-to-serial conversion and all the delays on the software side.

Even though FTDI chip is 12 Mbit/s full speed USB device, if you remove USB protocol overhead and add your own serial protocol with arbitration, I doubt you'll be able to hit even 1 Mbps throughput.

P.S.

Regarding "hardware vs software" discussion. Here is your comment from another answer:

"If you read the question, it is about whether the UART and the driver control is done in hardware or software. As I said, my understanding is that there is a processor in the cable with software that emulates the UART function and controls the driver enable."

Now, if you read the quote from the documentation above, do you understand why @Justme was absolutely right saying that it is irrelevant?

The switching of the TXDEN can be done entirely in hardware, based on a state of receive FIFO. Or there could be a specialized processor in the chip running some microcode or firmware that does TXDEN switching. In the end, it does not matter, as long as the pin behaves exactly as it does.

Answer 4

As others have pointed out, your question is not very precise.

It is usually the best to focus on what you would like to achieve instead of what you think would help you without divulging "too much details", in order to avoid the XY problem.

---

To focus on the subject matter:

1. This is way more an economical question than a technical one.

First, according to current economic conditions, it would be quite hard to come out with an architecture that is powerful enough to attain even USB 1.1 speeds (that is, anything above ~921600 bps) with proper timing, as well as remaining economical to produce (sadly, in current age, that equals to couldn't be sold for more for any different purposes).

In my personal experience with multiple (but far from "most") architectures, even an ARM Cortex-M0 core clocked at 36MHz dedicated for this task struggles to keep up with maintaining jitter, rise and fall times for 2Mbaud within spec – even on bare-metal / hard-RT implementations. (I am sure one could do better, with goto abominations, or native assembly, but this is a great ballpark range.) To put that into perspective, a 40MHz MIPS core can be used (with hardware I2S, and some frustration) to decode various MP3 formats in more than acceptable quality.

But then again: if someone is not into the standard that much, then timing is not that critical practically – most chips (including FTDI ones; notable exceptions being the WinChipHead CH3xx series) don't care for timing that much.

2. As such, even if the chip would use a bit-banging transceiver, it would definitely need some higher-precision interrupt timers or other hardware peripheral/offloading support to remain within the spec (which it does). But given the cost factor for something such, it would only make sense if they made an "universal peripheral", that they may use for CAN, I2x, USART, and probably a few others, and then e.g. select the features with efuses, in order to keep the manufacturing costs low.

3. Unless you are into tampering with the workings of the chip using for instance, clock or power glitches, then – as most others already pinpointed – it really doesn't matter for you, since it is economically absolutely out of question that the chip, even if using software UART, is actually reprogrammable, or even erasable.

Bottom line: according to economic considerations, it is more than unlikely that it is implemented as a completely bit-banging interface, and if it is not a dedicated USART IP core, but a more universal one (which I seriously doubt), it is for cost savings and not any performance/simplicity/etc. consideration.

Also, the decapping/hardware analysis of FT232R seems to underpin my initial thoughts.

Answer 5

I've not used the output-enable function for RS485, but the handshaking behavior of the FTDI is handled at the hardware level and I would expect the output enable would be likewise. While I don't know the exact setup time requirements, the FTDI will hold off on sending a byte if the handshaking output is deasserted during the previous byte. Further, if the handshaking line is asserted and deasserted around the time that a byte would be queued for transmission, the FTDI will transmit a byte essentially as soon as it decides that it is going to do so. Thus, a device that deasserts the handshake line, waits a bit time to see if the FTDI has started sending a byte, and observes that it has not, may safely assume that the FTDI isn't going to send a byte until the next time the handshake line is asserted.

There are some things I dislike about the FTDI chips, such as the fact that it will often discard serial data that is received immediately preceding a long break, but the hardware handshaking is nice and responsive--more so than even an old fashioned PC serial port.