I'm thinking about making a simple address-free serial protocol, using serial connections, instead of a bus.

In my application, the controller always sends data to each node in sequence. It never skips a node, or messages them out of order.

Using only simple logic chips and latches (no uC), how to get a node to latch first command it receives, and pass through all others?

1. Controller sends Node 1 command directly to Node 1.
2. Node 1 send confirmation back to controller (i might eliminate the ACK's).
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 (unless i eliminate the ACK's)
4. etc

A command is one four-bit number.

 

Assuming you get it working like you describe, how would the controller ever pass a second message in the future to Node 1?

 

Here's an idea: a 4-bit SPDT switch.

In waiting position it sends data to its own latch. In pass-through position, it sends the data to the next node.

How to get the SPDT to switch at the right time?
It should switch to pass-through after it sends confirmation back to the controller (or, if i eliminate the ACK, then immediately on receiving the first command).
And switch back to waiting mode when it receives a reset signal from the controller.

In my application, the controller always sends data to each node in sequence. It never skips a node, or messages them out of order.

 

Here's an idea: a 4-bit SPDT switch.

In waiting position it sends data to its own latch. In pass-through position, it sends the data to the next node.

How to get the SPDT to switch at the right time?
It should switch to pass-through when the latch is set.
And switch back to waiting mode when it receives a reset signal from the controller.

In my application, the controller always sends data to each node in sequence. It never skips a node, or messages them out of order.

Is the format of the data rigid? For instance, each message is exactly N bits long? Is the acknowledgement you mentioned being sent on the same line, or a separate line? Is the controller producing the sole clock in the communications stream?

A number of devils in the details that will make things either easier or harder.

 

each message is exactly N bits long?

Yes, 4 bit.

acknowledgement you mentioned being sent on the same line

Yes, same line. I might be able to eliminate the ACK.

controller producing the sole clock

Yes, or no clock.

 

The individually addressable RGB(W) LEDs like the WS28nn type use a strategy where the program needs to know how many LEDs are in the string, and to address a particular LED data is sent 24 bits per LED, each LED consuming the first 24 bits it sees and then becoming a passthrough.

So, the first 24 bit message is consumed by LED 1, then it becomes transparent to the data and LED 2 hears bits for the first time and it consumes bits 25-48, passing anything further through after that. LED 3's first visible bit is 49, and it consumes that plus the rest up to 72—and so forth until LED n as specified in the program.

Once the data stops, the next transmission will start the process over again.

 

The individually addressable RGB(W) LEDs like the WS28nn type use a strategy where the program needs to know how many LEDs are in the string, and to address a particular LED data is sent 24 bits per LED, each LED consuming the first 24 bits it sees and then becoming a passthrough.

I wonder how they do the passthrough. I guessing they use a uC on each LED. My protocol is simpler, as there's no addressing.

 

I wonder how they do the passthrough. I guessing they use a uC on each LED. My protocol is simpler, as there's no addressing.

There is no addressing in this case either, though they do use a small MCU in each. But you should be able to use a shift register to consume 4 bits and then put the next ones on the bus for whichever device is electrically next.

Frankly, something like an ATTiny13A—a single 8-pin package in either DIP or SMD packages—would make things completely flexible and require only a bypass capacitor to be a complete setup.

I am not sure why you are working so hard to avoid an MCU, so I can't really help too much. Maybe you can explain the actual problem you are trying to solve? What is the application?

 

shift register to consume 4 bits and then put the next ones on the bus

Ah, shift register! How?

ATTiny13A—a single 8-pin package in either DIP or SMD packages—would make things completely flexible and require only a bypass capacitor to be a complete setup.

Yes, that's my current plan, if i can't solve it without uC.

I am not sure why you are working so hard to avoid an MCU

I'm trying to reduce per-node cost. The cheapest uC's i can find are about $0.50.

If i can do it with 3 simpler chips costing $0.15 total, plus eliminate programming tasks, that would cool. At 100 nodes, that's a saving of $35. But as i said, my current plan is a uC.

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

The steps i'm seeing at the moment are:

1. SPDT
2. Shift register
3. Latch

 

If the bits are stored in four registers, the next bit can be an overflow signaling the time to pass the bits on the shared bus. Your messages can be four data bits and an EOD bit, so five bits per node. The fifth bit is the instruction to connect to the bus. You could shift in the command in reverse order with a 1 always being the first bit sent and so the first but to shift out of the four bits meant as a command to the node. When the 1 shifts out, it turns on the latch that bypasses the shift register and puts the bits onto the bus. The next node does the same thing.

 

If the bits are stored in four registers, the next bit can be an overflow signaling the time to pass the bits on the shared bus. Your messages can be four data bits and an EOD bit, so five bits per node. The fifth bit is the instruction to connect to the bus. You could shift in the command in reverse order with a 1 always being the first bit sent and so the first but to shift out of the four bits meant as a command to the node. When the 1 shifts out, it turns on the latch that bypasses the shift register and puts the bits onto the bus. The next node does the same thing.

You said "bus". So, not serial connections between nodes? Then the downstream nodes will hear all commands.
Would your scheme work without the SPDT switch? Just need shift register and latch?

Assuming you get it working like you describe, how would the controller ever pass a second message in the future to Node 1?

Excellent question. When the last node is reached, then all nodes will be in pass-through mode. The controller would send some sort of reset to flip them all back to receive mode. Maybe it could be a reset signal to the SPDT. All nodes should see it.

I think passthrough mode doesn't mean the node can't see commands -- it just means the SPDT isn't sending the data into the latch.

 

It is a series connection but the active node consumes the bits of its command making the following nodes effectively disconnected, and the pervious nodes are effectively wire since they've been set and are not listening.

The shift register is a way to store bits for your command, and to count bits to know when to pass on the bit stream.

The latch is just an SPST switch activated by the fifth bit.

 

The latch is just an SPST switch activated by the fifth bit.

This is very interesting. Do you mean SPDT?
Can you say more about that? thx!

 

It really only needs to connect the bus (D+ and D-, where D- can be left connected or shared with 0V as common). So one wire, D+ needs to be disconnected from the rest of the bus until the active node has collected a command.

 

D+ needs to be disconnected from the rest of the bus until the active node has collected a command.

I think that's a SPDT. Position 1 connects upstream data to the latch. Position 2 connects upstream data to the downstream node. Correct?

 

I'm thinking about making a simple address-free serial protocol, using serial connections, instead of a bus.

In my application, the controller always sends data to each node in sequence. It never skips a node, or messages them out of order.

Using only simple logic chips and latches (no uC), how to get a node to latch first command it receives, and pass through all others?

1. Controller sends Node 1 command directly to Node 1.
2. Node 1 send confirmation back to controller (i might eliminate the ACK's).
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 (unless i eliminate the ACK's)
4. etc

A command is one four-bit number.

Simple SPI daisy-chaining using shift-registers.
https://www.analog.com/en/technical-articles/daisychaining-spi-devices.html

 

I think that's a SPDT. Position 1 connects upstream data to the latch. Position 2 connects upstream data to the downstream node. Correct?

No. It's effectively one long wire that gets added to when a node is "full of bits". So it is either connected to the upstream, or it is not connected. The downstream connection is determined by the preceding node, not the current one. That's the SPST switch.

 

Simple SPI daisy-chaining using shift-registers.
https://www.analog.com/en/technical-articles/daisychaining-spi-devices.html

This describes a very closely related architecture to what I am talking about. You do have to have a mechanism to say "we are done with this round of commands". I would assume in your case it would be some sort of bus EN that is driven high to indicate active and low to say we are done. Next time it goes high the process would start from the beginning.

 

Curious if it would be useful to connect the end of the wire, after the last cell, back to the controller. It would still be a one-wire system, but then i think the controller could send a message in the opposite direction, up the wire from the bottom. Then maybe it could connect to the last node when all the other nodes are locked.

No, i don't think that would work. The wire is broken at every cell that's in listen mode. So a command sent to the end of the string wouldn't get pass the last node.

However there may be another benefit to connecting the end of the wire to the controller -- it will tell the controller when the last node has latched. When the last node latches, the controller's signal sent to the beginning of the wire will be heard at the end of the wire. If the controller can hear itself, it knows all the nodes are in latched mode.

 

Curious if it would be useful to connect the end of the wire, after the last cell, back to the controller. It would still be a one-wire system, but then i think the controller could send a message in the opposite direction, up the wire from the bottom. Then maybe it could connect to the last node when all the other nodes are locked.

Nope, KISS.