RTEMS is a participating organization of the Google Summer of Code 2013! Please use this page as a jumping off point and ask questions. We want you to be a part of the RTEMS community!

Imported from old wiki.

Potential Students: Read through all the material on this page, and be sure to add yourself to the table in the Student Information section. Remember to fill out an official GSOC application in addition to the informal application we request. We also require you build RTEMS, create an application, run it and post the result to the RTEMS mailing list. The Configure and Build RTEMS page has the details on how you do this. Information on what to post are found on the Prove You Can Work On RTEMS page. For new comers to RTEMS we recommend you use a proven Virtual Machine image.

Potential Mentors: Share your knowledge and pledge to help a student. Visit the URL for GSoC 2012 to register as a mentor and then add yourself to the list of RTEMS Mentors.

General Information

The RTEMS Community is proud to have participated in five previous editions of the Google Summer of Code as well as 2 previous editions of the Google Code-in (GCI).

Information for prior years:


In 2012, we had ten students. In 2011 and 2010, we had eight students each year. In 2009? there were six students with a seventh sponsored by a combination the mentor donation and a donation from OAR Corporation,. In our first GSOC experience, 2008 we received four student slots with one failing. These students have contributed great code and some have continued to be a part of the community. We have been impressed with the quality of both high school and college students who have participated in the GSOC and GCI programs.


Google Code-In has been an incredibly challenging experience for the RTEMS Community. The tasks are much smaller that those in GSOC with a target of 2-4 hours for a skilled developer. Plus they should be achievable by a high school student and meaningful to the community. We gathered some statistics to give an idea of the magnitude of what they accomplished.

Year Students Tasks Tasks By Top Student Students with Over Ten Tasks
2011 22 65 12 1
2012 31 245 67 4

The increase in tasks performed is likely due to just ten free software organizations participating in the 2012 edition (twenty in 2011) combined with our improved ability to define tasks which students could perform.


General Program Information and Guidance

RTEMS Specific Information

Be sure to add yourself to the table below.

Writing Proposals and Doing Projects

