Getting Started with Tilcon Graphics on VxWorks: A Practical Guide

Getting Started with Tilcon Graphics on VxWorks: A Practical Guide

🎨 Understanding Tilcon, WindML, and VxWorks

#

Tilcon is a graphical user interface toolkit designed for embedded systems where responsive graphics must coexist with real-time operating system requirements.

When integrated with VxWorks and Wind River Media Library (WindML), Tilcon provides a development path from visual interface design to a deployable embedded GUI. Developers can create screens and widgets using the Tilcon Interface Design Tool (IDT), integrate the resulting designs into VxWorks applications, and validate them using a simulator before moving to physical hardware.

A typical Tilcon application consists of several layers:

• Tilcon IDT — Used to visually design interfaces and generate Tilcon Window Description (.twd) files.
• Tilcon runtime — Loads and manages the graphical interface.
• WindML — Provides graphics, fonts, input devices, and display services.
• VxWorks — Provides the underlying real-time operating environment.
• VIP — Packages the required VxWorks and WindML components into the system image.
• DKM application — Contains the application-specific GUI logic.

Keeping these components appropriately separated makes the development process easier to maintain and troubleshoot.

🖥️ Recommended Development Environment

#

The original workflow can be validated using the VxWorks x86 simulator, avoiding the need for dedicated target hardware during initial development.

Exact project names, paths, and component versions can differ between Wind River releases, so the installed version should always be used as the reference when configuring a project.

🧩 Step 1: Design the GUI Prototype

#

The first stage is creating the graphical interface in the Tilcon Interface Design Tool (IDT).

The basic workflow is:

1. Create the desired screens.
2. Add widgets and graphical elements.
3. Configure their properties.
4. Simulate the interface inside the design environment.
5. Generate the .twd Tilcon Window Description file.

The .twd file represents the visual definition that the application can load at runtime.

This approach separates visual design from application programming, allowing interface changes to be made without rebuilding the entire graphical system from scratch.

⚙️ Step 2: Build the WindML Media Library

#

WindML provides the lower-level graphics and input functionality required by Tilcon.

To create the required library:

1. Create a new Downloadable Kernel Module (DKM) project.
2. Select Librarian as the build tool.

   

3. Configure the graphics monitor.
4. Select an appropriate display mode.

   

5. Build the resulting library.

Example configurations include:

1024x768-60-32 Bit – ARGB8888
1280x1024-60-16 Bit – RGB565

The Librarian selection is important because this project is intended to generate a library archive rather than a standalone executable.

A higher display resolution can also make it easier to test applications containing multiple screens or graphics-intensive demos.

🏗️ Step 3: Configure the VxWorks Image Project

#

The next step is creating the VxWorks Image Project (VIP) that will provide the operating environment for the GUI application.

Within the VIP component configuration, enable:

INCLUDE_WINDML_ALL

The required WindML components should include the functionality needed by the application, such as:

• Graphics
• Fonts
• Keyboard input
• Pointer input
• Display support
• Other required media components

The components included in the VIP must remain compatible with the WindML library built previously.

After configuration, build the VIP to generate the bootable VxWorks image.

📦 Step 4: Create the Tilcon Application DKM

#

The Tilcon application contains the code responsible for loading and controlling the graphical interface.

Select the Appropriate Tilcon Template

#

When adding Tilcon support to the project, select:

Tilcon Graphics application support (not linked with Media Library)

Keeping the Tilcon application separate from the Media Library provides a cleaner architecture and makes it easier to update or replace individual components.

Add the Sample Application

#

For the classic TireGauge example, copy the appropriate source file from the Tilcon installation into the DKM project.

A typical source location is:

<tilcon-install>\components\tilcon-5.8\samples\tutorials\tiregauge\tiregauge.c

After copying the source, refresh the project in Workbench so that the new file appears in the project configuration.

Configure the Build Macros

#

Open:

Project Properties
→ Build Properties
→ Build Macros

Add the required VxWorks definition:

-DCC_TRT_VXWORKS

This tells the Tilcon source that it is being compiled for the VxWorks environment.

Configure Libraries

#

Under the project’s Libraries configuration, add the required Tilcon and support libraries using the fully qualified library-file option.

The exact library list depends on the Tilcon version and application.

Once the configuration is complete, build the DKM.

The resulting .out file can then be downloaded to the target.

🚀 Step 5: Run the Application on the VxWorks Simulator

#

Start the VxWorks simulator, such as SIMNT, and download the compiled application.

Symbols can optionally be loaded to simplify debugging.

From the target shell, start the application’s entry point:

sp main

If the environment has been configured correctly, the TireGauge demonstration should appear.

The sample provides a useful first validation because it exercises the complete chain:

Tilcon → WindML → VxWorks → graphics simulator

Successfully displaying the demo confirms that the major components are correctly integrated.

📡 Running the RadarDemo

#

The RadarDemo provides a more advanced example and introduces additional considerations involving working directories and .twd resources.

A typical source location is:

tilcon-5.x\samples\demos\RadarDemo

