I could put a few controllers on an SPI bus using CS to address one to all, which is neat.
I was thinking about controllers daisy-chained like shift registers. Each would get a data stream off the one before and pass a data stream to the next though at/most times the data may be NULL and the chain may be circular.
Data could be addressed and passed on through (after any outgoing message is sent, per node) fairly quickly, flags and responses sent not passed on after use -- the serial traffic never mixing message contents.
What do the controllers do? I would hope, track and respond to the real world when 1 controller is not enough.
This is just about a way to connect them.
Consider non-blocking tasks written inside of loop(). This is like that for multi-processors, one after the other in the serial sense they pass data along rather than executing in sequence.
Please don't ask why or what it's for. Why are there compilers? What are they for?
Come to think of it, this might work with serial RX and TX.
Mmm, nothing sexier than some spi in daisy chains.
And that is all I have to add.
GoForSmoke:
I could put a few controllers on an SPI bus using CS to address one to all, which is neat.
I was thinking about controllers daisy-chained like shift registers. Each would get a data stream off the one before and pass a data stream to the next though at/most times the data may be NULL and the chain may be circular.
If the chain is circular you will have to give your data stream a 'time to live', else it will continue circulating for ever.
I might want "a trigger" to loop around until a task is done and the trigger would not get passed on.
If not looped, it could be a bit like command line pipes with the controllers running the commands.
"daisy chains"
its Spring here! Australia.
So why in the norther hemisphere, Fall or Autumn, did you start thinking of "daisy chains"?
Either you are not taking enough water with it.
OR
Like most of us, need our medication adjusted.
GoForSmoke:
I might want "a trigger" to loop around until a task is done and the trigger would not get passed on.
If not looped, it could be a bit like command line pipes with the controllers running the commands.
Sounds like Token Ring Topology.
travis_farmer:
what about a master controller, setup like a network switch? seems like it would be more efficient than a ring. maybe with some multiplexing/demultiplexing to handle the switching.
That's Star Topology.
See ya learned sumfink every day.
Those terms were new to me back in the 70's. And then there's all the ways they get applied, always something new.
Daisy chaining is what people do to shift registers on SPI, data out from one connects to data in on the next, etc, daisy chain.
We probably have different views here where the flowers don't have deadly spiders hiding under.
I'm also thinking that serial links might be better for this, no SPI clock to keep with but fast enough to be useful. At 115200 baud the rate is > 11000 chars/sec and the load is whatever is on all the wires, the trickle-through speed won't be great but doesn't have to be slow either, depending on what processing is done. Main advantages are flexibility and simplicity, any system has to be put in by the programmer so there's none to get in the way.
travis_farmer:
the copy of my "Serial ring" that i found was heavy on the use of the String object. i had a working version at some point that transferred bytes, but i can't find it.
essentially, it was a leading byte to identify the start of a block, a byte for the sender address, then the receiver address, followed by the data, and a terminator byte. it worked great, if all the Arduinos booted at the exact same time. i didn't have any error correction built in, or even a checksum.
though, in thinking now on it, i may revisit the idea, simply out of curiosity if i can improve it.
~Travis
Start by ditching the use of String and use char array instead. Arduino Serial has 64 byte input and output buffers already so you don't need to replicate those, just read and write to Serial but never let a buffer fill!
At 115200 baud you have 1388 cpu cycles between arriving chars. The more you can process your data char by char as it comes in, the faster the process will be done. It may be done before the next char arrives.
If you buffer then process, 'then' doesn't start until the last char arrives and there may be times when it has to be that way but I find it often is not.
I have a keyword match system that uses small code and RAM but could use a big chunk of flash if the keywords are long. It's fast enough to keep up with 250000 baud but it's a bit complicated to use, there's a sketch that takes a word list and generates Arduino source to make tables in flash for the new sketch that uses the match() function to parse text commands.
Still it shows that an Uno can read a serial char and trace down if it matches any of the choices in the list links and print debug text before the next char shows up in 40 microseconds (640 cpu cycles) --- my test pushed that hard btw --- it shows that you can do a good bit of processing in between serial arrivals if you put your head to it and do a bit of trial and error coding.
The whole thing seems beyond most people here. I could make something that stores the list and offsets in EEPROM but that would limit the list severely to 256 chars including null terminators. With short words, maybe 40 or so.
That is buffer then process, you need the end marker to verify the binary data message.
You don't need to shift the data bits. Store as an array of bytes then address it with int pointers.
Each node has to determine if a message applies to it and pass the message along if it applies to other nodes (a message addressed to all would do both). If the message applies to the node, the node needs to act on the message which may include sending another message along.
Serial (including SPI) has no guarantee that every byte gets through. However there is usually some baud rate that any connection will run "rock solid" and 10,000,000 chars tests shouldn't be hard to run until found hopefully > 28800.
I like text, it makes the data log easier to read. Text transmission errors generally produce non-text, easy to spot where with binary data it's all the same only different -- binary data needs CRC.