@Robin, to understand your context:
As a question: what is driving the work?
Timers - timers that trigger a process
Interrupts from slaves (on separate lines)
All this sounds to me a bit fictitious... to say the least.
Solution could be to setup multiple MCs as masters of which each is controlling its own bus with the type and amount of slaves it can handle, and another MC - if needed - to oversee / coordinate / collect from these individual MCs on a high level.
Back to SPI: since SPI is by definition a Single-Master-Multi-Slave- BUS, trying to put more than one master on the bus is a mis-design - or wrong choice of communication vehicle: SPI is just not applicable for such needs.
If work as listed above has to be done and only one bus has to be used, the solution could be a single master that takes care of only the communication. This Communication MC has to work of a queue for talking to the slaves and then place the responses onto another or multiple other queues. The queues are fed from and served by multiple general or specific Worker MCs. Such setup needs queue arbiters to make sure that things don't get garbled and get done exactly once... (like in a system where processor(s) and DMAs are working all over the same (address and data) bus...).
Another solution is something likeCarrier-sense multiple access with collision detection ( CSMA/CD ) as was used early days of the ethernet (when coax was the shared medium).
Something like CSMA/CD can be implemented using I2C Multi-Master protocol - https://www.i2c-bus.org/multimaster/
May be you need to reveal a bit more concrete details about what your setup is all about.
© Espruino, powered by microcosm.
Report a problem