Version 1 (modified by Robert, on Nov 20, 2008 at 3:17:07 PM) (diff)

New page: ==Introduction== This page describes how to setup and use RTEMS Eclipse Plug-in. This plug-in has most features of a full-fledged Eclipse/CDT IDE with ordinary GNU toolchain. After setup, ...

RTEMS Eclipse Plug-in


This page describes how to setup and use RTEMS Eclipse Plug-in. This plug-in has most features of a full-fledged Eclipse/CDT IDE with ordinary GNU toolchain. After setup, except typing in project name and post build commands, with only mouse clicks, it can finish the whole process of:

  • Generate skeleton code
  • Compile
  • Link
  • Generate boot image and externally start up the system (in simulator)
  • Setup break points, and hook GDB to the remote target

Current Capabilities

Here is a list of its main features:

#Editing features come with Eclipse/CDT, such as syntax error checking, refactoring, etc. #RTEMS specific template enabling auto-generation of skeleton code via new-project wizard #Cross-compilation #Post-build infrastructure with implementation of boot image generation #Remote GDB integration (via serial GDB stub)


#Currently there is only one configuration to build executables, and no configuration to build libraries yet. #Due to hard and soft resource constraint, I only tested the plug-in against i386 target on Windows (and it's done with simulation). For other targets, I only verified that corresponding toolset could be invoked. Since Eclipse and the plug-in are written in Java, it's likely they would work in most host environments. #GDB with CEXP is not tried yet.

Starting Point

It's assume that we start from the environment constructed by the end of Simulate Serial Communication Application. In other words, it assumes that #RTEMS MinGW toolset has been installed according to Windows Installers #Build, boot and simulation (or real hardware) environment has been setup according to MinGW:Grub2:VMWare Development Environment Setup #Serial communication hardware has been proven to work with RTEMS. Refer to Simulate Serial Communication Application. #JDK with version at least 1.5 is installed. If not, download one from My JDK version is 1.5.0_10. You can check the version using "java -version".

Eclipse, CDT and RTEMS Plug-in Installation


  • For this plug-in development, I put RTEMS source code under C:/opt/src/rtems, my build directory is C:/opt/src/rtems/i386_build, and it's configured as the following: /opt/src/rtems/rtems-4.9.0/configure --target=i386-rtems4.9 --enable-rtemsbsp=pc686 --enable-cxx --enable-rdbg --prefix=/opt/rtems_install
  • If desired, it's better to change baud rate now in c\src\lib\libbsp\i386\shared\comm\i386-stub-glue.c as the following, and build or rebuild. The reason is that when verbose option is enabled, GDB becomes slow with low baud rate.

/* BSP_uart_init(uart, 38400, CHR_8_BITS, 0, 0, 0); */ BSP_uart_init(uart, 115200, CHR_8_BITS, 0, 0, 0);

Setup RTEMS Environment Variables

  • RTEMS_TOOLSET holds set of GNU tool commands in the order of Archive, Assembler, C Compiler, C++ Compiler. It defaults to i386 target toolset if undefined, so you don't need define it if you build i386 target.

RTEMS_TOOLSET=i386-rtems4.9-ar, i386-rtems4.9-as, i386-rtems4.9-gcc, i386-rtems4.9-g++

  • RTEMS_BSP_DEFINED_SYMBOLS holds BSP defined symbols determined by configuration.

From DEFS of a generated Makefile like "i386_build\i386-rtems4.9\c\pc686\testsuites\samples\Makefile", extract all -DXYZ=1, remove "-D" and "=1", and then set the variable like the following:


  • RTEMS_INSTALL_BSP_DIR holds directory of the installed BSP


  • RTEMS_INSTALL_DIR holds the install directory of built BSP (i.e., the --prefix in configure)


  • RTEMS_TARGET_CPU_GCC_LIB_DIR holds the GCC lib directory for target CPU


  • RTEMS_TOOL_DIR holds the directory of toolset


  • RTEMS_TARGET_TOOL_DIR holds the directory of target toolset


When the plug-in cannot construct bin, lib or include path, it'll be disabled, and won't show up, just like other toolchains won't show up when a RTEMS template is selected.

Install Eclipse

There are several ways to install Eclipse and CDT. Take a look of We need Eclipse and CDT of the simultaneous release no earlier than Ganymede SR1 release. One of the possible ways is described below.

#Download "Eclipse for RCP/Plug-in Developers" from The file name would look like "". #Unzip it to a directory like c:/java. c:/java will be used in the rest of this document. #(Optional) Rename c:/java/eclipse to c:/java/eclipseCDT. c:/java/eclipseCDT will be used in the rest of this document. #(Optional) Create short-cut of c:/java/eclipseCDT/eclipse.exe on Windows desktop. #Create a directory (e.g., c:/java/CDT_workspace) for Eclipse workspace

