wiki:Developer/OpenProjects

Version 163 (modified by JoelSherrill, on 01/26/10 at 19:31:54) (diff)

/* Project Template */ Split to new page

Open Projects

Welcome Google Summer of Code Students and fellow hackers. 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 2010 (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!!!

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. Similarly, some projects might be a starting point for a thesis or dissertation.

The projects on this page are lumped into broad categories but there is no prioritization applied to the order. The order of projects in the list does not reflect their importance, difficulty, or feasibility. It is just an organized dump of ideas with enough details to give an outline of the effort required. If you are interested in doing one, a core developer will be happy to augment the description or development plan.

Small or Class Appropriate 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 Projects Not Initiated

The following projects have no work on them.

Run-Time Projects With Some Work

The following projects have had some work on them but are not complete. The remaining activities could be large or small:

  • Run-Time Tracing? - includes gathering, capturing, and displaying information to the user.
  • TinyRTEMS is an umbrella term that corresponds to any activities or ideas that could shrink the code and data space requirements for RTEMS. The goal is to progressively lower the minimum CPU requirements.
  • RTEMS Sequenced Initialization is a project to allow RTEMS initialization to be dynamically constructed based upon user requirements. It would be like C++ global constructors conceptually.
  • See Dynamic Object File Loading for detail on the status of this project.
  • TBD Move other descriptions to their own page and list here. Shorten master page.

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.

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.

Third Party Packages

This is a list of projects related to third party free and open source software and its support for RTEMS. The following project areas have been identified:

  • See the RTEMS Graphics Toolkit for current status of the kit and ideas for future work.
  • IntegrateCEXP? into main RTEMS distribution.
  • Turn the current port of LWIP into a first class citizen. Submit port, make target independent, etc.
  • IDL/COM? Support for RTEMS.
  • Parrot TBD
  • MONO TBD

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. Some of the identified activities which would augment our testing capabilities are listed here:

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.

The following areas have been identified for projects related to GUI development environments:

There are host operating systems which do not have prebuilt RTEMS tools available. These projects are about addressing that need:

The following projects are about general improvements to the development environment.