Hotplugging UART

[player80]

Hi,

I have a system with around 90 clients those 90 clients should connect via UART to the main system and be hotpluggable.
The cables from the clients (from the controller to the main system is around 20cm).
On the terminal I thought about using optocouplers before passing the signal into an FPGA.
Each of the 90 clients also has his own slot, and the fpga / arm system should detect which slot is occupied (the ARM should query the FPGA via SPI/I2C, I have done SPI/I2C cores earlier already)
The frontend software on the other side can just query the fpga which positions are occupied.
(I thought about a serial protocol first but I need the position information).

Can anyone comment if this is viable/practically?

 

[barry]

Are you planning on having 90 separate UART channels? What hardware, RS-485, RS-422?

 

[player80]

I directly plan to use UART at 3.3v (not RS-485) the distance is relatively small (below 50cm I'd say); and cut in the middle via optocoupler; also the speed can be very slow I just want to read / write a few values.
There should be some hardware based handshake in the FPGA and the microcontroller will just read the map from the FPGA. I thought about using a few TQFP144 FPGAs (eg. some ice40 part). The FPGA itself might be connected via SPI/I2C or even RS-485 to the ARM (probably just last one because the distance will be longer).
As mentioned I want to maintain the position information, that's why I can't use a serial approach (which certainly would be easier).
And the negotiation should happen immediately on all ports at the same time when the machine is powered on.

The main question for me is if this kind of hot-plugging is viable using optocouplers.

 

[KlausST]

Hi,

In post#1 you talk about 90 clients ... all within 20cm. I can't imagine how this can be.
Just to clarify:
* with "slot" you mean "connector" ... and not a "time slot" in the bus protocol?
* I don't understand why you consider to use optocouplers. Please explain.
* with "distance longer", "very slow" and "few bytes" only you have a clue ... but we need values with units to find a suitable solution.
* hardware based handshake: how many signal lines to each client?
* if microcontroller (=ARM?) is not involved in the UART problem, please put it aside for now. Let's focus on the UART.
* why UART at all? Why not SPI, since you seem to have experience with it.
* I don't understand what "position" means.
* You talk about "position" and "protocol". Why do you think both don't fit? For me this are two independent things.
* "immedate" again is a vague or even impossible description. It leaves no (zero) room for a delay. Not even a picosecond.
* I don't understand what "hot plug" has to do with "optocouplers". Please explain.
* still missing information: do you expect the FPGA to handle 90 independent UART (HW) channels?

As always: a picture says more than a lot of words.

If you want to find a solution: you should give us your true (unfiltered) requirements. (Requirements are: count, timing, data rate, cable length..)
In opposite there are solutions: (optocoupler..for example is a part of a solution)
It's unclear whether "UART" is a clear requirement (must) or just your idea for a solution (can). The same is for: hardware handshake, "immediately", TTL3.3V, isolation / optocoupler, ......

Please focus on what "must" be. At least for the first step.

Klaus

 

[player80]

thank you for your questions Klaus, I'll try to answer your questions.

* with "slot" you mean "connector" ... and not a "time slot" in the bus protocol?

yes I mean physical slot -- not time slot.

* I don't understand why you consider to use optocouplers. Please explain.

for hotplugging considerations to protect the FPGA pins. The slave devices can be added or removed during runtime.

* with "distance longer", "very slow" and "few bytes" only you have a clue ... but we need values with units to find a suitable solution.

as mentioned the entire connection can be considered less than 50cm (and I intend to split this in half // adding optocouplers in between).
With slow I mean the rise time of the signal isn't a time critical factor.

* hardware based handshake: how many signal lines to each client?

the handshake should set a value in a map that a slot/port is occupied. The microcontroller will query the FPGA which slots are occupied.
However I do not want to query every single slot about the status, the FPGA should maintain a list/map which ports are occupied.

* if microcontroller (=ARM?) is not involved in the UART problem, please put it aside for now. Let's focus on the UART.
* why UART at all? Why not SPI, since you seem to have experience with it.

this is due to practical reasons, the clients are programmed via uart interface, I want to use the same pin interface for connecting to the
FPGA.
The cable will have following pins to the slave microcontroller:
RX/TX/GND/3.3V
the protocol ontop of uart is simple.

FPGA <-> OPTOCOUPLER <-> SLAVE Controllers.

* I don't understand what "position" means.

I have like 90 slots (physically), I want to know which slot exactly is occupied.

* You talk about "position" and "protocol". Why do you think both don't fit? For me this are two independent things.

once I plug in the extension board on eg. slot 45, it should start to build up a communication with the FPGA and register slot 45 as occupied.

* "immedate" again is a vague or even impossible description. It leaves no (zero) room for a delay. Not even a picosecond.
* I don't understand what "hot plug" has to do with "optocouplers". Please explain.

I intend to place the optocouplers to protect the IO ports of the FPGA and slave devices.

* still missing information: do you expect the FPGA to handle 90 independent UART (HW) channels?

yes 90 independent UART channels.

 

[betwixt]

Squeezing 90 physical connection in 50cm of wiring is a challenge in itself!

I'm just as confused as the others trying to help and I agree a diagram would be a great help.

Do these 90 UARTs have to work simultaneously or can they be multiplexed so that only one or small group from the whole operate at the same time? My thinking is that even if you implement 90 UARTS on an FPGA, which would be a difficult task alone, you still have to get the information to and from those UARTS in real time. Somewhere along the data path you are going to need a routing mechanism to connect source to destination and the optimal solution would involve putting that routing at the optimal point.

Brian.

 

[KlausST]

Hi,

Optocoupler is an "isolating" part, not a "protection" part. If you don't need isolation, then don't use optocouplers. There are simpler, cheaper and more fail safe solutions.

Again: give values instead of vague descriptions like "slow"...

I asked to not involve the "microcontroller" into the discussion as long as it is not part of the UART communication. Thus I understand that the microcontroller is part of the UART communication. Please explain how.

Handshake: why HW is a requirement? Why not using the protocol?

Cable: if it has only the 4 mentioned signals, then there is no room for hardware handshake. please explain.

90 independent UART channels. Wow, a lot of effort in wiring and FPGA programming. Why no "bus"? Why no MUX?

Please focus on the true requirements = "must have"

Klaus

 

[player80]

Slow = smaller 9600baud

> Do these 90 UARTs have to work simultaneously or can they be multiplexed so that only one or small group from the whole operate at the same time?

during the registration / startup phase they will talk simultaneously, afterwards it can be serialized.
The startup phase should build up a register map in the FPGA, so the ARM / PC on the other side can check which slot is occupied.

> Squeezing 90 physical connection in 50cm of wiring is a challenge in itself!

there will be 90 cables / one cable for each slot.

> Optocoupler is an "isolating" part, not a "protection" part.

hmm, certainly an optocoupler is a protecting part, and PC817C optocouplers aren't expensive either.
In case something's going wrong on a slave module it won't damage the FPGA on the other side.
I think about splitting the FPGA into 2 banks so 45 UARTs per FPGA.

Also as mentioned I want the system to support hotplug without damaging anything.
I don't want to use a serial bus system because I want to know the location of each module.

I think about implementing the handshake in the FPGA to retrieve the information which module is connected to which slot before querying the FPGA via the main system.

But I'm still grateful about any discussion about it, serial bus vs direct connect is definitely a topic (but my choice is set to one dedicated channel to every module slot).

The amount of uart channels in the fpga itself is more a question for the synthesis program rather than how to implement it.
just instantiate one channel as many times as it would fit into it and wire it up with the pins. 9600 baud (including oversampling) is not fast for an FPGA, so it shouldn't be difficult for the synthesis tool.

 

[FvM]

Although there are surely other options, I'd fully agree to the above conclusions. An UART channel in FPGA is in the order of 100 logic elements, thus no problem to implement 90 channels in a relative small FPGA. It's just a generate statement to instantiate the channels.

 

[barry]

More and more confusing: “during the registration / startup phase they will talk simultaneously, afterwards it can be serialized.” How do you propose to have 90 channels in parallel and then miraculously put them all in serial?

 

[player80]

More and more confusing: “during the registration / startup phase they will talk simultaneously, afterwards it can be serialized.” How do you propose to have 90 channels in parallel and then miraculously put them all in serial?

Every module (which themselves are equipped with microcontrollers) will have an identifier, they will start to talk with the FPGA during startup.
The FPGA itself maintains a module port map.

 

[KlausST]

Hi,

90 individual UARTs with handshake (one direction just to tell availability) means at least 270 wires to the FPGA.
While surely possible ... I´d say this is overkill for a low datarate project.


How I´d do it:
* I´d build a matrix board with 8 rows and 12 columns.
* 8 Rows are selected with R0..R7
* 12 Columns are selected with C0..C11

Each slave connector has: VCC, GND, Tx, Rx, Cn, Rn, A (Tx and Rx seen form master)

On the matrix board all Tx could be connected, the same for Rx, an A. A as well as Rx should get a pull up.
(but to improve capacitance effects I´d spend a Tx buffer , a Rx buffer and an A buffer for each row)

On each slave:
There is an Rn input and an Cn input.
If both are HIGH (AND) then
* it drives a BJT to pull A LOW (for the host to detect presence)
* it enables the uC_Tx Buffer (3 state) (so only one Slave_tx is actve per time) uC_Tx_buffe_output is connected with Master_Rx
* it also drives an "slave select" signal to the microcontroller

I see no promblem for using 100kBaud.

With this .. a fast "scan" can tell you which slave is available. Could be done within 1 ms.
Also wiring is rather simple.
Flexible for baudrate.

****
So the minimum wiring to the FPGA is:
* 3 lines for Row (binary coded)
* 4 lines for column (binary coded)
* one Tx
* one Rx
* one A
--> 10 wires in total.

**
If you want more flexibility and speed you may route
* 4 colum lines biniry codes
* 8 row lines 12 column lines individually
* 8 Tx lines (one per row)
* 8 Rx lines (one per row)
* 8 A lines (one per row)
36 lines in total
.. with 8 times speed. (8 slaves acessed by the same time)
(while still having the possiblitiy for single access)

Klaus

 

[andre_luis]

In case something's going wrong on a slave module it won't damage the FPGA on the other side.

Once you have mentioned the hotpluggable opperation and electrical level being in the LVTTL range, you mingh be aware that in general RS-485 connectors are made in such a way that the body is first connected yielding signal shielding in some extent. I would bet due to space restrictions you'll not use e.g 90x standard DB-9 connectors, so this should be considered on selecting the connector itself.

 

[barry]

Connecting the FPGA directly to the outside world is never a good idea; receiver and driver ICs are generally used. There’s nothing wrong with using opto isolators , but I’m not sure I see the need.

But as Klaus, and everybody else, has alluded to, your 90 individual channels is just insane. An RS-485 driver can handle 32 loads. So, with 3 channels you can handle all 90 nodes.

 

[player80]

I will divide the channels into 2 parts so it will be around 45 and I'm going to use 2 FPGAs.
Overall from what I read here is that using the optocouplers seems to be okay with that.
I don't think it's crazy first of all it's on a PCB and second of all every module needs some work anyway (serialized or non serialized).
Certainly the better way would be to use a single channel per module (RX+TX together within one wire), but since I'm just re-using the uart ports I will have
those 90 signals per fpga now.
Also the PC817C optos (which are the faster ones of that series) are very cheap

 

[barry]

Two FPGAs?!!! Why?

You are stubbornly refusing to listen to common sense. Why use 270 opto isolators when you can use 3 RX485 transcievers?

 

[player80]

I think you did not read my requirements, I want to know the location of every module, eg. which slot is occupied. For 90 uarts I need 180 optocouplers.
Also I don't see that it's much of a challenge to make that. If I position the FPGA in the middle it's like 45 traces on the left and 45 traces on the right side, not too many.
in case of the RS485 transceivers they wouldn't have any protection either, so the requirement of the optocouplers is still there in any case. The output of the single modules is and will be UART (since I'm re-using the programming ports).

 

[KlausST]

Hi,

in case of the RS485 transceivers they wouldn't have any protection either,

which datasheet exactly did you read to say so?
I´d say most RS485 IC have built in ESD protection.

Before you said you need a hardware handshake. This is a third signal line per channel. Thus I see 270 signals to the FPGA and 270 optocouplers..

Klaus

 

[player80]

The modules themselves still output UART only, I would not want to add a rs485 transceiver module to every module.
It's fine I'll just go the way I had in mind before.
I plan to do the handshake via the uart protocol once the modules have enough power they can send a registration command to the FPGA (which will not be forwarded to the main processing unit, but the main processing unit can query the fpga and check a register map which slots are occupied).

 

[KlausST]

Hi,

I guess we never had the chance to help you... did we?

Klaus