From RTSC-Pedia
[printable version] [offline version] | offline version generated on 11-Jun-2009 18:06 UTC |
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 RTSCthat 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 documentinitially developed by Texas Instruments and currently used in a number of its flagship productsfor broader use by embedded software developers targeting any hardware platform.
Contents |
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 producersalways looking to minimize non-recurring engineering costs through greater re-usewe'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-outleveraging 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 costsless MIPs, less memory, less powerwe'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 importantespecially 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 integratorcombining 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-inreconciling 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, genericyet inefficientbuilding-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 programmingone that encourages producing more modular, more scalable, and more flexible target-contentwithout 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 Cfrom 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 unchangedRTSC strives to leverage and enhance C, not replace it.
1 Specification
Like any component-based flow, RTSC begins with well-specified componentsa 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 thesedo 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 producerspecs, 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 elementthat 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 targeta 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 packagesenabling 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 integrationcombining 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 scriptsourced in the RTSC meta-languagewhich 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 inputsrecipes for compiling and linking target-content that help shape configuration outputs.
Within the configuration scriptconsider it the application's meta-programthe 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 computerto execute meta-content before consuming corresponding target-contentthe 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 memoryvia a host-based debugger, an embedded program monitor, or even a snapshot of program state saved to diskRTSC 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 loggingeither 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 flowfrom component production to component consumptionwithin 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 productfreely available from Texas Instruments from the outsetwill 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-languagerespectively named XDCspec and XDCscript. Working hand-in-hand with standard Csupplementing the language in ways we've already describedthe 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 targetswhich, 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 modulesimplemented in portable ANSI C with sources availablefacilitate 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 issuesgeneral or specificnot 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
FAQ-080713-9 | How is the RTSC-Pedia organized, and what sorts of documents exist |
FAQ-080713-7 | If I'm only consuming RTSC content, what should I read next |
FAQ-080713-8 | I also want to produce RTSC content, what should I read next |
FAQ-080713-4 | Can I leverage RTSC with legacy content, or am I starting from scratch |
FAQ-080713-6 | Who's using RTSC today, and what's the roadmap going forward |
[printable version] [offline version] | offline version generated on 11-Jun-2009 18:06 UTC |