You have multiple SPI slaves all on one bus - like all kind of sensors and control devices / servos / a like.
You think you need multiple processors / worker because of he work load all these slaves cause.
As a question: what is driving the work?
Timers - timers that trigger a process
to command a slave to do something, where determining what the slave has to do could take a lot of computing resources / time
to command the slave to respond and that the handling of the response could take a lot of computing resources / time
Interrupts from slaves (on separate lines)
that ask the master for communication with the slave for doing work similar as listed under Timers ... above.
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).
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@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.