What is the best way to get 2 mainboards to talk to each other without having one board constantly waiting on communication from another board?
I am using a Cerbuino as the host and I need to put a Domino as an additional device which provides the host with information. Neither board has the time to wait on each other to be “ready” before a data frame can be sent as they both have their own work to do.
Serial?
@ Gus, I hate serial. Are there any other options?
an interrupt to start comms?
Why do you hate serial? It’s the most reliable way. And it doesn’t have to be “wait”. But defpends on your scenario whether it can or can’t work in a polled method.
is there any kind of mail box system where I can send a message to another uC which it can buffer and read when it’s ready?
Ok, let me expand my situation;
I want to connect the G120 module to the Cerbuino so that I can offload the time critical SPI tasks to the Cerbuino while the G120 continues communicating with the host. The Cerbuino also has the task of off decrypting the spi commands (optional) before sending them off down the bus. There is only a short window of time where the Cerbuino can communicate with other devices. I considered using the interrupt method to signal the G120 to start sending UART data to the Cerbuino; but the G120 has to drop everything and immediately send the data.
(indecisiveness is a hell of a thing)
You can make a small RLP function to register a RLP interrupt.
In that RLP interrupt handler you can send UART data to other board directly.
I think that this is not too hard to do (I think there is some RLP UART stuff in codeshare).
By this the G120 will definitely drop every thing else to send out the UAR message.
ok, call me what ever you like, but here’s the thing.
It seems to me that you need a tightly coupled system, because you have timing critical tasks that you are essentially delegating to another processor. And you’re looking at a signaling mechanism that allows you to instruct that processor to execute a delegated command.
So without knowing more about what is timing critical, here’s some options. (and if you’re serious about getting input you will need to elaborate more - is it the sequence of SPI command/s the “slave” needs to issue timing critical, or is the latency from when the master instructs the slave to execute it that’s timing critical, or is it the latency of when the last command “completes” to when the next needs to start ? I get the feeling it’s something to do with the slave needing the commands in time to issue the next when the "short window of time"is open, but really am not sure. And while it’s a dead horse, if the slave is just doing SPI have you considered if the DL40IO could be extended / used to handle this ?)
Use a “wide” data bus between the two, and an interrupt port on the slave to advise it when it needs to read the port. That helps you reduce the “length” of any storage / buffer you might need of whatever command you’re sending, but increases it’s “width”. You could use a latch IC in between the devices if you actually needed to store the state because you can’t control the latency. You’ll likely need a “command” structure to maximize use of the data bus you create, but really that’s not much different to serial except your unit of transfer is larger.
Use a bi-directional signaling scheme (much like RTS/CTS) to tell the other device when it needs to send / receive (depending on which way that is important, and which way it is driven from). This isn’t much different than using a UART except you’re telling the other device you need to be fed or it needs to listen now, and then letting the UART hardware do the transfer which it’s good at.
Have you considered using Ethernet?
Meaning that you could have each board be a server/client to each other spawned in separate threads. Master sends commands and does what it needs to do. Slave gets it and does it when it can. Then when complete sends command back to master who’s separate thread can read it and hold it until the main thread is ready to process.
Not really a “bus” per-se or tightly-coupled. Just completely separate units. I realize I don’t know how your G120 is set up, how easy ethernet is on each device or as @ Brett says what is timing critical but just an idea. I have done this in the past and it saves a lot of headaches.
Then again, I could be completely off-base hence why I am still a Junior… 
Ethernet would introduce too much latency, cost and complexity.
(Looks like I’m stuck with serial hey Gus)
@ Reinhard, So an RLP interrupt causes the uC to drop everything and handle that task immediately; that could work.
@ Bret, yes you got it: is it the sequence of SPI command/s the “slave” needs to issue and is it the latency of when the last command “completes” to when the next needs to start. The steppers (L6470s) must not be idle too long before they get sent their next command. With the Cerbuino (STM32F405) running the whole show it has to handle wifi data, calculate the next command and send the commands (as well as logging and other items). By the time the thread executing the SPI commands gets back to sending commands the motors have been stopped for too long in my opinion. The speed is more noticeable when a debug version of the code is deployed vs a release version.
Now that I have to add control of a heater and the monitoring of a 3D Mouse to the list of tasks it would be much better to offload the Mouse, communications and calculations to a G120 (and also having in field updates over SSL would save me a lot of headaches)
I’ve also been looking at CAN bus, however I’ve never used it.
Yes, RLP Interrupts are real Hardware Interrupts.
And as Long as RLP code is executed, the managed scheduler is stopped, so no managed code is executed during that time.
Knowing this, your RLP methods and Interrupt handlers should be only short running.
But any other Hardware Interrupt (set by any other driver included in Firmware) might still Interrupt your interrupt handler, if it has an higher priority.
So can I set the RLP interrupt to have the highest priority?
So, I just got caught up with the changes to the Cerb family; they are now closed source.
This implies real RLP right? If so then I couldn’t I implement an RLP interupt to send data to the L6470 modules when they ask?
The L6470 has a feature in that it raises it’s busy pin (active low) when it is performing calculations and can’t be disturbed. It does this when it’s Accelerating and Decelerating the motor. I didn’t know that the RLP interrupts were so fast (I really need to RTDM).
The L6470’s are daisy chained btw so all of them share the same busy and flag pins.