Thank you for all the clarification. I think you're still overcomplicating things (it sounds like you could just let all 8 sensor complexes send data continuously, no problem, and only listen to each one in turn. The 7 others don't seem to care whether you're listening or not).
But if that's not the case, the usual solution is to have an actual bus where you can have multiple data streams, or packets, or whatever, transported in a non-conflicting manner.
Now, there's mature solutions to the problem of connecting 128 sensors to one controller – CAN bus comes to mind; it's meant for pretty much the use case of one electronic control unit query dozens to hundreds of sensors. It's robust as RS-485, because that's what it's been invented to replace, by the automotive industry. That would solve this all at once.
Alas, it seems you're stuck with a sensor model that plain can't do CAN; bummer.
Now, the usual solution to your problem "I need to interface a large number of nodes to a single controller" is still: give the controller a single, fast interface, with which it can talk to all the sensors, while these work autonomously. This helps a lot with your isolation problem: now you only need to isolate that single bus, instead of 8 (or 4 at reduced functionality).
So, here's how I approach it, given the info you've given in response to my previous answer:
- Use a simpler microcontroller that speaks, unisolatedly, to exactly one sensor array. A microcontroller with a single UART is easy and cheap to find – ST's STM32G0 low-cost series would totally do!
- Aside from attaching the sensor array to the UART side of the microcontroller, use its SPI peripheral on the other side: That allows you to exchange data at very high speeds, very low effort, and best of all: daisy-chained
- For simplicity's sake (you could do this in software, but why be complicated?), dedicate one input pin to be a "now read a command from the SPI buffer, and put your sensor data in the buffer".
The core idea here is that the communication with the continuously sending device (sensor array) can well be handled by a "simple" device, which becomes easy to develop and test, and that you then build a secondary arbitrarily extensible bus onto that, which in itself should also be easy. That way, you get "infinite" extensibility, at low component cost, and ease of isolation.
System as a whole would look like this:
┌──────┐ ┌──────┐ ┌──────┐
│Sensor│ │Sensor│ │Sensor│
│Array │ │Array │ │Array │
│ 1 │ │ 2 │ │ 8 │
└──┬───┘ └──┬───┘ └──┬───┘
│ │ │
┌──┴────┐ ┌──┴────┐ ┌──┴────┐
│ UART │ │ UART │ │ UART │
│ │ │ │ │ │
│ MCU │ │ MCU │ │ MCU │
│ │ 1 │ │ 2 │ │ 8 │
│ │ │ │ │ │ │
│ │ SPI │ │ SPI │ │ SPI │
┌──────────────────────┐ │ │ │ │ │ │ │
│Main Controller MOSI│──│──►│IN OUT│───►│IN OUT│───► … ─►│IN OUT│───┐
│ │ │ └clk trg┘ └clk trg┘ └clk trg┘ │
│ │ │ ▲ ▲ ▲ ▲ ▲ ▲ │
│ SCLK│──│────┴────│───────┴────│─────► … ───┘ │ │
│ │ │ │ │ │ │
│ trigger GPIO│──│─────────┴────────────┴─────► … ────────┘ │
│ │ │ │
│ MISO│◄─│──────────────────────────────────────────────┘
└──────────────────────┘ │
│
isolation boundary
Note that you can, no problem, instead of having 1 isolation barrier between the Main Controller and all MCUs, being a simple 4 optocouplers, have 8 isolation barriers instead, being isolated RS-485 transceivers (e.g., TI ISO3086), isolating each Sensor Array individually.
The communication would then look like this:
- Main controller sends out command (typically "give sensor value!") for MCU 8 by putting command in its SPI buffer, and telling its SPI interface to send 1 byte
- this causes the Main Controller's SPI peripheral to automatically toggle SCLK 8 times, sending one bit of the byte at each rising edge through its MOSI pin
- this byte is now in the SPI input buffer of MCU 1
- the MCUs' processors don't ever deal with the fact that something is happening on SPI. The "shift register logic" is all baked in hardware in a MCU's SPI peripheral!
- Main controller sends out command (typically "read sensor!") for MCU 7
- this shifts the contents of MCU 1's buffer into MCU 2's buffer, and puts the command for MCU 7 into MCU 1's buffer
- Main controller sends out command (typically "read sensor!") for MCU 6
- this shifts the content of MCU 2's buffer into MCU 3, the contents of MCU 1 into MCU 2, and the new command into MCU 1
- …
- Main controller sends out command (typically "read sensor!") for MCU 1
- now, every MCU has "its" command in its buffer
- Main controller pulls up the Trigger output
- In reaction to the Trigger getting pulled high, each of the 8 MCUs reads its SPI buffer. It interprets the command.
- typically, that command would instruct the microcontroller to put a reading received from its sensor array into the SPI buffer
- So, the microcontroller, which has been interfacing with its sensor array via UART all the time,
- After a while, the Main Controller sends 8 new commands. This time, however, it observes what gets put into its SPI buffer through the MISO pin
- the first byte comes from MCU 8, the second byte from MCU 7, and so on
- The Main Controller now has the values from all the Sensor Arrays, through a single interface
