Electronic – Best way to connect to UART lines to multiple entities

The output from the PIC to the FT232 can be reused for any purpose you like, provided that you don't care that the signal is also going to the FT232 and hence to a connected PC.

The other signal is an output from the FT232, so if you want to re-use it you must 'isolate' the FT232 in some way. My favorite is a 1k resistor. If you use the PIC pin as output this will add some extra load. If you want to use the PIC pin as input there is a problem: the other source must be disabled while in bootload mode. I don't think this is worth the trouble.

The FTDI chip connects on one side via a USB interface to a PC, and on the other presents a UART interface to the microcontroller; to the latter it looks as if a RS232 cable had been plugged into the device through an RS232-UART level shifter.

This has two advantages. On the PC side, the USB interface becomes a virtual COM port, which makes it easier for programs to communicate with it, since they don't need to go through a special USB driver -- they just have to talk to the COM port, and are thus not even aware a USB port is involved at all and do not need to have code to talk to a special USB driver.

Normally the driver for the FTDI chip doesn't need to be installed -- since thee are so many devices using variations of the FTDI chip, the newer versions of Windows and Linux come with an USB/FTDI driver already built-in.

On the microcontroller side, the same is true -- instead of having to write software to function as a USB device (assuming the microcontroller even has a USB port), the firmware program in the microcontroller only has to deal with interfacing with the UART which is much easier. So at both ends, the PC and the microcontroller, the software thinks there is an RS232 cable between the PC and the board, and is not aware at all there is a USB cable instead.

If an FTDI chip is not used, and the microcontroller has a USB interface, then a USB cable can be connected directly between the microcontroller cable and the PC. One can then write firmware on the microcontroller to present a USB "device" interface to the PC. (This is in contrast to USB "host" interface, which would be used for example if a USB device such as a memory stick or mouse was plugged into the microcontroller.)

If possible, programmers writing this sort of firmware try to make use of the HID (human interface device) interface, which was initially intended to be used by devices like keyboards and mice. However since the USB HID driver is always included in the OS (otherwise your keyboard wouldn't work when booting!), it never needs to be loaded, and it is relatively easy to write software on the PC to interface with it.

The most difficult situation is where a special USB protocol is needed. This makes life much more complicated for both the firmware (microcontroller side) and software (PC side) implementers. When the USB device is plugged in and enumerated, the OS (Windows or Linux etc.) will be unable to find a built-in driver for it. So the software for the device must include a special USB driver, which the user will have to install before using the device.