wiki:Developer/SmallProjects

Small Projects

This page contains projects which can easily be tackled by someone new to RTEMS.

No Coding Required

The following requires no coding although it may help to be able to read C code:

  • Improve the Wiki (requires Wiki editing)
    • BSPs: There are approximately 100 boards supported by RTEMS. Each board has a page in the Wiki and there is an standard Wiki Infobox. Most BSPs still do not have any information here, links to vendor information, or even a good description of the board. This effort just requires a bit of web research.
    • Open Projects: Create a template and prioritization for adding/updating open projects. See Open Project Template. Update all projects.
  • Wikipedia presence
    • Increase the web presence of RTEMS in Wikipedia. Find places in Wikipedia related to real-time/embedded operating systems that are relevant to RTEMS but do not lead readers toward RTEMS. (A good place to start is pages pointing to http://en.wikipedia.org/wiki/RTOS).
  • Flesh out our POSIX API User's Guide
    • RTEMS supports the POSIX 1003 standard following the "single process, multi-threaded" profile. We have permission from The Open Group and IEEE to excerpt text from their standards (available online) for use in this manual if cited. This manual is in the doc/posix_users directory in the source tree and by looking at it, I am sure you can find something that needs to be written. The corresponding code is in cpukit/posix or cpukit/libcsupport.
  • Use LanguageTool on RTEMS documentation, wiki pages, etc. to report spelling and grammar mistakes. If you start to tackle a large area, please help us make a checklist so we know what hasn't been checked.
  • Verify that every directive manual page indicates whether it can or cannot cause the current thread to be rescheduled.

Modest Coding Required

The following require only modest coding experience. Remember you can test RTEMS on a simulator so no special hardware is required.

  • Doxygen markup
    • RTEMS predates Doxygen and thus our .h files were not created with Doxygen markup. We have added this to a lot of files but would eventually like to see it in the score, rtems, posix, libcsupport, and libfs subdirectories of cpukit. In much of the code, the information is there but not in Doxygen markup format.
  • Writing test code
    • There is a continual need for more test code. We would like a timing test suite for the POSIX thread support that is comparable to the current Classic API timing test suite. We expect this will eventually comprise about 50 different tests so could be tackled as a class project with the individual tests assigned to different people or groups.
  • Write tests to improve Test Coverage. We want full object coverage for as much of RTEMS as possible. In this light, there are areas which are under tested in the automated test suite. This is an ongoing project with a variety of areas that need test cases written. Please ask for a current coverage report and a recommended area you can tackle.
  • Add example uses of each Manager to User's Guide. The C User's manual for the Classic API currently does not include example uses. One part of this is letting readers know that counting semaphores may be used to manage a pool of resources and binary may be used for mutual exclusion or condition synchronization. But the other part is moving it beyond the theoretical to show code and give examples of how this might be used in a real application. For example, condition synchronization with binary semaphore to announce that an interrupt occurred to a waiting task.

Investigate GCC Test Failures

The many many tasks that comprise this project are a bit harder but there are lots of small individual cases. If this isn't your strength, don't feel bad. But if you want to learn about debugging when you know very little, this is your opportunity. GCC is a complex beast with 100K tests. You are expected to understand everything, just figure out why something isn't working and maybe give a hint that will move it to resolution.

The GCC C, C++, and Ada test suites are regularly run on multiple architectures using simulators. All RTEMS tools tests reports are archived at http://www.rtems.org/pipermail/rtems-tooltestresults/ as well as at http://gcc.gnu.org/ml/gcc-testresults. Pick the latest test result for your favourite target architecture and start looking at the failure cases.

  1. Make sure there isn't a PR for it already. If there is, update it to note the failure is still occurring.
  2. Check out the gcc-testing CVS modules from the RTEMS CVS repository and follow the instructions to build and run the tests yourself.
  3. Pick a test that fails and investigate it
    1. Some "scan assembler" tests fail because RTEMS tests are run on a particular BSP which uses specific CPU model compile options which may conflict with the CPU model the instructions would be generated on.
    2. Others may core dump. Try to get a stack backtrace in gdb.
    3. Check that the stack isn't blown or that it isn't using too much memory for the BSP. It may be "expected to fail" on this BSP.
  4. In all cases, file a PR at http://gcc.gnu.org/bugzilla so your explanation is captured.
  5. If you can provide a patch, try. Fixing test infrastructure issues is generally easier than fixing code generation problems.
Last modified 15 months ago Last modified on Dec 20, 2015, 1:10:40 AM