In general, DDS supports any compiler which generates ELF/DWARF or I3E-695 files.
However, due to the different interpretation of the mentioned specifications by the compiler vendors, it might be that the DDS import filters must be adapted slightly to some compilerspecifics.
Each version of DDS contains a file named ThisVersion.rtf which is accessible via the DDS program folder (the file is located in the 'Docu' subdirectory of the DDS installation directory). The
file contains among others a section 'Supported Compilers'
which lists he supported compilers (including the exact version number)
together with possible restrictions. If your compiler is not mentioned in
that section, please contact the DDS support to get further information.
Most export filters have the filter option 'PartialExportViaFunction".
This option controls - through the DDS function assignment - the
amount of definitions which have to be exported. Only definitions
which are assigned to a function which is in the partial export list
are exported. When the list is empty (default case), all definition
are exported.
Note: Only global functions are used for the partial export. However
also definitions assigned to sub-functions are exported when the
sub-function belongs to a (global) function which is meant for the
partial export.
The DDS Login-Dialog can be hidden/disabled by adding the
entry "Show Login" to the windows registry. The registry entry must be
added to the key
HKEY_CURRENT_USER\Software\Visu-IT!\DDS\<your DDS Version,
e.g. 4.2.0>\DDS\Login Options,
must be of the type "REG_DWORD" and must have the value "0".
Alternatively, a *.reg file with
the following contents can be launched:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Visu-IT!\DDS\<your DDS Version,
e.g. 4.2.0>\DDS\Login Options]
"Show Login"=dword:00000000
This warning message might occur when working with types and
instances. In that case, most attributes of the type will be inherited
to the instance by default. When overwriting those inherited
attributes at the instance with identical values, the DDS check
detects those redundant individual attributes and emits a warning
message. Additionally to that, it is possible to delete all those
redundant attributes automatically:
(1) change the warning message to an error message (e.g. via the
option '-=ErrorMessage L3005')
(2) start the check once more (in 'Advanced' mode)
After that, all redundant attributes are removed from the database.
Since version 4.1.0, it is possible to search for unused entities in the DDS editor (via the
context menu command "Display Unused Entities"), e.g. conversions
which are not used. In big databases, there might be thousands of
unused entities. When deleting these entities from the database, it
might happen that after the deletion some other unused entities are
shown in the "Unused Entities" dialog of the DDS editor. When applying
the deletion for these other unused entities, there might be again
new/other unused entities. After performing the search and the
deletion three/four times, no further unused entities exist in the DDS
database.
The reason for that behaviour is that when an unused entity gets deleted, another one
which is currently only used from this unused entity will also get
unused due to the deletion. That means, that new unused entities might
get 'created' during the deletion of the current unused ones.
Scenario: The dataType 'myType' is marked as unused. The
dataType uses the conversion 'conv1' which is not marked as unused
since it is used from the dataType. When the dataType 'myType' is
deleted, the conversion 'conv1' gets unused and will be shown in the
"Unused Entities Dialog".
When importing ASAP2 files into existing databases it might happen that ASAP2 definitions
conflict with DDS definitions which are already present in the
database. The ASAP2 import keeps or overwrites (depending on the filter
options) the conflicting definitions. However this happens on a quite
global/rough level. If you have problems with this automatic merge
approach or if you want to completely control the merge behaviour we
strongly recommend to perform a two step process instead:
Step 1: Import the ASAP2 file into an empty database
Step 2: Merge this newly created database into the current database
via the CompareMerge functionality
In general, C variables with the data type 'char' are not aligned.
However certain compiles (like Tasking TriCoreVX v2.x) may align array
members (of type 'char') in a structure on even addresses.
DDS will detect this alignment and add the needed padding for 'normal'
structures, that means structures which are explicitly created in DDS.
DDS will not detect this alignment and deliver wrong addresses for 'implicit'
structures, that means structures which are implicitly created by
using certain (structure-)mappingSchemes like mappingScheme
'51_Struct_NumberAxisPts_StandaloneAxis_(ASCET)'.
Example:
struct aMapType {
char sizeOfAxis;
char axisValues[4];
...
}
Some compiler may align the element 'axisValues[4] on an even address.
In this case, DDS will - e.g. in the ASAP2 file - deliver the correct
start address, but the RECORD_LAYOUT will not take the padding into
consideration.
If you use such a compiler, please consult the DDS hotline in order
to get a modified mappingScheme which is prepared for that alignments.
Bit addresses as for relocatable bits of C167 are calculated by
offset 0xFD00 and modulo 8. As bit addresses can't be distinguished
from byte addresses in the I3E-695 file of Tasking, the DDS memory
type INT_RAM_BIT is used as (only) criteria for this special
calculation. This can lead to wrong addresses. User confusion occur in
particular for the C167 data type 'bitword', for which users
often assign INT_RAM_BIT as memory type, as this type is also located
in the hardcoded internal RAM although it has a byte address in
I3E-695.
The I3E-Import emits a warning message when a non-'bit'-definition has
the memory type INT_RAM_BIT. (Nevertheless the address calculation is
also done for non-'bit'-definitions)
The CompareMerge filter can be used to delete configuration units both
within the DDS editor and via command line.
In general, a detailed control of the CmpareMerge filter from the
command line is not really possible and required. Nevertheless, it is
possible to delete GRL files via command line:
The GRL files, which are to be deleted, must exist as empty files in
another directory and must then be referenced with the switch
SourceGirlFiles.
Example: When you start the
example (DDS version
4.1.0) on the command line with "
cmpmrg
-p .", the GRL file "ToBeDeleted.grl"
will be deleted.
In principle, the hex-/phys-values of a table conversion can be
accessed via the attribute 'intRealTable'. However, this attribute
dosn't work with the 'normal' attribute methods, since its value is
not a simple (e.g. 'bool', 'integer', 'real', 'string', 'Entity') but
a special one: an embedded entity. If those attributes have to be
accessed, set or added, a specific handling is necessary. For working
with embedded entities there exist the two functions 'GetEmbedded(..)'
and 'AddEmbedded(..)'. Both functions return an EmbeddedEntity
interface which is quite similar to the Entity interface.
VBS-Example:
Dim conversion
Dim embed
Set conversion =
DDSEntityMan.Create("conversion", "my_table", 128) ' 128 =
interpolation table
Set embed = conversion.GetEmbedded("intRealTable",
0)
' get row with index '0'
bSuccess = bSuccess AND embed.SetAttribute("int", 9.)
bSuccess = bSuccess AND embed.SetAttribute("real", 99.99)
Set embed = conversion.GetEmbedded("intRealTable",
1)
' get row with index '1'
bSuccess = bSuccess AND embed.SetAttribute("int", 100.)
bSuccess = bSuccess AND embed.SetAttribute("real", 110.11)
The GetAttribute(..) method returns the value of an attribute as
VARIANT. In Visual Basic, no special measures have to be taken in
order to work with the VARIANT type.
However, to call the GetAttribute(..) method
successfully with Perl, a special declaration of the variable is
necessary.
Perl-Example:
use OLE;
use Win32::OLE::Variant;
our $tmp = Variant(VT_VARIANT|VT_BYREF, '');
$dserver = Win32::OLE->new("DServer.Database") or die "ERROR: Can't
open DServer !";
$dds = $dserver->open("c:/dds/db1", 0); # or die "ERROR: Can't open
database $dds_path !";
$ent = $dds->Entity("parameter", "c_soi_mplp_man") or die;
$ent->GetAttribute("description", $tmp);
print "$tmp\n";
Some DServer methods work with VARIANTS and list of VARIANTS (safe arrays containing 'IDispatch(Entity)' values).
The following two examples show the principle usage of these types in Perl.
Perl-Example 1:
1) Open DB
2) Find all instances
3) Extract responsible from list and delete them
4) Close DB
-> see
Example 1
Perl-Example 2:
1) Open DB
-> must be a DDS V5.0.0 database/DServer because of using the new function "GetAttribute2(..)"
2) Find description of a specific parameter 'otto' (name search)
3) Close DB
-> see
Example 2
Sometimes it makes sense to access the DServer via late binding using the method "InvokeMember(..)". However in this case you have to work with the data type VARIANT* in order to retrieve the value of an attribute. Working with VARIANT* in C# is not very convenient. Fortunately, there exists the helper class VariantWrapper in .NET which easies this task.
C#-Example:
private int GetDDSIntegerAttribute(object ddsEntity, string sAttributeName, out object o)
{
object o1 = new VariantWrapper(new object[1]);
object [] oMyArgs = new object[3];
oMyArgs[0] = sAttributeName;
oMyArgs[1] = o1;
oMyArgs[2] = 0;
ParameterModifier modifier = new ParameterModifier(3);
ParameterModifier[] modifiers = new ParameterModifier[] { modifier } ;
modifier[0] = false;
modifier[1] = true;
modifier[2] = false;
object oRet = myDDS.InvokeMember("GetAttribute", BindingFlags.InvokeMethod, null, ddsEntity, oMyArgs, modifiers, null, null);
int iResult = ((int)oRet);
o = oMyArgs[1];
return iResult;
}