Arduino Uno R3 hardware serial: peripheral interfering with the USB/Serial-converter?

I like to use the hardware serial port (pin 0 RX and 1 TX) to connect a bluetooth module. Internally these pins are also connected to the onboard USB to serial converter microcontroller which is used to flash the ATMega328 using the bootstrap code.

Now these two signals would interfer, I think.

• Can the RX/TX pins be used to interface with an UART peripheral?
• If, what should one do to avoid colliding signals?

I couldn't find examples in my Arduino books and with Google that used the hardware serial port of the Uno R3 to connect peripherals.

Edit 1:

Let me add the following: I don't want to use the Serial monitor (of the Arduino IDE) and the peripheral (Bluetooth module) at the same time. I don't expect that it can be used at the same time. The device should run without USB connected. The Bluetooth module, in this case, will be used to remotely and wirelessly control the Arduino.

Even when not using both together, I suspect the ATMega16U and the periperal might interfer.

And: I know, there's a shield and also an "ArduinoBT", but I don't want to use them as long as it's possible to do this with the hardware serial port of the Uno.

Edit 2:

The peripheral (Bluetooth) module operates at 3.3V while the Arduino operates at 5V.

Those two resistors, marked RN4A and RN4B, are used to protect the uart line from conflicts, while also assigning priority to the external header. They act like weak pullups, in that anything before (In this case, left of) the resistors will only affect the line after them, if the lines are not being used.

Anything serial connection plugged into the header, will take priority over the Arduino's usb/serial connection, as they can directly power the lines.

But this will also provide issues during programming, so use an enable pin, or power switch, or simply remove the bluetooth module while programming.

• Does this make any difference if the Bluetooth module is powered with 3.3V? – try-catch-finally Apr 23 '13 at 8:33
• From Atmega16U2 specification (18.4, page 152): "When a complete frame is transmitted, it can be directly followed by a new frame, or the communication line can be set to an idle (high) state." does the 5V idle high state make problems? – try-catch-finally Apr 23 '13 at 10:16
• That's a bit of a gray area. The question would be along the lines of if the 3.3v device has protection diodes (probably) and if the current through the resistors across that voltage difference is within the rating of those diodes, and if the 3.3v supply is rated to absorb current injected into the supply rail. One thing you can try is using even larger resistors at the point where you connect your 3.3v device. If your resistors are too large, you'll get data errors, while it's on the resistors too small end where damage is a theoretical possibility. – Chris Stratton Apr 23 '13 at 14:20
• You could also consider adding your own zener diodes (reverse biased, to ground) if you want to be sure. Some people have even used LEDs (with their relatively large forward voltage drop) as such a clamp - for example, see some of the interface circuits for the software USB hack. – Chris Stratton Apr 23 '13 at 14:21
• @try-catch-finally without a datasheet for the bluetooth module, I would err on the "you will kill it" side. You will need to use level translation. A pair of transistors would do that just fine. Some modules do have level translations on them though. But this is a different question, and has been answered before, use the search. – Passerby Apr 23 '13 at 15:40

I can't think of a reason why your peripheral UART and the USB-UART would interfere. You probably want to disconnect you UART peripheral during programming, as it may interfere with programming.

Also I wouldn't be surprised if you can eavesdrop on the traffic between ATmega and peripheral UART and insert data to the ATmega through USB. So you probably want to disconnect the computer while your device is operational.

• The fact that they would both be trying to drive the same receive pin would be reasons enough. The series resistor may provide some limited electrical protection, but is far from being an actual multiplexer when both are connected with drivers enabled. It's common to use a software serial implementation on an unused GPIO pin when connecting serial peripherals to the single-hardware-UART sort of Arduino boards (in contrast to the Arduino MEGA style boards with multiple hardware UARTs) – Chris Stratton Apr 22 '13 at 4:45
• On one of my later projects there's not enough port space to use software serial (in fact I'll use software serial, but it will be connected to another device). Even if there's enough port space, I don't want to use that method as long as there's a serial port which can be used (or why has it been wired to two connectors? I think it's a kind of waste.) At least I think - you might correct me - that the - even the "new" - software serial implementation will take more space in the flash memory. – try-catch-finally Apr 23 '13 at 8:10