Switching Serial Port Connection between multiple devices?

[x0054]

Hi all! I'll be honest, I am very new to electronics in general, so please be patient I know that to ask an intelligent question you need to know most of the answer. I am afraid I know none of the answer, so this question might be less then intelligent.

Here is the problem: I have 3 devices that communicate via a serial port. Let's call them Device 1, Device 2, and Bluetooth (BT to serial adapter). The BT is used to communicate with a computer, but it can be treated just like a 3rd device for the purposes of the question. There are 3 modes I need this setup to function in. Mode A would have Device 1 be connected to the Bluetooth, Mode B would have Device 2 be connected to the Bluetooth, and Mode C would have Device 1 and Device 2 connected to each other. Please see attached image for a diagram to make things clear.



I can switch between modes with a 3 way switch or a button. What I am looking for is a way to switch between these 3 modes. I have considered just using a mechanical switch, but given the number of connections, and considering that my final project needs to be very small, this is impractical.

My ideal solution would be to use some kind of IC that would allow me to foreword a serial signal from one pin to another, depending on the mode selected, or a set of transistors that would allow me to switch between different modes. But I am completely open to any other, better, solution.

Any help or pointers in the right direction would be very appreciated. Thank you!

 - Bogdan

[Paul Price]

Whenever there are more than two clowns in the circus, things can be very complicated. You then have to think about addressing and bus collisions and who and when which clown is the master or slave and which one of the three clowns decides this.

Until you can determine who is to going to be the ringleader and that the how of who is is to do what to whom and when, no advice can be given.

But you can consider CAN.

[x0054]

I was intending to use manual switching. Basically flipping a switch or pressing a button to switch between mode A, B, or C. No automated switching is necessary in my case. The idea I was considering was using a 3 pos switch and several MOSFET transistors to achieve the switching between the different modes. But, I am not really sure how to do that, I got the general idea, but I am learning more right now about MOSFETs.

[Paul Price]

It all depends on the intelligence and the type of the devices that make up the group.

If you have MCU's then you can have a token passed around to allow it to be the speaker and the others would be listeners.

If you use something like I2C or OneWire or SPI then you can have all TX, RX tied together, with one device being master, the other slaves..but when trying to switch who is master, things like control/bus-arbitration code can get complicated fast!
I2C has stand-alone chips to manage such a circus between members of a group.

Mechanically switching communications between devices is primitive, clumsy, slow, error-prone, and so subject to a need to completely reset the serial ports or each device whenever there is a change of who's doing who, same with FETs or no FETs for switching.

If you have more than one serial port on a device then things can be even more complicated before they become simple.

Then you can consider TCIP internet protocols or BlueTooth, like some PI type MCU boards now have..but that is a whole different tail to wag the dogs.

CAN can do it, but it ain't simple to learn and MCU's are all required.

[Rerouter]

As you are using bluetooth, you could have it that if device C (the computer) is visible, connect to it, as by default you have to turn this on temporarily, otherwise connect to the other device,

Essentially as most computers can connect to multiple devices, this would mesh the devices until they saw the computer, at which point they would all connect to the computer, and by switching off ht eblutooth on the computer they would go back to a mesh?

Hows that sound for and auto

[x0054]

I probably should have explained this a little bit more clearly. My bad. Basically, 90% of the time the device will be operating in Mode C, with 2 devices connected together over a serial port. On rare occasions I would need to connect to one or the other via BT to update firmware, change settings, etc. Power cycling the system beforehand isn't at all problematic. Basically I am making a PCB to connect together 2 serial devices (I didn't build them and will not be modding the firmware), and a BT module.

I know that manually switching the serial link isn't at all elegant, but it will do for the infrequent times I actually need to do it.

 - Bogdan

[Rerouter]

.. sounds exactly like what i just proposed?

[x0054]

The 2 devices, in this case a Flight Controller and an OSD module, do not have those functions built in. Further, since the BT module is acting as a BT-Serial adapter, I am not actually sure if the computer can connect to both of them at the same time and see them as 2 separate devices. Finally, how would you physically connect them, even if it was practical to edit the FCs and OSDs firmware to support listening for a computer connection and connecting to each other instead if they do not see a computer connection?

Each device has a simple USART port with TX and RX pin. So you can connect Device 1 and Device 2 RX to BT TX and Device 1 and 2 TX to the BT RX. That theoretically will allow you to connect both of them to a computer via BT, but how are they going to talk to each other? If I misunderstood your solution, I do apologize.

