What is the part number of the device you call "peripheral" ?

 

Tho' i think my method (above) may use fewer bits.

Your method:
controller: 01, 00, 001, 110
(node address 01, command 00, first port 01, second port 10)

Or maybe you mean:
controller: 01, 001
controller: 01, 110
(node address 01, first port 01)
(node address 01, second port 10)

My method is positional. Also, it makes more sense for my application to combine them into one command.
controller: 01, 00, 01, 10
(node address 01, command 00, first port 01, second port 10)

Do you want to change the state of one port or both with a single command? To clarify, what I'm calling Port A and B are the two sets of outputs per peripheral.

Also, it may be easier to write your commands like this instead of encoding in binary:

1) I2C Controller sends command "p1_portA_outputA"

2) I2C Peripheral uses If - Then clauses on the string p1_portA_outputA to turn on the appropriate output.

 

For controlling a single port at a time with a 3 bit command:

1) I2C Controller sends command "011".

2) I2C Peripheral uses If - Then clause to look at first bit of 011. Its a zero so lets call it Port A.

3) I2C Peripheral uses If - Then clauses to look at the last two bits of 011. It's 11 so let's call it Output D.

 

p1_portA_outputA

I wouldn't create a separate variable for every output, because the number of nodes, and number of outputs, is unpredictable.

want to change the state of one port or both with a single command

both

Peripheral uses If - Then

For me, if..then's don't feel like the right fit for this project. Too procedural. A more direct translation from the binary to the outputs seems a better fit. A kind of state-machine, i think.

I wonder if a non-uC solution is possible.
Ignoring addressing for a moment, assume there's just one node. At the node:

1. 1st device at the node is simple serial to parallel
2. Next device is a dual demux, which turns on the two intended ports.
3. done

I don't need a uC for that!

 

i think i can eliminate addressing.

On every communication cycle, the controller is always talking to each node in sequence. The first command is for the first node, second command is for second node, etc.

That brings the issue of, how can a node know which command is meant for it, when it doesn't know how many nodes are in the network, and it doesn't know it's own position?

Possible solution: Serial connections, instead of a bus.

1. Controller sends Node 1 command directly to Node 1.
2. Node 1 send confirmation back. I may be able to eliminate the confirmations.
3. Controller sends Node 2 command to Node 1. Since Node 1 already received it's message, it passes the message down the wire to Node 2. It also passes Node 2's confirmation back up the wire to Controller
4. etc

So... how to get a node to latch first command it receives, and pass through all others? Hmm.

 

i think i can eliminate addressing.

On every communication cycle, the controller is always talking to each node in sequence. The first command is for the first node, second command is for second node, etc.

That brings the issue of, how can a node know which command is meant for it, when it doesn't know how many nodes are in the network, and it doesn't know it's own position?

Possible solution: Serial connections, instead of a bus.
View attachment 307443

1. Controller sends Node 1 command directly to Node 1.
2. Node 1 send confirmation back, and passes all remaining messages to Node 2. Node 1 ignores remaining messages.
3. Controller sends Node 2 command to Node 1. Since Node 1 already received it's message, it passes the message down the wire to Node 2. It also passes Node 2's confirmation back up the wire to Controller
4. etc

So... how to get a node to latch first command it receives, and pass through all others? Hmm.

This is a new problem but still requires sequential logic. The first post I made with the 2 to 4 Line Decoder is an example of a combinational logic circuit which can be defined as obeying a truth table.

Of course this can be done but as you pointed out above in the 4 bullet points, not only does the communication have to happen sequentially in time, each Node must know when the correct combinational control bits are asserted for them. This will require many decode logic circuits all over the place.

This is why I've been pushing an I2C solution. I2C is a user friendly communication scheme that does it own encoding / decoding. For the trouble you'd go through making a combinational solution with logic gates or writing your own UART scheme etc., simply coming up with a short list of I2C commands for each microcontroller is much easier.

I can help you consolidate your code in Arduino IDE or MicroPython. You also didn't discuss the nature of the control bits. Do you want the inputs to be physical switches or a command sent in your favorite language. Either way, I2C takes care of the transmission between devices.

 

This will require many decode logic circuits all over the place.

Maybe, maybe not. See https://forum.allaboutcircuits.com/threads/latch-and-ignore.197186

This is why I've been pushing an I2C solution.

I'd like to minimize wires, commands, and handshakes. I like the 1-wire protocol, but even that's too complex for my taste

Even if i decide to use uC, i think it's a very useful exercise to solve it with discrete devices. That forces me to simplify the steps and functional-blocks. Then, my uC code can model the same steps.