Open Projects

Welcome Google Summer of Code Students. Peruse our projects and see what interests you. If you have questions ask them on the Wiki talk page or the RTEMS mailing list. If you plan to submit a GSoC 2009 (if and when it happens <wink>) proposal to do something for the RTEMS Project, we now require that you demonstrate that you have a basic RTEMS development environment installed. See GSoC Getting Started for details on what we want you to have done. We want you to succeed and have fun on an RTEMS related effort.

This page captures ideas for RTEMS projects. They range from OS projects to development environment to testing to just about anything else. If you like one of the ideas, you can pitch in and tackle it. If you aren't able to code and test it yourself, consider sponsoring one of the core RTEMS developers to do it for you. This is really the only way things get done -- USERS LIKE YOU KEEP RTEMS DEVELOPMENT ALIVE!!!

The projects on this page are lumped into broad categories but there is no prioritization applied to the order. It is just an organized dump of ideas with enough details to give an outline of the effort required.

We do not provide time estimates on these because the time depends on the experience and skill of the developer. Most of these projects will fall between a few weeks and a few months of effort by a person who is not completely unfamiliar with the general use of GNU/Linux and GNU tools. Some of these projects may consist of multiple steps. In this case, each step is defined to fall into short discrete steps.

Many RTEMS projects are done as student or volunteer efforts in a person's spare time or as a hobby. This means it is imperative that projects be either relatively small or divided into steps that can be considered complete and committed to the main RTEMS source base. Thus we have lots of experience in defining useful projects that are sized to be doable and useful to the community in relatively small work packages.

Most of the projects are feasible as a Google Summer of Code project. Since some projects have multiple steps, a Google Summer of Code participant should work with us to size up how many of those steps to undertake.

Project Template

Credit to Boost C++'s Google SoC page for the inspiration for the template entry.

Project Name

Status: Current status of project.

Introduction: Introduce the main concepts around the project: Theoretical preliminaries, preexisting RTEMS capabilities used or augmented (if any), important concepts, problems/needs the project will try to solve/satisfy.

Goal: Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective.

Requirements: List the requirements and level of expertise you estimate are required by the developer tackling this project will have to have: Required level of programming language(s), specific areas of RTEMS or tools, level of familiarity with RTEMS, cross-development, GNU/Linux, etx., development/documentation/testing tools, mathematical/algorithmic background, other desirable skills.

Resources: Current RTEMS developers, papers, etc that may help you in this project.

URLs:

• TBD

Other sections: If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.

Ideas Needing More Details

The following ideas have been proposed but there is not enough detail written up yet on the project itself to justify a section.

