8.1. Supported Platforms and Programming Languages

Connext DDS Micro supports the C and traditional C++ language bindings.

Note that RTI only tests on a subset of the possible combinations of OSs and CPUs. Please refer to the following table for a list of specific platforms and the specific configurations that are tested by RTI.

Table 8.1 Tested Platforms

OS	CPU	Compiler	RTI Architecture Abbreviation
Elektrobit™ AUTOSAR™ 4.0.3	Infineon™ AURIX™ TriCore™ TC297	Tasking 6.2r2	tc29xtOsekCoreTasking6.2r2
Mentor™ AUTOSAR 4.2.2	Infineon AURIX TriCore TC297	Tasking 6.2r2	tc29xtVSTARTasking6.2r2
Red Hat® Enterprise Linux® 6.0, 6.1 (Kernel version 2.6)	x86	gcc 4.4.5	i86Linux2.6gcc4.4.5
Ubuntu® 18.04 (Kernel version 4)	x64	gcc 7.3.0	x64Linux4gcc7.3.0
Ubuntu 16.04 (Kernel version 3)	x86	gcc 5.4.0	i86Linux3gcc5.4.0
PPC Linux (Kernel version 3)	ppce500mc	gcc 4.7.2	ppce500mcLinux3gcc4.7.2
macOS® 10.16	x64	clang 8.0	x64Darwin16clang8.0
QNX® 7.0	armv8	qcc 5.4.0	armv8QNX7.0.0qcc_gpp5.4.0
QNX 6.6	armv7a	qcc 4.7.3	armv7aQNX6.6.0qcc_cpp4.7.3
QNX 6.6	i86	qcc 4.7.3	i86QNX6.6qcc_cpp4.7.3
Windows® 7	x86	Visual Studio® 2010	i86Win32VS2010
Windows® 7	x64	Visual Studio® 2015	x64Win64VS2015
VxWorks 6.9	ppc604	gcc 4.3.3	ppc604Vx6.9gcc4.3.3 and ppc604Vx6.9gcc4.3.3_rtp

8.2. What’s New in 2.4.14

8.2.1. Important Interoperability Changes

8.2.1.1. DataWriter’s Default Reliability Changed to Reliable

The default reliability for a DataWriter has been changed from best-effort to reliable.

This solves interoperability problems when the remote DomainParticipant does not send the QoS value if configured with its default value. However, this may cause interoperability problems with previous releases if the former default reliability QoS is used.

8.2.2. Port Validation for Connext DDS Micro

After porting Connext DDS Micro, it is important to confirm that your code works as expected. For this purpose, Connext DDS Micro comes with a suite of tests that you can compile and run to validate your port.

8.2.3. New Documentation on Compiling Connext DDS Micro for Connext DDS Micro Cert Compatibility

This release includes a new chapter on how to compile Connext DDS Micro with for compatibility with Connext DDS Micro Cert. See Building Connext DDS Micro with compatibility for Connext DDS Micro Cert.

8.2.4. ThreadX CMake Files and New Documentation on Building Connext DDS Micro for ThreadX + NetX

Connext DDS Micro libraries can now be compiled using rtime-make and CMake for ThreadX + NetX. There is a new section in the documentation on building for the ThreadX operating system and NetX network stack, including example configurations. See Building the Connext DDS Micro Source for ThreadX.

8.2.5. Updated Example CMakeLists.txt to Automatically Regenerate Code when IDL or XML File Changes

The CMakeLists.txt generated by the Code Generator now has a rule that will regenerate type-support files if the IDL or XML file with the type definition changes. The rule is conditional: it is only added if the option RTIME_IDL_ADD_REGENERATE_TYPESUPPORT_RULE is set to TRUE when invoking CMake.

8.2.6. Message Logged when Samples Received Out of Order

This release logs an additional message when a sample is received out of order and reliability is enabled. This will occur if a reliable sample with a data submessage is received with a sequence number higher than the lowest, next expected sequence number.

