rtw.connectivity.Config - Define connectivity implementation, comprising builder, launcher, and communicator components

Syntax

rtw.connectivity.Config(componentArgs, builder, launcher, communicator)

Description

Constructor	Description
Config	Wrapper for the connectivity component classes builder, launcher and communicator.

Constructor Arguments
componentArgs	rtw.connectivity.ComponentArgs object.
builder	rtw.connectivity.Builder (e.g. rtw.connectivity.MakefileBuilder) object.
launcher	rtw.connectivity.Launcher object.
communicator	rtw.connectivity.Communicator (e.g. rtw.connectivity.RtIOStreamHostCommunicator) object.

Constructor syntax:

rtw.connectivity.Config(componentArgs, builder, launcher, communicator)

To define a connectivity implementation:

You must create a subclass of rtw.connectivity.Config that creates instances of your connectivity component classes:
- rtw.connectivity.MakefileBuilder
- rtw.connectivity.Launcher
- rtw.connectivity.RtIOStreamHostCommunicator
You can see an example ConnectivityConfig.m, used in the demo rtwdemo_custom_pil.
Define the constructor for your subclass as follows:
```
        function this = MyConfig(componentArgs)
```
When Simulink creates an instance of your subclass of rtw.connectivity.Config, it provides an instance of the rtw.connectivity.ComponentArgs class as the only constructor argument. If you want to test your subclass of rtw.connectivity.Config manually, you may want to create an rtw.connectivity.ComponentArgs object to pass as a constructor argument.
After instantiating the builder, launcher and communicator objects in your subclass, call the constructor of the superclass rtw.connectivity.Config to define your complete target connectivity configuration, as shown in this example.
```
% call super class constructor to register components
this@rtw.connectivity.Config(componentArgs,...
builder, launcher, communicator);
```

You will register your subclass name (e.g. "MyPIL.ConnectivityConfig") to Simulink by using the class rtw.connectivity.ConfigRegistry. This uses the sl_customization.m mechanism to register your connectivity configuration.

The PIL infrastructure instantiates your subclass as required. The sl_customization.m mechanism helps in specifying a suitable connectivity configuration for use with a particular PIL component (and its configuration set). It is also possible for the subclass to do extra validation on construction. For example, you can use the componentPath returned by the getComponentPath method of the componentArgs constructor argument to query and validate parameters associated with the PIL component under test.

For supported hardware implementation settings and other support information, see SIL and PIL Simulation Support and Limitations in the Embedded Coder documentation.