3

I have a board that I would like to design and there are 11 devices that can only be spoken to via UART. I am restricted to a Microchip uC chip product range and I have found one with 5 UART ports. I have come up with a jumper based solution whereby the user, with making the connection via jumpers to the 5 available ports, can choose 5 of the 11 devices. I have been looking for a chip that will take either UART, SPI or I2C in and give me a few additional UART ports but I have come up short. Can anyone suggest a solution or a product that they may have come across?

It is not critical that all 11 devices are able to connect to the uC (that would be nice) but it is important that these devices are on the board for a modular product. However, I wish to make the product more user-friendly as the jumper based solution is a bit complicated at first glance or so I have been told.

EDIT

Okay sorry, I am not explaining the problem properly. With this method, you limit the user's options. Let say you link port a to device 1 and 2 and port b to device 3 and 4 and so on...

But what if the user would like to use device one and two? Then the product is limiting the user heavily. With 5 port options and 11 choices for devices, the binomial coefficient yields 462 combinations for the user to choose from. That is overkill, I am not looking for that level. But with the jumper based solution port a can connect to 9 of the devices while port b can connect to 7 of the devices, port c can connect to 8, port d can connect to 7 and port e can connect to 9. The number of mux switches needed to do this would be over the limit.

Is there another solution to giving the user the option to use (close to) any combination of the devices?

I have thought about using two uC with 5 UART port each to connect to 10 of the devices and then using a much smaller jumper based solution for the last device, but this solution is too complicated for production and is expensive.

Are there any Chips or concepts out there that will expand the UART control to 11 devices?

Gareth T.
  • 369
  • 3
  • 14
  • We used to use the old (StarTech) ST16C554 or ST68C554, I think. Back in the day. NXP may be making them now. They supported several interfaces to the micro and provided four added RS-232 ports. They made 552 devices for two ports, as well. You could mix and match to get to where you want. (They each included FIFOs, as well.) Personally? I'd add more PIC parts. – jonk Oct 30 '18 at 07:08
  • As long as all of the remote UART devices transmit only in response to commands from the host, could you use RS422/RS485 transceivers? Then you could bus all of the receive data to a single UART port on the host, and only drive RS422/RS485 transmit-enable for one remote at a time. – MarkU Oct 30 '18 at 07:36
  • Why do you need to simultaneously use any combination of UARTs at the same time? What problem exactly are you solving by that? – Chupacabras Oct 30 '18 at 16:21
  • @Chupacabras it does not need to simultaneously use any combination of UARTs but the system needs to be modular enough to give the user any of the 11 devises on the board and at this point, they can use 5 of them. – Gareth T. Oct 31 '18 at 12:06
  • @GarethT. So you need to communicate only to 1 UART device at one time? You do not need to communicate to multiple devices at the same time? – Chupacabras Oct 31 '18 at 12:08

5 Answers5

3

Use some UART-SPI bridge ICs, like:

You can have as many UARTs as you have spare GPIO pins to use as Chip-Select lines (or use a demux or decoder and you can have orders of magnitude more) - limited only by your UART baud rate vs the max speed you can run your SPI.

brhans
  • 14,373
  • 3
  • 34
  • 49
  • This looks promising, I will look into each of them. Thank you. – Gareth T. Oct 30 '18 at 13:55
  • The SC16IS7xx is on the right track with SPI or I2C to two UART's is great as I would need three of them to do everything, but unfortunately, the cost for just one of them is too high. If there is a chip that can take SPI or I2C and give 4 or 6 UART I would be really excited. – Gareth T. Oct 30 '18 at 14:16
  • 1
    @GarethT. In this day, I think that would be another of your 5-UART PICs. Just program it, is all. – jonk Oct 30 '18 at 20:12
  • @jonk I have really been considering that option but it is a bit overkills for the task and when boards come in for repairs and it is not an easy fix they always blame the uC or the memory chip. If there where two of them on the next lot of boards, I can see the world ending in there eyes. – Gareth T. Oct 31 '18 at 12:00
  • @GarethT. Sure. As I said, we used to use the ST16C554 or ST68C554 devices (different interfaces.) They worked fine for creating a large number of serial asynch I/O ports. But I suspect they are quite boutique, these days, because it's cheaper/easier and more powerful and convenient to use MCUs now. But I'm not in the business today, either. So I can't tell you what others do when they need dozens of such ports. But I don't see any really good multi-asynch device answers yet, either. So perhaps that's the way of things, now. What do you think, seeing what you've seen so far? (+1, by the way.) – jonk Oct 31 '18 at 14:46
  • @jonk I pitched the SC16IS752; SC16IS762 to my boss and he was interested in the chip, but for other projects with fewer UART port requirements. Thank you for your help in this. Yes, it looks like the use of two programmable PIC32's would be required to achieve the results we want. After looking into the SC16IS752 I see that it has RS485, would you say that this chip can handle the full requirements of the RS485 protocol (distance)? By that I mean could it replace the functionality of the SN75175A? I do not see the drivers for SR485 in the datasheet of the SC16IS752. – Gareth T. Nov 06 '18 at 13:03
  • AFAIK the "RS485" support in that device is only to manage the RX/TX direction control on a half-duplex line. There are no line drivers/receivers included and you'd still need a 75175/MAX485/whatever. – brhans Nov 06 '18 at 15:43
