5
\$\begingroup\$

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.

\$\endgroup\$
15
  • \$\begingroup\$ What do you mean who controls the driver enable? Are you talking about the RTS/CTS? \$\endgroup\$
    – DKNguyen
    Commented Nov 5, 2022 at 20:35
  • 2
    \$\begingroup\$ @gnuarm The PC is perfectly capable of controlling the driver enable. But as it unknown which specific FTDI chip you are talking about, or which way an RS-485 PHY chip is connected to it, it can't be known if the chip controls it in hardware or if the PC does it. Why do you need to know how it is implemented, what are you worried about? PCs have been doing RS-485 over UARTs long before USB was even invented, and has worked through USB as well. \$\endgroup\$
    – Justme
    Commented Nov 5, 2022 at 23:23
  • 1
    \$\begingroup\$ There's no point in arguing about it, but Windows is not a real time operating system. If the PC is doing other tasks, there is no way it would be able to manage the RS-485 driver enable at the required time. The UART typically provides an indication that the character has transmitted in the middle of the stop bit. The driver needs to be turned off before the stop bit ends, so that other devices can jump on the bus with a start bit, without collision. At 3 Mbps, that's about 167 ns. No, not happening under Windows. \$\endgroup\$
    – gnuarm
    Commented Nov 5, 2022 at 23:37
  • 1
    \$\begingroup\$ @gnuarm You are mistaken, if the PC would use RTS for data enable, it would turn on RTS, send data, and turn off RTS. Standard practice. And And no real world system would use 167ns turnaround time, that is completely unrealistic, it is not done and not needed. \$\endgroup\$
    – Justme
    Commented Nov 6, 2022 at 0:09
  • 2
    \$\begingroup\$ I would like to emphasize the comment I made on one of the answers and strongly suggest stop using "handshake", "control line", "RTS/CTS" and such in regards to this question. RS-485 does NOT have any control lines, handshaking or anything like that. Furthermore, driver enable signal the OP is asking about is just a way to switch on/off the driver in local transceiver. Since RS-485 transceivers typically can't tell the difference between Idle and Mark states of the bus, this signal cannot be used for handshaking either. \$\endgroup\$
    – Maple
    Commented Nov 7, 2022 at 15:56

5 Answers 5

18
\$\begingroup\$

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.

\$\endgroup\$
11
  • 3
    \$\begingroup\$ It's relevant to me, which is why I'm asking the question. Maybe I need to design my own. The USB side is the messy part though. \$\endgroup\$
    – gnuarm
    Commented Nov 5, 2022 at 22:59
  • 2
    \$\begingroup\$ @gnuarm For example many MCUs have hardware UART but no hardware handshake, so that is external to the UART. If you please mention which exact cable or chip you are talking about, I can improve the answer. So is your question only about hardware handshake, or UART which may not include handshake, or what? I understood you were only concerned about the driver enable signal, correct me if I am wrong. \$\endgroup\$
    – Justme
    Commented Nov 5, 2022 at 23:34
  • 2
    \$\begingroup\$ @gnuarm Be more specific. Which FTDI cable? Which FTDI chip it has? Where are the schematics? They have had dozens of cables and adapters with different chips in them over the past 20 years, so I can't possibly know which of them you mean. \$\endgroup\$
    – Justme
    Commented Nov 5, 2022 at 23:45
  • 3
    \$\begingroup\$ @gnuarm It does. You need the processor or controller of some kind because USB and RS-422/485 or UART aren't 1:1 compatible. Something has to do the packetizing, depacketizing and interpretation. Obviously if you do that, you can send other messages over the USB as well, such as whether to enable outgoing control lines or whether incoming control lines are enabled. \$\endgroup\$
    – DKNguyen
    Commented Nov 5, 2022 at 23:47
  • 5
    \$\begingroup\$ @gnuarm The confusion is that your intial question doesn't seem to actually be what you want to know at all. You initially asked about software vs hardware UART. A software UART is bit-banging. A hardware UART has built in hardware so it doesn't need to bit-bang. That's why Justme said it was irrelevant because from the outside it doesn't matter whether the controller is using a hardware UART or whether it is bit banging: You have a functioning UART either way. You instead seem to be wanting to know if there's a controller at all involved and the answer is yes. \$\endgroup\$
    – DKNguyen
    Commented Nov 5, 2022 at 23:49
11
\$\begingroup\$

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.

\$\endgroup\$
6
  • \$\begingroup\$ You seem to think a "software UART" has to be in the PC software. The "software UART" can be in a processor in the chip. If you read my question again, you will see that is what I'm talking about. Even in the parts you quoted, I was talking about the driver enable being under direct control by the PC software. \$\endgroup\$
    – gnuarm
    Commented Nov 6, 2022 at 0:32
  • \$\begingroup\$ I'm sorry this is causing so much confusion. \$\endgroup\$
    – gnuarm
    Commented Nov 6, 2022 at 0:33
  • 5
    \$\begingroup\$ @gnuarm I never said the software UART is in the PC software. In fact I said it was the software running on the controller. The UART literally cannot be driven directly from USB because USB and UART are not 1:1 compatible. The driver enable is no different. There is no reason for you to distinguish the UART bits from the control lines such as the driver enable. The PC controls bits and control lines all in the same way: It sends USB packets to the FTDI chip, and the controller on the FTDI interprets those packets and takes care of everything else. \$\endgroup\$
    – DKNguyen
    Commented Nov 6, 2022 at 0:45
  • 3
    \$\begingroup\$ Where does it seem like I think a software UART has to be PC software? \$\endgroup\$
    – DKNguyen
    Commented Nov 6, 2022 at 0:45
  • 1
    \$\begingroup\$ What's relevant is not so much whether both bit-level transmission and external control lines are both handled by hardware or both by a very fast interrupt in software, but rather whether they are both controlled at the same abstraction layer. A common annoyance with the 16550 UART is that it has no clue what RTS and CTS mean. Achieving maximal performance often requires that characters be loaded into the 16550's buffer before it is ready to transmit them, so that when it becomes ready it won't have to wait for the characters to be loaded, but if a remote device deasserts CTS after... \$\endgroup\$
    – supercat
    Commented Nov 8, 2022 at 19:51
