Studio:How to define message structures: Difference between revisions
No edit summary |
m (Text replace - 'Category:Unions' to 'Category:Studio:Unions') |
||
(3 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
Below is an example: | Below is an example: | ||
<source lang="c"> | |||
typedef struct | |||
DEVICE_NAME, | { | ||
INQUIRY, | DEVICE_NAME, | ||
SD, | INQUIRY, | ||
SECURITY, | SD, | ||
CONN, | SECURITY, | ||
CONN, | |||
} app_opcodes_t; | |||
</source> | |||
The corresponding message structure is as follows: | The corresponding message structure is as follows: | ||
<source lang="c"> | |||
typedef struct | |||
ros_hdr_t ros_hdr; | { | ||
vris_hdr_t vris_hdr; | ros_hdr_t ros_hdr; | ||
app_hdr_t app_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_name_msg_t app_name_msg; | ||
app_sd_msg_t app_sd_msg; | app_inquiry_msg_t app_inquiry_msg; | ||
app_sec_msg_t app_sec_msg; | app_sd_msg_t app_sd_msg; | ||
app_conn_msg_t app_conn_msg; | app_sec_msg_t app_sec_msg; | ||
app_conn_msg_t app_conn_msg; | |||
} ros_msg; | |||
} app_msg_t; | |||
</source> | |||
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. | 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: | 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: | ||
<source lang="c"> | |||
typedef enum | |||
{ | |||
DISCOVERABLE_CFM, | |||
CONNECTABLE_CFM, | |||
SEC_AUTHORIZE_CFM, | |||
SEC_AUTHENTICATE_CFM, | |||
SEC_BOND_CFM, | |||
} app_prim_sec_t; | |||
app_prim_sec_t sec_msg_rsp; | typedef struct | ||
{ | |||
app_prim_sec_t sec_msg_rsp; | |||
discoverable_mode discoverable_info; | union | ||
connectable_info_t connectable_info; | { | ||
authorize_info_t authorize_info; | discoverable_mode discoverable_info; | ||
authenticate_info_t authenticate_info; | connectable_info_t connectable_info; | ||
user_info_input_t user_input_info; | authorize_info_t authorize_info; | ||
bond_info_t bond_info; | authenticate_info_t authenticate_info; | ||
user_info_input_t user_input_info; | |||
bond_info_t bond_info; | |||
} sec_msg; | |||
} app_sec_msg_t; | |||
</source> | |||
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. | 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. | ||
[[Category:Studio:Unions]] |
Latest revision as of 00:34, 21 August 2009
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.