0
\$\begingroup\$

I am working on a project in which multiple ATTINY's need to send numerical data between each other. In most cases the ATTINY will have to receive multiple streams of data on different pins. See the image below:

enter image description here

So in this case the ATTINY needs to receive data on the top right 3 pins at the same time. And needs to send data from the bottom pin to an other ATTINY.

I looked at doing this with the Software serial library but this doesn't support multiple pins and doesn't allow multiple pins to send and receive data at the same time.

So i heard that some sensors / modules have extra hardware to take care of the serial communication.

So my question is if it is possible to add this hardware to each pin so the chips can receive data on multiple pins at the same time. And what components should i use to accomplish this behaviour.

This is my first electronics project so please don't be to harsh. (I do have quite some coding experience).
If more information is required or if something is unclear let me know so I can clarify.

Thanks in advance!

\$\endgroup\$

closed as too broad by Chris Stratton, JYelton, hacktastical, Voltage Spike, RoyC Aug 9 at 14:17

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ The extra hardware to add would be extra UARTs and the way to do it would be to use instead a chip with them built in - perhaps an ARM part with as many as four. Or maybe something odd like the Parallax Propeller chip (if it's still available) which is sort of a collection of programmable interface processors. Or with a fast enough CPU and slow enough communication, you can do multiple software serial implementations, but not with the usual library. Can you re-design using a shared bus topology where nodes take turns talking? \$\endgroup\$ – Chris Stratton Mar 30 '18 at 16:04
  • \$\begingroup\$ Another idea would be an "only answer queries" approach where you blip one of those inputs to trigger the connected chip to talk, and only listen to that input then. This means that each chip needs to monitor its output for queries, and whichever input it most recently blipped. The query could be a single pulse detected by an interrupt, and you could give some time allowance for responding, so that is probably achievable. \$\endgroup\$ – Chris Stratton Mar 30 '18 at 16:06
  • \$\begingroup\$ If it is just receiving and the data rate is not too high I would go for three UARTs in software. (Not exactly trivial to write but do-able.) More important what are you trying to achieve? Only bouncing data around seems rather useless. \$\endgroup\$ – Oldfart Mar 30 '18 at 17:08
  • \$\begingroup\$ If it's just receiving data and the data rate is not too high I'd consider using a shared bus instead. \$\endgroup\$ – immibis Apr 6 '18 at 9:54
  • \$\begingroup\$ I'm voting to close this old abandoned question because it is too broad and generally impractical. In theory with extreme care at slow speed it could be done in software but realistically the entire scheme should be replaced with something more viable. \$\endgroup\$ – Chris Stratton Aug 7 at 15:40
1
\$\begingroup\$

You could do this with only software.

You would set up a timer interrupt to fire at least 4x the incoming bit rate.

On each fire, you sample all the input pins and do some edge detection and bit shifting into input buffers for each of the inputs.

You could then use the single hardware UART to send the data out, which is nice because you will want the output to be at least 3x faster than the inputs so it does not get overrun when combining the inputs into a single stream.

This is not too hard to code, but you do have to understand how software USARTs work.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.