The system I described in part 2 needs to send a message from a module in device #2 to a module in device #5.
This tree is basically the physical address of a resource as seen from RPI1 and RPI2. But, as this address might change with wirings we need a more generic way to program this. The key in this case is that we use the module names are a “resource”.
32xIO and LedHat are both reported as resources in the system during startup. The 32xIO module will due to the “use LedHat” statement request a “LedHat” resource and be sent an address in return. This is part of Dynamic Resource Allocation in easyIPC – a topic we have yet to cover. With an address we need to map a message routing from device#2 to device#5 – this is called a stream in easyIPC. A stream is always 2-ways.
| 1 | The VM “32xIO” (Not the device) will initiate a DRA request. And as part of the request we assign a Stream ID on the device. |
| 2 | RPI1 decide to forward the request to RPI2 since this own a request of this type. |
| 3 | RPI2 will forward the request to the LedHat device using a managing stream id |
| 4 | The LedHat will allocate the resources and send a DRA Responce back with a selected stream ID. |
| 5 | RPI2 will set up it’s own Routing between this Stream ID’s and RPI1 and forward the response to RPI1 |
| 6 | RPI1 will set up its own Routing between the stream ID’s and forward the response to 32xIO. |
We have now set up a stream. Any message sent from 32xIO on that stream will be forwarded to the LedHat and wise versa.
DRA will also deal with re-allocating of resources and it is more details to it, but this illustrates how we will (1) report the modules as resources and (2) connect resource streams in easyIPC.
to be continued in part 4 …