Crystal-Photonics / RPC-Generator

Python script that generates code to call functions from one device on another using a network.
GNU Lesser General Public License v3.0
5 stars 3 forks source link

it should be possible to cancel rpc answer #19

Open ArnePhotonics opened 8 years ago

ArnePhotonics commented 8 years ago

Parsing a request which requires an answer looks now like this:

        /***Declarations***/
            uint16_t return_value_out[1];
            rpcLEDStatus_t ledStatus;

        /***Read input parameters***/

            /* reading enum type rpcLEDStatus_tledStatus of size 1 */
            {
                uint8_t temp;

                /* reading integral type uint8_t temp of size 1 */
                temp = *current++;

                ledStatus = temp;
            }
        /***Call function***/
            *return_value_out = mcuSetLEDStatus(ledStatus);
            /***send return value and output parameters***/
            RPC_TRANSMISSION_message_start(3);
            RPC_TRANSMISSION_message_push_byte(45);

            /* writing integral type uint16_t (*return_value_out) of size 2 */
            RPC_TRANSMISSION_message_push_byte((unsigned char)((*return_value_out)));
            RPC_TRANSMISSION_message_push_byte((unsigned char)((*return_value_out) >> 8));

            RPC_TRANSMISSION_message_commit();

It would be great if the function mcuSetLEDStatus() would have the ability to suppress an answer. This could look like this:

        /***Declarations***/
            uint16_t return_value_out[1];
            rpcLEDStatus_t ledStatus;

        /***Read input parameters***/

            /* reading enum type rpcLEDStatus_tledStatus of size 1 */
            {
                uint8_t temp;

                /* reading integral type uint8_t temp of size 1 */
                temp = *current++;

                ledStatus = temp;
            }
        /***Call function***/
            RPC_TRANSMISSION_suppress_answer=false;
            *return_value_out = mcuSetLEDStatus(ledStatus);
            if (RPC_TRANSMISSION_suppress_answer==false){
                /***send return value and output parameters***/
                RPC_TRANSMISSION_message_start(3);
                RPC_TRANSMISSION_message_push_byte(45);

                /* writing integral type uint16_t (*return_value_out) of size 2 */
                RPC_TRANSMISSION_message_push_byte((unsigned char)((*return_value_out)));
                RPC_TRANSMISSION_message_push_byte((unsigned char)((*return_value_out) >> 8));

                RPC_TRANSMISSION_message_commit();
            }

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.

pioupus commented 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.

ArnePhotonics commented 8 years ago

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.

ArnePhotonics commented 8 years ago

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.

ArnePhotonics commented 8 years ago

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

ArnePhotonics commented 8 years ago

it should be possible to name the lower layer by config. The name will be written then in xml file as metadata