With a main board and up to 8 sub-modules I need to design ipc communication between them. The sub-module uses a fast, exclusive serial port 1:1, but we also need to take into account Ethernet, RS485 and CAN as media. The essense of easyIPC is that I want a protocol where I don’t care about what media I use for transport. But’ lets focus on basic protocol design as I have drafted a standard IPC protocol.
The protocol is outlined in the BSA diagram below:
What I like most about BSA is that it make it simple to illustrate complex software and it clears you mind as it gives you a visual overview of what you want to design. What you see above is events, the core easyIPC protocol and funtions that are methods and events in C++. This show one interface as seen from a simple sub-module, so the full protocol is a bit more complex than this.
OnIPCMaintenance is a timer event generated every ms – it calls easyIPC and process timeout’s. Every time we send someting we start a timeout action and if ack is nor received we will take action. All events will either be Acked, Nacked or we execute timeout logic.
ipcInitRequest is sent to a module once it is started. Main will repeat the message until an InitResponse is received. The PLD diagram below illustrate the function. Once a request is answered we instantly report current state – if we are not ready we just report state, but once we are ready we send a full resource list as state is changed to started.
ipcInitResponse is sent to main as we receive InitRequest. The response indicate startup state of the module that will repond with Booting, Starting, Started or not at all. Some modules will require longer start-up times, so if InitRequest is sent to early we do not get a response at all – in this case we wait and send it again. Booting/Starting indicate the sub-module is awake and in the process of getting ready. A sub-module might have sub-devices of it’s own so Starting indicate it is waiting on other devices. Booting indicate it is waiting on itself. Once started the device will respond with a InitRequest that also contain a sub-tree of available resources. InitResponse is repeated every time a resource change.
ipcSubscriptionRequest is sent from main to sub-modul to get selected data/events sent to main. Each sub-module will always send ipcHeartBeat, but otherwise nothing unless requested.
ipcSubscriptionResponse is an Ack for ipcSubscriptionRequest.
ipcDataEvent is the normal way of sending data and events both ways. Data can be sent cyclic or as events then something happens. The essense is that bandwidth usage should be optimal once the system is started.
ipcDataEventAck is used to ack data that is not cyclic.
It might be more to the protocol later, but I will start with this and see what I end up with. I have sub-modules using the previous SWD, but they are so difficult t work with that I will wait until I get the next lot in 1,5 weeks. Ordering PCB’s these days are fast.
A key factor in IPC is that both ends have the same interface and a sub-module can interact with the tree and send data to both main and other sub-modules as well. Data transfer device to device will happen through main in this case – basically main subscribe on data from sub-module 1 while sub-module 2 subscribe on the same data from main/sub-module 1. As data is sent to main it will trigger an event that send the same data to modules subscribing on this. Care need to betaken for bandwidth and latency, but in normal usage we should expect low bandwidth and latency < 1ms.