From RTSC-Pedia

[printable version]  [offline version]

offline version generated on 04-Aug-2010 21:08 UTC

Overview of RTSC

Brief introduction to RTSC and XDCtools

What is RTSC?

Real-Time Software Components (RTSC, pronounced "rit-see") is a program designed to bring component based development to embedded C programmers. Unlike enterprise workstation-based component models, RTSC components (called "packages") are optimized for real-time embedded systems where resource constraints make it impractical to use enterprise models such as JavaBeans or Corba, for example.

XDCtools is a product that contains all of the tools necessary to create, test, deploy, install, and use RTSC components. This product - currently available from TI (from here) - includes tools and standards for API development, static configuration, and packaging. RTSC components have hardware-neutral formal interfaces, are configurable offline to optimize memory and performance, and support custom automation in the development environment via a scripting language.

The main benefit of RTSC is that it standardizes the delivery of target content and makes it easier for target content to be included in applications. RTSC is unique in that components also include code that runs on "Rich Client Platforms" such as development workstations. This code provides a bridge between the component's target content, written in C/C++, and a variety of development tools that manage the component throughout its life-cycle: from creation, integration, and testing to the real-time monitoring of the target content in deployed end-equipment. With the target content being written in C/C++, RTSC components not only leverage existing code bases but are also usable in traditional C development environments.

The users of RTSC are divided into developers we call "consumers" and "producers." Consumers integrate target content packages—DSP algorithms, device drivers, TCP/IP stacks, real-time OSes, and so on—into their own applications. Producers create the packages used by consumers.

A RTSC "package" is a named collection of files that form a unit of versioning, update, and delivery from a producer to a consumer. Each package is embodied as a specially-named directory (and its contents) within a file system. Packages are the focal point for managing content throughout its lifecycle. All packages are built, tested, released, and deployed as a unit.

A RTSC "repository" is simply a directory that contains packages. The dots in the name of a package, interface, or module refer to its location within the repository. For example the ti.sysbios.knl.Task module would be located at ti/sysbios/knl with respect to a repository directory named in the RTSC "package path". The package path is simply a list of repositories containing packages installed by the user.

This overview is intended for use by consumers who need just enough to understand how to use a RTSC package. However, producers must also be familiar with the concepts in this document in order to move beyond it and understand how to create packages. Producers often function as consumers, for example, to test the content they've produced. For a more detailed description of RTSC, all users are strongly encouraged to read the RTSC whitepaper "Introducing RTSC".

RTSC and XDCtools Terminology

RTSC and the XDCtools product use a number of terms that you will need to be familiar with:

• Packages: These serve as general-purpose containers for modules and interfaces as well as other software artifacts. Packages are the focal point for managing content throughout its life-cycle. All packages are built, tested, released, and deployed as a unit.
• Modules: These encapsulate a related set of types and functions. They have both an external specification and a concrete internal implementation. A module optionally manages a single instance type, which is analogous to a C++ class.
• Interfaces: These are effectively "abstract modules". They have a specification without an implementation. Other modules and interfaces can inherit the specification. An interface defines a collection of related types, constants, variables, and functions. A single C (and/or asm) header file defines the interface.

• Repository: A directory in which one or more packages are installed. Repositories can contain only one version of a package. So, side-by-side installations of two different versions of a package require two repositories. The user has complete control over the number and names of repositories.
• Package Path: An ordered sequence of repositories that are searched when locating a package's file. Like the PATH environment variable used to locate commands, the package path is set by the user and allows source code to reference package files without using absolute paths. Simple adjustments of the package path can be used to quickly switch between different versions of one or more packages.
• Target content: Software bound into an application program executing on a particular hardware platform.
• Meta content: Host-based content that plays an active role in the design-time configuration as well as the run-time analysis of target programs.
• Client applications: The application that consumes packages and calls functions in interfaces to perform application actions.

[printable version]  [offline version]

offline version generated on 04-Aug-2010 21:08 UTC