龙的电器售后:Introducing RTSC - RTSC-Pedia

Introducing RTSC

Learning about Real-Time Software Components

Welcome to the world of RTSC.... To help you learn more, this document provides an important introduction to the what, why, and how of RTSC. Once grounded in concepts and terminology fundamental to RTSC, we'll explore two complementary roles which you may find yourself playing as you work with RTSC—that of producer and consumer of Real-Time Software Components.

This introductory document also contains links to a handful of other technical documents and support resources which together serve as "next-steps" as you further explore the world of RTSC.

In April 2008, our proposed RTSC Project passed its creation review at eclipse.org, joining this growing open-source community. Moving forward, we plan to re-license the RTSC technology outlined in this document—initially developed by Texas Instruments and currently used in a number of its flagship products—for broader use by embedded software developers targeting any hardware platform.

Contents

• 1 Bringing component technology to embedded C
• 2 From producer to consumer under RTSC
• 3 A quick tour of the XDCtools product
• 4 Additional RTSC resources
• 5 See also

Bringing component technology to embedded C

The producer/consumer dilemma.  As C programmers developing embedded applications, we'll generally play the role of producer and consumer of target software content:

• we'll produce libraries of callable functions, often with an eye towards re-use from one application program to the next; but then at the same time,

• we'll consume these sorts of libraries by calling their functions, perhaps to produce other libraries but ultimately for use within an executable program targeted for a particular hardware platform.

As embedded systems and software become ever more sophisticated and complex, a natural tension that already exists between these two roles becomes ever more pronounced. As content producers—always looking to minimize non-recurring engineering costs through greater re-use—we'll favor making our software as portable, as flexible, and as general-purpose as possible. As producers, our challenge becomes one of managing content fan-out—leveraging a single code base across multiple instruction-sets, multiple tool-chains, and multiple application settings.

Playing the role of content consumer, however, our values can reverse rather rapidly. Always looking to minimize recurring end-equipment costs—less MIPs, less memory, less power—we'll give up a measure of software portability, flexibility, and generality in exchange for code that has been optimized, tailored, and specialized for the particular application at hand. Needless to say, priorities like these often thwart any efforts aimed at broad software re-use.

But software re-use is important—especially as engineering schedules and resources remain inversely proportional to the growing list of software-based features demanded in next-generation end-equipments. With today's software producers truly distributed in time/space, often working independently from one another in different parts of the world, the traditional role of content consumer will further expand to one of software integrator—combining and assembling these elements in novel ways that their original producers had not necessarily anticipated or even imagined.

Beyond concerns about trading system performance for software re-use, our challenge as consumers becomes one of managing content fan-in—reconciling a diverse array of tools, formats, and techniques used by different producers to describe, deliver, and deploy individual software elements. The naive view that content producers can simply ship C headers/libraries to content consumers belittles the problem here. Lacking any common ground on matters ranging from portable types and function names to directory structure and version compatibility, interoperability amongst different software elements becomes intractable as the number of content producers grows to even a handful. Once again, concerted attempts at broad software re-use will come up short.

The promise of software components.  Components have become a pillar of modern software engineering practices. Beginning with COM and CORBA in the 1990s, contemporary programming languages like Java or C# innately support the design, delivery, and deployment of software components. Thanks to component frameworks aligned with these languages, present-day applications are more modular, more scalable, and more flexible than ever before; software components also promote greater levels of re-use from one application to the next. Equally important, thriving ecosystems of component producers/consumers working in contemporary programming languages validate how establishing some common ground can successfully overcome the fan-out/fan-in challenges mentioned earlier.

While overwhelmingly successful in the mainstream, component technology has had very little impact on the development of embedded applications where C (still!) remains the programming language of choice. Given the constraints of time, space, and power under which most embedded systems must operate, the run-time overhead typically incurred by mainstream languages and frameworks is simply too high a price to pay. And yet, given the rising complexity of embedded applications coupled with a desire to field portable (and re-usable) software across a range of systems, we continually struggle with trade-offs between flexible, generic—yet inefficient—building-blocks versus more specialized elements optimized for one particular application setting or hardware platform.

With RTSC (pronounced rit-see), however, we can finally resolve this dilemma between producers/consumers in the world of embedded C programming. Requiring no more than an ANSI C compiler, RTSC effectively takes the C language to new heights by introducing supplementary tooling and infrastructure aligned with modern programming practices, yet responsive to the unique challenges of producing/consuming embedded software. Simply a better way to leverage C, RTSC enables a higher-level form of programming—one that encourages producing more modular, more scalable, and more flexible target-content—without necessarily impacting system performance through additional run-time overhead.

We believe that taking RTSC open-source can accelerate adoption across an otherwise fragmented community of nearly a half-million embedded C programmers.

From producer to consumer under RTSC

RTSC introduces tooling and infrastructure that articulates a five-phase flow spanning the life-cycle of embedded software components implemented in C—from component production to component consumption.

As we touch upon each phase of the RTSC flow, bear in mind that the familiar steps of compiling and linking C libraries and programs remain unchanged—RTSC strives to leverage and enhance C, not replace it.

