Notice: We have migrated to GitLab launching 2024-05-01 see here:

Version 35 (modified by Gedare Bloom, on 12/04/14 at 16:31:41) (diff)

fix links to previous gsocs


RTEMS is a participating organization of the Google Summer of Code 2014! 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 proposal we request. We also require you build RTEMS, create an application, run it and post the result to the RTEMS mailing list. The GSoC Getting Started page has some more information.

Potential Mentors: Share your knowledge and pledge to help a student. Visit the GSoC2014 Melange system to register and open a connection with RTEMS Project.

General Information

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

Information for prior years:

General Program Information and Guidance

RTEMS Specific Information

Be sure to add yourself to the table below.== Writing Proposals and Doing Projects ==


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)


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

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.

Please read through the SoC Project Management page to get a sense of our expectations from you for the summer of code.


Students' Proposals

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
NAME Yes or No nick on #rtems Project Title Link to Google Docs for proposal (shared with mentors)
Zhang wenjie Yes Json Condition Variables for RTEMS Proposal
Youren Shen Yes Sched Paravirtualization Layer in RTEMS Proposal
Hesham AL-Matary Yes Hesham Porting RTEMS to OpenRISC Proposal
Andre Marques Yes asuol Raspberry Pi BSP Peripherals Proposal
Yang Jin Yes jinyang Porting CAN driver, LinCAN, to RTEMS Proposal
Janek van Oirschot Yes JustJanek ARINC 653 compliance on RTEMS using POK Proposal
Premysl Houdek Yes AoLaD RTEMS port to Cortex – R4f 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. The Google Docs URL is your proposal in Google Docs that can be reviewed and commented on by mentors.

Students' Summer of Code Tracking Table

Students whose GSoC project is accepted by RTEMS shall fill in a slot with their information in the following table, which helps to centralize SoC Project Management.

Student IRC Handle Project Link Repository Link Blog
NAME nick on #rtems Link to Project Wiki page Link to project's public Github repository Link to your development blog
Hesham ALMatary Hesham Wiki page github Blog
Andre Marques asuol Wiki page github Blog
Youren Shen Sched Wiki page github Blog
Janek van Oirschot JustJanek/JustJNK Wiki page github Blog
Premysl Houdek AoLaD Wiki page github
Krzysztof Miesowicz krzysiekm13 TODO: make wiki github Blog

RTEMS Mentors

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

Attachments (1)

Download all attachments as: .zip