Import OpenCyphal to QPC application.

[andrew frank]

Hi, Dr Samek
Background is:
I am trying to add the OpenCyphal framework to my QPC application. OpenCyphal is a universal protocol processing framework for drones. It uses dsdl to describe the data format and supports redundant transport processing. The framework provides three transport layer protocol libraries: can, udp, serial .
My purpose is to use active objects to complete Cyphal protocol processing, which provides a standard publish and subscribe interface for the application layer, and manages redundant transports automaticly (assuming that only isomorphic redundancy is considered, for example, three udp interfaces share one domain, two can interfaces share another domain, message priority sorting and redundancy removal are completed by OpenCyphal libs). The following architecture is considered:

When CyphalMger receives the sending signal from the application layer, it calls the cyphal library, encapsulates the datagram, and push it into the priority queue;
When CyphalMger receives the TX_COMPLETE signal provided by bsp, the data with the highest priority is taken out from the priority queue and sent out.

Now the question is:
In the pop_from_cyphal_queue_and_send process. The official sample program provided by OpenCyphal uses blocking mode to send by three channels (such as three socket fds), and sets a timeout to exit. However, the event-driven framework does not allow blocking mode and the status of the three devices may be asynchronous. Should I create a separate queue to be sent for each device and maintain the busy and idle status of each device? Can you give me some advice?

[Quantum Leaps]

Hi Andrew,
I'm not familiar with OpenCyphal , so it's hard for me to give authoritative advice.

Of course, you are right that blocking should NOT be used inside active objects. But, as you write, blocking is only used in the example application, so hopefully it is not embedded inside the OpenCyphal library. If this is the case, I hope you will find a way to avoid blocking.

Finally, if you have multiple identical "channels", you don't need to create a separate active object for each. Instead, one active object could manage all of them as "Orthogonal Components". The standard examples that ship with QP provide many insances of this. For example, take a look at the DPP-Comp example: <qpc|qpcpp>\examples\posix-win32\dpp_comp\.

--MMS

[andrew frank]

Thanks, I'll try both ways.