1  Specification

Like any component-based flow, RTSC begins with well-specified components—a necessary requirement to enable downstream consumers to mix-and-match components sourced from different producers, freely substituting one component for another based upon common specifications. Acknowledging the limits of C in this regard, RTSC introduces a special C-like specification language used to formally define programmatic boundaries between producer and consumer in a more expressive and robust manner than possible with C headers; in fact, RTSC generates C .h files used by producers and consumers alike from specifications sourced in this (higher-level) language.

The RTSC specification language promotes three important programming constructs not directly supported in C, but necessary when using C to implement components participating in ever larger and more complex applications:

module

a cohesive set of constants, types, and functions with a public specification and a private implementation

interface

an abstract module (spec only) that other interfaces may inherit and that modules will ultimately implement

package

a higher-level programmatic namespace that in turn contains modules/interfaces within its scope

Not surprising, modern programming languages like Java and C#—which already support higher-level constructs very similar to these—do not necessarily require a companion specification language as does C.

2  Implementation

As a producer, you'll typically implement spec'd RTSC modules in C (though you can use C++ or assembly code where desired or appropriate) using a very clean, crisp, and portable style of programming that is both easy-to-read and fun-to-write. In general, though, RTSC modules will carry two implementations that nicely complement one another:

target-implementation

C-based content for later consumption within target programs executing on embedded hardware platforms

meta-implementation

higher-level meta-content that guides downstream configuration and analysis of these target programs

Whereas C-based target-content typically executes on a resource-constrained platform, meta-content invariably executes on your resource-rich host computer and enjoys access to virtually unlimited resources; skillful partitioning of functionality between these two complementary domains helps fulfill RTSC's promise of higher-level programming and higher-levels of performance. Again recognizing the limitations of C, RTSC introduces a dedicated meta-language based on industry-standard JavaScript.

3  Packaging

RTSC packages serve as both logical and physical containers. Besides providing a programmatic namespace that scopes spec'd RTSC modules/interfaces, each RTSC package has a concrete manifestation as a file-system directory that follows a prescribed set of conventions, but otherwise can house virtually any sort of software artifact originating with the component producer—specs, headers, libraries, scripts, docs, even other packages. To help maintain its internal integrity, each RTSC package is built, released, and ultimately deployed as an indivisible element—that is to say, all of its content remains in place throughout the component life-cycle.

To help manage the producer's fan-out challenge, RTSC packaging streamlines the process of building multiple libraries using multiple C compilers by leveraging instances of a basic abstraction termed a target—a recipe that prescribes the steps necessary to compile C source files for a particular instruction-set and memory-model using a particular compiler tool-chain. Additional mechanisms enables producers to fabricate side-by-side releases of a particular package, to specify dependencies of one package on other RTSC packages, and to characterize compatibility with earlier versions of the same package.

On the consumer's side, standardizing upon RTSC packages as the unit of delivery goes a long way towards mitigating the fan-in challenge. RTSC packages also standardize content deployment by leveraging a proven physical design (patterned after Java) that builds upon three basic concepts:

package directory

a directory whose relative path-name matches the package-name and which houses the package's contents

package repository

an arbitrarily-named directory that in turn contains canonically-named package directories

package path

an ordered list of package repositories used to locate packages and their contents using relative path-names

By finding some common ground here, automated tooling can easily validate the completeness and consistency of a set of deployed RTSC packages—enabling a more friction-free flow of content from producers to consumers.

4  Configuration

From the consumer's perspective, RTSC configuration serves as the focal point for component integration—combining and assembling uniformly packaged target-content elements delivered by multiple producers for ultimate use within an application program executing on some hardware platform. Here again, uniformity becomes the operative word as we strive to streamline the passage of content from producers to consumers.

The process begins with a dedicated configuration script—sourced in the RTSC meta-language—which identifies each software element required within a corresponding target-program. The configuration process eventually yields additional target-content artifacts that in turn become inputs to your compiler/linker during final program build. To coordinate these latter steps, content consumers will designate a RTSC target and platform as additional configuration inputs—recipes for compiling and linking target-content that help shape configuration outputs.

Within the configuration script—consider it the application's meta-program—the content consumer identifies each spec'd module included within the corresponding target-program. While the target-program ultimately uses the module by calling its public functions, its meta-program will typically tailor the module's run-time behavior by altering its public configuration parameters. A unique feature of the RTSC specification language, module configuration parameters transition from read-write variables in the meta-program to read-only constants in the target-program, and play a central role in "specializing" otherwise generic software elements for the application at hand.

Once the consumer's configuration script has finished execution, all RTSC packages contributing target-content to this application become active contributors to the configuration process through corresponding meta-content supplied by the producer. Systematically invoked during the tail-end of configuration, RTSC meta-content enables component producers to programmatically participate at this all-important juncture in several ways:

• by importing other RTSC modules and assigning their configuration parameters;
• by issuing errors or warnings if anything seems "wrong" with the current configuration;
• by guiding generation of linker-commands customized for this program and its platform; and
• by automatically synthesizing C code using knowledge gained throughout the configuration process.