8.2.7. Message Logged when Sequence Numbers Received More than Once

This release logs an additional message if a sample is received more than once when reliability is enabled. This means that a sample with the same sequence number has already been received.

8.2.8. Ability to Send Logs over UDP

This release includes support for sending logs over UDP. The destination IP address and UDP port can be configured in the AUTOSAR port properties.

8.2.9. rtime-make Provides Help for a Specific Target

The help output from the script rtime-make has been improved to show that is possible to get help for a specific target.

Use the command “rtime-make –target <target> –help” to print help for the target.

8.2.10. FreeRTOS CMake Files

The Connext DDS Micro libraries can now be compiled using rtime-make and CMake for FreeRTOS.

8.2.11. Improved Documentation on Building Connext DDS Micro for AUTOSAR Systems

The documentation on building Connext DDS Micro for AUTOSAR systems has been improved with information about the number of resources needed. See Resources.

8.2.12. Examples Used Undocumented APIs

The provided examples, and those created by the Code Generator, were using Foo_create() and Foo_delete() to create and delete samples. Those APIs are not documented and should not be used. The examples have been changed to use FooTypeSupport_create_data() and FooTypeSupport_delete_data() instead.

8.2.13. New CMake Option to Enable Real-Time Timers on QNX and Linux Systems

Connext DDS Micro has supported POSIX.4 real-time timers as a way to run the its internal timers. However, this feature has only been available by updating the osapi_os_posix.h header file and has been disabled by default because it relies on POSIX signals that may interfere with an application, such as if an application uses fork() and one of the exec system calls without setting the signal mask.

Connext DDS Micro uses the signal SIGRTMIN by default. To change this, it is necessary to modify the constant OSAPISYSTEM_POSIX4_TIMER_SIGNAL at the beginning of src/osapi/posix/posixSystem.c. Please note that the number of signals available varies between systems.

To enable this feature on a QNX or Linux system, pass the following additional option to cmake or rtime-make:

8.2.14. New -showTemplates and -exampleTemplate options for Code Generator

This release introduces two new Code Generator command-line options, -showTemplates and -exampleTemplates.

The -showTemplates option prints and generates an XML file containing a list of available example templates in your Connext DDS installation, organized per language.

When you use the -exampleTemplate option, you can specify one of these example templates, which are in $RTIMEHOME/rtiddsgen/resource/templates/example/<language>/<templateName>/. You may also create your own templates and place them in this directory.

To use -exampleTemplates, you must also use one of the following command-line options:

• -create examplefiles

• -update examplefiles

• -example

When you use the -exampleTemplates option, Code Generator will generate the example you specified, instead of the default one. For example:

rtiddsgen -language C++ -example -exampleTemplate <exampleTemplateName> foo.idl

8.3. What’s Fixed in 2.4.14

8.3.1. Small Enums Caused Serialization Errors

In previous releases, enum types that were represented internally as 1 or 2 byte values caused serialization and deserialization errors. This problem has been resolved by adding support for enum types with 1 or 2 byte internal memory representations. The wire representation for enums is unchanged at 4 bytes.

[RTI Issue ID MICRO-2249]

8.3.2. -Wcast-function-type and -Wdeprecated Compiler Warnings

This release fixes two different compiler warnings:

• When compiling Connext DDS Micro with GCC8 (or later versions) and -Wcast-function-type, the compiler printed warnings such as:

  cast between incompatible function types
  

• When compiling Connext DDS Micro with a C++11 compiler and -Wdeprecated, the compiler printed warnings such as:

  warning: definition of implicit copy constructor
  

Both of these issues have been fixed. Note that neither issue caused incorrect behavior.

[RTI Issue ID MICRO-2488]

8.3.3. Documentation did not list all Entities that Support Transport QosPolicy

The previous documentation did not list all the entities that support the DDS_TransportQosPolicy. This problem has been fixed.

