I am currently trying to figure out the best way on how to make data collected by slave microcontrollers available to a master controller.
The slaves each sample data from sensors currently at a rate of about 50kHz.
While I was trying to figure out the best way to send this data to the master using I2C or something along these lines, I started to wonder if it wouldn't be possible to use one "shared memory".
In other words each slave would have a specific memory space assigned on a shared memory where it would continuously update it's data.
The master could then read out all the collected data at real time without the need to synchronize and communicate directly with all the slaves.
Is such a setup possible let alone a good idea?
Thank you once again in advance for the help and guidance!
Have a great day,
Tom
All possible, you can buy dual-port RAMS (and even quad-port I think), but they are usually expensive.
You can DIY but something will have to sync the access, it can't be a free for all.
You could use a ATmega with external memory interface, but once again something has to arbitrate and as AVRs don't have any form of WAIT input I don't think hardware can do it.
One way may be for the master to provide an INT to the slaves one at a time, this tells them it's time to write.
To do this at hardware speeds you would need a LOT of octal buffers. You could do it all in software albiet with the very real chance of a major screw up if things go out of sync.
All in all I think it's more trouble than it's worth.
All the above refers to using parallel shared memory. It would be much simpler to implement something with say an SPI RAM chip. All uCs could be masters to the SPI but the master chip controls the slaves by dishing out interrupts to them.
It would need some more thought but once again it's hard to see that it's worth it.
PS there are also dual (and multi?) port serial RAM chips.
Possible, yes, a good idea, no. If you need such a structure, look into more performant platforms which have enough memory, proper management management, proper network interfaces and probably also more processing power. It will be cheaper in the end than a flock of Arduino talking to each other.
So you're talking about 32 bytes of data updated at every 20µs, giving you 1.25µs per 2 byte sample for processing or about 16 assembly commands sustained processing time. If you expect to do anything useful with that data meanwhile, I would say: Forget it. Get a faster processor for the master, one with a proper I/O-bus so you can read the data in one cycle.
The 50kHz so far is collecting samples only, no processing or sending data has been implemented.
So this will probably slow the entire system down a bit, but generally you are right.
What would a "proper I/O"bus be that could handle this be?
I guess I will start a new thread for this so shared memory topic won't be too much cluttered.
What I was saying is, that the Arduino is probably the wrong platform for the master. Better look into the ARM processors or small Intel boards running at higher clock rates which won't have so little margin to keep up with the data flow.
