- Can you show us a block diagram of how you envision the project’s components are to be connected.
That makes one wonder in what sort of order or time frame they need to arrive at the other end. If it's truly random then you could just sample the state every 2 mS and transmit them in parallel.
Maybe it's not clear: as fast as possible with RS232, even at 9600 baud. Basically, on one side, I need to obtain a "duplicate" of the logic states on the other side in the shortest possible time. Imagine that on one side I have 128 colored LEDs that change state rapidly (from on to off and vice versa). Pretend they form an image. I need to replicate the same image on the other side. These days, we're used to 4K color images on thousands of pixels. Guys, we're talking about technology from the '60s and '70s. I don't think it's difficult to do this with an Arduino in 2026, even using RS232...
“Guys, we're talking about technology. . .”
Guys and gals,
Realize that this will be a "snapshot" and will not represent the "look" of the original.
Then study the limits of RS-232 and the reason for the limits. The drivers cannot charge and reverse the charge on the wires fast enough for the speed you need.
The block diagram is simply, on one side, a block with 128 bare inputs that scans their logic state, say, 500 times per second, with some multiplexed ICs, and the Arduino inside encapsulates everything in RS232, outputting it on 2 wires + ground (3 wires total).
On the other side, there's another block with another Arduino (and various demultiplexers) that outputs everything on the correct lines, say, numbered from 1 to 128.
Yes, please.
Yes, do that.
I think 16 74HC573 octal latches would do the trick for the transmit end. On the receive end you can reconstruct the data with 16 74HC574s. You can use 574s for everything as they are essentially the same.
It would be convenient to use a Mega since it has a totally free 8 bit port and enough GPIO lines to control all the latches.
Sorry about the confusion, I'm multiplexing a highly technical discussion with a three year old at the moment.
So, just to explain better. I'll post a circuit from the 1980s here that does exactly this function, except it does it on 12-16 input lines and transmits at a speed of 300 baud in one direction only. On the other side, you obviously need something that reconstructs the logic states of the 16 starting lines from the two TXD and RXD wires. In the diagram, the input lines are 12 to 15 with multiplexing induced on 16, 17, and 18 (perhaps even 19).
Everything outputs to pin 25 of the AY-3-1015D, which is a very underutilized UART because, in addition to having double the inputs (pins 26 to 33, so DB1...DB8), it also has an internal receiver that performs the opposite function for duplex operation, so in both directions (pins 5 to 12, so RD1...RD8, which reconstruct the starting logic states).
Obviously, I can't use this old thing because, in addition to being made with obsolete components, it doesn't have enough inputs and is too slow, but, I repeat, we're talking about technology from the '80s. I can't imagine that now, in 2026, we can't do much better with Arduino...
There is also this UART from the 90s that seems to have 24 or 40 inputs on its own and I could get to 120 inputs with 3 of them but with Arduino you can certainly have a very different power, minimal consumption and greater simplicity of construction
ST16C654.PDF (912.5 KB)
Something like this but with 16 instead of 2.
On the Multiplex side, the inputs are clocked in simultaneously and read into the Arduino by sequentially enabling the tristate outputs via their individual OE. On the Demultiplex side the 8 bit values are clocked individually into their respective latches via the individual CP.
Build a record of 16 bytes + start byte + CRC on the Multiplex side and transmit. Reverse to Demultiplex.
It might be useful to tell us more of this project .
128 lines is a lot , you will get a lot of data arriving at the receiving end - what will you do with it ? .
if you have signals changing rapidly , how will they be synchronised ? Eg you read pin 1 just as it is about to switch to ‘0’ ( read ==1) and by the time you read pin 128 , pin 1 is now ‘0’ so your data then looks faulty (as your data for pin 1 is recorded as a ‘1’ , but you read pin 128 when 1is at state ‘0’) .
I would look to be looking at clocked in data points and some calculations made before sending “working ok” . Also say look at several points , if that reads good , read points somewhere else and check those etc
Do you really need 128 data points ???
If you use latches, you clock them all simultaneously so you have a "snapshot" of all 128 lines at that moment in time. Then you read the individual latch values in and construct a data record for transmission.
The details indicate a whole raft of support chips are needed!
Are you kidding, EmilyJane? No problem, in fact, I have to congratulate you because I think you're getting very close to the "solution" very quickly. I was thinking about the 74HC165 and 74HC595, but if you think the 573 and 574 are more suitable, I can try.
What hardware do you recommend, exactly?
I'll also need the libraries and code. I'm a bit inexperienced with the latter...
I recommend the 57x parts just because its I/O pins are arranged nicely for PCB/breadboard layout.
For that you'll need to move your topic to the paid consultancy section as this part of the forum caters to you doing the work and us doing the answering your questions and correcting your mistakes.
Yes, you're right, Paul_KD7HB, it's not a good idea. Maybe if we were still in those years...
Okay, fine. I'll do it.
By hardware, I meant which Arduino I should use? Can you recommend a powerful one?
I suggest the Mega2650 since it has whole 8 bit I/O ports that are not shared with anything else. It also has enough I/O for all the CP, OE lines you would need to do Mux/Demux on one board. On the other hand with a little clever hardware/software you might be able to cram it all onto a Uno or Nano. By using 74HC154 decode chips you can get 16 CP/OE lines with only 4 GPIO. Building the 8 bit word from noncontiguous I/O ports would just take a little extra code.
Edit:
Never mind on the Uno/Nano, not really practical.