2

You could use analogue switch ICs (analog multiplexers) to replace manual jumpers.

If you have 5 UART ports, you can multiplex 1 of those ports to 8 multiplexed UART ports. You need to use 8-channel switches, like DG4051E.

Chupacabras
  • 5,394
  • 2
  • 23
  • 50
  • Yes, I have looked into that already, but it requires a rediculous amount of Mux IC's to replace what I have done with the jumper based solution because there is also the RTS line as well as the TX and RX line. – Gareth T. Oct 30 '18 at 07:21
  • So, you need to switch 3 signal lines, and you have 5 UARTs. You do not need ridiculous amount of muxes. All you need is 3 chips and have one of those UART ports multiplexed (so you will have 4 UART ports + 8 multiplexed). So 3pcs. of 8-channel multiplexers, like DG4051E (randomly picked). – Chupacabras Oct 30 '18 at 07:48
  • Please see the edited question. – Gareth T. Oct 30 '18 at 09:44
  • 1
    @GarethT. You have dramatically changed requirements in your question. You did not mention you want simultaneously use any combination of UARTs at the same time. – Chupacabras Oct 30 '18 at 13:05
  • Yes, that is why I apologized. Sorry. – Gareth T. Oct 30 '18 at 13:47
0

drive a SIPO shift register (eg. 74hc595) from 2 GPIO pins connect the ~OE input to the UART output

using the GPIO clock in a pattern that represents the device you want to talk to, then use the UART to send

if a pull up is in place the port with a zero bit will echo the UART output.

for the receive end use an and gate/gates to combine the signal from the device UARTS.

Jasen Слава Україні
  • 31,874
  • 1
  • 31
  • 65
0

I think you are using the wrong protocol and/or topology for your case. I would suggest using RS-485 transceivers and build a bus topology. If you have 11 possible devices, you can use 4 lines to enable one of them.

The caveats I see for this option are:

  • Half-duplex communication (No simultaneous Rx/Tx)
  • You can interact just with one device at a time (Bus topology)
  • Your uC will be like a master. It must enable a device and start communication with it. (transceivers are configured for write to or read from the bus)

I did not see any detail in your questions about how these limitations can affect your system or if it is worth at all. I hope this could help.

gustavovelascoh
  • 426
  • 3
  • 13
  • 3
    In a design from scratch, sure, though on the same board there is typically no need for RS485, it can all be done single ended at logic level using the output enables of the UARTs. But it sounds pretty strongly like the things the asker wants to talk to are already fixed designs, so changing their firmware to implemented an addressable shared bus probably isn't an option. – Chris Stratton Oct 30 '18 at 12:59
  • I'm not talking about addresses, just enable lines to each transceiver. This implies less firmware changes than trying an I2C bus- you just will need 1 uart in your host uC. – gustavovelascoh Oct 30 '18 at 13:16
  • If the main MCU is controlling the transceivers, then this is just an awkward way to build a mux. Skip the differential, skip the half duplex concern, and just follow the existing suggestions to build a mux. The point of actual RS485 is that the devices themselves listen for their address and pay attention to the following data or enable their transceiver afterwards to reply, and that the signaling is differential. Neither really fits your revised proposal for this application. – Chris Stratton Oct 30 '18 at 13:33
  • RS485 just defines an electrical interface, not addressing. For that reason, I suggest enable transceivers from the uC, as addressing indeed implies additional firmware. The only change you need is: instead of using UART X for device Y, enable Transceiver Y and use UART1. I see this option feasible as the OP stated: "I have a board that I would like to design..." – gustavovelascoh Oct 30 '18 at 14:02
  • Sure, but you persist in ignoring the obvious fact that doing it that way is pointlessly complex and more restrictive than using the multiplexors others already proposed. Your scheme offers no advantages over that, and many disadvantages compared to it. RS485 is only *useful* when used to do things that would not apply here. – Chris Stratton Oct 30 '18 at 14:08
  • As you can read in my post, I list 3 cons of using this, and just one answer suggests using analog mux and OP already reply to it. Advantages depend on what is valuable for you: UARTs used, pins used, PCB area, scalability, modularity, cost, hardware or firmware effort, etc. – gustavovelascoh Oct 30 '18 at 14:19
  • Exactly none of those factors give your overcomplex idea the advantage. What you are describing is logically a mux; but the way you efficiently build one is from mux or switch chips, not differential drivers and receivers. – Chris Stratton Oct 30 '18 at 14:20
  • Sure it is logically a mux, and that is the short answer to the OP question, he needs a mux. And for a mux, the limitations are the same that I described. I think more pros/cons coud be given with details as if the UART devices are able to start a communication, if more devices will be added, if it is planned to change topology, etc. as these details are not given by the OP. However, my main advice is intended to reconsider the topology if he/she has some control over how to interface with the devices and it is in design stage. – gustavovelascoh Oct 30 '18 at 14:40
0

As an alternative PSoC might help you

here is one example with 11 UART on a PSoC 5lp

https://hackaday.io/project/11974-averaging-many-gpses/log/39157-11-serial-ports-with-psoc5

aravind.h615
  • 1
  • Just a suggestion, check to be sure your system can handle the additional serial ports and the data that will have to be processed. I do not know how fast or how much data is passing through these and you may be just fine. – Gil Jul 08 '21 at 15:36