Problem: Over the years of participating in Summers of Code, the RTEMS project has noticed some recurring themes with Summer of Code projects:

  1. Projects would not meet the needs of the RTEMS project (and so would not be upstreamed).
  2. Projects would be completed in such a way as they were not maintainable (external projects would make use of the RTEMS build system see:LUA, as opposed to using the external software's own build system see:rtems-addon-packages), or projects would be hardcoded based on the RTEMS tree at one point in time see:BuildingMingwTools? the NSIS installer.
  3. Projects would be partially done without enough information for the next summer of code (or google code in) student to continue the work. For example: a change would be made for one architecture, but the way to generalize for the others was not documented.
  4. Projects would be submitted as one giant patch at the end of summer, if rtems-devel reviewed the patch, the student would be busy with schoolwork when it was time to make changes.
  5. Projects were not documented well enough for someone to verify it works.
  6. Projects would be done over and over again (instead of being new)

Solution: In the proposal the following MUST be included:

  1. A paragraph explaining what the project is trying to accomplish
    1. What is the core problem being solved?
    2. Why is this better than what we have already done?
  2. A sentence explaining how this project could be maintained (given developers have little time to maintain the code)
  3. Make documenting how the next summer of code student will pick up with developing the project in later years a project deliverable
  4. Break the project up into increments, so that if time runs out, each increment could be upstreamed, or at least written up on a wiki page so the next year's student could get farther faster.
  5. Make writing a tutorial to include a deliverable
  6. email the first draft to rtems-devel@… for feedback, and make adjustments before submitting (THIS IS A CRITICAL REQUIREMENT!!!)

Expect the following questions from the email list:

  1. We really need something else specific done instead... could you do something else specific?
  2. What's the maintainence plan?
  3. How will we test it?
  4. We did this already... How is this an improvement?
  5. This is too much for you to complete in a summer... please remove these pieces from your proposal

In addition, the RTEMS project will furnish not only a mentor, but a co-mentor, and one or two additional people to help with keeping the project on a topic that is both meaningful for the student, and for RTEMS.

Project Ideas

Open Projects contains the open projects list for RTEMS. It is by no means an all inclusive list and we are open to suggestions. Submissions of ports to new architectures, new BSPs, new device drivers, and test improvements are always welcomed.

Student Information

SoC Project Management

Visit Open Projects to find an interesting project, or propose your own! Ask about your project idea on the email list or IRC. The project descriptions often require additional knowledge to flesh out a project proposal.

We want you to hit the ground running, so you need to build RTEMS, modify it a little, and run samples as a prerequisite. Please visit the RTEMS GSoC Getting Started page for details.

RTEMS is an operating system targeting embedded systems that are cross-compiled, meaning that you develop on a host system and run programs on a target system. In general, students working on code require no special hardware, because RTEMS runs on simulators like gdb, skyeye, and qemu. The development can all be done and tested using a GNU/Linux or other suitable host.

RTEMS is designed to operate under tight resource restrictions. Some of the projects focus on breaking existing linkages between subsystems so those limits can be lowered further, or to help RTEMS fit into smaller systems.

Even though it is targeted to embedded systems, developers still expect as many features as possible. RTEMS provides a robust set of POSIX primitives and what is now known as the Classic API which provides hard real-time functionality. Some of the projects are focused on implementing a few missing pieces of POSIX functionality.

Not all of the projects necessarily run RTEMS or target an embedded system. Some of the projects are focused on improving the development experience by improving developer tools and environments.


Students' Summer of Code Tracking Table

The final version of your proposal must be submitted via Melange at Google. We have provided a Google Docs template for the Student Proposal. Feel free to copy it and invite potential mentors to review. Please be aware that this is NOT the official form to submit your proposal on. Your official application must be submitted through the GSOC Melange system. Periodically copy and paste your proposal into the student application form and save it in Melange to avoid any last minute problems. Until then, please use Google Docs and put the link in this table. That way any mentor or RTEMS community member can request access and comment on your proposal. Students.. please don't peek at each other. :)


Student Completed Hello IRC Handle Proposal Title Google Docs URL Blog
NAME Yes or No on #rtems Title Link to Google Docs for proposal
Jin Yang Yes SYCrane CAN driver and API for CAN stack Proposal
Prateek Tiwari Yes prateekt Supercore Scheduler Proposal
Hesham ALmatary Yes Hesham Enhance low-level API of libmm (Memory Protection & Caches) Link to Google Docs for proposal | Proposal
Deng Hengyi Yes weiY Atomic Operations and SMP lock debug tool for RTEMS Proposal
Dhananjay Balan Yes dhananjay Better RTEMS Support in GDB Link to Google Docs for proposal | Proposal
Peng Fan Yes freenix RTEMS Runtime Loader Proposal
Shubham Somani Yes S_Somani Application Configuration GUI for RTEMS. Proposal
Philipp Eppelt Yes phipse Paravirtualization of RTEMS Proposal
Vipul Nayyar Yes vipulnayyar Unified API Proposal
Jaskaran Singh Yes
Vivek Krishnamurthy Yes Vivekkmurthy RTEMS BenchMark Kit Proposal
Ye Xu Yes AresHsu Fault Tolerance / Power Aware Scheduling Proposal
Dinesh Rathinasamy Thangavel Yes rtdin Implementation of Condition Variable Classic API
Sree Harsha Konduri Yes sreekonduri SMP Aware Scheduler Proposal

The Student column is for your name.

The Completed Hello column lets us all know whether or not you completed the require Hello World project. Based upon our experience, students who have successfully compiled and run an RTEMS application have a MUCH MUCH higher chance of success on the proposed project.

The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on

The Proposal Title should be self-explanatory. If approved, we will ask you to create a project to host your work and link to it here. You will need to give at least your mentor and Joel Sherrill read/write access.

The Google Docs URL is your proposal in Google Docs that can be reviewed and commented on by mentors.

RTEMS Mentors

See our RTEMS Mentors page for a list of potential project mentors.

Last modified on Dec 24, 2015 at 1:16:44 AM Last modified on Dec 24, 2015, 1:16:44 AM

Attachments (1)

Download all attachments as: .zip