Initial Eclipse Launch

#Double click on the above eclipse short-cut, and select the workspace created above (e.g., c:/java/CDT_workspace) #Go to workbench

Install or Update CDT

"Eclipse for RCP/Plug-in Developers" package does not come with CDT. "Eclipse IDE for C/C++ Developers" does not come with the debugger we need. Thus in all cases, this step is necessary. #In Eclipse, select menu "Help | Software Updates...", then select "Available Software", and click on "Add Site..." #Fill in "Location" field with CDT update URL (e.g., from: #Select all CDT features except any of XL C/C++ Compiler features, then click on "Install...", and follow instructions to finish the update. If you install XL C/C++ Compiler features, you might get annoying error or warning down the road. #After Eclipse restarts, verify that you have "Eclipse GDB Hardware Debugging Plug-in" installed by selecting menu "Help | About Eclipse Platform" and CLick on "Feature Details".

Install RTEMS Eclipse Plug-in

#Close Eclipse if it's running. #Download the zip file RtemsEclipsePlug? from #Install it in one of the following ways #*Unzip it into c:/java/eclipseCDT #*Unzip it into a temporary location, then copy org.rtems.cdt.toolchain_x.y.z.jar into c:/java/eclipseCDT/plug-ins. #Start Eclipse

Note about Updating Plug-in

When the time comes to update RTEMS plug-in, in order to workaround a caching issue in Eclipse, do the following: #Close Eclipse if it's running. #Delete RTEMS plug-in jar file from c:/java/eclipseCDT/plug-ins. #Start Eclipse, after it opens up, close it. #Follow the above steps to install the plug-in as a fresh new install.

Application Skeleton Code Auto-Generation

#Go to C/C++ perspective if it's in other perspective #Select menu File | New | C Project, type in project name "SerialRemoteDebug?", then select "RTEMS Serial Remote Debug Project" template under "Executable", and the only applicable "RTEMS Toolchain" is automatically selected.
<center>No image "IDE_New_Project.jpg" attached to Developer/Eclipse/Plugin</center>
#Click "Next", and you can fill information in the "Basic Settings" page or simply click on "Next". #Click on "Next", and then click on "Finish". By default, "Build Automatically" is turned on, and without any manual source code edit ting and manual configuration, the project is built automatically, and the executable is created. #Try menu "Project" | "Clean..." to clean and rebuild it. #From "Project Explorer", open src/SerialRemoteDebug.c. You can see it has been automatically based on the template.
<center>No image "IDE_New_File_Bld.jpg" attached to Developer/Eclipse/Plugin</center>
Noticed the include paths which are made available through auto-discovery customization. They are necessary for features like indexing, syntax error checking, etc. Here is the generated code:

 *  File Name   : SerialRemoteDebug.c
 *  Author      : Your name here
 *  Version     : 1.0
 *  Description : A simple serial and shell test program if defined TEST_COM1;
 *                A serial remote debug test program otherwise
 *  Copyright   : Your copyright notice


#include <stdio.h>
#include <stdlib.h>

#include <string.h>  /* String function definitions */
#include <unistd.h>  /* UNIX standard function definitions */
#include <fcntl.h>   /* File control definitions */
#include <errno.h>   /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */

#include <rtems.h>
#include <rtems/shell.h>

// BSP specific include
#include <bsp.h>
#include <bsp/uart.h>
#include <bsp/tty_drv.h>

extern rtems_task Init(rtems_task_argument argument);


#include <libchip/ata.h> /* for ata driver prototype */
#include <libchip/ide_ctrl.h> /* for general ide driver prototype */


 * these values are higher than needed...
#define CONFIGURE_MAXIMUM_TASKS             20



#include <rtems/confdefs.h>


#include <rtems/shellconfig.h>

extern int BSPConsolePort;

/* Temporarily worked around the issue with remote_debug in i386.
   "int     remote_debug;" is defined in m68k-stub.c, but only declared
   in i386-stub.c. Also except "remote_debug = !(remote_debug);", nowhere else
   value is assigned to remote_debug.
int remote_debug = 1;

 * Setup GDB as described in c\src\lib\libbsp\i386\shared\comm\GDB.HOWTO.
 * Later found similar function: init_remote_gdb in
 * c\src\lib\libbsp\i386\shared\comm\gdb_glue.c. But it does not fit with the
 * following hardware configuration:
 *       there exist VGA console and COM1, but not COM2.
void setupRemoteGDB(void) {
   // Initialize GDB glue
   if(BSPConsolePort != BSP_UART_COM2) {
        // If com2 is not used as console use it for debugging
   } else { // Otherwise use com1  */

   // Initialize GDB stub itself

   // Initialize GDB break in capability
   // It has to be called after set_debug_traps

   // Put breakpoint in