• TFS adapter for MicroMonitor (underway by Ed Sutter)
• Unified Interrupt and PCI APIs -- UnifiedAPIs?
• Hypervisor providing ARINC-653 capabilities.
• Port Transparent IPC (​http://tipc.sourceforge.net/index.html) to RTEMS
• Merge BSP for Simplescalar simulator -- ​http://www.jwhitham.org.uk/simplescalar/
• Support for new Processor Families
• ISO9660 filesystem
• OSEK Support ​http://portal.osek-vdx.org/
• Complete µITRON Interface ​http://www.www.tron.org/index-e.html
• Add cache manager support for architectures not having it.

Small Projects

These are small projects that could be tackled by anyone. They are mostly projects which can easily be nibbled on in small work units. They may require no coding or modest coding skill. Some of these will require the ability to read code and analyse it. Some of these will be good projects to tackle in an "Introduction to FOSS" class or as a class project by a student. Individual tasks may also be useful for those new to RTEMS and looking to try a simple project to earn the ropes. See Small Projects for details.

RTEMS Run-Time Oriented

The projects in this category are more focused on the development of software that runs on RTEMS on target hardware.

Run-Time Tracing

Status: ChrisJohns? and JoelSherrill have done initial work on adding trace points to RTEMS. This is still work in progress.

Instrument RTEMS so that a timeline visualization tool can be used to "place a scope" on a running RTEMS system. This project has multiple parts.

• Addition of trace points to generate log entries
• Transmission of logged data to host
• Receipt of logged data on host
• Decoding of logged data on host
• GUI Timeline Visualization tool

The requirements of the Run-Time tracing is to provide a common means audit an RTEMS application for conformance of input/output parameters and/or timing, or to debug an application. The auditing process typically uses a static configuration the user manages. The debugging process usually targets a standard set of calls such as the RTEMS Classic API and uses dynamic filtering to control what is looked at as the debugging session unfolds.

The current status of this project can be found here?.

Implement POSIX Asynchronous and List IO

Status: No active volunteers.

RTEMS does not currently support POSIX Asynchronous IO as defined by OpenGroup?. These methods and associated constants are prototyped by the [​http://www.opengroup.org/onlinepubs/009695399/basedefs/aio.h.html <aio.h>] header file which is cpukit/posix/include/aio.h in the RTEMS source tree. The following methods would have to be implemented:

• ​aio_read()
• ​aio_write()
• ​aio_cancel()
• ​aio_error()
• ​aio_return()
• ​lio_listio()

All methods currently are implemented in RTEMS as stubs which return ENOSYS.

It is assumed that the implementation would have to have one or more server threads and these methods would interact with that server thread by enqueueing operation requests and checking on the completion status. The number of server threads along with characteristics such as stack size and priority would need to be application configurable.

Use Map/Hashes?

Status: No active volunteers.

Reimplement Classic API notepads and POSIX keys using code like std::map but in C. The current implementation requires that enough memory be reserved for every task to have memory for all notepads and every key whether they use them or not. This results in simple and fast array lookups to access individual values but is obviously heavy on memory. It is hoped that a hash/map algorithm can be found or designed which reduces the memory overhead without adding excessive lookup overhead or heavy handed O(n) algorithms for management of the entries. This is particularly important because tasks and keys can be dynamically created and deleted.

JoelSherrill and PavelPisa? are good resources for this. Joel can answer questions about the rationale driving this need and help evaluate algorithms. The run-time behavior of the algorithm is very important because RTEMS strives to be as predictable in run-time execution times and memory usage as possible. Pavel is very knowledgable about hash algorithms.

TinyRTEMS

Status: Ongoing effort with multiple discrete projects. Much progress has made on this goal since 4.7.0 but there is more shrinking left. We are now to the point where the ARM/Thumb BSP rtl22xx_t and h8300/h8sim BSP have ~15K of code in the minimum.exe test.

Reduce footprint of minimum RTEMS application. We would like to be able to run on a CPU with only 64K ROM and 16K RAM. This level of target hardware obviously is too small to host some RTEMS features.

Currently a minimum RTEMS application assumes that you want items like a shutdown code, initialization of all Classic API Managers, and support for c. Some ideas in this area are captured at TinyRTEMS. The project would focus on breaking linkages between components so they can be configured out by the user, dropped out automatically at link time, or other mechanisms. The goal is to be able to provide the user with a full featured RTEMS library and defer as much configuration as possible to application configuration and link time.

One issue that will be an ongoing concern is that the minimum footprint varies by BSP. This is because some BSPs are structured to be lean, while others may have unintentional dependencies. One idea is a tool to assist in identifying RTEMS symbols which are not expected occur in some of the sample applications such minimum, hello, and ticker. This utility could provide guidance on the known reasons this symbol creeps in. For example, placing printk() support in the same file as the console driver will result in the entirety of the Termios subsystem being in the minimum footprint even though it is unused.

More NIC Drivers

Status: No active volunteers.

Convert more NIC drivers from FreeBSD to RTEMS. It would actually be more useful to have an semi-automated procedure to assist developers in porting individual drivers on an as needed basis than a large collection of untested drivers.

RTEMS Sequenced Initialization

Status: ChrisJohns? has filed ​PR1253 with a prototype.

Mentor: Chris Johns

Note: this project was called "RTEMS Initialization By Constructor".

This project adds to RTEMS a Sequencer that calls user defined functions held in an unordered table in a specific order. An example of its use is the RTEMS Managers initialization. The initialisation of the RTEMS Managers is a specific ordered sequence of calls currently hard coded into RTEMS. The sequencing code will take a table of nodes that is un-order, determine the order and make calls to the user provided functions which in this case is the manager initialisation calls.

The solution should be general enough to support RTEMS managers, drivers and BSD sysctl type nodes. The result of this work is expected to impact the TinyRTEMS effort as it would provide a central mechanism to automatically eliminate unused code. If you don't reference a part of the RTEMS API the initialization code would automatically drop out. The dropping of unused code is critical to both the TinyRTEMS effort and to those woh use RTEMS in safety-critical systems which must be validated. The automatic part here refers to the creation of the table of nodes.

A prototype of the work can be found in ​PR1253. This work combines the call sequencing with the automatic generation of the table of nodes. The solution is not suitable as it uses the word "constructor" which we have since decided should not be used, as well as too much RAM. The ideal solution should use little if any RAM and all nodes and tables be held in ROM type memory. A typical small foot print CPU which would use a TinyRTEMS solution has much more ROM than RAM. Also this is a once off initialization procedure and so using RAM means it is gone from application use.

The automatic table generation uses the same linker technique used to create C++ static object constructor and destructor tables. Consider the RTEMS Message API. In the Message Manager's initialization call's source file you create a {{{static const</code> structure with the specific fields needed by the sequencer code then reference this variable from the source file containing the {{{rtems_message_queue_create</code> code. The application must make a call to {{{rtems_message_queue_create</code> or all the other Message API calls will fail therefore this API needs only one reference from a single source file. The application call of {{{rtems_message_queue_create</code> will pull in its code and as this code references the node in the initialization call's file it is also pulled in along with the initialization code. We also create a variable that is a pointer to the sequencer node and this is placed in a special section using the GCC "attribute" modifier. The linker command file for each BSP must be modified to group all these pointers together in one location in ROM. This creates the table that is passed to the sequencer code.

The sequencer code iterates over the table calling entries in the order specified. The order could be a number or it could be relative. The relative order design makes for a more robust system because you have moved away from specific numbers. The idea here is to allow high level ordering operators, for example "first", "last", "after", "before", "just after", "just before", etc. You can then say "message" is "after" "heap" and the order is determined at runtime. Most system parts are relative not absolute. It may even be possible to allow relative and absolute ordering to be mixed. Priorities are similar. At the end of the day we do not need 256 levels if we only use 4. Typically all we need is to say is this task is higher or lower than another task. Sequencing ca viewed the same way.

This project tasks are: # Develop the sequencer code and API with documentation and tests. # Update the RTEMS Classic API, POSIX API and ITRON API initialization calls with the sequencer implementation using automatic table generation. This also includes removal of the hard coded call with a sequencer call. # Update all linker command files to handle the initialization automatic table entries. # Initial testing can all be done on SPARC/sis. The modification of other BSP linkcmds should be done with caution but mistakes will be caught by Test Builds of RTEMS by JoelSherrill which include all BSP configurations.

Code and data size measurements should be made before and after the implementation is done on the sparc/sis and arm/rtl22xx_t BSPs. These BSPs are used for code size analysis across releases.

BSPs for CPU Simulators

Status: Please ask for detailed information on the particular BSP/simulator combination you are interested in. There are lots of combinations available and the status changes frequently.

See the GNU Tools Testing? project for information on which targets need simulator BSPs to aid in tool testing.

There are a variety of potential projects listed on the Emulator? and SkyEye pages. Some of these involve addressing issues in the simulator itself. Others involve developing BSPs for specific simulators. This is an important area of work since any target that can be tested easily and in an automated fashion on a simulator is always in better shape. Here is a list of BSPs on simulators that are currently thought to be of high interest because they would add significantly to our testing infrastructure:

• a BSP for a QEMU Coldfire target
• a BSP for a QEMU SuperH target
• a BSP for a QEMU or SkyEye ARM PXA target.
• a BSP for SkyEye edp9312 target configured to match the < USD200 Olimex board.

The ​GXEmul SkyEye project emulates a number of ARM-, PPC-, MIPS-, and SH4- based platforms, including ​"test-machines" SkyEye which may be good targets for RTEMS.

Where available please include support for networking and graphics. The RTEMS Project uses simulators for automated testing as well as for manual testing of features like graphics and network application behavior. Full featured simulator BSPs make this much easier. It also provides more BSPs which anyone on the project has access to free with no need for special hardware to be purchased.

JoelSherrill hopes someone will tackle RTEMS support for the ARM PXA models and edp9312 as supported by SkyEye. This would benefit RTEMS testing a lot.

RTEMS Virtual Machine Monitor

Status: No active volunteers.

RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS can not support to run another OS (such as Linux or uClinux). We want to add hypervisor (or Virtual Machine Monitor) function on RTEMS, then RTEMS has the power like XEN that can run Linux or other OS, but RTEMS also maintain original hard Real-Time funtions. First, we will try to make RTEMS run uClinux on ARM simulator SkyEye?( ​http://www.skyeye.org ), then we will try to make RTEMS run ARM Linux on XSCALE CPU based board or SkyEye? simulator. We consider virtualization techs on Embedded RTOS area has potential value. (from chyyuu@…)

USB Stack

Status: Ray is trying to run ohci test on QEMU with RTEMS

USB host stack for RTEMS. Port the latest NetBSD USB stack for RTEMS. Currently, a initial porting is finished. The following work is needed

a) Merge BSD include file with old header file tcp/ip stack is using b) More file system support and also, dynamic file system mount/un-mount c) Memory alloc/de-alloc for realtime system. USB need lots of dynamic memory. Current porting do not consider the performance issue for RTEMS d) More hardware/IC-chip support

The project is very likely beyond the scope of a Google Summer of Code project. However, we can divide it to some small ones like add HID device support for RTEMS.

TCP/IP Stack Update

Status: Started -- Contact Andrew Spoerner

The FreeBSD 7.1 source for the TCP/IP stack will be the basis for the update. Existing RTEMS APIs will be kept and additional ones added to support newer TCP/IP functionality.

Page based memory management system

Status: No active volunteers.

Mentor: Manuel Coutinho (proposed)

Page based memory system is supported by CPUs with MMU. Introducing MMU support and page based memory management systems can benefit RTEMS a lot as regarded to memory protection, reduce memory fragmentation.

Advance topic would be process support. Though, would introduce lots of overhead, it can benefit RTEMS being more compatible with *nix systems.

Simple Line Editor

Status: No active volunteers.

Mentor: Sebastian Huber

The ​RTEMS Shell and Monitor have a simple line editor. They use a very similar implementation. One may refactor this into a common implementation which is usable in a general environment.

There are 3 parts:

• The key definitions moved to rtems-lineeditor.h
• The line editor function, ie rtems_shell_line_editor
• The terminal parser, ie rtems_shell_getchar

Some notes: The shell interface and code is better than the monitor. The shell uses FILE handles and this is nice for redirection and multi-user usage (a threaded version). It also supports a command history. The caller should provide the terminal type. This could be a string or a pointer to the terminal data returned to the caller after a call to get the terminal data with a string. It is recommended to review some of the keys actions, for example C-f, to make sure they are considered standard in relation to a normal shell. One should consider cutting out the code that disables echo and obtains the password and putting it in getpass(). See the linux man page. We don't have a controlling /dev/tty so just make it work exactly like it does now.

Dynamic Object File Loading

Status: No active volunteers.

Mentor: Chris Johns

Dynamic object file loading or dynamic linking provides a way for RTEMS to run-time link an application from relocatable object files or libraries. This task is to implement the functionality using the IEEE standard API based on {{{<dlfcn.h> </code> interface more commonly know as {{{dlopen</code>. The intention is for this work to build on the work by Till Straumann and the CEXP package. For more detail on the task see the Dynamic Object File Loading page in this Wiki.

RTEMS System Events

Status: No active volunteers.

Mentor: Chris Johns

The Classic RTEMS API Event interface is a user API that provides a efficient task synchronisation. This user API is also used by RTEMS system tasks such as the networking tasks and the libblock cache. These RTEMS services have taken event numbers and use them to wake a blocked task waiting on a specific resource. In the networking task this could be the reception of a packet and in the libblock cache once a block of data has been read into memory. If the task is internal to the service being provided there is no problem how-ever where the task is a user one there are possible problems. A blocked user task may be woken by another user task that happened to send the same event. This would upset the RTEMS service and make it look like a bug that is complex to find. Typically this is avoided in current application because the user is aware of the issue or uses an event number lower down. RTEMS needs a cleaner solution to this issue.

The project is to add a new "system" Event API for RTEMS system services. The API would be the same as current Event API and the services would be defined and use restricted to that service. If a user uses this API and a service for another use that would be considered a bug so no runtime checking is required. It is hoped the current Super Core code would be used with a different event bit map from the task control block and the current RTEMS services would be updated with a new API call and event.

Third Party Packages

RTEMS Graphics Toolkit

See the Open Projects? section of the RTEMS Graphics Toolkit for current status of the kit and ideas for future work.

LWIP

Status: No active volunteers.

Current Port: ​ftp://ftp.rtems.org/pub/rtems/people/joel/rtems-lwip/

Update the RTEMS port of LWIP. Provide reproducible test cases so we can be sure it stays in working condition.

A goal of this effort is to be able to use the standard TCP/IP NIC drivers already in RTEMS. If this is feasible, then a user could switch between the full-featured BSD TCP/IP stack in RTEMS or the LWIP stack to save memory at the expense of reduced functionality.

The work would have to do : 1 start with current LWIP source 2 update the port for current RTEMS and current LWIP 3 make the port portable across CPU architectures and BSPs (This is usually not as hard as it sounds.) 4 Provide documentation and examples that run on at least qemu so others can provide feedback. 5 Ideally use the standard BSD NIC drivers if at all technically possible so when you write a driver for one TCP/IP stack, you automatically get it for both stacks in RTEMS.

IDL base components model support in RTEMS

Status: No active volunteers.

Interface base development model (normal known as COM in Microsoft’s world) is very helpful for large scale software development. Major commercial RTOS like VxWorks?, LynxOS support IDL/COM. Introduce IDL and COM model need an idl compiler, and also there are lots type of COM to choose in open source world. There is support for omniORB in RTEMS, however, omniORB lack feature for recent language like JAVA. The popular COM/COBRA choices are Universal Network Objects from Sun (used in openoffice), XPIDL by mozilla and SWIG (​http://www.swig.org/) to name a few.

RTEMS Testing

Testing a large body of software like RTEMS is in a continual state of improvement. There is always a need for more test cases and easier ways to run them all and decode the results. In addition, we want to be able to run all tests on as many hardware and simulator configurations as possible.

POSIX Timing Tests

Status: No active volunteers.

There are very few tests in the RTEMS source base which benchmark the POSIX Threading API and other POSIX services. The first step in this project would be to develop POSIX API Timing Tests which test the same logical tests cases as the existing Classic API Timing Tests. After that is complete, we would want to see Timing Tests for POSIX specific objects such as conditional variables and keys.

RTEMS does not use Timing Tests as much for comparison with other operating systems but as a ruler for self-improvement. Each RTEMS version should maintain or exceed the performance characteristics of previous versions.

Coverage Analysis

Status: On going effort.

See RTEMS Test Coverage? for current status, ideas, and other information.

This is being taken up as a Google Summer of Code 2009 project by Santosh G Vattam and the updates about this project can be found here

Add Sixty-Four Bit Timestamps

Status: Implemented. Needs evaluation on various architectures.

Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks. At each clock tick, the current time of day was updated. This meant that the granularity of all time stamps and statistics on per-thread CPU usage were constrained to that of the clock tick. In RTEMS 4.8.0, the lowest level of RTEMS -- the SuperCore? (e.g. rtems/cpukit/score) was converted to use POSIX struct timespec as the format for all timestamps. In conjunction with the addition of the ability of a BSP to report "nanoseconds since last clock tick", RTEMS could now provide nanosecond accurate timestamps and CPU usage statistics.

Unfortunately, performing mathematical operations on struct timespec is painful and slow. This project will consist of the following work:

• Baseline Testing
  • (DONE) Verify all test cases work as baseline.
  • Capture execution times of RTEMS Timing Tests on reference hardware.
  • Capture sizes of sample tests.

• (DONE) Add a SuperCore? object "ScoreTimestamp?".
  • This is an opaque class which will be used by all SuperCore? time related functions.
  • Includes methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp?.
  • RTEMS has a class to operate upon timespec's so this will be implemented in terms of this.
  • Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon struct timespec arguments.
  • Initial implementation will be using struct timespec and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. Note that by adding the class "ScoreTimestamp?", we have added a class whose implementation can be changed.

• (DONE) Verify all existing test cases still work.

• (DONE) Implement alternate version of SuperCore? object "ScoreTimestamp?" which uses unsigned sixty-four bit integers to represent nanoseconds since the POSIX epoch.
  • This implementation should be fairly simple as you can do direct math on 64-bit integers.
  • Do not destroy struct timespec alternative. The goal is to be able to pick the implementation is for each port to a new CPU architecture to select its preferred method.
  • Provide configuration similar to other configure/build time parameters in RTEMS to let user select implementation.
  • Make sure both implementations work. :-D

• Post Testing
  • Verify all test cases work as they did baseline.
  • Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations.
  • Capture sizes of sample tests.

• Select proper implementation for each target architecture
• Evaluation
  • We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version. But RTEMS supports over a dozen architectures so this is certainly not guaranteed.
  • Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture.
  • Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work.

Test POSIX FIFOs

Status: Implemented. Needs configuration support and tests.

Implement POSIX (named) FIFOs and (unnamed) Pipes. See POSIXFIFOs? for technical details.

Most of the core RTEMS developers are potential resources here. See cpukit/libfs/src/pipefs for details and contact information.

Implement Functionality Currently Missing in dup

Status: No active volunteers.

Identify and implement missing file descriptor dup() cases.

Development Environment Oriented

Remember that RTEMS is a real-time operating system targeting embedded applications. Applications are cross-compiled on a development host to produce executables that are transferred to and executed on target systems. The projects in this section are more focused on the host side of that equation. This means they will run on GNU/Linux or MS-Windows and possibly communicate with embedded hardware.

RTEMS is a free real-time operating system that must compete against commercial closed source offerings that have very impressive looking GUI oriented Development Environments. The RTEMS Project has spent years honing RTEMS and tuning it to be a competitive run-time and it certainly the technical capabilities to compete. But often RTEMS gets dinged for not having a "pretty face". Some of the projects in this category address that deficiency.

Eclipse Integration

See also: RTEMS Eclipse Page.

CEXP

Status: ChrisJohns? has started this effort. Contact him for information on how you can help.

The goal of this project is to integrate CEXP into the main RTEMS Project. By integrating CEXP into the main RTEMS Project, it can more easily be updated to stay in sync with the main code base and re-released as new RTEMS versions come out.

​CEXP in conjunction with GeSYS provide RTEMS with capabilities long familiar to VxWorks? users. They provide a base system and the ability to dynamically load software modules onto the embedded system. Without this system, RTEMS can only be used with statically linked executables in which the entire application is linked together with RTEMS and loaded onto the board.

Till Straumman wrote CEXP and GeSYS anbd provides instructions and a Live CD to demonstrate it running with the target environment on qemu. This would be useful to someone on this project because it provides a baseline reference for what the software does.

Application Configuration GUI

Status: No active volunteers.

Status: Sebastian Huber

The goal is to have a graphical tool to configure RTEMS for a certain Application e.g. max number of tasks, semaphores etc. It could generate a userconf.h which includes confdefs.h. The complete list of RTEMS configuration parameters for version 4.9.1 of RTEMS are documented in the [http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.9.1/share/rtems/html/c_user/c_user00039.html Configuring a System] chapter in the User's Guide.

There are a variety of ways to approach this project.

• One solution is to write a GUI in Python. This should be cross-platform.
• Another solution could be a Wizard/Editor? for Eclipse.
• Another solution is to use the config infrastructure used by the GNU/Linux kernel.
• Another approach would be to use the configuration GUI from eCos and NutOS: ​http://www.ethernut.de/en/software/nutconf.html

JoelSherrill has used the GNU/Linux kernel config infrastructure for similar jobs in the past and things it is likely the best alternative as a baseline. This would certainly provide multiple interfaces on GNU/Linux hosts (e.g. X11, menu, command line). But we would like a solution that also addresses MS-Windows users.

A better possibility is to write a GUI program in Python which reads an XML format file describing the RTEMS configuration parameters. As the user set values, the program would store this information in another XML format file. When it was time to write the C code to use with the RTEMS application, the GUI application would write that. So we would have:

• XML file describing RTEMS configuration parameters
• XML save file with user settings
• C/H file output for use with RTEMS application

Automated GNU Tools Testing

Status:

• JoelSherrill is slowly building test scripts. He has reported gcc results on mulitiple targets.
• The CVS module gcc-testing has the support infrastructure.
• Some targets are not tested on simulators yet.
• Skyeye has some bugs preventing testing on Coldfire and Blackfin.
• There seem to be regression checking scripts we need to utilize to help reduce the burden of tracking results.
• There are tests which spuriously fail due to the test infrastructure issues.
  • not knowing we add specific CPU options which prevent generating expected instructions on "scan assembly" tests
  • missing instructions in simulators
• Want to eventually run on multiple BSPs inside a single target architecture to cover more code generation possibilities.

This project broadly consists of doing whatever is required to automate testing of GNU tools on RTEMS targets. The first steps are to be able to automate the building of binutils, gcc/newlib, and gdb from source using either released versions of the tools or the development version checked out and updated from the source code control repositories of those projects. This step is largely complete with the test scripts in the CVS module gcc-testing.

Since there are approximately a dozen active RTEMS targets, this ultimate goal of this effort is to be able to test at least one BSP on all targets. Some of the targets have simulators. If there are executable tests, then the project will have to address being able to run those executable tests on the simulators capturing the output and verifying tests do not run too long.

The volume of test data generated is very high with GCC having over 60,000 tests. We need to be able to generate deviation reports which highlight changes between subsequent test runs. We believe a script to do this exists although the integration of that into the overall test system needs to occur. Also the deviation report should be emailed to the RTEMS Tool Test Results mailing list (http://www.rtems.org/pipermail/rtems-tooltestresults).

The RTEMS Project has access to the GCC Compile Farm for the purpose of testing GNU tools and providing automated reports. This is a collection of high power servers and our intent is to do as much of the automated tools testing as possible on those machines. But the scripting needed to drive this will be portable to other environments.

The RTEMS Project has a lab or test hardware hosted at OAR Corporation which includes multiple target boards and infrastructure to remotely access as well as power on/off each board. Once the simulator targets have been completely exercised, we will want support running executable tests on real embedded hardware targets -- with highest priority going to those with no simulator.

RTEMS Tool Support on Debian

Status: Packaging generated as a GSOC 2008 project. Needs to be "templatized" to minimize duplication and then production Debian packaging build infrastructure established similar to the one for RPMs and MinGW binaries.

Pre-compiled versions of the RTEMS tools are currently available for RPM-based GNU/Linux distributions such as Fedora, RedHat? Enterprise Linux, CentOS, and SUSE as well as MS-Windows via MinGW. This project consists of the development of comparable .deb package specifications and build scripts. The resulting packaging and infrastructure should be suitable for at least GNU/Debian and Ubuntu distributions. As the RTEMS toolset updates frequently, there must be scripting infrastructure developed to build these tools easily when updates are required.

RalfCorsepius? is the RPM builder and maintainer. He uses Mock to use a single development machine to build binaries for a variety of distributions. He is a good resource or mentor for this project.

The RTEMS Project currently does not have a computer running a Debian based GNU/Linux distribution and would have to have one before these could be supported long term.

RTEMS Tool Support on MacOS

Status: No active volunteers.

The goal of this project is to provide precompiled versions of the RTEMS tools for Mac OS X. As the RTEMS toolset updates frequently, there must be scripting infrastructure developed to build these tools easily when updates are required.

Tool distribution questions:

• Provide Binary installers for all of the tools ( similar to the Windows MingW binaries ) ?
• Provide Mac Ports ( ​http://www.macports.org ) for the tools ? ( and can these be used for BSD variants too? ) ?
• Provide Fink .deb packages ( ​http://www.finkproject.org/ ) ?
• Or just provide an easy to use shell script that can download, patch, build and install the tools?

Mac OS X version/architecture questions:

• Does the project make a cut-off with a newer version of OS X ( say 10.4 or even 10.5 )?
• Does the project support x86 and PPC Macs or just stick with x86?

Build questions:

• Can the tools be built and packaged on an open source Darwin OS machine? or is a full Mac OS X machine needed to do these builds?

License questions: Little is know by those who currently build RTEMS tool binaries about the packaging and legal requirements associated with providing MacOS binaries.

The RTEMS Project currently does not have a MacOS X computer and would have to have one before these could be supported long term.

Multilib GNU Ada

Status: LaurentGuerby? has implemented the multilib'ing of the Ada run-time libraries.

• gnatmake does not yet properly process -mcpu options like gcc so you have to use special command line options that make you way too aware of the multilib.

You have to use --RTS together with -m for gnatmake
to work for non-default multilib:

gnatmake $FLAGS --RTS=$(gcc -print-multi-directory $FLAGS)

• There may as yet be target specific issues to work around where the same source file does not support all variants.

The goal of this project is to implement Multilib support for GNU Ada (GNAT) run-time libraries in GCC. This primary focus of this project will be to augment the existing configure and Makefile infrastructure for the GNU Ada run-time libraries in GCC to build multilib rather than a single library variant.

Multilib is a GNU term for building a single source library to be tailored for multiple CPU variants within a single architecture. This is done because even within a CPU architecture, not every CPU model is object code compatible. For example, on the RTEMS SPARC tools, we provide four libc.a versions -- SPARC V7 and V8 with and without hardware floating point support. Similarly, the m68k target supports many m680x0 and Coldfire core implementations with and without hardware floating point.

GNU Java

Status: No active volunteers.

The purpose of this project is to make the ​GJC (GNU Java Compiler) work with RTEMS. RTEMS is supported as a target in GCC so it is expected that the primary development focus of this project will be to adapt the run-time library to RTEMS. Since the GNU Ada and C++ run-times are already ported to RTEMS, there are examples to work from for many issues. Also if the porter assumes it is using the POSIX thread interface, it is very likely that the GNU/Linux port will be a good reference.

This project will consist of the following phases:

• Port GJC Run-time to RTEMS. The port will be target CPU architecture independent. Just like the GNU Ada tasking support, this should be written in a processor architecture manner using portable API calls provided by RTEMS.
• Run GJC Test Suite. We are already running the general GCC C/C++ testsuite and the Ada run-time tests. So there is precedence and help available.
• Submit modifications to GCC and RTEMS Projects

Here is a list of technical details from Tom Tromey, the GCJ maintainer. A lot of stuff in libgcj is optional. So, a minimal port can be made pretty quickly. From memory:

• The GC must be ported. This can be difficult but usually is not, since it has already been widely ported.

• For a good libgcj port, libffi must be ported. It already runs on most architectures though. This would only matter if the target is a new architecture or if the target has a different ABI. A libffi port has two parts. Each is optional. First, the normal libffi API is used for reflection and one direction of JNI. Second, the libffi closure API is used for the interpreter and JNI->Java calls. libgcj will configure and build just fine if these are missing.

• For an excellent libgcj port, you have to write code to turn a signal into an exception. This is some hairy unwinding stuff, partly in gcc and partly in libgcj. However, there is an option to have gcj add explicit checks where needed, for platforms where this is not possible. [NOTE from joel: This is the technique also used by GNU Ada so there should be existing code to leverage and share between the GNAT/RTEMS port and the GJC/RTEMS port.]

• libgcj's thread layer must be ported. This is usually easy. The POSIX "flavor" already works in a lot of places. Note that this can affect the GC as well. This part can actually be disabled, but you can't run much java code without threads.

• File I/O, sockets, and other stuff like that should be ported. Some of this can be disabled for less-capable targets. Again, the POSIXy code should work fine.

• For the full pull, port AWT. This is a lot of work and, really, nobody ever bothers.

There was a previous effort to do this but it was not submitted to the GCC Maintainers. At this point, it was against such an old version of gcc that it would probably have to be used as a reference more than a code base.

This is expected to be a good Google Summer of Code project.

The contributor MUST have or file Free Software Foundation paperwork and it is assumed that this code will be contributed to GCC.

=eVisual Studio Integration =

Status: No active volunteers.

Integrate RTEMS Development Environment with [​http://msdn2.microsoft.com/en-us/vstudio/bb510103.aspx Visual Studio 2008 Shell]. This would ideally allow project level target configuration, code development, building with GCC backend, deployment, and debugging.

ChrisJohns? is a good resource for this project because he is the maintainer for the RTEMS MinGW hosted tools

==ArgoUML for RTEMS==

Status: No active volunteers.

ArgoUML is a java base CASE tool. It can generate C++ code from UML and it is very useful in large scale firmware development. First step of integrating ArgoUML with RTEMS is converting some of the RTEMS C++ class into ArgoUML's UML.