Open ArnePhotonics opened 8 years ago
Since this feature is used to allow a bus communication with different addresses, it should be considered to insert an address layer between rpc and channel_codec instead. This layer then must know where the package is intended to be sent to. To provide this information an address must be included in the remote procedure call and passed to the layer beneath for example by using the function RPC_TRANSMISSION_message_start. For staying compatible with old point to point protocols this feature can be enabled by configuration.
In case we introduce a flag in the configuration to switch between using an address layer and not using an address layer this flag should be documented in the xml and the other doc files.
Since as lower layer also something different than the channel codec and the address layer (maybe CAN, TCP/IP) can be used the address added to the remote procedure call should be something more generic than just a number. It should be possible for the user to define a struct which may contain the address information but can be also used e.g. for some kind of socket instance.
In case we use something typedefed info for providing lower layers with connection information: Still the following functions could be useful for server procedures: RPC_CancelRequest() //server wont send answer lowerlayerSocketINfo_t RPC_GetSourceConnectionInfo() //the server procedure can ask for request sources
it should be possible to name the lower layer by config. The name will be written then in xml file as metadata
Parsing a request which requires an answer looks now like this:
It would be great if the function mcuSetLEDStatus() would have the ability to suppress an answer. This could look like this:
This way it is possible to implement protocols running on busses using addresses. If an address doesnt match, this device simply doesnt answer. The address could be then a parameter of the called funtion.