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

Version 45 (modified by Chris Johns, on 12/02/14 at 09:49:01) (diff)





Joel Sherrill, Cynthia Rempel


Shubham Somani


The git repo needs to be updated to a location where a beginning RTEMS application developer would stumble onto it accidentally, but posting it to the rtems.git needs to be done by an RTEMS committer.

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 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.

Flow of Control of the GUI (useful while editing code)

When you open the executable the file is opened. After which the init function is called in the It is responsible for opening the first dialog box. The first dialog box has a Open button in it. On clicking the open button, the function OnOpen is called. The OnOpen function is responsible for

a) Getting the path of conf.t

b) Opening conf.t

c) Reading conf.t and feeding it to the text parser (In this step, the return_parameters module in the file is called. It parses all the necessary information from conf.t)

d) After getting the Output from the text parser, feeding the output to the for UI creation.

In the GUI, the set_parameters function is called with the data fetched from the text parser. This function is a setter function and it sets the value of the global variable parameters and then calls the main function of the GUI.

The main function initialises the GUI and launches the Application. Before dynamically creating the GUI, it parses out exact default values to be put in the UI.

Now according to user input the following cases may arise-

a) The user presses Save button. In this case the OnSave function will be called. The OnSave function makes use of Python's config parser module and writes the pair (macro name, current value) into the configuration.ini file.

b) The user presses the Check button. In this case the OnCheck function will be called. The OnCheck function uses regular expressions to see whether the macro values are in format or not.

c) The user presses the Load button.The OnLoad function is called. In this case the values stored in the configuration.ini file are loaded into the GUI.

d) The user presses the Generate button. The OnGenerate function is called. In this case the create_header function will be called which is present in the The sees if the value is same as the older value or the user has changed it. In case the user has changed the value, then it gets written into the header file.

Using generated header with Applications

This post will cover on how to use the generated header with applications.

For using the header there are basically 3 major steps-

Step 1) Get the Application-

You need to have the application in which you want to use the header. For example- to use an application from examples-v2 you would need to clone the examples v2 repository ( You can do this easily by - git clone git:// examples-v2 has a lot of sample applications. You can choose any one of them to use with the header.

For the purpose of this tutorial I will choose the ticker application.

Step 2) Generate the header-

Now open the editor you are most comfortable with and open the init.c file of the particular application. init.c is the file which contains configuration data of the application. Scroll down and you would see configuration information. For the ticker application the configuration information looks as follows-

Now since we wish to use the header generated by the GUI for storing our configuration information, we open the GUI. On opening the GUI you will be greeted by a welcome screen. On the welcome screen you would see a box saying open conf.t. Click on that box and go to the location of conf.t ( . It should be present in rtems/doc/user/conf.t.

Now you would be able to see the complete GUI with a lot of sections and configuration parameters. Change the parameters according to your requirements. For the ticker application as an example we would do the following changes-


2) Click on Classic API configuration and set CONFIGURE_MAXIMUM_TASKS 4


4) Click on the basic system information tab and set CONFIGURE_EXTRA_TASK_STACKS (4 * RTEMS_MINIMUM_STACK_SIZE)

now go to header tab above and click on generate. A header file with the name of header.h would have been generated now in the same directory as that of the GUI. Now copy this header file to the location of the init.c file of your application.

Now that you have the header, remove the configuration information from init.c and instead replace it with

# include "header.h"

If you do a git diff then it contents should be like this (for ticker's init.c) -

If you wish you can also save this configuration and use it later for future applications.

Reached Here? Sweet!

Step 3) Compile the Application with the generated header-

These 2 sections would be of great help for learning how to compile and run the application-

Here I would take SPARC for the purpose of compiling.

1) Configure the shell to compile the BSP

 export RTEMS_MAKEFILE_PATH=prefix/sparc-rtems4.11/sis/

2)Add the RTEMS toolset to the PATH

export PATH=/opt/rtems-4.11/bin:$PATH

3) cd into examples-v2 now

cd examples-v2

4) build the executable


5) Run the the ticker executable in GDB

sparc-rtems4.11-gdb `find . -name ticker.exe`

5) Select the sim target in GDB

(gdb) target sim
Connected to the simulator.

Load and run the executable

(gdb) load
(gdb) run

And voila! your application runs with ease! :)

TUI Directory Structure -> .py file to read/write data from/to .ini file input_provider.h -> header file to call existing .py files from cpp and provide input to TUI. TUI.c -> cpp file used to make the TUI. /text/ -> file to parse conf.t and provide input to the TUI.

Flow of Control of TUI (useful while editing code)

When we open the TUI, the TUI.c file runs. It then calls the return_parameter() function in input_provider.h This file makes use of the Python/C API which is used for calling python inside cpp. Here, the previously made parsing functions of and are called. They read the parameters and after reading these parameters, Ncurses based TUI is dynamically generated.

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+


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.