Hi,
I was wondering if there was an electronic part that would allow me to connect a digital input (0/5V) to it and where I could basically daisy chain these parts together to read the current state of all digital inputs through a single line connected to a microcontroller.
Basically, it would be something reverse to a WS2812 LED where rather than receiving a sequence of bits, consuming the relevant bits to defined the outputs, and passing on the reduced number of bits to the next IC, I want to achieve something where each part in the line adds it’s current input state to the data and sends to the next in line. At the end I would want to read somewhere around 500-1000 inputs.
Does something like this exists?

i guess it could be down with the general shift registers, but I would prefer a single signal line and really only need on single input read per node.

 

A bunch of shift registers could do that, but they need control lines. Would that be a problem?

 

Yes. It is called 1-Wire.

https://en.wikipedia.org/wiki/1-Wire

 

There are a few protocols that do what you are talking about, in one fashion or another. SPI and JTAG come to mind.

Reading hundreds of inputs could prove to be challenging, especially without adding additional information to let the final receiver reliably separate out the data.

 

Thanks. It will keep search. It seems nobody here is aware of a low cost IC with such capability

 

How many bits of data per digital input, per data frame?

How many data frames per second are you needing?

 

If you want multiple senors, then each sensor needs a unique address.
You can do this over an RS-485 network.

 

If you want multiple senors, then each sensor needs a unique address.
You can do this over an RS-485 network.

That's one way of doing it, but there are others that do not require address assignments. With a thousand devices, the throughput is going to be severely limited. If address information needs to be sent along with each data packet, that can really trash it, especially if the data packets are small.

What the TS appears to be trying to get at is essentially a slotted communications channel, but since it is wired point-to-point in a daisy-chained fashion, it's a bit different.

One factor that could be key to designing the system is the length of the channel between furthest points. If this is short enough, there a variety of options exist. If it is long, then the options are considerably more limited.

Also at play is to what degree all of the nodes are in lock step. Perhaps the simplest scheme, using a point-to-point daisy-chained approach (though I'm not convinced that's best), is if the first device knows the rate at which it must send it's data packets. So it controls the data flow. Essentially, it sends a packet and then waits long enough for all of the nodes to send their packets before sending its next packet. It also always sends a packet, even if it has no data to report (assuming that is a possibility in the first place). The packet has both a start-of-frame and end-of-frame sequence (preamble and postamble) attached. Now each subsequent node has a pretty simple task. When it sees the preamble, it starts echoing the data to it's output (with a suitable buffering delay to allow it to insert it's data, either at the beginning or at the end, either way would work and has pros and cons). The encoding would need to deconflict the data with the preamble and postamble sequences, as well as provide enough edges to prevent framing errors, but that's pretty easy to deal with. One advantage to this is that, other than the first device, all of the other devices can be identical and pretty stupid. When they have data to send, they know they must remain silent until they receive data on their input, at which point they echo it and insert their data to the stream.

Another way would be to use a wired-logic approach in which all of the devices are attached to a single wire with a passive pull-up (or pull-down) and they each monitor the wire and add their data to it when it is their turn. The final receiver can initiate the start of transmission. With the proper protocol, each device adds its data to the bus in its assigned slot without having to transmit its address. But, each device has to have a unique address in order to know when its slot is.

Yet another way, which is demonstrated but very experimental, is to use a concurrent coding scheme in which each device simply encodes and transmits its data on the bus when it is ready, even if that means stomping on other transmissions going on at the same time. The receiver is able to still decode all of the transmissions, provided there aren't too many. Being able to superimpose a couple hundred packets has been demonstrated and accommodating a couple thousand would not be difficult. The big problem with this approach is that each node needs a bit more processing capability (not a lot) and access to sufficient memory to encode their packet. The receiver needs more memory to buffer the packet -- probably several megabytes.

 

That's one way of doing it, but there are others that do not require address assignments. With a thousand devices, the throughput is going to be severely limited. If address information needs to be sent along with each data packet, that can really trash it, especially if the data packets are small.

What the TS appears to be trying to get at is essentially a slotted communications channel, but since it is wired point-to-point in a daisy-chained fashion, it's a bit different.

One factor that could be key to designing the system is the length of the channel between furthest points. If this is short enough, there a variety of options exist. If it is long, then the options are considerably more limited.

Also at play is to what degree all of the nodes are in lock step. Perhaps the simplest scheme, using a point-to-point daisy-chained approach (though I'm not convinced that's best), is if the first device knows the rate at which it must send it's data packets. So it controls the data flow. Essentially, it sends a packet and then waits long enough for all of the nodes to send their packets before sending its next packet. It also always sends a packet, even if it has no data to report (assuming that is a possibility in the first place). The packet has both a start-of-frame and end-of-frame sequence (preamble and postamble) attached. Now each subsequent node has a pretty simple task. When it sees the preamble, it starts echoing the data to it's output (with a suitable buffering delay to allow it to insert it's data, either at the beginning or at the end, either way would work and has pros and cons). The encoding would need to deconflict the data with the preamble and postamble sequences, as well as provide enough edges to prevent framing errors, but that's pretty easy to deal with. One advantage to this is that, other than the first device, all of the other devices can be identical and pretty stupid. When they have data to send, they know they must remain silent until they receive data on their input, at which point they echo it and insert their data to the stream.

Another way would be to use a wired-logic approach in which all of the devices are attached to a single wire with a passive pull-up (or pull-down) and they each monitor the wire and add their data to it when it is their turn. The final receiver can initiate the start of transmission. With the proper protocol, each device adds its data to the bus in its assigned slot without having to transmit its address. But, each device has to have a unique address in order to know when its slot is.

Yet another way, which is demonstrated but very experimental, is to use a concurrent coding scheme in which each device simply encodes and transmits its data on the bus when it is ready, even if that means stomping on other transmissions going on at the same time. The receiver is able to still decode all of the transmissions, provided there aren't too many. Being able to superimpose a couple hundred packets has been demonstrated and accommodating a couple thousand would not be difficult. The big problem with this approach is that each node needs a bit more processing capability (not a lot) and access to sufficient memory to encode their packet. The receiver needs more memory to buffer the packet -- probably several megabytes.

thank you!
I really like your response.
There are some very valuable thoughts and maybe I need to consider using some very cheap microcontroller on each node (potentially something like the puya) which either receives in all the data from the previous nodes and simply adds it’s data (which really would only be a single bit depending on the state of the input) and sends this to the next. This would also improve transmission if the distance between each node is not so much but the total distance between the first and the last node is actually over 150 meters.

 

With SIPOs, you can daisy chain 'em together and read the current state of all those digital inputs using a single line connected to your microcontroller.

 

Thanks. It will keep search. It seems nobody here is aware of a low cost IC with such capability

As per above,
one wire
https://www.analog.com/en/product-category/1wire-devices.html

 

If you really wanted to get sophisticated, use a message based network like canbus or even Ethernet.

 

If you really wanted to get sophisticated, use a message based network like canbus or even Ethernet.

So much depends on information not given (even though it's been asked for).