Running RTI Connext DDS Micro on Hercules TMS570 MCUs [tutorial] Reply


Is your product based on Hercules TMS570 MCUs? Do you need to enable scalable, real-time, reliable, high-performance and interoperable data exchanges in your system? Are you really into tutorials and learning how to do new things on small devices? If you answered yes to any of these questions, this blog post is for you!

Keep reading to be introduced to two RTI products that were designed with for small-footprint devices in mind, the Hercules MCU, and gain access to a FREE tutorial I put together. This tutorial will enable you to quickly get started, and realize the immense value Connext DDS Micro can bring to your embedded solution, today.

The Products

RTI Connext DDS Micro is RTI’s product targeting small-footprint devices, and it was also the basis for RTI Connext DDS Cert, a product for small-footprint, safety-critical use cases. While Connext DDS Micro is distributed with binaries for a few common architectures, it is also distributed with the full source code since we anticipate the majority of our users will compile, and even port, to their specific platform. RTI Connext DDS Micro is based on the DDS standard and provides high-level publish/subscribe communication. It complies with the Object Management Group (OMG) Data Distribution Service (DDS) for Real-Time Systems standard.

RTI Connext DDS Cert provides a complete certification package for the flight-critical avionics standard DO-178C Design Assurance Level A (DAL A). This package also provides the basis for certification to other standards including IEC 61508 for industrial systems, IEC 60601 for medical devices and ISO 26262 for automotive systems.

Hercules MCUs

The Hercules TMS570 microcontroller (MCU) family enables Hercules customers to easily develop safety-critical products. Developed to meet the requirements of ISO 26262 ASIL D and IEC 61508 SIL 3 safety standards and qualified to the AEC-Q100 automotive specification, this ARM® Cortex®-R based family offers several options for performance, memory and connectivity. Lockstep CPU architecture, hardware BIST, MPU, ECC and on-chip clock and voltage monitoring are some of the key functional safety features available.

The key features of Hercules TMS570 family are: up to 300MHz, ARM Cortex-R CPU (options with Floating Point), Lock-Step CPUs with error-detection logic, 256KB to 4MB of embedded flash, 12-bit ADC with up to 41 channels, Ethernet, FlexRay, CAN, LIN, timers for PWM and input capture, etc.

Companies developing industrial, medical or automotive products can use a Hercules TMS570 MCU as a safety-certifiable platform and run RTI Connext DDS Micro or RTI Connext DDS Cert, which will provide a safety-certifiable communications infrastructure, eliminating the need to develop custom communications code and any requisite certification evidence.

The FREE Tutorial!

A tutorial and sample project, which will help developers getting started, can be found here.

We would love your feedback about running RTI Connext DDS Micro or RTI Connext DDS Cert on Hercules TMS570 MCUs! Please be sure to check out the RTI Connext Micro forum, located on the RTI Developer Community site,

Compiling RTI Connext DDS Micro For The Raspberry Pi IoT Device 1


RTI Connext DDS Micro is RTI’s product targeting small footprint devices, and it was also the basis for RTI Connext DDS Cert, a product for small footprint, safety critical use cases. While Connext DDS Micro is distributed with binaries for a few common architectures, it is also distributed with the full source-code since we anticipate that the majority of our users will compile, and even port, to their specific platform.

The Raspberry Pi is a popular IoT device with numerous sensors and add-ons available, and is a great device to run Connext DDS Micro on. In this blogpost, I’ll cover how to easily compile Connext DDS Micro for the Raspberry Pi. Please note that porting Connext DDS Micro to a new OS/platform is not covered in this blogpost!

Compiling Raspberry Pi IoT Device

The author’s Raspberry Pi (bottom) with the Gertboard I/O board (top).

CMake is the preferred tool to build Connext DDS Micro because it simplifies configuring the Connext DDS Micro build options. Note that CMake itself does not compile anything. CMake is used to generate build files for a number of environments, such as make, Eclipse CDT, Xcode and Visual Studio. Once you have your build file, any of the tools I mentioned can then be used to build Connext DDS Micro. This system makes it easier to supporting building Connext DDS Micro with different tools. CMake is easy to install with prebuilt binaries and has no dependencies on external tools. If you have not yet installed CMake, please do so now.

We’ll assume a Linux development host for the remainder of this blogpost. Start the CMake GUI from a terminal window, preferably in the top-level Connext DDS Micro source directory. Note that there are two directories under source: Unix and Windows. The only difference between these two is that the source in the Unix directory has Unix style line-endings, and the source in the Windows directory has Windows style line-endings.

> cmake-gui .

(Note the period after cmake-gui!)

