Bug 467945: use deserialization API
This changes protocol message serialization to use the RTS provided API
instead of simple memcpy's.
The protocol's generated signal functions use the encode function, e.g.,
UMLRTOutSignal signal;
signal.initialize( signal_ping, sourcePort, sizeof( param ) );
signal.encode( ¶m, UMLRTType_DataType1 );
The decode code pattern is slightly more complicated. This will be
partially simplified by new RTS API. In this change we introduce a new
field on the generated Capsule class. This field is set with the active
message parameters type descriptor. In the .hh:
const UMLRTObject_class * currentType;
This is used in the generated state function, e.g.,
case PingPongProtocol::signal_ping:
currentType = UMLRTType_DataType1;
actionchain_____top__onPing__ActionChain5( msg );
Finally, the type descriptor is used to decode the message parameter in
the generated action code, e.g.,
void Capsule_Ponger::<...cut...>_onPing( const UMLRTMessage & msg )
{
void * rts_decodeInfo = NULL;
DataType1 rtdata;
if( currentType )
( (UMLRTInSignal & )msg.signal )
.decode( &rts_decodeInfo, (void *)&rtdata, currentType);
// USER CODE
}
NOTE: The currentType field will be replaced by new RTS API. A new
type, UMLRTInMessage will make this field unnecessary. I've done
minimal implementation to add this field as I expect it to be
removed shortly.
I've used the PingPong-data model to confirm that the structure is
passed propertly. I've used the standard PingPong model to confirm no
change in existing behaviour.
Change-Id: Ida4eba9e601924389fa9b1856ee0009dd3cf6750
Signed-off-by: Andrew Eidsness <andrewe@jfront.com>10 files changed