The DDS entities that support the DDS_TransportQosPolicy are the DomainParticipant, DataWriter and DataReader.

[RTI Issue ID MICRO-2503]

8.3.4. Generated Examples Registered Wrong Type Name

The generated code for Connext DDS Micro may have registered the wrong type name if you used the option -create examplefiles and IDL such as:

module My_Module {
   struct My_Entity {
      long id; //@key
   };
};

This generated an example that registered a type with a name that was incompatible with the type name used by other DDS tools that were configured with the same IDL file. This issue has been fixed.

[RTI Issue ID MICRO-2605]

8.3.5. For C++ Types Generated by rtiddsgen that have Inheritance, the ParentCclass was also Declared in the Class as Another Member

Consider the following Foo.idl file, used to generate code with rtiddsgen:

struct Base
{
     long x;
};

struct Foo: Base {
     long y;
};

This generated the following Foo.h file:

class Base
{
    long x;
};

class Foo: public Base
{
    Base parent;
    long y;
};

Note that the class Foo inherited from the class Base, and its first field was a ‘parent’ field of type ‘Base’. This should not happen, since it results in extra space being taken for each sample that will not be used.

This problem has been fixed. The generated Foo class no longer has a ‘parent’ field of type ‘Base’.

[RTI Issue ID MICRO-2633]

8.3.6. DomainParticipant not Rediscovered if Terminated and Restarted Before its Lease Duration Expired

A DomainParticipant was not rediscovered if it was terminated and restarted before its lease duration expired. For example, if an application with a DomainParticipant was terminated with Control-C and restarted before the DomainParticipant’s lease duration expired, the DomainParticipant would not be rediscovered. However, if the DomainParticipant was deleted with delete_participant() this problem would not occur. This issue has been resolved.

[RTI Issue ID MICRO-2672]

8.3.7. OSAPI_Log_clear did not Zero Out Log Buffer Memory

OSAPI_Log_clear() did not zero out the log buffer memory. This problem has been resolved. Now it will set the buffer memory to zero when it resets the buffer head.

[RTI Issue ID MICRO-2678]

8.3.8. Error in Generated C/C++ Code when Two Members of Different Enumerations had Same Name

The generated C/C++ code for an IDL file containing enumerations with members that had the same name would not compile. For example, consider this IDL:

module a {
     module b {
            enum Foo {
                     GREEN, RED
           }
    ;};
};
module c {
      module d {
          enum Bar {
               GREEN, YELLOW
          };
     };
};

The above IDL produced the following code:

typedef enum c_d_Foo
{
    GREEN ,
    RED
} c_d_Foo;


typedef enum c_d_Bar
{
    GREEN ,
    YELLOW
} c_d_Bar;

And it produced an error similar to this when trying to compile it:

test.h:82: error: redeclaration of enumerator ‘GREEN’
test.h:25: error: previous definition of ‘GREEN’ was here

This release introduces a new command-line option in RTI Code Generator, -qualifiedEnumerator, which allows you to generate fully qualified enumerator names. This avoids having conflicting names in C/C++.

For example, given this IDL:

module myModule{
    enum Color2 {
       GREEN,
       RED
     };

   union MyUnion switch (Color2){
     case GREEN:
            long m1;
     case RED:
             long m2;
     };
};

The following table shows the code that will be generated without the new option and with it:

Table 8.2 Effect of using -qualifiedEnumerator