Make sure the path to the source and binaries is the location of the Connext DDS Micro source-code.

  1. Press “Configure”.
  2. Select a generator (I typically use Eclipse CDT Unix Makefiles).
  3. Select “Specify options for cross-compiling”
  4. Type “Linux” as Operating System
  5. Type in a Linux version number
  6. Type arm for Processor
  7. Select the C and C++ compiler you want to use (full path to the executables).
  8. Select the compiler root as the Target Root. RTI Connext Micro does not rely on any libraries other than libc and libc++
  9. Press “Done”
  10. Press “Configure”
  11. Check “Grouped”
  12. Expand RTI Connext Micro and select your build options.
  13. Type a target name for RTIMICRO_BUILD_TARGET_NAME, for example armv6Linux3gcc4. The target name is sent as part of the participant discovery but is not used by RTI Connext Micro.
  14. Press “Configure”. All red lines should disappear.
  15. Press “Generate”.
  16. Exit the GUI.

In the terminal window:

> make VERBOSE=1

The libraries will be placed in:

./lib/<target name>/

When the libraries are built “RTI Style” the libraries will have the same names as the ones RTI distributes. The libraries are:

  • rtime is the core library, including the DDS C API
  • discdpde is the Dynamic Participant Dynamic Endpoint plugin
  • discdpse is Dynamic Participant Static Endpoint plugin
  • rhsm is Reader History plugin
  • whsm is Writer History plugin
  • cpp is the C++ API

The following conventions are used for library naming:

  • Static libraries have a z suffix, shared libraries does not have an additional suffix
  • Debug libraries have a d suffix, release libraries does not have an additional suffix

You can also build a single library if that is easier to work with. For more advanced build configurations, such as compiler and linker options, run cmake-gui again, and this time check the “Advanced” checkbox. Next, expand CMAKE to see available build options.

This blogpost only described recompiling Connext DDS Micro for a supported platform (Linux and GCC). The next step is to port Connext DDS Micro to a new OS, or use an unsupported system or compiler.

We would love your feedback about RTI Connext DDS Micro! Please check out the RTI Connext Micro forum, located on the RTI Developer Community site,


Visualizing Data in Micro Sensor Applications Reply


I can’t believe I have been at RTI for more than 12 years now! In that time, I have seen the evolution of the OMG Data Distribution Service from its early days, as well as the realization of RTI’s mission to create the best DDS implementation available.

During our history with DDS, we have come across applications that could only support very low memory resources. It may seem remarkable today to field a system with less than 8 MB of RAM, but we have seen application requirements that specify far less memory than that. A while back we set out to create a version of DDS for resource-limited devices. We call it RTI Connext DDS Micro and we have built it into applications with under 128 K of RAM. We’re pretty excited about that!

To achieve this capability, Connext DDS Micro supports a subset of the functionality of a complete Connext DDS implementation. I would estimate the level of functionality to be around 80% of the standard DDS product we provide. Within this 80%, we support critical capabilities like reliability, keys/instances, liveliness, durability, and so on. And because we preserved the RTPS (Real Time Publish Subscribe) wire format protocol, DDS Micro applications can communicate with regular DDS applications and visa versa.

As I mentioned above, in order to reduce RAM usage, we had to make a few sacrifices along the way. One of the features we eliminated was the ability for a participant to send out data type information on discovery. This feature is an optional part of the RTPS protocol and is in use today, when enabled, by regular DDS participants. In fact, this is a key feature we rely on when using our tools with DDS applications. For example, our Admin Console was upgraded last year with the ability to visualize data directly within the tool. This means that the Admin Console tool is now able to subscribe directly to data being published by DDS applications. You can see the Admin Console data visualization tools in action here: overview & deep dive.

When this feature first came out, it relied on the ability of DDS participants to share data type information on discovery. Once learning of the data type, and creating a subscription to the topic using that data type, Admin Console could display live data as it was being published. Here is an example of Admin Console displaying a patient heartbeat waveform published by a DDS application:


This is a great feature that many developers of DDS applications leverage today. However, it cannot be used with DDS Micro applications because these applications do not send out data type information on discovery.

To fix this limitation, our great tools team added a new capability within Admin Console. Instead of relying solely on data type information being sent out on discovery, the Admin Console now has the ability to configure a data type directly into the tool using an XML file to describe the data type or set of data types. When subscribing to a topic within Admin Console, you can now source in an XML file, as seen in this screenshot:


Once you pull up the subscribe function, you have the option to “Load Data Types from XML file.” From there you can select an XML file:


The content of the XML file is basically a description of the FunctionGeneratorType as shown below:


Then, with the correct data type information loaded, Admin Console is able to subscribe to the publisher.

In the following example, the DDS Micro publisher is a simple Function Generator publisher that sends out streaming sensor data and emits sine wave, square wave, and triangle wave data. Here is the visualization of that streaming DDS Micro publisher.


I have to say, it’s great being here at RTI to see all of these capabilities come together to provide a platform for the Industrial Internet of Things. I can’t wait to see the innovations coming in the future for enabling even more devices to share their data.

For more information, see RTI Connext DDS Micro and RTI Administration Console.