Difference between revisions of "LDRA Integration for Model References"

From T-VEC Wiki
Jump to: navigation, search
(Pre/Post Includes might be necessary)
(Start TBrun and Load New Test Sequence)
 
Line 31: Line 31:
 
[[Image:stoplight_sm_example.png|Model Reference Code Generation]]
 
[[Image:stoplight_sm_example.png|Model Reference Code Generation]]
  
The names extracted from the exported model information do not necessarily correspond with the different the code generation works. There is tool provided with the release called
+
The names extracted from the exported model information do not necessarily correspond to the names produced by the code generator. There is a tool provided with the release called
  
 
  get_rtw_types.bat --- Download it here [http://www.t-vec.com/download/get_rtw_types.bat get_rtw_types.bat]
 
  get_rtw_types.bat --- Download it here [http://www.t-vec.com/download/get_rtw_types.bat get_rtw_types.bat]
Line 39: Line 39:
 
[[Image:VGS_Toolbox.png|VGS Toolbox with get_rtw_types]]
 
[[Image:VGS_Toolbox.png|VGS Toolbox with get_rtw_types]]
  
Simply select the subsytem from the VGS Project window and then execute the get_rtw_types from the Tools menu. It will update the object mappings. Do this for each subsystem that needs to have the object mappings updated.
+
Simply select the subsystem from the VGS Project window and then execute the get_rtw_types from the Tools menu. It will update the object mappings for the subsystem selected and for all its dependencies.
  
 
[[Image:VGS_Toolbox_Execution.png|VGS Toolbox Execution of get_rtw_types]]
 
[[Image:VGS_Toolbox_Execution.png|VGS Toolbox Execution of get_rtw_types]]
Line 53: Line 53:
 
   <rtDWStruct> - defines the localDW variable relating to state data
 
   <rtDWStruct> - defines the localDW variable relating to state data
 
   <rtZCEStruct> - defines the localZCE variable relating to triggers
 
   <rtZCEStruct> - defines the localZCE variable relating to triggers
 +
 +
It also performs further analysis of the code generated for model references. Normally when there are input scalar variables in a model, the code that is produced looks like the following:
 +
 +
extern void mr_stoplight_sm(boolean_T rtu_0, boolean_T rtu_1,
 +
  boolean_T *rty_0, boolean_T *rty_1, boolean_T *rty_2, rtDW_mr_stoplight_sm
 +
  *localDW, rtZCE_mr_stoplight_sm *localZCE);
 +
 +
The variable rtu_0 and rtu_1 are scalar inputs. These default situations are handle properly by the sl2tvec translator. However, for unknown reasons, the code is sometimes produced as follows:
 +
 +
extern void mr_stoplight_sm(const boolean_T *rtu_0, const boolean_T *rtu_1,
 +
  boolean_T *rty_0, boolean_T *rty_1, boolean_T *rty_2, rtDW_mr_stoplight_sm
 +
  *localDW, rtZCE_mr_stoplight_sm *localZCE);
 +
 +
In such situation there are changes required in the sections called:
 +
* <ldraExternalDeclarations>
 +
* <ldraParameterPointerInitialization>
 +
 +
The following changes are made by the get_rtw_types program - the following example shows that a global LDRA variable must be added to the <ldraExternalDeclarations>
 +
 +
<ldraExternalDeclarations> = '
 +
<if(<isModelReference> != 0)>{    # Begin Global
 +
 
 +
      File = <codeDirectory>\<functionFilename>.cpp
 +
      Name = rtu_0_obj
 +
      Decl_type = boolean_T
 +
 
 +
    # End Global
 +
 
 +
    # Begin Global
 +
 
 +
      File = <codeDirectory>\<functionFilename>.cpp
 +
      Name = rtu_1_obj
 +
      Decl_type = boolean_T
 +
 
 +
    # End Global
 +
 +
Similarly, corresponding entries must be made to the parameter pointer initialization as shown below:
 +
 +
<ldraParameterPointerInitialization> = '
 +
<if(<isModelReference> != 0)>{    # Begin Variable
 +
 
 +
      Name = rtu_0
 +
      Decl_type = boolean_T*
 +
      Usage = P
 +
      Value = &rtu_0_obj
 +
 
 +
    # End Variable
 +
 
 +
    # Begin Variable
 +
 
 +
      Name = rtu_1
 +
      Decl_type = boolean_T*
 +
      Usage = P
 +
      Value = &rtu_1_obj
 +
 
 +
    # End Variable
 +
 +
In addition the corresponding variables rtu_0 and rtu_1 are replaced in their corresponding object mappings with the variables rtu_0_obj, and rtu_1_obj.
 +
 +
Finally, the updated version of the program updates the following 7 variables to the other dependent object mappings files. These dependent files are defined in the user defined variable:
 +
 +
<dependencies> = '__triggerFallingB,signal_light__sf__a';
 +
 +
Note, for example, that signal_light__sf__a is a subsystem related to the user model, but __triggerFallingB is a utility subsystem generated by the translator. It will not have a .map file.
 +
 +
The updated version of the program replaces the values of the following variables if they exist with the value from the object mapping subsystem from which it was called.
 +
 +
<functionName>
 +
<isModelReference>
 +
<isReusable>
 +
<ldraExternalDeclarations>
 +
<ldraParameterPointerInitialization>
 +
<rtDWStruct>
 +
<rtZCEStruct>
 +
 +
If any of these variable do not exist, one is added just before the following line:
 +
 +
EMBED_PERL '<SCHEMA_HOME>\<embedFile>';
  
 
===Build Test Drivers===
 
===Build Test Drivers===
Line 80: Line 158:
 
*Process Driver Output
 
*Process Driver Output
  
Note: during the Generate Driver process, you might see the following LDRA Question - Answer '''None'''.
+
Note: during the Generate Driver process, you might see the following LDRA Question
 +
 
 +
Dataflow analysis has detected that output parameter "rty_0" is used in the unit
 +
tested by test case 1.
 +
 +
Adding this value to the test case will result in the test case not running until
 +
an expected value is provided
 +
 +
Not adding this variable will add it to the removed variables list from which it
 +
can be restored at a later date if required. The test case will then be executed as
 +
previously, but may fail to compile.
 +
 +
Do you wish to automatically add this variable to the test case?
 +
 
 +
Answer '''None'''.
  
 
====Pre/Post Includes might be necessary====
 
====Pre/Post Includes might be necessary====

Latest revision as of 10:35, 30 June 2008