Studio:How to define message structures: Difference between revisions

From STRIDE Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:


Below is an example:
Below is an example:
<source type="c">
<source lang="c">
typedef struct
typedef struct
{
{
Line 18: Line 18:


The corresponding message structure is as follows:
The corresponding message structure is as follows:
<source type="c">
<source lang="c">
typedef struct
typedef struct
{
{

Revision as of 21:49, 11 March 2008

The following rules make it easier to process unions and select the active member(s) within a union or nested unions, as well as making it easier to transfer data between tasks.

  • Have a one-to-one correlation between disciminants and union members.
  • The order of enums for discriminants matches with the order of members within the union.
  • In the case of nested unions, each union should have its own discriminant.
  • Use inline data instead of pointers.

Below is an example:

typedef struct
{
    DEVICE_NAME,
    INQUIRY,
    SD,
    SECURITY,
    CONN, 
} app_opcodes_t;

The corresponding message structure is as follows:

typedef struct
{
    ros_hdr_t  ros_hdr;
    vris_hdr_t  vris_hdr;
    app_hdr_t  app_hdr;
    union
    { 
        app_name_msg_t   app_name_msg;
        app_inquiry_msg_t   app_inquiry_msg;
        app_sd_msg_t   app_sd_msg;
        app_sec_msg_t   app_sec_msg;
        app_conn_msg_t   app_conn_msg;
    } ros_msg;
} app_msg_t;

The first element of the union app_name_msg matches with the first enum value of DEVICE_NAME (discriminant within ros_hdr). The number and order of the discriminant values (app_opcodes_t) are the same as the union members.

If the union within the message contains other unions (nested unions), the same rule would apply. The following example demonstrates app_sec_msg_t within ros_msg:

typedef enum
{
    DISCOVERABLE_CFM,
    CONNECTABLE_CFM,
    SEC_AUTHORIZE_CFM,
    SEC_AUTHENTICATE_CFM,
    SEC_BOND_CFM,
} app_prim_sec_t;

typedef struct
{
    app_prim_sec_t sec_msg_rsp;
    union
    { 
        discoverable_mode   discoverable_info;
        connectable_info_t   connectable_info;
        authorize_info_t   authorize_info;
        authenticate_info_t   authenticate_info;
        user_info_input_t   user_input_info;
        bond_info_t   bond_info;
    } sec_msg;
} app_sec_msg_t;

The above examples have the same number of discriminant values and union members. There is a one-to-one correlation between discriminant and union member. Having a discriminant for each union within nested unions decouples the unions and makes it more scalable and easier to maintain. The unions become independent of each other and can easily be extended.