Using FTDI interface while Bluetooth module TX/RX is connected?

[zenwebb]

I've been working on a simple LED controller board that has an ATMEGA328P on-board along with an cheap Bluetooth module from DealExtreme (http://dx.com/p/wireless-bluetooth-rs232-ttl-transceiver-module-80711). I have the RX/TX lines of the Bluetooth module connected to the TX/RX lines of the ATMEGA328, but I also wanted to provide an FTDI interface so different sketches can be uploaded after the board is shipped (so users can update animation patterns, sensor input, etc).

But all of the tutorials and similar projects I've seen using Bluetooth modules with Arduinos have warnings saying that I'll need to disconnect the RX/TX lines between the two, otherwise the FTDI serial connection won't work. If this is correct, how can I isolate my on-board Bluetooth module from the ATMEGA328 when the FTDI interface is active?

I've attached a schematic for my board, if anyone wants to take a look.

[retrolefty]

The bluetooth has an output signal wired to the 328p rec pin. The FTDI also has a output pin wired to the 328p rec pin. What happens if the FTDI output is high and the BT output is low? That's called a short circuit and will cause large currents to flow and chips to be damaged. You simply can't wire two or more output together unless you can guarantee that they will never switch to different states from each other. So some form of isolation needs to be wired in to prevent that. It could just be a dip switch or a diode-or gate with pull-up. The standard arduino design uses two 1k series resistors between the FTDI send and rec pins to the avr rec and send pins. This prevents damage but still does not allow for interference free data sharing between two different data links, and usually you have to disconnect the external serial connections if you want the FTDI usb uploading to work correctly.

Hope that helps?

Lefty

[zenwebb]

Makes sense why they can't both be connected. Now I need to figure out how to isolate the BT module and the FTDI interface when the FTDI interface is in use.

What is the 'standard' way to prevent cross talk? Put diodes on both the FTDI and BT RX/TX lines, or something more clever?

[retrolefty]

Makes sense why they can't both be connected. Now I need to figure out how to isolate the BT module and the FTDI interface when the FTDI interface is in use.

What is the 'standard' way to prevent cross talk? Put diodes on both the FTDI and BT RX/TX lines, or something more clever?

Personally I like to use a pair of PCB mounted 3 pin male header and then use a two pin clip and place the jumper clip in one position or the other as to who 'owns' the AVRs serial pins. Total isolation, little board space used. Keep  it simple is my rule. 

Lefty

[zenwebb]

I like the idea, but I'm really tight on board space at the moment. I'd like to keep my size at or below 1.96x1.96" to be cheap to run through Seeed Studio's PCB service, and am already close to that size.

I just tried fitting an SMD DPDT slide switch, and then a 3-pin male 0.1" header, but both were too big for my board. Here's a screencap of my PCB right now, maybe you can suggest another solution?

[zenwebb]

I think I may have got it! I was able to fit a 2-pin 0.1" header right near the 3.3V power line, with the idea being that when the user wants to use the FTDI interface, they can remove the jumper and cut off power to the Bluetooth module. Would this solve the RX/TX conflict issue and protect the Bluetooth module?

In the attached screen shot, the new header is in the top left, just next to the Bluetooth module.

[retrolefty]

Well maybe a wired-or gate is the only thing that might fit. So you need a pull-up resistor (say 10k ohms) on the AVR rec pin (maybe enabling the internal pull-up resistor would suffice?) then wire two diodes from that rec pin, one to the FTDI output pin and one to the BT output pin, anode leads wire to the AVR. That will electrically isolate the two output pins from each other and allow the AVR rec pin to see both signals. So it won't solve the problem if both the BT and FTDI are actively sending data to the AVR at the same time (data will be garbled), but as long as one or the other link is idle it will work and prevent any pin damage.

Lefty

[retrolefty]

I think I may have got it! I was able to fit a 2-pin 0.1" header right near the 3.3V power line, with the idea being that when the user wants to use the FTDI interface, they can remove the jumper and cut off power to the Bluetooth module. Would this solve the RX/TX conflict issue and protect the Bluetooth module?

Not sure, as having active voltage on a input pin while the device is powered off can cause the device to try and power up through the input pin. It's called finding a 'backdoor circuit' and can cause real problems. Check out the wired-or solution posted.
Lefty

In the attached screen shot, the new header is in the top left, just next to the Bluetooth module.

[draythomp]

I'm not sure it will work for you, but I regularly put XBees on pins 2 and 3 which leaves me the rx, tx pins for programming and debugging.  I use the softwareserial library to do this and it has worked fine on many projects.

[zenwebb]

Nice, draythomp! That is a great suggestion No extra parts, nice and tidy traces. Since I intend for the Bluetooth connection to be supplementary, and not be directly responsible for the main function of the board, SoftwareSerial should work well.

[retrolefty]

Using software serial is certainly an alternative. However I wouldn't use arduino pins 2 and 3 as that would preclude using them as user interrupt pins which can be a powerful and more important use for those two specific pins.

Lefty

[draythomp]

That's true.  Especially in this case where you're building it into the board.  Take a look at the other uses of the various pins and pick one that you'll never want to use for this particular device.  I use 2,3 on boards that I can change easily. 

Your mileage may vary.

[zenwebb]

For me, using pins 8 and 12 (PB0 and PB4) work out beautifully. The resulting PCB routes are cleaner and more direct than criss-crossing all the way over to the RX/TX pins Thanks for the suggestion!