wiki:Developer/OpenProjects

Version 25 (modified by JoelSherrill, on 03/07/08 at 01:47:31) (diff)

/* TCP/IP Stack Update */ Formatting

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 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 RTEMSSummerOfCode project. Since some projects have multiple steps, a RTEMSSummerOfCode participant should work with us to size up how many of those steps to undertake.

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

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.

Most of the core RTEMS developers are potential resources here. JoelSherrrill? and JenniferAverett? originally implemented the filesystem infrastructure. ThomasDoerfler? and ChrisJohns? have done extensive work with the FAT filesystem on disk, flash,and RAM. TillStraumman? implemented an NFS client for RTEMS. EricNorum? implemented the TFTP filesystem and is familiar with the system call infrastructure.

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

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

This project is very likely beyond the scope of a Summer of Code project.

TCP/IP Stack Update

Status: No active volunteers.

Update current TCP/IP stack to new source base from FreeBSD.

This project is very likely beyond the scope of a Summer of Code project unless the student is familiar with the FreeBSD code base.

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.

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.

The analysis will identify a subset of RTEMS such as the SuperCore? and a single API implementation and use that as the basis for analysis. RTEMS includes a lot of source code and the coverage analysis should only focus on improving the test coverage of that code subset.

The resulting analysis is expected to provide a report on individual assembly instructions within RTEMS subsystems which are not currently exercised by existing tests. Each case has to be individually analyzed and addressed. Historically, we have identified multiple categories for code being uncovered:

  • Needs a new test case
  • Unreachable in current RTEMS configuration. For example, the SuperCore? could have a feature only exercised by a POSIX API object. It could be disabled when POSIX is not configured.
  • Debug or sanity checking code which can be placed inside an RTEMS_DEBUG conditional.
  • Unreachable paths generated by gcc for switches. Sometimes you have to restructure switches to avoid unreachable object code.
  • Critical sections which are synchronizing actions with ISRs. Most of these are very hard to hit and may require very specific support from a simulator environment. OAR has used tsim to exercise these paths but this is not reproducible in a BSP independent manner. Worse, there is often no external way to know the case in question has been hit and no way to do it in a one shot test.

There are multiple ways to measure progress on this task. In the past, we have used two metrics. The first is the reduction in the number of uncovered binary code ranges from that identified initially. The second is the percent of untested binary object code as a percentage of the total code size under analysis. Together the metrics provide useful information. Some uncovered ranges may be a single instruction so eliminating that case improves the first metric more than the second.

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 [http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.8.0/share/rtems/html/c_user/c_user00400.html 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: JoelSherrill is slowly building test scripts. He has reported gcc results on mulitiple targets but there is still a lot to do.

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.

Since there are approximately a dozen active RTEMS targets, this effort will have to be able to support 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 RTEMS Project has been offered 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: No active volunteers.

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 the x86 MacOS. As the RTEMS toolset updates frequently, there must be scripting infrastructure developed to build these tools easily when updates are required.

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: No active volunteers.

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.

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.

==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