To increase the readability, the naming of the Bus Database Channel properties have changed. With the new naming syntax, the bus type and channel index can be determined more easily.
In parallel to the naming, the numbering has also changed.
The following table illustrates the new Bus Channel Properties for the CAN Service.
|old CAN DBC Index||new CAN DBC Index||comment|
|DBCFiles4Channel0||can_channel_1||starting index changed from 0 to 1, more easy to read|
Bus datastreams of old ADTF 2.x DAT-Files are converted automatically to the new channel index by the
adtf_devtb_2_deserializer.adtffileplugin is loaded automatically by the appropriate bus service, if you are not using a bus service for any
reason, you can also use the
devtb2_support.adtfplugin which will extend the functionality by loading
The CAN FD Services can be understood analogous, besides changing the property variable from can_channel_1 into canfd_channel_1, etc..
The following table illustrates the new Bus Channel Properties for the FlexRay Service. In contrast to ADTF Device Toolbox 2.x, we are now able to access multiple flexray devices. We had to change the handling of different database for different devices. The property for the flexray databases is not separated into different channels, which are mapped to different devices.
|old flexray database Index||new flexray database Index||comment|
|fibex_filename||flexray_channel_1||old: comma separated list for different devices|
|fibex_filename||flexray_channel_2||new: every device got its own index|
The coupling between database and device can be configured within the Vector Hardware Config Tool.
For accessing the device Device 1 / Channel 2 mapped to Application Channel/Usage 1, you must enter the corresponding database(s) into the FlexRay Service property flexray_channel_1
The customized database parser support was reworked completely. With the new version you are now able to add a database parser which is in form of a dynamic library. The Bus-Service will load and use the database library during runtime.
Map-files are nearly identical to the old buffer configuration files.
The difference between is, that they are now easier to use and the xml tags are now more selfexplained.
In addition, a 'first-level' structure is no longer required for each buffer respectively input / output pin.
In general, a map-file can be edited in two ways:
The internal structure of a map-file consists of several xml tags which are explained in the next section. See the examples below for a minimum version of a map-file which maps a CAN message to a specified signal set and vice versa.
|old buffer xml node||new buffer xml node||comment|
|<buffer>||<input> or <output>||data direction and pin name|
|<struct>||-||structure to separate one or more signals|
|<trigger>||<trigger> (optional)||trigger element|
Examples of existing map-files can be found within your delivery:
The following code snippet displays a map-file for decoding an incoming CAN message signals to a ddl-streamtype
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?> <mapping codec="CCC" version="2.00"> <outputs channel="1"> <output name="output_ddl"> <assignment> <to>ECU2_Signal8_16</to> <from>ECU2_Full.ECU2_Signal8_16</from> <type>tUInt16</type> <limits>ignore</limits> </assignment> <assignment> <to>ECU2_Signal7_4</to> <from>ECU2_Full.ECU2_Signal7_4</from> <type>tUInt8</type> <limits>ignore</limits> </assignment> </output> </outputs> </mapping>
Regarding to the decoding, this code snippet shows an encoding map-file for converting a ddl-streamtype to a CAN messagetype
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?> <mapping codec="CCC" version="2.00"> <inputs channel="1"> <input name="input_ddl"> <assignment> <to>ECU2_Signal8_16</to> <from>ECU2_Full.ECU2_Signal8_16</from> <type>tUInt16</type> <limits>ignore</limits> </assignment> <assignment> <to>ECU2_Signal7_4</to> <from>ECU2_Full.ECU2_Signal7_4</from> <type>tUInt8</type> <limits>ignore</limits> </assignment> </input> </inputs> </mapping>