Versions
Note
Some of the information in this chapter is only applicable for the Commercial Edition of Code RealTime since it includes the source code for the TargetRTS. With the Community Edition comes only precompiled versions of the TargetRTS for a limited number of commonly used target configurations.
It's common to extend and modify the TargetRTS with your own utilities and customizations. In this case you will build your application against a copy of the TargetRTS that contains these changes. However, when a new version of the TargetRTS is released, you then must incorporate the changes in that new version into your own copy of the TargetRTS. This document helps with this process by documenting all changes made in the TargetRTS. It also describes some strategies for more easily managing multiple versions of the TargetRTS.
Note
The version of the TargetRTS is defined in the file RTVersion.h by means of the macro RT_VERSION_NUMBER.
Patch Files
To simplify the process of adopting changes from a new version of the TargetRTS, so called patch files are provided in the folder TargetRTS_changelog (located next to the TargetRTS folder). The patch files have names <from-version>_<to-version>.patch and contain all changes made from one version to another. You can use the command-line tool patch to automatically apply the changes of a patch file to your own copy of the TargetRTS.
For example, to apply the changes from version 8000 to version 8002, go to the folder that contains the TargetRTS and TargetRTS_changelog folders and run this command:
patch -p3 < TargetRTS_changelog/8000_8002.patch
You can also downgrade the version of the TargetRTS by running the same command but with the -R flag.
Note
The patch command is included in Linux and Unix-like operating systems, but on Windows you have to download it separately. You can for example get it through the Git for Windows set of tools.
The patch files in the TargetRTS_changelog folder have been created by a Bash script TargetRTS/tools/createPatch.sh. You can use this script if you have your version of the TargetRTS in a Git repo and want to produce a patch file for the changes you have made to the TargetRTS. You can then later use that patch file to apply your changes to a newer version of the TargetRTS.
Whether it's best to adopt changes in a standard TargetRTS into your version of the TargetRTS, or to do the opposite, i.e. adopt your changes into a standard TargetRTS, may depend on how big changes you have made. If your changes are small and limited the latter may be easiest, while if you have made substantial changes the former may be the better option.
Change Log
Below is a table that lists all changes made in the TargetRTS since version 8000 (which were delivered with Code RealTime 1.0.0). For changes in older versions of the TargetRTS, which were done for Model RealTime, see this document.
JSON decoder
A new decoder class RTJsonDecoding is now available for decoding messages and data from JSON. JSON produced from data by the JSON Encoder (RTJsonEncoding) can be decoded back to (a copy of) the original data.
Building without rtperl
New macros were added in makefiles to support building generated applications without using rtperl.
JSON parser
A new class RTJsonParser can be used for parsing arbitrary JSON strings. It has a more general use than RTJsonDecoding which is specifically for decoding JSON that has been produced by RTJsonEncoding. See this chapter for more information.
Script for creating TargetRTS patch files
A Bash script createPatch.sh is now available in the tools folder of the TargetRTS. It can be used for producing patch files describing the differences between two versions of the TargetRTS. See Patch Files for more information.
Pointers in JSON encoding/decoding
Data of pointer type is now encoded to a string by the JSON encoder (RTJsonEncoding) and can be decoded back to a memory address by the JSON decoder (RTJsonDecoding).
Align terminology in comments
Several comments were updated to align the terminology used in Code and Model RealTime. This was done so that the Doxygen documentation that is generated from the TargetRTS header files will be easy to understand for users of both products.
Configurable max TCP connections
The RTTcpSocket class has a new function setMaxPendingConnections() which can be used for setting the maximum number of clients that can connect to the TCP socket. Previously this limit was always 5, and this is still the default in case you don't call this function to change it.
Improved implementation of JSON parser
The RTJsonParser now has an improved recursive implementation that uses a map instead of a vector for storing keys and values in the RTJsonResult object. The new implementation provides new functions RTJsonResult::keys_begin() and RTJsonResult::keys_end() which allows to iterate over the keys in the parse result without knowing their names.
JSON encoding/decoding for RTByteBlock
The RTJsonEncoding and RTJsonDecoding now support JSON encoding/decoding for objects of the RTByteBlock class.
New target configuration for MacOS on AArch64
A new target configuration for the Clang 15 compiler for MacOs with ARM processor is now available. It has the name MacT.AArch64-Clang-15.x.
New free list macros
New TargetRTS configuration macros are now available in include/RTConfig.h for configuring the free list. The new macros are MIN_FREE_LIST_SIZE, MAX_FREE_LIST_SIZE and RTMESSAGE_BLOCK_SIZE. Previously these configuration settings were hard-coded at a number of places in the TargetRTS implementation, but now they are handled like all other configuration settings.
Static analysis warning reductions
Some static analysis tools previously reported a few warnings on the TargetRTS source code which now have been fixed.
- Reordered member variables according to their types to potentially reduce the size of the container struct or class on certain platforms
- Moved definition of RTInjector::getInstance() from inline function to
RTInjector.cppto ensure it always returns a singleton object - Removed the unused local variable
attachedin the implementation of RTDebugger::printActorInfo() - Removed unused #includes
- Removed duplicated assignments of
remotePortandremoteIndexin RTProtocol::reply() - Changed type of the
need_lockvariable in RTProtocol::reply() from int to bool - Removed dead code
- Improved initialization of a memory buffer in RTToolSetObserver::sendTxBuffer()
New debugger API "getChildren"
A new debugger API for getting a JSON representation of the runtime structure of a debugged application is now available. It includes information about the capsule instance tree and metadata about the debugged application which is available in the TargetRTS. It is used by the Art Debugger for populating the Art Debug view when debugging an application in Code RealTime.
Handle type names containing spaces in encoding/decoding
Type descriptor names for primitive types that contain spaces have been changed to use an underscore (_) instead of a space. This affects how values of such types are encoded/decoded. For example the value 4 of type unsigned long will now be encoded as unsigned_long 4. This change was done since during decoding a space is used for separating the type name from the value. Previously it was therefore not possible, while debugging, to send events with a data parameter typed by such types, but after this change it now works. Note that if your application somehow relies on the specific encoded format for values of types with a space in their names, it must be updated to accomodate for this change.
Extend debugger API "getChildren" to obtain active state
The debugger API "getChildren" now includes information about the state that is initially active for each capsule instance.
Long double
The TargetRTS now supports long double as other predefined C++ types. The Log port API was extended to allow logging long double data, and it is also supported in encoding/decoding.
RTCONFIG_INFO
A new configuration macro has been added for controlling if the config_info array should be included in src/RTMain/mainLine.cc. Previously this array was always included, but not used, which could cause compiler warnings.
Protocol constructor initilizer ordering
The order of initializers in the Protocol constructor was changed to match the declaration order of the initialized member variables. This avoids a compiler warning.