4
\$\begingroup\$

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.

\$\endgroup\$
13
  • 1
    \$\begingroup\$ Thanks for the better quote. I only mentioned the datasheet saying handshakes are handled by hardware. However be careful how you define the throughput. I use these at the maximum rate of 3 MBps, but as the appnotes warn, it can't be continuous due to FIFO size. \$\endgroup\$
    – Justme
    Commented Nov 6, 2022 at 8:55
  • \$\begingroup\$ @Justme I do not define throughput. It is defined for me as data rate between application layers in OSI model. The FIFO size, arbitration, protocol overhead, OS multitasking and a lot of other factors all work together to chip away at that bitrate until what is left can be quite frustrating throughput. \$\endgroup\$
    – Maple
    Commented Nov 6, 2022 at 9:10
  • \$\begingroup\$ @Justme I am curious, are you using these in multidrop or dedicated p2p? \$\endgroup\$
    – Maple
    Commented Nov 6, 2022 at 9:45
  • \$\begingroup\$ Using the FT232R as TTL debug cable to MCU. No RS-485. \$\endgroup\$
    – Justme
    Commented Nov 6, 2022 at 9:49
  • 2
    \$\begingroup\$ @Victor-ReinstateMonica The actual question as stated in OP is "who controls the driver enable and how." I have quoted the datasheet that clearly says that driver enable pin on the transceiver is controlled by TXDEN signal from FT232R, which in turn is active only when byte is being transmitted. I think that answers the question precisely. \$\endgroup\$
    – Maple
    Commented Nov 6, 2022 at 15:58
3
\$\begingroup\$

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.

  1. 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.

  2. 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.

\$\endgroup\$
3
  • \$\begingroup\$ It's all shades of gray. What about a UART implemented using the FlexIO peripheral in an NXP chip? Is it "hardware?" Is it "software?" Is it a bit of both? or should we call it by some other name? \$\endgroup\$ Commented Nov 6, 2022 at 19:24
  • \$\begingroup\$ @SolomonSlow well, if we want to go down the rabbit hole, most digital hardware is designed in either Verilog or VHDL, and "synthesized" onto FPGAs or CPLDs, before actually fabricated, based on the gate-level representation that is actually "compiled" FPGA or CPLD. In that sense, everything is software - once. \$\endgroup\$ Commented Nov 6, 2022 at 21:12
  • 1
    \$\begingroup\$ @SolomonSlow but yes, FlexIO is exactly what I've meant by the "other hardware peripheral/offloading support" above. \$\endgroup\$ Commented Nov 6, 2022 at 21:18
1
\$\begingroup\$

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.

\$\endgroup\$
11
  • \$\begingroup\$ What handshaking are you talking about? RS-485 is a simple differential electrical interface. It does not have "handshaking line" to assert or deassert. \$\endgroup\$
    – Maple
    Commented Nov 7, 2022 at 15:28
  • \$\begingroup\$ The FTDI USB to RS-422 interface cable supports RTS and CTS. Aren't those handshake lines? \$\endgroup\$
    – gnuarm
    Commented Nov 8, 2022 at 0:20
  • 1
    \$\begingroup\$ @gnuarm No matter how many times I read those, there is still NO handshaking in either RS485 nor in RS422. They both are single signal carriers. The only difference is that RS485 has provisions for limiting driver current, thus preventing it from burning out on collisions, and allowing bi-directional communication. It is up to you what you send over those lines, including flow control signals. You can also send for example PCM audio over either of them, that does not make them audio protocols. \$\endgroup\$
    – Maple
    Commented Nov 10, 2022 at 7:26
  • 1
    \$\begingroup\$ @supercat Are we still talking about RS485? Because in this case if a remote device starts sending XOFF while FTDI is in the middle of a transmission then one of 3 things can happen: a) UART controller will see the difference between what it is sending and what is received and stop transmitting, b) on a long bus local driver will overcome the remote and controller will see nothing out of ordinary, or c) on a very long bus it will finish transmission, power down the driver and then receive XOFF. Note that former two cases still require host-side software to deal with collisions somehow. \$\endgroup\$
    – Maple
    Commented Nov 10, 2022 at 20:06
  • 1
    \$\begingroup\$ @Maple: I was talking about the responsiveness of the FTDI chip to data entering its receive pin. You're right that with shared-bus RS485 xon/xoff wouldn't work, but I've also seen systems that use one pair to allow a master to transmit to many slaves, while another pair is used by all slave devices to send data to the master. Essentially RS-422 in one direction, and RS-485 in the other. You were talking about having four differential signal pairs, which would seem to accommodate the possibility of such half-shared communications lines. \$\endgroup\$
    – supercat
    Commented Nov 10, 2022 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.