Version 33 (modified by Shubhamsomani, on Sep 16, 2013 at 11:53:33 PM) (diff)




Joel Sherrill, Cynthia Rempel


Help Wanted


The GUI has been coded, packaged and tested(on Windows,Ubuntu and CentOS). It can be cloned from (temporary).

The TUI has been coded and tested.(on Ubuntu).It can be cloned from (temporary).


The GUI attempts to solve the problem of how to make configuring RTEMS in a user-friendly way. Having the GUI automatically generated from either # a Makefile (or Makefiles) and or, # Waf solves the problem of keeping the GUI up-to-date with limited maintainer-hours.

The application GUI is # Written in Python # Allows the user to edit values # Recognizes when one of the values is not in correct format # Saves its own version of user configuration, and # Generate a .h file which would be used in an application # Automatically generated by running a command that uses textual substitution/parsing of

GUI Directory Structure -> Controller of the complete tool. -> File responsible for UI generation. -> File responsible for header file generation.

configuration.ini (present after you save values) -> responsible for storing saved values.

header.h -> The generated header to be used in Applications.

/text/ -> The text parser module, which parses the conf.t and fetches neccesary information.

The Graphical User Interface is created on the MVC(Model View Controller) framework. In the GUI ,the Model is the conf.t file where definitions of the macros are present. The View is file which handles with creating the GUI. The Controller is the file.


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 version 4.9.1 of RTEMS are documented in the Configuring a System chapter in the User's Guide.== Code ==

# A script to generate the GUI # A Makefile/Makefiles? to run the script # A generated GUI # Header files showing: the default, slightly modified default, and major configuration changes # A modified that's trivial to parse, but still generates informative HTML, each configuration item should clearly describe:

  • The Constant Name
  • Type: integer, defined, address, etc.
  • Default Values:
  • Range:
  • Description:
  • Notes


# A tutorial for adding additional functionality is provided, and the code is commented enough to enable additional functionality # A tutorial for using the GUI is provided # is commented so that developers will keep conf.t easy to parse== Testing ==

# Generate the files in the Code section

Required / Suggested Methodology

# (Suggested) Start with an existing open source project that generates configurations, for example: # (Suggested) Identify patterns in the open source project for how it writes configurations # (Required) Rewrite so it's trivial to use textual substitution to generate parts of the configuration GUI from them, and thus the trivial textual substitution will be easier to maintain # (Suggested) Use a template approach, automatically generate from, and have a file (or files) for the top, and a file (or files) for the bottom. # (Required) Generate configuration support from

Standards of Quality

# The GUI generating script runs on Fedora (this is the Linux distribution RTEMS provides support on) # The GUI generating script can be run from a Makefile. # The GUI generating script is open source and resulting GUI is written in a Python version that runs on 32-bit Debian 6.0.6 (stability oriented distribution), 64-bit Fedora (cutting edge distribution), MacOS, Windows cmd.exe (probably should be geared towards Windows 7, but might be tested on Vista, Server 2008, or 8)... # The GUI only generates headers with documented configuration constants from the C user's guide. # is modified to be easy to parse (i.e. the parser is trivial to write). # The GUI generates headers for all documented configuration constants in the C user's guide. # The GUI runs on 32-bit Debian 6.0.6 (stability oriented distribution), 64-bit Fedora (cutting edge distribution), MacOS, Windows cmd.exe.

Possible Goal Extensions beyond the Main Objective

# Add to the Makefile a check for whether the required libraries/headers were on a system, and if not, install them. # Copy the script and modify the copy to use another approach, for example: if an Eclipse Wizard was generated, re implement to generate the a Linux kernel config infrastructure. # Work on the RTEMS ConfigKit?. # Hook the Application Configuration GUI into the RTEMS source tree, by putting into # Package the GUI so that it includes the libraries it depends on, for example, if the GUI uses GTK+, the GUI would ship with GTK+

Skills Required

The level of expertise required by the developer tackling this project will have to have: # Prior experience with bash/Makefile scripting, C preprocessor, texinfo, and textual substitution is not required, but moderate skill level will be acquired while completing this task # The ability to read an open source programming language is highly desired # No mathematical/algorithmic background is required # An interest in finding and modifying code from existing open-source projects to meet this need is a big plus

There are a variety of ways to approach this project.

  • One solution is to write a GUI in Python. This should be cross-platform.
  • Another solution could be a Wizard/Editor? for Eclipse.
  • Another solution is to use the config infrastructure used by the GNU/Linux kernel.
  • Another approach would be to use the configuration GUI from eCos and NutOS: Resources =

JoelSherrill has used the GNU/Linux kernel config infrastructure for similar projects 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.

Chris Johns is the resident Python wizard and offered to help define classes to do the transformations. Python is a very portable language and toolkit which should be easy to dynamically generate UIs in -- both TUI and GUI. Using one implementation language would allow you to share the "controller" portion of the program but implement different "views"

A better possibility is to write a GUI program in Python which reads an XML format file describing the RTEMS configuration parameters. As the user set values, the program would store this information in another XML format file. When it was time to write the C code to use with the RTEMS application, the GUI application would write that. So we would have:

  • XML file describing RTEMS configuration parameters
  • XML save file with user settings
  • C/H file output for use with RTEMS application


# Some Design work # Python Config Parser Examples : The python config parser can read and write config files.