Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

How is SYS/BIOS related to XDCtools and RTSC?

From Texas Instruments Wiki
Jump to: navigation, search

Sysbios image.png
SYS/BIOS uses underlying technology provided by Real Time Software Components (RTSC).
  • RTSC is an open-source specification within the ecosystem for providing reusable software components (called "packages") for use in embedded systems.
  • XDCtools is the actual product that contains all the tools necessary for you to use the SYS/BIOS components and configure your application. XDCtools is installed as part of Code Composer Studio (CCS).

RTSC and XDCtools are important to SYS/BIOS users because:

  • SYS/BIOS is delivered as a set of RTSC packages containing the modules that make up the RTOS.
  • XDCtools provides configuration tools you use to create and build a static configuration as part of your application. This *.cfg configuration file specifies:
    • Which modules from XDCtools, SYS/BIOS, and other components to include in the run-time image.
    • What static instances of RTOS objects to create. For example, these include tasks and semaphores.
    • Settings for parameter values for modules and objects.
  • XDCtools provides critical APIs that are used by SYS/BIOS and other related software components. These include memory allocation, logging, and system control.

The RTSC-pedia web site describes RTSC and XDCtools in more detail. In particular, it provides information for developers planning to create RTSC packages. It is also useful if you plan to edit configuration scripts with a text editor rather than using the XGCONF graphical editor provided withing CCS.

SYS/BIOS as a set of RTSC packages

Package hier.png
SYS/BIOS is implemented as a set of RTSC packages, each of which delivers a subset of the product's functionality. The RTSC standard recommends a naming convention for packages to aid readability and to ensure that packages delivered from different sources don't have namespace collisions that will pose problems for the system integrator. If you are familiar with the Java package naming convention, you will find it to be quite similar.

SYS/BIOS packages conform to this convention with names that consist of a hierarchical naming pattern; each level is separated by a period ("."). Usually, the highest level of the name is the vendor ("ti"), followed by the product ("sysbios"), and then followed by the module and submodule names (for example, "knl" and "Clock"). So, the full name to reference the Clock module is ti.sysbios.knl.Clock.

These names have the added benefit of reflecting the physical layout of the package within the file system where SYS/BIOS has been installed. For example, the ti.sysbios.knl package files can be found at


Configuring SYS/BIOS using RTSC

Config flow1.png
Configuration is an essential part of using SYS/BIOS and is used for the following purposes:
  • It specifies which modules will be used.
  • It can create objects statically.
  • It performs integrity checks between packages to make sure they are compatible for integration.
  • It sets configuration parameters for modules and objects to change their default behavior.

An application's configuration is stored in one or more script (.cfg) files. These are parsed by a command-line tool provided by XDCtools. The output from the command line tool includes C source, C header, compiler option, and linker command files that will be compiled and linked into the end application. When you build a CCS project, this configuration build step occurs before the normal compiler and linker steps. The following diagram depicts a build flow for a typical SYS/BIOS application.

The configuration .cfg file uses modified JavaScript syntax to set properties and call methods provided by objects. You can create and modify such configuration files in two different ways: by writing the .cfg file in a text editor or by using the visual configuration tool (XGCONF) provided with Code Composer Studio.

In CCS, you can control how the .cfg file is processed in the Build Properties dialog for the project. Choose the following categories in the Properties dialog to access RTSC/XDCtools options:

  • RTSC Package Path and Target Settings: Select the CCS Build (CCSv4) or CCS General (CCSv5) category and then choose the RTSC tab. See Setting RTSC Build Properties in CCS.
  • XDCtools Command-Line Settings: Select the C/C++ Build > XDCtools (CCSv4) or CCS Build > XDCtools (CCSv5) category. See the xs and configuro command-line help.

Commonly-used RTSC modules

The XDCtools run-time package (xdc.runtime) contains a number of different modules that provide basic system services. Your SYS/BIOS application can make use of these. By default, all SYS/BIOS applications automatically add the xdc.runtime package during build time.

The functionality provided by the xdc.runtime package can be roughly partitioned into the following four categories. The Modules column lists modules that may be useful in many SYS/BIOS applications.

Category Modules Description
System Services System Basic low-level "system" services. For example, character output, printf-like output, and exit handling.
Startup Allows functions defined by different modules to be run before main().
Memory Management Memory Creates/frees memory heaps statically or dynamically.
Diagnostics Log Allows events to be logged and then passes those events to a Log handler.
Assert Provides for configurable assertion diagnostics.
Error Allows raising, checking, and handling errors defined by any modules.
Timestamp Provides time-stamping APIs that forward calls to a platformspecific time stamper (or one provided by CCS).
Diags Allows diagnostics to be enabled/disabled at either configuration- or run-time on a per-module basis.
Concurrency Support Gate Protects against concurrent access to critical data structures.

See the xdc.runtime overview and the xdc.runtime reference documentation.