Language	without -qualifiedEnumerator (default)	with -qualifiedEnumerator
C	typedef enum myModule_Color2 { GREEN , RED } myModule_Color2; typedef struct myModule_MyUnion { myModule_Color2 _d; struct myModule_MyUnion_u { DDS_Long m1 ; DDS_Long m2 ; }_u; } myModule_MyUnion ;	typedef enum myModule_Color2 { myModule_Color2_GREEN , myModule_Color2_RED } myModule_Color2; typedef struct myModule_MyUnion { myModule_Color2 _d; struct myModule_MyUnion_u { DDS_Long m1 ; DDS_Long m2 ; }_u; } myModule_MyUnion ;
C++	typedef enum myModule_Color2 { GREEN , RED } myModule_Color2; typedef struct myModule_MyUnion { typedef struct myModule_MyUnionSeq Seq; ... myModule_Color2 _d; struct myModule_MyUnion_u { DDS_Long m1 ; DDS_Long m2 ; }_u; } myModule_MyUnion ;	typedef enum myModule_Color2 { myModule_Color2_GREEN , myModule_Color2_RED } myModule_Color2; typedef struct myModule_MyUnion { typedef struct myModule_MyUnionSeq Seq; ... myModule_Color2 _d; struct myModule_MyUnion_u { DDS_Long m1 ; DDS_Long m2 ; }_u; } myModule_MyUnion ;
C++ Namespace	namespace myModule { typedef enum Color2 { GREEN , RED } Color2; typedef struct MyUnion { typedef struct MyUnionSeq Seq; ... myModule::Color2 _d; struct MyUnion_u { DDS_Long m1 ; DDS_Long m2 ; }_u; } MyUnion ; };	namespace myModule { typedef enum Color { Color_GREEN , Color_BLUE } Color; typedef struct MyUnion { typedef struct MyUnionSeq Seq; ... myModule::Color2 _d; struct MyUnion_u { DDS_Long m1 ; DDS_Long m2 ; }_u; } MyUnion ; } ;

[RTI Issue ID MICRO-2718]

8.3.9. Incorrect Documentation Regarding Changeability of QoS

The previous release’s documentation incorrectly stated that some QoS are changeable, when they are not. This has been fixed.

The DomainParticipantFactory.EntityFactoryQosPolicy is always changeable. The following are changeable until the entity is enabled:

• DomainParticipant.EntityFactoryQosPolicy

• Publisher.EntityFactoryQosPolicy

• Subscriber.EntityFactoryQosPolicy

[RTI Issue ID MICRO-2749]

8.3.10. Unexpected Behavior when Copying a DDS_UnsignedShortSeq with 0 Length

When copying a DDS_UnsignedShortSeq with 0 length, the destination sequence length was not set to 0. This issue has been fixed.

[RTI Issue ID MICRO-2756]

8.3.11. Incorrect Range Documented for DDS_ResourceLimitsQosPolicy.max_samples

The range for DDS_ResourceLimitsQosPolicy.max_samples was incorrectly documented as max_samples >= max_instances * max_samples_per_instance.

While that is correct for Connext DDS Micro Cert, the correct range for Connext DDS Micro is max_samples >= max_instances.

The documentation has been corrected.

[RTI Issue ID MICRO-2757]

8.3.12. Wrong Compiler Option for AUTOSAR Elektrobit Platform caused ‘double’ to Compile as 4 Bytes instead of 8

CMake files include an option to optimize doubles as floats when compiling for the AUTOSAR classic Elektrobit platform. This caused the serialization and deserialization of type double to fail.

This optimization has been removed; now the size of type ‘double’ is 8 bytes when compiling for the AUTOSAR classic Elektrobit platform.

[RTI Issue ID MICRO-2823]

8.3.13. Log Message with Random Characters Printed

In some cases, a log message was printed with random characters. For example:

$ Alignment32 id\:000000\,sig\:06\,src\:000000\,op\:flip1\,pos\:1

[1612981807.603703999]ERROR: ModuleID=5 Errcode=20021 X=1 E=1 T=1
��hV�F��~ycV
/:0/:

This issue has been resolved.

[RTI Issue ID MICRO-2877]

8.3.14. Event Masks of Semaphores in AUTOSAR Port were Calculated Incorrectly

Event masks of semaphores in the AUTOSAR port were calculated incorrectly. This only affected semaphore implementation and Waitsets. This issue has been resolved.

[RTI Issue ID MICRO-2953]