Could someone check my thinking and see if they can see any flaws in the plan, so to speak!
I have a device, with an ATmega128, and UART0 will be connected to two TTL level serial "streams", although only one stream will ever be active at any moment (sorry UART1 is already used talking to a separate peripheral).
Those "streams" are both external diagnostics style interfaces, one is hardwired (and requires the device to be physically opened and a plug inserted to a connector on the pcb) and won't be used much (EOL programming via bootloader, and high speed flight recorder data dumping from the on-board memory) but it's set up for 1Mbaud, and full duplex. It's connected to some pc software via an FTDI Virtual serial port device (FT232 etc), and is the "secure" door into the system.
The second stream is slow speed IRDA link (half duplex due to the IR echoing) at around 56kbaud, used to change settings and trigger customer test modes. It uses some light pipes passing through the device enclosure to transmit the data, and includes a magnetic hall switch that senses some magnets in the mating half of the diagnostic "plug". Therefore, when the IR diagnostics are plugged in, the system drops it's baud rate, ignores the echo'd TX data, and allows a more limited range of actions (the ones we let the customer do..... ;-) )
So far, so good, i hope. I will repeat that it's a pure "OR" situation between those streams, and they are not going to be connected simultaneously.
So, for the TX line from the embedded micro to the outgoing data stream, that line, being an output, and being driven by a (relatively) low impedance AVR port pin can just be Tee'd off to the two streams i think? I might put in some current limiting resistors to perhaps prevent any silly errors from blowing things up, and perhaps a high value pull down (pullup ?) on this data line to make sure it sits at some known value during reset / power up etc
The RX (streams returning data back into the embedded micro in the device) is more complex, because the IRDA transciever (a Vishay part: TFBS4711 ) has a tri-state output, with a weak pull up to vcc, which normally, when the hardwired stream is not plugged in, will have complete domination over the RX pin on the embedded micro. As this is a pretty slow stream, my though was to connect the data returned line on the IRDA transciever to the 128's RX pin through a relatively high value resistor (say ~ 10k or similar). As long as there isn't too much capacitance on that line (and hence cause a loss of signal edges), then the IRDA should be able to drive the RX pin ok. Because the "default" mode will be the slow speed, half duplex IRDA stream, this must have a permanent connection to the embedded micro.
The second stream, the high speed hardwired one, can then be connected through a much lower value resistor (say 330 ohm) and so it will "win" any arbitration for the RX line (i need to check the strength of the driver in the FTDI part!!) when it is plugged in. Ie the IRDA will be idling (idle high i guess when it's not sending any data), but the FTDI can still pull the pin low through it's OR'd series resistor? I could also use the "shutdown" pin on the IRDA device to tri-state it's output when it's not being used, but that can't be set permanently because the unit must respond to data on that stream normally,
Because the IRDA necessarily includes TX echoing, there operating modes will have to be different to take advantage of the true ful duplex coms from the hardwired stream (ftdi). As i use an interupt driven RX function, i can just disable that function when operating in IRDA mode (as well as drop the baud rate etc)
So, can anyone see any problems with this approach?