Studio:How to define message structures - Revision history

Timd: Text replace - 'Category:Unions' to 'Category:Studio:Unions'

2009-08-21T00:34:29Z

Text replace - 'Category:Unions' to 'Category:Studio:Unions'

← Older revision		Revision as of 00:34, 21 August 2009
Line 64:		Line 64:

	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:Unions]]		[[Category:Studio:Unions]]

Timd: How to define message structures moved to Studio:How to define message structures

2009-08-18T23:19:04Z

How to define message structures moved to Studio:How to define message structures

← Older revision	Revision as of 23:19, 18 August 2009
(No difference)

Timd at 21:49, 11 March 2008

2008-03-11T21:49:25Z

← Older revision		Revision as of 21:49, 11 March 2008
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
	{		{

Timd at 21:48, 11 March 2008

2008-03-11T21:48:44Z

← Older revision		Revision as of 21:48, 11 March 2008
Line 6:		Line 6:

	Below is an example:		Below is an example:
	<tt>typedef struct~~<br>~~		<source type="c">
	{~~<br>~~		typedef struct
	DEVICE_NAME,~~<br>~~		{
	INQUIRY,~~<br>~~		DEVICE_NAME,
	SD,~~<br>~~		INQUIRY,
	SECURITY,~~<br>~~		SD,
	CONN, ~~<br>~~		SECURITY,
	} app_opcodes_t;</tt>		CONN,
			} app_opcodes_t;
			</source>

	The corresponding message structure is as follows:		The corresponding message structure is as follows:
	<tt>typedef struct~~<br>~~		<source type="c">
	{~~<br>~~		typedef struct
	ros_hdr_t ros_hdr;~~<br>~~		{
	vris_hdr_t vris_hdr;~~<br>~~		ros_hdr_t ros_hdr;
	app_hdr_t app_hdr;~~<br>~~		vris_hdr_t vris_hdr;
	union~~<br>~~		app_hdr_t app_hdr;
	{ ~~<br>~~		union
	app_name_msg_t app_name_msg;~~<br>~~		{
	app_inquiry_msg_t app_inquiry_msg;~~<br>~~		app_name_msg_t app_name_msg;
	app_sd_msg_t app_sd_msg;~~<br>~~		app_inquiry_msg_t app_inquiry_msg;
	app_sec_msg_t app_sec_msg;~~<br>~~		app_sd_msg_t app_sd_msg;
	app_conn_msg_t app_conn_msg;~~<br>~~		app_sec_msg_t app_sec_msg;
	} ros_msg~~<br>~~		app_conn_msg_t app_conn_msg;
	} app_msg_t;</tt>		} 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:
	<tt>typedef enum~~<br>~~		<source lang="c">
	{~~<br>~~		typedef enum
	DISCOVERABLE_CFM,~~<br>~~		{
	CONNECTABLE_CFM,~~<br>~~		DISCOVERABLE_CFM,
	SEC_AUTHORIZE_CFM,~~<br>~~		CONNECTABLE_CFM,
	SEC_AUTHENTICATE_CFM,~~<br>~~		SEC_AUTHORIZE_CFM,
	SEC_BOND_CFM,~~<br>~~		SEC_AUTHENTICATE_CFM,
	} app_prim_sec_t;~~<br>~~		SEC_BOND_CFM,
	typedef struct~~<br>~~		} app_prim_sec_t;
	{~~<br>~~
	app_prim_sec_t sec_msg_rsp;~~<br>~~		typedef struct
	union~~<br>~~		{
	{ ~~<br>~~		app_prim_sec_t sec_msg_rsp;
	discoverable_mode discoverable_info;~~<br>~~		union
	connectable_info_t connectable_info;~~<br>~~		{
	authorize_info_t authorize_info;~~<br>~~		discoverable_mode discoverable_info;
	authenticate_info_t authenticate_info;~~<br>~~		connectable_info_t connectable_info;
	user_info_input_t user_input_info;~~<br>~~		authorize_info_t authorize_info;
	bond_info_t bond_info;~~<br>~~		authenticate_info_t authenticate_info;
	} sec_msg;~~<br>~~		user_info_input_t user_input_info;
	} app_sec_msg_t;</tt>		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:Unions]]

Root at 21:56, 5 February 2008

2008-02-05T21:56:36Z

← Older revision		Revision as of 21:56, 5 February 2008
Line 57:		Line 57:

	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:Application Notes]]~~

Root at 23:41, 4 February 2008

2008-02-04T23:41:54Z

← Older revision		Revision as of 23:41, 4 February 2008
Line 59:		Line 59:


	[[Category:~~SCL~~]]		[[Category:Application Notes]]

Andreo at 21:28, 11 December 2007

2007-12-11T21:28:27Z

← Older revision		Revision as of 21:28, 11 December 2007
Line 59:		Line 59:


	[[Category:~~Scripting~~]]		[[Category:SCL]]

Root at 18:47, 11 December 2007

2007-12-11T18:47:22Z

← Older revision		Revision as of 18:47, 11 December 2007
Line 59:		Line 59:


	[[Category:KB]]		[[Category:Scripting]]

Root at 23:23, 21 June 2007

2007-06-21T23:23:05Z

← Older revision		Revision as of 23:23, 21 June 2007
Line 57:		Line 57:

	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:KB]]

Root at 22:28, 19 June 2007

2007-06-19T22:28:17Z

New page

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:
<tt>typedef struct 
{ 
DEVICE_NAME, 
INQUIRY, 
SD, 
SECURITY, 
CONN, 
} app_opcodes_t;</tt>

The corresponding message structure is as follows:
<tt>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;</tt>

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:
<tt>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;</tt>

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.