void testIO(char *devName) {
  char buffer[256];

  #ifdef TEST_COM1
    printf("*** Simple COM1 Test (9600 8N1) ***\n");
    printf("*** Simple Remote Debug Test ***\n");

  int fd = open(devName, O_RDWR | O_NOCTTY | _FNDELAY);

  int numBytes = write(fd, "Hello, I'm waiting for input...\r\n", 33);
  if (numBytes < 0) {
    printf("\nFailed to write to %s!\n", devName);

  numBytes = read(fd, buffer, 255);
  if (numBytes < 0) {
    printf("\nFailed to read from %s!\n", devName);

  } else {
    buffer[numBytes] = 0; // terminate


void startShell(void) {
  printf("\n====== starting shell ======\n");
    "SHLL",                          /* task_name */
    RTEMS_MINIMUM_STACK_SIZE * 4,    /* task_stacksize */
    100,                             /* task_priority */
    "/dev/console",                  /* devname */
    0,                               /* forever */
    1                                /* wait */

rtems_task Init(rtems_task_argument ignored) {
#ifdef TEST_COM1
  char devName[] = "/dev/ttyS1";
  char devName[] = "/dev/console";




  exit( 0 );
  1. Normal editing features like refactoring works (Right mouse click on a symbol | Refactor | Rename...).
    <center>No image "IDE_Refactor.jpg" attached to Developer/Eclipse/Plugin</center>
    <center>No image "IDE_Refactor_Preview.jpg" attached to Developer/Eclipse/Plugin</center>

RTEMS Specific Customization Features

#Predefined symbols, includes and library paths made available through auto-discovery customization
<center>No image "IDE_Gen_Includes.jpg" attached to Developer/Eclipse/Plugin</center>
<center>No image "IDE_Gen_Symbols.jpg" attached to Developer/Eclipse/Plugin</center>
<center>No image "IDE_Gen_Lib_Paths.jpg" attached to Developer/Eclipse/Plugin</center>
#Default defined symbols for C/C++ compiler (previous ones are for general editing features)
<center>No image "IDE_C_CPP_Symbols.jpg" attached to Developer/Eclipse/Plugin</center>
#Default miscellaneous compiler settings
<center>No image "IDE_Compiler_Misc.jpg" attached to Developer/Eclipse/Plugin</center>
#Default shared libgcc linker setting
<center>No image "IDE_Link_Shared.jpg" attached to Developer/Eclipse/Plugin</center>
#Default miscellaneous linker settings
<center>No image "IDE_Linker_Misc.jpg" attached to Developer/Eclipse/Plugin</center>
#Default RTEMS specific manager-related relocation linker settings (corresponding to MANAGERS/MANAGERS_NOT_WANTED in Makefile)
<center>No image "IDE_RTEMS_Specific.jpg" attached to Developer/Eclipse/Plugin</center>

Post-build Infrastructure

#Post-build step equivalent to "make install"
<center>No image "IDE_Post_Build.jpg" attached to Developer/Eclipse/Plugin</center>
#Via menu "Run | External Tools | External Tools Configurations...", create and run an external tool to build boot image and possibly other actions like loading image onto hardware. Since we can start shell and run script, its functionality can be easily extended.
<center>No image "IDE_Ext_Tool.jpg" attached to Developer/Eclipse/Plugin</center>
Here is content of

#! /bin/sh

grub-mkrescue --overlay=/opt/rtems_install/i386-rtems4.9/pc686/lib/rtems-4.9 --overlay=/opt/rtems_install/grub_cfg /vm/pc686_rtems4.9.0.iso

Note: Might be able to combine the above 2 steps into one.

Remote GDB Integration

Note: as shown below, Zylin CDT plug-in is not needed.

#Via menu "Run | Debug Configurations", create a "GDB Hardware Debugging" configuration, and fill in "Main" page as shown below.
<center>No image "IDE_Dbg_Main.jpg" attached to Developer/Eclipse/Plugin</center>
#Fill in "Debugger" page exactly as shown below.
<center>No image "IDE_Cfg_Debugger.jpg" attached to Developer/Eclipse/Plugin</center>
#Fill in "Startup" page as shown below. (For baud rate setting, refer to the note regarding baud rate in the installation section.)
<center>No image "IDE_Dbg_Startup.jpg" attached to Developer/Eclipse/Plugin</center>
#Start the virtual machine (VM) in VMWare (or startup your real hardware), and execution breaks as shown below.
<center>No image "IDE_VM_Break.jpg" attached to Developer/Eclipse/Plugin</center>
#Setup one or more break points in IDE, and start GDB from IDE. As shown below, if everything works correctly, your GDB on host machine should stop at your 1st break point, and you can evaluate variable values, step through code, etc.

Enjoy[[BR]]<center>No image "IDE_Debugging.jpg" attached to Developer/Eclipse/Plugin</center>

Attachments (6)

Download all attachments as: .zip