So i'm running into an issues where I can't get a DKM (Downloadable Kernel Module) to talk to a RTP (Real-Time Process). I have all the default transports enabled and i'm using the default QoS profiles for all of my data readers and writers. What's interesting is that i can do RTP to RTP, but not DKM to RTP. I know that the data is coming out of the DKM because I can see it in DDS Spy running on a Windows PC outside of the system, and I know that the desitantion RTP can read it because I launch a dummy RTP to send the same topic and know that it receives it? The DKM project is using the standard VxWorks 6.9 libraries whereas the RTPs are using the RTP libraries. What am I missing?
OS: VxWorks 6.9
Hi:
What's happening is that because both the DKM and the RTP processes are on the same host, they are attempting to communicate via the shared memory transport, but because they are executing in separate memory spaces they do not share the same shared memory segment, and thus are unable to communicate.
You can get the processes to communicate over UDPv4 by disabling the shared memory transport. If you are using a USER_QOS_PROFILES.xml configuration file (which will be loaded if it is present in the current working directory) you can disable the shared memory transport by setting the transport_builtin property in the participant_qos section of the qos_profile.
Thanks for the reply. I'll give this a shot. I guess I was under the assumption that the DKM libraries would by default set up a shared memory region "under the hood" in order to enable DKM to RTP communication.
We've done some more research into this, and discovered that the problem with VxWorks systems communicating over shared memory between kernel mode and RTP mode process is that they are not properly coordinating the participant index. They ARE properly setting up the same shared memory segment, but the mechanism used to coordinate the parcipant indicies for the participants requires information that cannot be obtained betwee kernel and RTP mode processes. So automatic assignment of each participant's participant index is NOT occuring properly over shared memory between a kernel mode and an RTP mode process.
What this means is that the shared memory transport CAN be used to communicate between kernel mode and RTP mode process on VxWorks, as long as the particiapnt index for each particpant is assigned manually.
I apologize for the misinformation originally posted when I thought that the problem was with the assignment of the shared memory segment. I hope this update is of some use.