Open Projects

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. :)

Most of the projects are feasible as a Google Summer of Code? project. A few have multiple steps and a Summer of Code? participant should work with us to size up how much is doable.

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

STATUS: No active work

​Eclipse is an open source Integrated Development Environment (IDE) which has become very popular in the real-time embedded systems community. For RTEMS to continue to compare favorably against its commercial proprietary competition, Eclipse support is an important feature. Eclipse has a plug-in architecture and there are already multiple plug-ins and add-ons for embedded development.

This is a very open ended project which has a number of steps based upon subprojects or plugins which need to be made available to RTEMS developers.

• C/C++ Development Tooling (CDT)
• Device Software Development Platform (DSDP)
• Target Management.

See ​http://www.eclipse.org/home/categories/embedded_device.php as a reference.

Since RTEMS has multiple targets, this project would focus on getting Eclipse working nicely with multiple targets. There are over half a dozen simulators which are capable of supporting a multithreaded RTEMS application and a few of those simulate target hardware with networking capabilities. There are existing RTEMS BSPs that run on simulators so the person(s) working on this project would not require special target hardware or anything that costs to verify that their implementation works with multiple hardware configurations.

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.

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 release 4.8.0 are documented in the Configuring a System chapter in the User's Guide.

There are a variety of ways to approach this project.

• One solution could be a Wizard/Editor? for Eclipse.
• Another solution is to use the config infrastructure used by the GNU/Linux kernel.

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. One possibility is to write a GUI program in Python which parses the same configuration information and provides a portable GUI interface.

Automated GNU Tools Testing

Status: No active volunteers.

Automate gcc testing on RTEMS targets.

RTEMS Tool Support on Debian

Status: No active volunteers.

TBD

RTEMS Tool Support on MacOS

Status: No active volunteers.

TBD

Multilib GNU Ada

Status: No active volunteers.

Implement Multilib support for GNU Ada (GNAT) run-time libraries in GCC.

GNU Java

Status: No active volunteers.

Get GJC (GNU Java Compiler) to work out of the box with RTEMS

Visual Studio Integration

Status: No active volunteers.

Integrate RTEMS Development Environment with ​Visual Studio 2008 Shell. This would ideally allow project level target configuration, code development, building with GCC backend, deployment, and debugging.

RTEMS Run-Time Oriented

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

Add Sixty-Four Bit Timestamps

Status: No active volunteers.

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
  • Verify all test cases work as baseline.
  • Capture execution times of RTEMS Timing Tests on reference hardware.
  • Capture sizes of sample tests.

• Add a SuperCore? object "ScoreTimestamp?".
  • This is an opaque class which will be used by all SuperCore? time related functions.
  • 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.

• Verify all existing test cases still work.

• 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.

• 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.

• 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.

Run-Time Tracing

Status: ChrisJohns? and JoelSherrill have done initial work on adding trace points to RTEMS.

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

Chris and Joel have done some initial work and prototyping has been done on the first four parts of this. Chris wrote the capture engine and together Chris and Joel believe that the bulk of the work adding trace points can be done automatically using the GNU ld "wrap capability". In addition, we believe that a simple text dump of the trace log on the host side can be derived in a highly automated manner. The code to transmit data from the RTEMS system and to receive the data on the host computer will have to be written.

Once data has been received on the host side, the next logical step is to display the timeline of events in a graphical fashion. This may include the development of the visualization tool or an existing may be able to be leveraged.

Greg Menke of NASA has used GNU plot to do a simple version of this and may have advice.

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 ​<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.

Implement POSIX FIFOs

Status: No active volunteers.

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

Implement Functionality Currently Missing in dup

Status: No active volunteers.

Implement missing file descriptor dup cases.

Use Map/Hashes?

Status: No active volunteers.

Reimplement Classic API notepads and POSIX keys using code like std::map but in C. I think an implementation of the map code is available under an appropriate license as a starting point.

TinyRTEMS

Status: Ongoing effort with multiple discrete projects.

Reduce footprint of minimum RTEMS application. Currently a minimum RTEMS application assumes that you want items like a reentrant C library, shutdown code and a minimal filesystem infrastructure. 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.

More NIC Drivers

Status: No active volunteers.

Convert more NIC drivers from FreeBSD to RTEMS.

RTEMS Initialization By Constructor

Status: ChrisJohns? has file a PR with a prototype.

Add an ordered constructor type system for automatic manager initialization. This should be general enough to support RTEMS managers, drivers and BSD sysctl type nodes. This is expected to significantly impact the TinyRTEMS effort as it would provide a central mechanism to eliminate code. If you don't reference it, the initialization code would automatically drop out.

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.

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.

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@…)

LWIP

Status: No active volunteers.

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.

USB Stack

Status: No active volunteers.

USB host stack for RTEMS. Port the latest FreeBSD USB stack for RTEMS.

TCP/IP Stack Update

Status: No active volunteers.

New TCP/IP stack supports IPv6

Merge C Program Heap and RTEMS Workspace

Status: JoelSherrill has done a lot of BSP and initialization refactoring to lay the groundwork for this..

Add optional capability to use merged Heap and Workspace [PR46].

By default, RTEMS limits the amount of memory and number of operating system object instances that can be created. By merging the C Program Heap and RTEMS Workspace, all usable memory available could be used by RTEMS to allocate objects. This would make RTEMS be able to behave like VxWorks? in regards to limits on object instances while still preserving the hard limits which are needed by many RTEMS users.

Memory Management

Status: No active volunteers.

Add advance memory management feature in RTEMS. The memory management in current RTEMS is fast and simple. But for a complex embedded systems, a page based memory systems is more preferable. other feature like runtime memory compression, memory tracer(for leak detection), DMA and cache management interface is also preferable.

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: JoelSherrill and JenniferAverett? have done work in this area.

This task consists of performing automated coverage testing using an open source simulator. The Skyeye? project is currently adding coverage analysis capabilities per our specifications. When those are available, the person(s) undertaking this project could analysis the binary object level coverage provided by the RTEMS Test Suites on any target BSP supported by the Skyeye?/RTEMS combination.