In thinking more about the problem, a MUX in front of every RX pin with a PIC or another IC with logic to control the 3 MUXs would be a solution. I just wish I knew a bit more to know how to practically implement it.

[Paul Price]

If the OSD and Flight Controller are not aware of how and what and when and what protocol or command/data language they would expect to communicate with each other, then you have a whole new ball game.

[helius]

When you're stuck on a problem, it can be helpful to ask if anyone has ever had it before. Serial ports are a relatively ancient technology and an actual new idea in relation to serial ports would be rare indeed. Mechanical switch boxes for serial ports have been sold since the 1970s:

The way they are used is to connect one side ("I/O") to a host computer, and the "A" and "B" side to a peripheral like a modem or printer. The user manually moves the dial and then restarts their computer (or exits to DOS, which in those computers resets the serial port hardware in a similar way).

This requirement for manual shutdown and restart is removed with a multidrop serial connection like RS485.

[Ian.M]

I would presume the flight controller is already protocol compatible with the OSD.  I'm also assuming everything is using logic level signalling, not RS232 levels.

What's the baud rate?

If it isn't too fast, a PIC could have a pin connected to each TX and RX pin and simply copy the pin changes from each selected TX pin to the correct RX pin.   Use a PIC18 or PIC16F1xxx part to get an accessible LAT bit for each pin so you can bit-bang them efficiently.   

Another alternative would be a PAL programmed to route the selected TX signals to the correct RX pins. 

How are you going to control this to select when and to which device the bluetooth interface connects to?  Presumably you have a problem with physical access otherwise why go to all this trouble?   Do you need to do anything else to put the flight controller or OSD into bootloader mode?

[x0054]

Thanks Ian, that sounds like the best solution so far. I was considering that option as well, but I need baudrate of at least 57600, preferably 115200, and I thought that that might be too fast for a software solution of read and repeat. What do you think? PAL would be a really simple solution, but I have never programmed one of those things, and don't have any of the required tools.

I wanted to select the connection mode vie a 3 position switch or a button. The button with an LED would be a simple solution if I go the PIC route. I could connect the button to an IO pin and monitor for button presses and switch between different modes depending on how many times the button is pressed. The LED could indicate the mode. Off for A, blink for B, solid for C. You are correct that I need the smallest and the lightest solution, and the boards will not be physically accessible without dissembling a bunch of things.

[Ian.M]

That's too fast for a pure software solution, however Microchip have a Configurable Logic Cell peripheral that can do pin to pin routing logic in hardware and if you use a 20 pin PIC16F1xxx part with at least three CLC modules, use CLCx (out) pins for all the RX signals and CLCxIN pins for all the TX signals then all your code has to do is monitor the mode switch, set up the correct routing then blink the LED. 

N.B. Do check the part you have selected has enough CLCxIN and CLCx (out) capable pins. e.g. there may be more CLC modules than available pins!

[Morgoroth]

what about to put a dedicated MCU for each one and use other protocol (more MCU oriented) to stream data between them ?, or for example using a bigger MCU with two serial ports using CTS and RTS enabled, but 115000 bauds is too fast for handle 2 serials at that speed and pretend to attend properly any real time task.

any modern MCU of 1 $USD does the job to get the data from each device and process it.

now, bluetooth at 115000 bauds require a clean environment to work properly, I just advice.

[x0054]

Using another MCU and using it to communicate between both devices is really much more complicated than I really need this to be. Basically, like I mentioned, I'll be updating the firmware and changing settings maybe once every month or so, so jumping through a hoop or 2 wouldn't be a problem at all, plus with the PIC idea, using a button to switch between modes sounds perfect to me. As for 115000 baud rate on BT, it works currently ok, but I may slow it down to 57600 if problems start to occur.

As for the PIC, thanks Ian, I think that's the idea I am going to try. I looked up some PIC chips yesterday, and PIC16(L)F1704 looks good:
http://www.digikey.com/product-detail/en/PIC16F1704-I%2FSL/PIC16F1704-I%2FSL-ND/4439823

According to the data sheet it has 4 CLC in pins (0-3) and it has 3 CLCOUTs not assigned to pins, but the data sheet says that "any pin can be selected as a digital peripheral output with the PPS output selection registers." Does that look like a good choice? It looks like it should work to me.

Now just need to go dig out my PIC programmer from storage.

Thanks for the help!

 - Bogdan

[Ian.M]

Looks possible.  Do check your programmer supports before ordering though.

You may find Microchip's Configurable Logic Cell Tips ’n Tricks helpful.