The main source file may be RadarSystem.cpp or its corresponding version-specific equivalent.

One important configuration is the working directory used to locate Tilcon resources:

#define CC_WORKINGDIR "/tgtsvr/samples/demos/RadarDemo"

The /tgtsvr path commonly maps to the Workbench workspace.

Therefore, the application must be able to locate the required .twd file and associated resources through that path.

Two practical approaches are possible:

1. Copy the complete samples directory into the appropriate workspace.
2. Copy only the required RadarDemo resources and modify CC_WORKINGDIR accordingly.

After rebuilding and downloading the application, start it with:

sp main

The radar visualization should then appear on the simulator display.

🔄 Tilcon 5.9 and VxWorks 6.9 Differences

#

The basic workflow remains similar when moving from older Tilcon/VxWorks environments to combinations such as Workbench 3.3, VxWorks 6.9, WindML 5.4, and Tilcon 5.9.

However, project organization becomes more clearly separated.

A typical setup contains:

Target Support Package

#

The TSP provides platform-specific Tilcon support and configuration.

Example Application

#

The Example Application contains the actual GUI application and demonstrates how the Tilcon runtime is used.

The Media Library continues to be built separately using the Librarian tool.

The VxWorks build definition and source configuration also continue to depend on the VxWorks-specific definition:

-DCC_TRT_VXWORKS

Because project structures changed between releases, developers should use the tutorial corresponding to the installed Tilcon version rather than blindly copying project settings from an older release.

🛠️ Troubleshooting Common Tilcon Problems

#

Several configuration problems repeatedly appear when setting up Tilcon applications.

Missing Graphics Output

#

If the application starts but no GUI appears, verify:

• WindML components are included in the VIP.
• The WindML library was built successfully.
• The selected display mode matches the simulator.
• Tilcon libraries are correctly linked.
• The application was actually started with sp main.

.twd File Cannot Be Found

#

Incorrect resource paths are a common source of runtime failures.

Check:

• CC_WORKINGDIR
• /tgtsvr mappings
• Workspace directory structure
• Location of the .twd file
• Case-sensitive path differences where applicable

The application must be able to resolve its graphical resources from the target environment.

Linker Errors

#

Link failures often indicate that the required Tilcon or WindML library has not been added to the DKM.

Check the library configuration and ensure that the library versions correspond to the installed Tilcon and VxWorks releases.

Version Compatibility Problems

#

Mixing components from different Tilcon, WindML, Workbench, and VxWorks releases can produce subtle build or runtime problems.

When possible, keep the following versions aligned:

• VxWorks
• WindML
• Tilcon
• Workbench
• BSP
• Tilcon support libraries

💡 Practical Development Tips

#

A few practices can make Tilcon development significantly easier.

Keep WindML Separate

#

Keeping the Media Library independent from the Tilcon application simplifies maintenance and allows the graphics layer to be updated without unnecessarily restructuring application code.

Test with the Simulator First

#

The simulator provides a convenient environment for validating:

• GUI layouts
• .twd loading
• Application logic
• Event handling
• Basic graphics behavior

Once the software works in simulation, it can be moved to physical hardware for device-specific validation.

Check Resource Paths Early

#

Do not wait until the final integration stage to test .twd loading.

Path problems are among the easiest issues to overlook because the application may compile and download successfully while still failing when it attempts to load its graphical resources.

Use Practical Display Settings

#

A sufficiently high display resolution provides more room for testing complex interfaces and multiple demonstrations.

At the same time, the selected pixel format must match the capabilities of the configured graphics environment.

🔭 Moving from Demonstrations to Production

#

The TireGauge and RadarDemo applications are useful because they validate different aspects of the Tilcon environment.

After successfully running these examples, developers can begin replacing the sample GUI components with application-specific screens and logic.

Production systems should additionally evaluate:

• Memory footprint
• Rendering performance
• Input latency
• Resource loading
• Display-driver behavior
• Target-specific graphics acceleration
• Localization and multi-language requirements
• Startup time
• Failure and recovery behavior

Simulator success is an important milestone, but physical hardware can expose additional constraints involving display controllers, input devices, memory bandwidth, and BSP implementation.

🏁 Conclusion

#

Tilcon, WindML, and VxWorks provide a structured development stack for creating graphical embedded applications that combine sophisticated user interfaces with a real-time operating environment.

The basic workflow is straightforward:

1. Design the interface in Tilcon IDT.
2. Generate the .twd graphical description.
3. Build WindML as a library.
4. Add WindML support to the VxWorks VIP.
5. Create the Tilcon DKM application.
6. Define CC_TRT_VXWORKS.
7. Link the required Tilcon libraries.
8. Download the application to the simulator.
9. Start the application with sp main.
10. Move to physical hardware after the software is validated.

The TireGauge example provides a simple introduction, while RadarDemo demonstrates more complex resource handling and graphical behavior.

Once the relationships between the Tilcon application, WindML library, VxWorks image, and target filesystem are understood, the same workflow can be adapted to substantially more sophisticated embedded interfaces.