Connecting peripheral controllers

[player80]

Hi,

I have developed some simple 8mm SMD Feeders, they're equipped with an ESP32 (the controller might change lateron, currently that seems to be the best available solution; and I'm not going to use wifi).
Now my plan is to have a fixed address for each feeder slot, the feeder bank will be controlled via FPGA and ethernet.
For interfacing the feeder bank I thought about adding a buffer ic between the FPGA and the external feeder.
The communication will be done with 3v3 uart (the cables are short ~20cm max). In a future version I plan to remove the cable and add a connector directly to the feeder, but that's subject of another revision.

Now I still have the question should I add another buffer IC on the feeder itself to isolate the microcontroller pins or would it be okay to leave it as it is?
My estimate is that those feeders might be swapped on/off around 2/3 times a day.

 

[barry]

i am definitely not a fan of directly connecting microcontroller (or FPGA) pins to the outside world, ESPECIALLY if you’re constantly connecting and disconnecting. You should also think about ESD protection.

 

[player80]

i am definitely not a fan of directly connecting microcontroller (or FPGA) pins to the outside world, ESPECIALLY if you’re constantly connecting and disconnecting. You should also think about ESD protection.

That's why I have the buffer in between. The main board only exposes the pins of the buffer.
However the external controller directly attaches to the buffer. I will see how it goes, I need to build some software for the first HW setup anyway afterwards I can still fine tune certain HW parts

 

[andre_luis]

those feeders might be swapped on/off around 2/3 times a day.

Hot swapped ? If so, connector kind matter a lot, as for example ensuring that GND is connected first. And, since boards are close each other this may be an overkill, but considering the low voltage level, wiring interleaving the signal between GND can help protect against certain types of electrical interference.

 

[KlausST]

Hi,

using "external buffers" does not necessarily result in better reliability. In detail it depends on the protection level of the buffers and the FPGA.
A simple 74HCxx "buffer" won´t be much improvement. The only benefit is that "in case" the cheap HC device needs to be replaced and not the FPGA. My customers surely are not happy with the "replacement" effort and the production loss.

--> I´d rather use a suitable protection than external buffers.

Klaus

 

[player80]

Hi,

using "external buffers" does not necessarily result in better reliability. In detail it depends on the protection level of the buffers and the FPGA.
A simple 74HCxx "buffer" won´t be much improvement. The only benefit is that "in case" the cheap HC device needs to be replaced and not the FPGA. My customers surely are not happy with the "replacement" effort and the production loss.

--> I´d rather use a suitable protection than external buffers.

Klaus

You got me, the 74HCxx buffer which I was looking at is supposed to have a little bit better drive strength than the fpga.
Which protection would you suggest? Some resistor / ESD clamping combo?
I still wouldn't feel well to expose the fpga pins directly.

--- Updated Nov 18, 2022 ---

Hot swapped ? If so, connector kind matter a lot, as for example ensuring that GND is connected first. And, since boards are close each other this may be an overkill, but considering the low voltage level, wiring interleaving the signal between GND can help protect against certain types of electrical interference.

thanks for reminding me... I was moreover looking for durable connectors and forgot that detail that one pin (gnd) at least has to be connected first. I'll check with the vendor tomorrow (hopefully he's available).

 

[KlausST]

Hi,

FPGA (input or output) <--> series resistor <--> clamping diodes <--> series resistor <--> connector

Now if there is an overvoltage pulse at the connector:
* the diodes limit the voltage (but maybe still higher than the FPGA specification)
* the connetor side resistor limits the current and needs to dissipate a lot of the pulse power
* the limited current also assists the diodes to to get overpowered, no internal overheat, limited voltage
* let´s say the voltage at the diodes is 8V (on a 3.3V system)
* now the FPGA side resistor limites the FPGA IO current.
* Lets say a 100 Ohms resistor will limit the IO current to about (8V - 3.3V - 0.5V in. protection diode) / 100 Ohms = 42mA .. which the FPGA should easily widthstand for a couple of milliseconds.

****
But part values depend a lot of your application.. How much current you need, what voltage levely you need, what pulse voltage and energy you expect, ...

We don´t know all this.

The connector side resistor should widthstand some overvoltage without arcing (no 0603 size) and needs to dissipate the pulse energy. So it is way more critical than the other. For power burst you may select carbon or dedicated burst proof resistors.

Klaus

 

[andre_luis]

forgot that detail that one pin (gnd) at least has to be connected first.

In the case you don't find any connector of this type available, at least routing GND as the first and the last net of the row, this can improve somehow. Most times people fasten the housing a bit tilted, anchoring in one of both sides.

 

[player80]

the vendor just told me they can change the conducting part of the female connector so one pin will connect first (that's what they usually do for customers).
Great so I have the ground part covered.
So finally I'll use a buffer and resistor/clamping diodes.

 

[FvM]

I don't dare to assess hot-plugging capability or suggest detailed protection circuits without hearing the whole story. I presume there's not only logic voltage level on the connector.

 

[player80]

I don't dare to assess hot-plugging capability or suggest detailed protection circuits without hearing the whole story. I presume there's not only logic voltage level on the connector.

I'm keeping it simple, I think I'll only have the 3.3V rail enabled when connecting the client, the 12V line might be activated once the 3.3v line has done some negotiation.
It's all low power, and there won't be a hugh inrush current at time when connecting the boards.
I'm still working on the software for it at the moment; I might get back when I fine tune the hardware connectivity.