As a final point, we can't stress enough that RTSC configuration is an automated process, supplanting past practices whereby content consumers would hand-edit producer-supplied files of linker commands or C code/data. By leveraging the virtually unlimited resources of your host computer—to execute meta-content before consuming corresponding target-content—the net result becomes early detection of serious problems that (at best) may yield obscure downstream compiler/linker errors or else (at worst) may trigger run-time behavior with fatal consequences.

5  Analysis

Besides guiding the integration-time consumption of RTSC modules into executable programs, producer-supplied meta-content can also actively partake in the run-time analysis of module behavior once execution has commenced (or even terminated). Given the ability to read the program's data memory—via a host-based debugger, an embedded program monitor, or even a snapshot of program state saved to disk—RTSC analysis tooling first decodes a module's target-implementation state-structures into equivalent JavaScript objects before calling upon the same module's meta-implementation to transform these objects into a more meaningful view of the underlying state.

Complementing this state-oriented perspective, another dimension of RTSC analysis involves merging, filtering, and interpreting streams of time-stamped events sourced during program execution; events can be retained in target-side memory or else uploaded in real-time using an appropriate output device on the underlying hardware platform. By calling upon a special Log module furnished by RTSC, producers and consumers alike can emit meaningful events from anywhere within their C code. Furthermore, configuration parameters exist on a per-module and program-wide basis to enable/disable different levels of event logging—either permanently or else through run-time flags.

A quick tour of the XDCtools product

You'll find all of the tooling and infrastructure needed to support each phase of the RTSC flow—from component production to component consumption—within a single product known as XDCtools. After a quick tour, we'll direct you to other resources that in turn will guide you through installing the product as well as working with its many elements.

This product—freely available from Texas Instruments from the outset—will nevertheless transition to eclipse.org, where the embedded software community at large can not only openly leverage the capabilities of XDCtools but can contribute to them as well.

Language support.  At its most rudimentary level, XDCtools supports the RTSC specification language as well as the RTSC meta-language—respectively named XDCspec and XDCscript. Working hand-in-hand with standard C—supplementing the language in ways we've already described—the net result forges an alliance of higher-level programming capabilities for specifying and implementing components which we've termed eXpanDed  C.

As for C itself, the XDCtools product does not bundle any particular compiler tool-chain(s); indeed, the XDCtools can work with any ANSI C compiler. At the same time, the product does maintain full knowledge of literally dozens of different C compilers from multiple vendors through standardized recipes known as RTSC targets—which, as it turns out, leverage XDCspec and XDCscript for their specification and meta-implementation. Using the XDCtools product itself, anyone can add support for a compiler tool-chain with only modest effort by creating a new RTSC target.

Core packages.  Moving up a level in the product block-diagram, the bulk of XDCtools comprises over a hundred RTSC packages containing even more modules/interfaces that broadly fall into three major groups:

package life-cycle

packages that support the general build/release/deploy life-cycle of other RTSC packages; just as many contemporary programming environments bootstrap themselves, all RTSC packages are ultimately managed through other well-known packages that lie at the core of XDCtools.

program life-cycle

packages that support the general configure/execute/analyze life-cycle of RTSC programs; here again, XDCtools builds upon itself through stock meta-content that in turn drives integration-time synthesis and run-time analysis of target-content elements in executable programs.

program run-time

packages that provide basic run-time support for executable C programs using other RTSC modules; this target-content offers improved embedded C support for pluggable memory allocators, event logging and error handling, entry/exit of critical sections, as well as overall program startup/shutdown.

Focusing on the latter for a moment, the XDCtools product ships a special RTSC package named xdc.runtime whose constituent RTSC modules—implemented in portable ANSI C with sources available—facilitate migration to a variety of targets, hardware platforms, and embedded operating environments.

Essential utilities.  Finally, the XDCtools product incorporates a number of basic commands and utilities used by producers and consumers alike throughout the component life-cycle:

xdc

command for building/releasing packages for multiple targets

xdc.tools.cdoc

utility for generating documentation from XDCspec sources

xdc.tools.repoman

utility for managing package repositories

xdc.tools.path

utility for managing the package path

xdc.tools.configuro

utility for integrating configuration into existing build flows

xs

command for invoking other tools written in XDCscript

In general, you can use these tools directly from the command-line or else invoke them through extension points within your development environment. And if you haven't already guessed from their canonical names, each of these utilities is a full-fledged RTSC package whose meta-content leverages XDCspec and XDCscript for its specification and implementation. This suggests, of course, that anyone can contribute additional tooling to the RTSC ecosystem by simply producing and delivering a package!

Additional RTSC resources

Visit the RTSC-Pedia, a centralized wiki devoted to all-things RTSC. Besides holding the most up-to-date versions of all RTSC documents, the RTSC-Pedia maintains active discussion pages for each document where you can comment on the material as well as ask directed questions.

If you have technical issues—general or specific—not addressed by material in the RTSC-Pedia, we've established a dedicated public newsgroup where you can search for answers as well as contribute new questions.

And finally, there's the RTSC Project itself at rtsc.eclipse.org, where you can track the migration of the current XDCtools product into the open-source community.

See also