Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Connect 32 serial lines to uC (eg. ESP32) over I2C or SPI?

Status
Not open for further replies.

harvie

Full Member level 1
Joined
Sep 10, 2014
Messages
98
Helped
2
Reputation
4
Reaction score
2
Trophy points
1,288
Location
Prague
Activity points
2,485
Hello,
i have approximately 32 Linux servers with 115200 baud serial console and i would like to connect all of them to single ESP32. While keeping things relatively scalable.
I know that first i have to convert the serial level to TTL using MAX232. Then i have to somehow manage all that lines.

Currently i am using raspberry PI with lots of USB serial converters and USB hubs, but it's kinda overkill, not very robust or reliable and far from being elegant. There are even solutions like https://freetserv.github.io/ , but i still want to stay clear of using such complex solution, because of reliability and security issues.

First i was thinking about using some multiplexer or analog switch IC to switch between individual RS232 lines, so i can connect any of the 32 lines to the hardware serial of ESP32. That would kinda work and i already like it more than raspberry solution, but can only use one line at time. (i don't usualy need to use all 32 lines at the same time, but more lines the better)

Now i am wondering if there's some UART transciever IC that would work over i2c (or SPI), so i can adress individual serial lines using i2c address and the IC would be able to buffer some of the data before i manage to read it. That way i could read one console, while not loosing the data from others. Even better if such IC would have more than one UART, so i don't have one IC per port.


Any ideas how to tackle this issue?
 

Either you need all 32 channels active at the same time, or you don't. You seem to be unsure about this. Personally, I'd probably just do this in an FPGA with 32 RS232->TTL converters. I'm not sure you can handle 32 UARTS simultaneously in a uC.
 

FPGA would be also my solution, lowest part count and probably cheapest. A flash based small FPGA like MAX10 has sufficient RAM to implement buffers for the serial channels.

You didn't yet mention the total data throughput, it decides about feasibility with a specific processor.
 

Thanks for cool tips with the FPGA! Sounds like interresting project. I've never designed with such chips and it seems to me there's bit of learning curve to overcome at the beginning... I totaly want to learn this, but it might take some time.

Idealy i am looking for something that will be easy to program with one of the FOSS toolchains available on Linux. But i don't really know what is the best solution for Open Hardware projects. I saw two toolchains. One is kactus2 and other one is yosys+nextpnr. Not sure if these are any good.

It would be also beneficial if i could use one of the chips pre-sourced in JLCSMT parts library, so they can do cheap PCBA for me:

https://jlcpcb.com/client/index.html#/parts/componentSearch?searchTxt=fpga

But i don't really know what to choose from there...
 

Well, maybe now is the perfect time to learn about FPGAs! There are megatons of information about FPGAs out there. Try one of the vendor sites (Xilinx, Altera(Intel), Lattice) for a starting point. Yes, there's a learning curve, but once you learn how to use FPGAs you'll never go back to uCs again!
 

Hi,

i am wondering if there's some UART transciever IC that would work over i2c (or SPI), so i can adress individual serial lines using i2c address a
For sure there are.
Just go to the distributor of your choice and do a search.

***
Your application is quite unusual. (And I asume there are better solutions)
Usually one has one bus .. and many slaves connected.... and some addressing scheme.

Or you may have 4 UARTS with 8 MUXed slaves each. or 8 x 4...

Also do a serach for: Modbus, multi drop bus, CAN bus, RS485 ... and so on


Klaus
 

Your application is quite unusual. (And I asume there are better solutions)
Usually one has one bus .. and many slaves connected.... and some addressing scheme.
Also do a serach for: Modbus, multi drop bus, CAN bus, RS485 ... and so on

Well... I am not designing the endpoints. These are given. I just need to aggregate them on single device. That's the way things are in computer world. Servers, routers and switches have serial ports. Not RS485, not modbus, not CAN, but plain old rs-232 VT100 serial. There's old saying that you got to p*ss with the c*ck you got. Of course nowadays all of these devices do have SSH, IPMI or webserver interface, but i am working on backup solution for cases when somebody screws the firewall settings or the internets get messed up somehow.
 

I don't think that terminal multiplexers are unusual.
 

It sounds like you are capturing the console logs for these devices. Is the console port the *only* place the text is stored?
At least on many servers there are log files that you can access, perhaps over a network.
This may or may not be feasible for the routers and switches you mention.
I'm just saying that you seem to be in a rut with your thinking about how you can capture the information.
Susan
 

Hi,

MUXing the ports will not work when the consoles send their informations without being asked.
You will loose informations.
For those systems you need as many UARTs as consoles (with built in FIFO)...

MUXing only will work on "request and reply" systems.

Klaus
 

The term "terminal multiplexer" is traditionally used for multi channel terminal input systems of mainframes and mini computers. "Multplexing" is a bit misleading in this regard, it does not mean time-multiplexing of the terminal RX line.
 

I think i will run daisy chained serial line through couple of uCs with at least 4 to10 times higher baudrate than the baudrate i need to handle at endpoints. I will inject some kind of custom packet headers to indicate which endpoint is origin/destination of the message. I guess that can be enough. Unless all terminals start flooding the terminal nonstop at the same time. Also i can add packet to indicate buffer overflow, so it does not go unnoticed. Also i can enable RX on individual daisychain nodes only when requested by master, so it does not slow down the daisychain if not needed.

This calls for cheap uC with lots of UART lines. At least 2 or idealy more.

Maybe i can replace the daisy chain with i2c or something, but i am not sure about speed and possible length of wiring...
 

ESP32 is not TTL compatible but the principle still applies. Is it feasible to configure the UARTs in 9-bit mode so they become addressable?

Brian.
 

Is it feasible to configure the UARTs in 9-bit mode so they become addressable?

Didn't knew about this possibility. I will surely look it up. I don't think it's possible on all the devices that i need to connect, but i might be able to use it to simplify my daisychaining protocol.
 

It’s sounding more and more like you should use an FPGA. What you’re proposing, daisy-chained uCs, 9bit UARTS, etc. just sounds like a nightmare to me, ESPECIALLY when you try to start debugging this tangled mess. The time you spend learning about FPGAs might be less than the time you spend debugging and weeping uncontrollably.
 

The time you spend learning about FPGAs might be less than the time you spend debugging and weeping uncontrollably.

Haha so true. I've already started looking. I like ICE40 and ECP5, they seem to have nice opensource toolchain available (yosys+nextpnr + icestorm or trellis).
https://www.youtube.com/watch?v=P-9WCFi0p-0
Looks to me much more likable than the traditional 5 or more GB proprietary IDE bullcr*p with enterprise licensing scheme.

But i am still not sure if this is economical solution for me... I would like whole thing to be somewhat scalable or daisychainable, so i can spread the daisychain across multiple datacenter racks and possibly add few more later... So having FPGA in each device might add to total cost. I will have to think about this...
 

i have approximately 32 Linux servers with 115200 baud serial console and i would like to connect all of them to single ESP32.

I think i will run daisy chained serial line through couple of uCs with at least 4 to10 times higher baudrate than the baudrate i need to handle at endpoints. I will inject some kind of custom packet headers to indicate which endpoint is origin/destination of the message. I guess that can be enough. Unless all terminals start flooding the terminal nonstop at the same time.
(…)
Maybe i can replace the daisy chain with i2c or something, but i am not sure about speed and possible length of wiring...
I think you started with a simple and straightforward concept and are moving to increasing soft- and hardware complexity. If the simple concept does it (star wired RS-232 lines, a single concentrator device), why implementing the complex one?

In case you want to implement the distributed solution for some reason, I2C or SPI don't seem appropriate. Both are inter-IC rather than inter-instrument busses, their original physical layer doesn't provide reliable interface over long cables. RS-485 which can work up to 10 or 20 MBPS, depending on the interface hardware, would be better suited.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top