![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
The project facility is a key element of the Tornado IDE. It provides graphical and automated mechanisms for creating applications that can be downloaded to VxWorks, for configuring VxWorks with selected features, and for creating applications that can be linked with a VxWorks image and started when the target system boots. The project facility provides mechanisms for:
|
|||||||||||||||||||
|
WARNING:
Use of the project facility for configuring and building applications is largely independent of the methods used prior to Tornado 2.x. (These methods included manually editing the configuration files config.h or configAll.h, while the project tool uses .cdf files). The project facility provides the recommended and simpler means for configuring and building, although the configuration file method may still be used (see 5. Command Line Configuration and Build). To avoid confusion and errors, the two methods should rarely be used together for the same project.
|
||||||||||||||||||
One exception is for any configuration macro that is not accessible through the project facility GUI (which may be the case, for example, for some BSP driver parameters). You can use a Find Object dialog box to determine if a macro is accessible or not (see Finding VxWorks Components and Configuration Macros). If it is not accessible through the GUI, a configuration file must be edited, and the project facility will implement the change in the subsequent build. |
|||||||||||||||||||
The order of precedence for determining configuration is (in descending order): |
|||||||||||||||||||
A second exception may be building a project based on a BSP. If you have customized your BSP by modifying config.h and other configuration files, you can convert it to a project and combine it with your application in the project facility. See 5.7 Building Projects from a BSP. |
|||||||||||||||||||
In general, changes to header files in the BSP or the BSP makefile are only carried over to projects by recreating the projects. However, changes to .c files are automatically picked up by existing projects. |
|||||||||||||||||||
There are several key terms that you must understand before you can use the project facility documentation effectively:
As its name implies, the Workspace window provides the framework for the project facility. The window displays information about projects files, VxWorks components (if any), and build options in three tabbed views: Files, VxWorks, and Builds (Figure 4-1).
A context-sensitive menu is available in each of the workspace views. A right-mouse click displays the menu. The first section of the menu provides commands relevant to the GUI object you have selected. The second section displays commands relevant to the current page of the window. And the third section displays global commands that are relevant to the entire workspace (Figure 4-2).
Many of the pop-up menu options are also available under the File, Project, and Build menus.
For information about using the Tornado editor, see 3. Editor. For information about using an alternate editor, integrating configuration management tools (such as ClearCase) with the project facility, and other customization options, see 12. Customization.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
If your BSP was included with Tornado 2.2, you can create a bootable project from it directly. Use the project wizard for a bootable application to create a project based on your BSP or the pre-built project (bspName_vx.wpj) which is shipped with every Wind River-supplied BSP.
For information on migrating a Tornado 2.0-compliant BSP to Tornado 2.2, see the Tornado Migration Guide.
If your BSP came from a third party or from Tornado 1.0.1, see the Tornado Migration Guide or the Tornado 2.0 documentation.
You may wish to enable the Tornado 1.0.1 compatibility mode, which exposes menu items to execute BSP builds in a BSP directory. (See 12. Customization.) Once your BSP builds, you may proceed to create a bootable project from it immediately. See 5.7 Building Projects from a BSP.
If you need to create your own BSP, refer to the VxWorks BSP Developer's Guide (a separate product available from Wind River). If you wish to develop the BSP and the application code in parallel, you may wish to begin application development on the VxWorks simulator. See Using the Simulator BSP.
If you already have a custom BSP that is Tornado 2.0 compliant, see the Tornado Migration Guide for information on migrating from 2.0 to 2.2.
If you already have a custom BSP but it is not Tornado 2.0 compliant, you will need to modify it to conform to the guidelines outlined in the VxWorks BSP Developer's Guide in order to use it with the Tornado project facility. Once you have modified it, verify that it builds properly before creating a project for it.
|
|
|||||||||||||||||||
You may still use a non-compliant BSP by managing its customization and configuration manually. For information on using manual methods, see 5. Command Line Configuration and Build. You can still create downloadable projects to hold your application code and download them to a target booted with a non-compliant BSP.
You can use the target simulator if you want to develop the BSP and application code for your product in parallel, or if your target hardware is not yet ready. The integrated simulator contains default VxWorks functionality sufficient for supporting many applications. It does not have networking support; for this you can use the full simulator (VxSim), which is available as an optional product.
If you are using the integrated simulator and do not need to customize it by adding or removing VxWorks functionality, you need not create a bootable project until you have your production BSP ready.
If you need additional VxWorks functionality, you will need to create a bootable project immediately. Use the project wizard for a bootable application. You will use a different base depending on what additional functionality you need.
The process for creating a project, and configuring it, is identical for both the integrated and full simulator.
Base this project on the simulator BSP (either the integrated simulator or the optional product), or the pre-built, default simulator project (simhost_vx.wpj. At this point, your project will build an image identical to the integrated simulator as you received it from Wind River. Now add any components you need using the VxWorks tab in the Workspace view (see 4.4.3 Configuring VxWorks Components).
Use size information to make sure your image will fit in your target memory space. The approximate image size information displayed in the Component Add Dialog reports the size of the VxWorks code in your configuration and the increase or decrease resulting from adding or removing components. This size will be smaller than your actual image size, as it does not reflect your BSP support code or any application code you will be adding.
If you already have a working application, or if your application is very large, you may want to use your own build system. You can use the project facility to link the output of an external build into VxWorks and even start external builds (see External Build System).
Alternatively, you may want to use the project facility to configure your VxWorks image and produce a makefile. You can build your application outside Tornado and call the project facility-generated makefile from your build to produce a final image.
Use this approach if your edit-compile-reboot cycle is relatively quick. Add the files to the bootable project using the Add File(s) to Project context menu available in the File tab of the Workspace view. Then edit the VxWorks initialization file, usrAppInit.c, adding calls to your application's initialization and startup routines. The VxWorks application initialization component is required, and is included by default. See 4.4 Creating a Custom VxWorks Image and 4.5 Creating a Bootable Application.
Use this method if rebooting your target is inconvenient, and if your code is modular enough that it can be added to the running target without interrupting execution or if you have the means to start and stop your application. Create a downloadable project using the Downloadable Project Wizard. Add application files with the Add File(s) to Project context menu. Build your downloadable project. Boot the target using the appropriate image described in 4.2.2 Creating a Bootable Project Based on a BSP. Download the partially linked and munched .out file produced by your project.2 See 4.3 Creating a Downloadable Application.
This ensures that the custom rule will be invoked only to process the specified source file. For example, you may wish to add a custom rule to process a yacc file into a C source file. To create a custom rule, see 4.6 Working With Build Specifications.
|
|
|||||||||||||||||||
A build-specific custom rule can invoke any command and reference any build dependencies. The rule can be selected as the current build rule to build the desired output explicitly or, if the Invoke this rule before building Project box is checked, it will be built implicitly prior to building any of the built-in rules (such as vxWorks, or project.a) for the project.
|
|
NOTE:
Custom build rules cannot be copied between projects. If you will use either form of custom build rules, and know that you will be migrating files between projects, you may wish to put files with similar build settings into separate projects. These projects can then be built and linked together. For more information, see the hierarchical sub-project model discussed in Sub-Projects.
|
||||||||||||||||||
You may migrate application source files between any two projects that coexist in the same workspace. Use the Add File(s) from Project context menu from the File tab. If you have defined custom build rules for any of your source files, you will have to replicate them in the destination project by hand.
|
|||||||||||||||||||
If you have a number of files that must be built with special build rules or flags, it may be easier to create a new project to build these particular files, and then build that project as a sub-project of your main project. For more information, see Structuring Your Projects.
Tornado provides configuration management integration. To enable and configure it, see 12. Customization.
VxWorks must be configured to support the calls your application makes to it, or you will not be able to link your image. If your BSP provides a "bare-bones" VxWorks configuration, you may wish to use Project>Auto Scale to detect and add most of the VxWorks functionality you require. Auto Scale will compile your code, analyze the symbols in your object modules, map them to components, and offer to include those components. There may be some components that Auto Scale does not detect. If you Auto Scale, build, and still get link errors, you will need to add the additional components from the workspace VxWorks tab. For information on using Auto Scale, see 4.5.1 Using Automated Scaling of VxWorks.
Add all your application source code to one bootable project. This method is the simplest. All your source code is added to the bootable project, which already contains the BSP code and is linked to the VxWorks libraries.
The Tornado workspace is very convenient for configuring VxWorks, building small applications, or building, downloading, and debugging small parts of a large application. It is not designed to handle a complete build of a large, modular application, which often requires sub-projects (though this can be achieved using custom rules and macros). For this reason, you may want to use an external build system to build your application, then link it to VxWorks using the EXTRA_MODULES or LIBS macros. You can write a custom rule to invoke your external build process; see Sub-Projects. Alternatively, your build can kick off a VxWorks build and link your application code as the final step.
Sub-projects allow you to create as many projects as are needed to hierarchically organize and build your product. This approach accommodates existing hierarchically-organized source code. You will want to use this approach if:
Tornado has only limited support for managing and building these hierarchical sub-projects. You must use macros and custom rules to create the hierarchy and structure the builds manually. For directions on how to organize your application code into sub-projects, please refer to Example 1, below.
This example illustrates how a master project can be used to build several sub-projects. The master project builds the sub-projects as .pl (partially linked) modules. Then they are linked with the master project and munched (integrated with code to call C++ static constructors and destructors) in the final build step.
In this example, the master project is a bootable project, and there are two sub-projects that are downloadable projects. However, a downloadable project can also serve as a master project. You could use this approach if you wanted to build several downloadable sub-projects and link them into a single downloadable project. You could also use this approach to integrate an external application build into VxWorks. You need to modify the custom rules in the example to invoke your external build (for example, using make).
Go first to the Build tab. Expand the project Master. Double-click on the build specification default to display the build property sheet. In the build property sheet, select the Rules page. Click New/Edit and add the new rules.
You enter a new rule by filling in the Target, Dependencies, and Commands fields of the Create or Edit Rule dialog box. For example, to add the clean rule, you type clean in the Target field, CleanProject1 CleanProject2 vxWorks in the Dependencies field, and nothing in the Commands field. For each rule, you must also uncheck the Invoke this rule before building project checkbox.
The required rules are listed below in makefile syntax. The first example shows the syntax. Fill in the appropriate boxes for each rule.
SYNTAX:
target : dependencies
commands
RULES:
../../Project1/SIMNTgnu :
- mkdir $@
Master : ../../Project1/SIMNTgnu/Project1.pl ../../Project2/SIMNTgnu/Project2.pl VxWorks
../../Project1/SIMNTgnu/Project1.pl : ../../Project1/SIMNTgnu
wind_force_make
$(MAKE) -C ../../Project1/SIMNTgnu -f ../../Project1/Makefile
BUILD_SPEC=SIMNTgnu Project1.pl
../../Project2/SIMNTgnu :
- mkdir $@
../../Project2/SIMNTgnu/Project2.pl : ../../Project2/SIMNTgnu
wind_force_make
$(MAKE) -C ../../Project2/SIMNTgnu -f ../../Project2/Makefile
BUILD_SPEC=SIMNTgnu Project2.pl
CleanProject1 : ../../Project1/SIMNTgnu
$(MAKE) -C ../../Project1/SIMNTgnu -f ../../Project1/Makefile
BUILD_SPEC=SIMNTgnu clean
CleanProject2 : ../../Project2/SIMNTgnu
$(MAKE) -C ../../Project2/SIMNTgnu -f ../../Project2/Makefile
BUILD_SPEC=SIMNTgnu clean
clean : CleanProject1 CleanProject2
|
|
|||||||||||||||||||
If you wish your rules to be portable between architectures, substitute $(CPU)$(TOOL) for SMNTgnu.
In the Rules pane, set the default build rule for project Master to be the rule Master. Next, in the Build pane, in the MACROS tab for project Master, append to the EXTRA_MODULES macro "../../Project1/SIMNTgnu/Project1.pl" and "../../Project2/SIMNTgnu/Project2.pl" and click the Add/Set button.
|
|
|||||||||||||||||||
Add to the source file usrAppInit.c, in project Master, a function prototype for, and a call to, the function Test( ):
void Test(void);
void usrAppInit (void)
{
#ifdef USER_FF
USER_APPL_INIT; /* for backwards compatibility */
#endif
/* add application specific code here */
Test();
}
When you build Master, all three will be built, munched, and linked into one bootable image. (For information on munching, see the VxWorks Programmer's Guide: C++ Development.)
|
|
|||||||||||||||||||
Example 4-2: Avoiding Absolute Paths
One problem that arises from using a version control system is that different users may extract projects and source files to different locations (for example, in Visual SourceSafe, or CVS), or map views to different drive letters (Clearcase on Windows). It helps greatly if projects do not have any absolute paths written into them.
If source files or subprojects are in a directory which is at the same directory level as the parent project directory or deeper, they are recorded in the parent project file with a path relative to the parent project directory. Organizing your source files and projects in this way is recommended to avoid absolute paths in project files and makefiles.
If you cannot organize your source files and projects in this way, we provide two environment variables to allow you to define the root of your source directory tree or your project directory tree: WIND_SOURCE_BASE and WIND_PROJ_BASE.
Below we give some examples showing how to avoid absolute paths to source files or to sub-projects.
Suppose your project is in directory t:\source_root\myproj and your source files are organized as follows:
t:\source_root\myproj\foo1.c t:\source_root\src\foo2.c t:\source_root\myproj\src\foo3.c
Your project will contain no absolute paths. Instead, the above files will be recorded in the project file as:
$(PRJ_DIR)/foo1.c $(PRJ_DIR)/../src/foo2.c $(PRJ_DIR)/src/foo3.c
Organizing your source files and projects in any of these ways is the recommended procedure for avoiding absolute paths in project files and makefiles.
If you cannot organize your source files and projects in one of these ways, the WIND_SOURCE_BASE environment variable allows you to define the root of your source directory tree. To illustrate the use of WIND_SOURCE_BASE, assume you wish to add the file:
t:\other_source_root\goo.c
If WIND_SOURCE_BASE is not defined, it appears in the project file with an absolute path (we do not support $(PRJ_DIR)/../../). However, before you add the file, you can use Tools->Options->Workspace to define:
WIND_SOURCE_BASE = t:\other_source_root
Then t:\other_source_roo\goo.c is recorded in the project file as:
$(WIND_SOURCE_BASE)/goo.c
The major drawback to the WIND_SOURCE_BASE variable is that all users of myproj must have WIND_SOURCE_BASE defined or the workspace cannot find goo.c.
This example refers to a master project called master and various sub projects called sub1, sub2,... The master project could be a bootable project and the sub-projects could refer to external build systems or downloadable projects.
Assume the master project is in directory t:\prj_root\master and your sub-projects are organized as follows:
t:\prj_root\sub1 t:\prj_root\master\sub2 t:\prj_root\subprojects\sub3 t:\prj_root\master\subprojects\sub4
In this case, your master project will contain no absolute paths. Instead, the above directories will be recorded in the master project file as:
$(PRJ_DIR)/../sub1 $(PRJ_DIR)/sub2 $(PRJ_DIR)/../subprojects/sub3 $(PRJ_DIR)/subprojects/sub4
Organizing your projects in any of the above ways is the recommended procedure for avoiding absolute paths in project files and makefiles.
If you cannot organize your projects in any of these ways, we provide the WIND_PROJ_BASE environment variable to allow you to define the root of your project directory tree. To illustrate the use of WIND_PROJ_BASE, assume you wish to add the project:
t:\other_prj_root\sub5
If WIND_PROJ_BASE is not defined, then it appears in the master project file with an absolute path (we do not support $(PRJ_DIR)/../../). However, before you add the project you could use Tools->Options->Workspace to define:
WIND_PROJ_BASE=t:\other_prj_root
Now when you add t:\other_prj_root\sub5, this sub-project will be recorded in the master project file as:
$(WIND_PROJ_BASE)/sub5
The major drawback to the WIND_PROJ_BASE variable is that all users of the master project have to define WIND_PROJ_BASE, or the workspace is unable to find sub5.
A downloadable application is a collection of relocateable object modules that can be downloaded and dynamically linked to VxWorks, and started from the shell or debugger. A downloadable application can consist of a single "hello world" routine or a complex application.
All work that you do with the project facility, whether a downloadable application, a customized version of VxWorks, or a bootable application, takes place in the context of a project.
If the Create Project window is open (the default when you first start Tornado3 ), click the New tab. Otherwise, click File>New Project. Then choose the selection for a downloadable application, and click OK (Figure 4-3)
The application wizard appears. This wizard is a tool that guides you through the steps of creating a new project.
First, enter the full directory path and name of the directory you want to use for the project (only one project is allowed in a directory), and enter the project name. It is usually most convenient to use the same name for the directory and project, but it is not required.
|
|
|||||||||||||||||||
You may also enter a description of the project, which will later appear in the property sheet for the project (Figure 4-4). Finally, identify the workspace in which the project should be created. Click Next to continue.
Identify the toolchain with which the downloadable application will be built. You can do so by referencing an existing project, or by identifying a toolchain. Basing a project on an existing one means that the new project will reference the same source files and build specifications as the one on which it was based. Once the new project has been created, its build specifications can be modified without affecting the original project, but changes to any shared source files will be reflected in both.
For example, to create a project that will run on the target simulator, select A toolchain and select the default option for the target simulator from the drop-down list (Figure 4-5).4 Click Next.
The wizard confirms your selections (Figure 4-6). Click Finish.
The Workspace window appears, containing a folder for the project. Note that the window title includes the name of the workspace (Figure 4-7).
|
|
|||||||||||||||||||
The project facility generates a set of files whose contents are based on your selection of project type, toolchain, build options, and build configurations. During typical use of the project facility you need not be concerned with these files, except to avoid accidental deletion, to check them in or out of a source management system, or to share your projects or workspaces with others. The files are created in the directories you identify for the workspace and project. The files initially created are:
Both of these files contain information that changes as you modify your project, and add projects to, or delete projects from, the workspace.
When you build your application, a makefile is dynamically generated in the main project directory, and a subdirectory is created containing the objects produced by the build. The subdirectory is named after the selected build specification. If other build specifications are created and used for other builds, parallel directories are created for their objects.
The Files view of the Workspace window displays information about the projects, and the directories and files that make up a project (Figure 4-8).
Initially, there are only the default folders for Built Objects and External Dependencies, and the projectName.out file. The file projectName.out is created as a single, partially-linked module when the project is built. It comprises all of the individual object modules in a project for a downloadable application, and provides for downloading them all to the target simultaneously.
To create a new file, click File>New, or press CTRL+N. Select the file type from the New dialog box. Then select the project to which the file should be added. Finally, enter the file name and directory, and click OK (Figure 4-9). The editor window opens, and you can write your code and save the file. (See 3. Editor).
Add existing files to a project by right-clicking in the Workspace window, selecting Add Files or Add Files from project from the pop-up menu, and then using the associated dialog box to locate and select the file(s).
To link object files with your project, use the PRJ_LIBS macro or the Linker page of the build specification property sheet (see Linker Options). To link library (archive) files with your project, add the libraries to the list defined by the LIBS macro in the Macros page of the build specification property sheet (see Makefile Macros).
Remove files from the project by right-clicking on the file name and selecting Remove from the pop-up menu, or by selecting the file name and pressing DELETE.
To display information about the properties of a file, right-click on the file name in the Workspace window, and select Properties from the pop-up menu. The extent of information displayed depends on the type of file and whether or not make dependencies have been generated. In the case of source code, a Properties sheet for the file appears, displaying information about make dependencies; general file attributes such as modification date; and the associated make target, custom dependencies, and commands used for the build process (Figure 4-10).
See Calculating Makefile Dependencies, for information about how and when to calculate makefile dependencies. See Compiler Options for information about overriding default compiler options for individual files.
The File and pop-up menus provide options for opening, saving, and closing files. You can also use standard Windows key and mouse shortcuts (such as double-clicking on a file name to open the file in the editor, using CTRL+S to save a file, and so on).
See 12. Customization for information about customizing the editor, including how it handles DOS and UNIX end-of-line markers.
The project facility uses the GNU make utility to automate compiling and linking an application.5 It automatically creates a makefile prior to building the project. But before it can create a makefile, the makefile dependencies must be calculated. The calculation process, which is based on the project files' preprocessor #include statements, is also an automated feature of the project facility.
Binaries produced by a given build are created in a project subdirectory with the same name as the name of the build specification (projectName\buildName).
|
|
NOTE:
All source files in a project are built using a single build specification (which includes a specific set of makefile, compiler, and linker options) at a time. If some of your source requires a different build specification from the rest, you can create a new project for it in the same workspace, and customize the build specification for those files. One project's build specification can then be modified to link in the output from the other project. See Sub-Projects.
|
||||||||||||||||||
|
|
NOTE:
The project facility allows you to create specifications for different types of builds, to modify the options for any one build, and to select the build specification you want to use at any given time easily. See 4.6 Working With Build Specifications.
|
||||||||||||||||||
|
|
|||||||||||||||||||
To calculate makefile dependencies, select Dependencies from the workspace pop-up menu. The Dependencies dialog box appears (Figure 4-11). Click OK.
After dependencies have been calculated, the files are listed in the External Dependencies folder (Figure 4-12).
If you do not calculate dependencies before you start a build, Tornado prompts you to do so for any of the project files for which dependencies have not previously been calculated. Dependencies are not calculated for each build specification. If your dependencies change for different build specifications (for example, if they are CPU-dependent), then you may want to:
Tornado assumes that your header files are in either your project directory or installDir\target\h. If you have placed files in other locations, you need to make two changes to your project build specification. Right-click on the name of your build specification (for example, SIMNTgnu). Select Properties from the pop-up menu. On the C/C++ compiler tab, click the Include paths button. Add a separate entry for each directory path.
The Advanced option allows you to speed up the build process by specifying paths in which none of the dependencies could have changed since the last build. The timestamps for the files in the specified paths are not checked (Figure 4-13).
Each build specification for a downloadable application consists of a set of options for makefile rules and macros, as well as for the compiler, assembler, and linker. A default build specification is defined when you create your project. To display its property sheet, double-click on the build specification name in the Builds view of the workspace to display the property sheet for the build specification.
The Rules page (Figure 4-14) allows you to select from the following build target options:
You can use the project facility to change the options for a given build specification, create and save new build specifications, and select the specification to use for a build. You can, for example, create one build specification for your project that includes debug information, and another that does not. For more information, see 4.6 Working With Build Specifications.
|
|
|||||||||||||||||||
The Macros tab contains pre-set build macros. Do not delete the pre-existing macros; while you can reenter them, the value will be lost. You can add and delete your own macros by typing in the Name window and then clicking the Add button.
|
|
|||||||||||||||||||
To build a project with the default options, select the name of the project (or any subordinate object in its folder) and then select Build 'projectName.out' from the pop-up menu. If you have created build specifications in addition to the default, you can select the build specification you want to use from the Build drop-down list at the top of the workspace window before you start the build.
The Build Output window displays build messages, including errors and warnings (Figure 4-15).
Any compiler errors or warnings include the name of the file, the line number, and the text of the error or warning text. Double-clicking on the line containing the error message opens the file in the editor with a context pointer on the offending line. The error or warning text is also displayed in the status bar at the bottom of the main Tornado window.
Use the Edit>Next Error/Tag and Edit>Previous Error/Tag menu options to navigate between errors when you are using the Tornado editor.
|
|
WARNING:
The default compiler options include debugging information. Using debugging information with the optimization set to anything but zero may produce unexpected results. See 4.6 Working With Build Specifications for information about modifying builds and creating new build specifications.
|
||||||||||||||||||
The Build toolbar provides quick access to build commands. Display of the toolbar is controlled with the View>Toolbar>Build Toolbar menu option. The toolbar is shown free-floating in Figure 4-16, but is docked by default.
The Build toolbar commands (Table 4-2) are also available from the main menus and the Workspace pop-up menu.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Before you can download and run an application, you must boot VxWorks on the target system, have access to a Tornado registry, and configure and start a target server. For more information, see 2. Setup and Startup and 8. Target Server.
You can download an entire project from the project workspace by selecting Download 'projectName.out' from the pop-up menu for the Files view, or by using the download button on the Build toolbar. You can download individual object modules by selecting the file name and then selecting the Download 'filename.o' option from the pop-up menu. However, you may inadvertently introduce errors by downloading individual object modules out of sequence. We strongly recommend that you always download the partially-linked projectName.out file.
C++ projects must be downloaded as projectName.out because this file is produced from application files and munched for proper static constructor initialization.
To run a downloaded application, use WindSh or CrossWind. For more information see 7. Shell or 10. Debugger.
To unload a project from the target, use the Unload 'projectName.out' option on the pop-up menu.
New projects can be added to a workspace by selecting File>New Project and creating a new project when the workspace is open.
Existing projects can be added to a workspace by selecting the menu options File>Add Project to Workspace, and using the file browser to select a project file (projectName.wpj).
Projects can be removed from a workspace by selecting the project name in the Files view, and then selecting the Remove option from the pop-up menu, or by selecting the project name and pressing DELETE.
|
|
|||||||||||||||||||
The Tornado distribution includes a VxWorks system image for each target shipped. The system image is a binary module that can be booted and run on a target system. The system image consists of all desired system object modules linked together into a single non-relocateable object module with no unresolved external references. In most cases, you will find the supplied system image adequate for initial development. However, later in the cycle you may want to create a custom VxWorks image.
VxWorks is a flexible, scalable operating system with numerous facilities that can be tuned, and included or excluded, depending on the requirements of your application and the stage of the development cycle. For example, various networking and file system components may be required for one application and not another, and the project facility provides a simple means for either including them in, or excluding them from, a VxWorks application. In addition, it may be useful to build VxWorks with various target tools during development (such as the target-resident shell), and then exclude them from the production application.
Once you create a customized VxWorks, you can boot your target with it and then download and run applications. You can also create a bootable application simply by linking your application to VxWorks and adding application startup calls to the VxWorks system initialization routines (see 4.5 Creating a Bootable Application).
All work that you do with the project facility, whether a downloadable application, a customized version of VxWorks, or a bootable application, takes place in the context of a project.
If the Create Project window is open (the default when you first start Tornado6 ), click the New tab. Otherwise, click File>New Project. Then choose the selection for a bootable application, and click OK (Figure 4-17)
The application wizard appears (Figure 4-18). This wizard is a tool that guides you through the steps of creating a new project.
First, enter the full directory path and name of the directory you want to use for the project (only one project is allowed in a directory), and enter the project name. It is usually most convenient to use the same name for the directory and project, but it is not required.
|
|
|||||||||||||||||||
Then you identify the BSP with which you will build the project. You can do so by referring to an existing project, or by identifying a BSP that you have installed.
Basing a project on an existing one means that the new project will reference the same source files as the one on which it was based, but it will start with copies of the original project's VxWorks configuration and build specifications. The build specifications and VxWorks configuration for the new project can be modified without affecting the original project, but changes to any shared source files will be reflected in both.
For example, to create a project for a module that will run on a mbx860 target, select An existing project and then select mbx860_gnu.wpj (or mbx860_diab.wpj if you have purchased the Diab tools) from the drop-down list (Figure 4-19). Click Next.
If, on the other hand, you must base your project on a BSP, select A BSP and choose one of the BSPs you installed or the appropriate simulator. If your BSP offers both GNU and Diab toolchains, select a toolchain as well. Click Next.
The wizard confirms your selections (Figure 4-20). Click Finish.
The project facility generates, or includes copies of, a variety of files for a VxWorks project. The names of the files that you may need to work with are displayed in the workspace File view (Figure 4-21).
|
|
|||||||||||||||||||
During typical use of the project facility you do not need to be concerned with these files, except to avoid accidental deletion, to check them in or out of a source management system, or to share your projects or workspaces with others. You will need to edit usrAppInit.c, however, when you create a bootable application (see 4.5 Creating a Bootable Application).
|
|
|||||||||||||||||||
The following files are created in the main project directory as well, but are not visible in the workspace:
When you build the project from the GUI, a makefile is dynamically generated in the main project directory, and a subdirectory is created containing the objects produced by the build. The subdirectory is named after the selected build specification. If other build specifications are created and used for other builds, parallel directories are created for their objects.
You can also build your project from the command line. When you do so, you must create the makefile first. See Using the Command Line.
The Files view can also display the default list of objects that would be built, and the external dependencies that make up the new project, in the Built Objects and External Dependencies folders, respectively.
The VxWorks view of the workspace displays all VxWorks components available for the target. The names of components that are selected for inclusion appear in bold type. The names of components that are excluded appear in plain type. The names of components that have not been installed appear in italics. Note that the names of folders appear in bold type if any (but not necessarily all) of their components are included. (Figure 4-22.)
|
|
|||||||||||||||||||
You can locate individual components and configuration parameters in the component tree, based on their macro names, with the Find Object dialog box. Open the dialog box with the pop-up menu for the VxWorks view (Figure 4-23).
|
|
|||||||||||||||||||
The component tree in the VxWorks view provides descriptive names for components. You can display a component description property sheet, which includes the name of the preprocessor macro for the component, by double-clicking on the component name (Figure 4-24).
To display online reference documentation, double-click on the topic of your choice displayed in the Help Link box of the property sheet. The corresponding HTML reference material is displayed in a Web browser (Figure 4-24).
VxWorks components that are not needed for a project can be excluded, and components that have been excluded can be included again. The pop-up menu provides Include and Exclude options for components you select in the VxWorks view. You can also use the DELETE key to exclude options.
Tornado automatically determines component dependencies each time a component is included or excluded. That is, it determines if a component you want to include is dependent upon other components that have not been included in the project, or if a component that you are deleting is required by other components. When a component is included, any components it requires are automatically included. When a component is excluded, any dependent components are also excluded. In either case, a dialog box provides information about dependencies and the option of cancelling the requested action. For example, if you exclude POSIX clocks, the dialog box informs you that the ANSI time component would be excluded (Figure 4-25).
|
|
WARNING:
The results of calculating dependencies is not necessarily identical for inclusion and removal. Including a component you previously excluded does not automatically include the components that were dependent on that component, and that were therefore excluded with it. For example, excluding the POSIX clocks component automatically excludes the ANSI time component, which is dependent on it. But if the POSIX clocks component is subsequently included, there are no components required by it, so the ANSI time component is not automatically included (Figure 4-26).
|
||||||||||||||||||
You can also include folders of components. However, not all components in a folder are necessarily included by default (nor would it always be desirable to do so, as there might be conflicts between components). Tornado offers a choice about what components to include. For example, if you include target shell components, not all of the components are included by default, and you are prompted to accept or modify the default selection (Figure 4-27).
Tornado automatically calculates an estimate of the change in the size of the image resulting from the inclusion or exclusion, as well as the new image size. The Include and Exclude dialog boxes display this information. (Also see Estimating Total Component Size).
Some folders contain component options that are explicitly combinative or mutually exclusive (in the sense of being potentially in conflict). These folders are called selections, and their names are preceded by a checkbox icon in the folder tree. You can make or change your selection either by opening the folder and performing an include or exclude operation on individual components, or by displaying the property sheet for the folder and making selections with the check boxes on the Components page (Figure 4-27).
If you include components that potentially conflict, or are missing a required component, Tornado warns you of the conflict by displaying a message box with a warning, and by highlighting the full folder path to the source of the conflict. The property sheet for the folder also displays error information in its Errors page. For example, if you attempt to include both symbol table initialization components, a warning is first displayed. Once you acknowledge the warning, the folder names development tool components, symbol table components, select symbol table initialization are highlighted. You can display the property sheet for the folder for a description of the problem and how to correct it. (See Figure 4-29 for all GUI elements.)
|
|
|||||||||||||||||||
In the VxWorks view, the pop-up menu provides access to component parameters (preprocessor macros). For example, selecting the operating system components folder, then Params for 'operating system components' from the pop-up menu (or double-clicking on the folder name), displays a dialog box that allows you to change the values of the parameters defined for the operating system components (Figure 4-30). Parameters specific to individual components can be accessed similarly.
To calculate and display the estimated size of the components included in an image, select the project name (in any of the workspace views), then select Properties from the pop-up menu, and select the Size tab in the property sheet that appears (Figure 4-31). Note that this estimate is for the components only, and does not include the BSP or any application code.
The default VxWorks is a RAM-based image. If you want to create something other than the default images, use one of the other build specifications created when you created your project:
These build specifications are identical to the default, except that instead of building the vxWorks rule, default_rom, for example, is set up to build the vxWorks_rom rule. (Figure 4-32).
|
|
NOTE:
Project files used only for a ROM-based image can be flagged as such, so that they are only used when a ROM-based image is built. See Compiler Options.
|
||||||||||||||||||
VxWorks projects are built in the same manner as downloadable applications. To build a project with the default options, select the name of the project (or any subordinate object in its folder) and then select the Build option from the pop-up menu. The name of the build specification that will be used is displayed in the Build drop-down list at the top of the workspace window.
For more information about a generic build, see 4.3.4 Building a Downloadable Application. For information about modifying builds and creating new build configurations, see 4.6 Working With Build Specifications.
The build menu allows you to choose boot ROMs or BSPs to build. Figure 4-33 illustrates the Build dialog box in a Tornado system that has a PowerPC BSP and the Diab compiler installed.
When you click OK in the build dialog box, Tornado builds the corresponding object in the BSP directory. Output from the build goes to a Build Output window, which you can use as a diagnostic aid.
To rebuild VxWorks, select the vxWorks target name in the Select an Image list. For example, Figure 4-33 shows the vxWorks target selected for the mbx860 BSP.
|
|
NOTE:
All source files in a project are built using a single build specification (which includes a specific set of makefile, compiler, and linker options) at a time. If some of your source requires a different build specification from the rest, you can create a project for it in the same workspace, and customize the build specification for those files. One project's build specification can then be modified to link in the output from the other project. See Linker Options.
|
||||||||||||||||||
|
|
WARNING:
The default compiler options include debugging information. Using debugging with the optimization set to anything but zero may produce unexpected results. See 4.6 Working With Build Specifications for information about modifying builds and creating new build configurations.
|
||||||||||||||||||
Using the command line allows you to automate builds. Projects must be created and configured in the GUI, and dependencies must be generated there as well. However, makefile generation and building are possible from the command line. To generate the makefile, use the makegen utility and to build, use make.
Change to the build directory and type make with flags, for example:
% cd installDir/target/proj/Project1/mbx860_gnu % makegen % mkdir default_rom % cd default_rom % make -f ../Makefile BUILDSPEC=default_rom
Your build output will be in the default_rom directory and the build will use the default_rom build specification.
For information about booting VxWorks (and bootable applications), see 2.5 Booting VxWorks. VxWorks images for the target simulator can be downloaded and booted with the pop-up menu Start command.
A bootable application is completely initialized and functional after a target has been booted, without requiring interaction with Tornado development tools. For information about developing your application, 4.2.3 Developing and Adding Your Application Source Code.
The auto scale feature of the project facility determines if your code, or your custom version of VxWorks, requires any components that are not included in your VxWorks project, and adds them as required. It also provides information about components that may not be required for your application. To automatically scale VxWorks, select Auto Scale from the pop-up menu in the VxWorks view of the workspace window to display the Auto Scale dialog box, and click OK.
|
|
|||||||||||||||||||
When VxWorks boots, it initializes all operating system components (as needed), and then passes control to the user's application for initialization. To add application initialization calls to VxWorks, double-click on userAppInit.c to open the file for editing, and add the calls to usrAppInit( ). Figure 4-34, for example, illustrates the addition of a call to runItAll( ), the main routine in the application file helloWorld.c.
The project facility allows you to create, modify, and select specifications for any number of builds. Default build specifications are defined when you create your project.
|
|
|||||||||||||||||||
You can change default or other previously defined build options by double-clicking on the build name in the Builds view of the workspace window. The build's property sheet appears (Figure 4-35).
For information about build targets for downloadable applications, see Build Specifications. For information about build targets for bootable applications, see 4.4.4 Selecting the VxWorks Image Type. Other features of the build property sheet are covered in the following sections.
The buttons at the bottom of the build property sheet allow you to create, edit, or delete makefile rules (default project entries cannot be deleted; only those created by a user can be deleted). When you click the New/Edit button, the Create or Edit Rule dialog box appears (Figure 4-36). Once you have created or edited an entry, click OK. Note that the default is to invoke the rule before building the project (see checkbox). If the default is not selected, the rule is only invoked if it is the rule currently selected for the build (with the drop-down list in the Rules page of the build property sheet) or if it is a dependency of the currently selected rule. New rules are added to the projectName.wpj file and written to the makefile prior to a build.
Select the Macros tab of the build specification property sheet to view the makefile macros associated with the current project, build specification, and rules (Figure 4-37).
You can use the Macros page to modify the values of existing makefile macros, as well as to create new rules to be executed at the end of the build. Use the Delete button to delete a macro from the build. To change an existing macro, modify the value and click the Add/Set button. To add a macro, change the name and value of an existing macro, and click the Add/Set button.
The recommended way to link library (archive) files to your bootable project is to add the libraries to the list defined by the LIBS macro and the modules to the list defined by the EXTRA_MODULES macro. Use the PRJ_LIBS macro for downloadable projects.
The C/C++ compiler page of the build specification property sheet displays compiler options. You can edit the options displayed in the text box (Figure 4-38). You can also click the Include Paths button and use the dialog box to enter and order your include paths.
|
|
|||||||||||||||||||
If you use the -I option to add include file paths for the build, you must use forward slashes ( / ) rather than standard Windows backward slashes ( \ ). Failure to do so causes dependencies from directories other than the current directory to try to make a target of the header file, preventing you from building real targets.
You can override the default compiler flags for individual files by right-clicking on the file name in the Files view, selecting Properties from the pop-up menu, and specifying a new set of options in the Build page of the property sheet. Unchecking the Use default build rule for this file box allows you to edit the fields in this page (Figure 4-40).
If the file should be used only when building a ROM-based image, check the Build for ROM images only box. See 4.4.4 Selecting the VxWorks Image Type.
Select the assembler tab of the build specification property sheet to view assembler options. You can edit the options displayed in the text box (Figure 4-41).
Select the Link Order tab of the build specification property sheet to view module link order (Figure 4-42). You can change the link order using the Down and Up buttons to ensure that static C++ constructors and destructors are invoked in the correct order.
Select the linker tab of the build specification property sheet to view linker options. You can edit the options displayed in the text box (Figure 4-43).
To link an object or library (archive) file with a project, you can list the full path to the file here. However, the recommended way to link library (archive) files is to add the libraries to the list defined by the LIBS, EXTRA_MODULES, or PRJ_LIBS macros on the Macros tab (see Makefile Macros).
|
|
WARNING:
You cannot link another project object file (projectName.out) with the project you are building. You must compile the other project as a library (see Build Specifications) or as a partial link (projectName.pl), and then link it with the current project.
|
||||||||||||||||||
You can create new build specifications for a project with the Add New Build Specification window, which is displayed with the New Build option on the pop-up menu. For example, one build specification can be created that includes debug information, and another that does not; specifications can be created for different image types, optimization levels, and so on. You can create a new build specification by copying from an existing specification, or by creating it as a default specification for a given toolchain(Figure 4-44).
Once you have created a new build specification, use the build specification property sheet to define it (see 4.6.1 Changing a Build Specification).
|
|
|||||||||||||||||||
When you want to build your project, select the build specification from the Build Spec drop-down list (Figure 4-45).
|
|
WARNING:
During development you must configure VxWorks with the target agent communication interface required for the connection between your host and target system (network, serial, NetROM, and so on). By default, VxWorks is configured for a network connection. Also note that before you use Tornado tools such as the shell and debugger, you must start a target server that is configured for the same mode of communication. See 2.4 Host-Target Communication Configuration; and 8.2 Configuring and Starting a Target Server.
|
||||||||||||||||||
To display the options for the communication interface for the target agent in the VxWorks view, select development tool components>WDB agent components>select WDB connection (Figure 4-46).
To select an interface, select it from the list and select the Include 'component name' option from the pop-up menu. (You can also make a selection by double-clicking on the select WDB connection option to display the property sheet, and then making the selection from the Components page.)
To display general information about a component, or to change its parameters, simply double-click on its name, which displays its property sheet (see Figure 4-47). The options for the target agent communication interface are described below.
|
|
|||||||||||||||||||
When VxWorks is configured with the standard network stack, the target agent can use an END (Enhanced Network driver) connection. Add the WDB END driver connection component. This connection has the same characteristics as the network connection, but also has a polled network interface that allows system and task mode debugging.
To configure the target agent to use a NetROM communication path, add the WDB netROM connection component. (See 2.4.4 The NetROM ROM-Emulator Connection).
Several configuration macros are used to describe a board's memory interface to its ROM banks. You may need to override some of the default values for your board. To do this, display the component property sheet, and select the Params tab to display and modify macro values.
The size of the NetROM dual-port RAM is 2 KB. The NetROM permits this 2 KB buffer to be assigned anywhere in the pod 0 memory space. The default position for the NetROM dual-port RAM is at the end of the pod 0 memory space. The following line in installDir\target\src\config\usrWdb.c specifies the offset of dual-port RAM from the start of the ROM address space.
dpOffset = (WDB_ROM_SIZE - DUALPORT_SIZE) * WDB_NETROM_WIDTH;
If your board has more than one ROM socket, this calculation gives the wrong result, because the VxWorks macro ROM_SIZE describes the total size of the ROM space--not the size of a single ROM socket. In that situation, you must adjust this calculation.
Refer to the NetROM documentation for more information on the features governed by these parameters.
To configure the target agent for use with a network connection, add the WDB network connection component. (See 2.4.1 Network Connections).
The default MTU is 1500 octets. To change it, display the component property sheet, select the Params tab, select the WDB_MTU item and change the value associated with it (Figure 4-48).
To configure the target agent to use a raw serial communication path, add the WDB serial connection component. (See 2.4.3 Serial-Line Connections).
By default, the agent uses serial channel 1 at 9600 bps.7 For better performance, use the highest line speed available, which is often 38400 bps. Try a slower speed if you suspect data loss. To change the speed, display the component property sheet, select the Params tab, select WDB_TTY_BAUD and change the value associated with it.
If your target has a single serial channel, you can use the target server virtual console to share the channel between the console and the target agent. You must configure your project with the CONSOLE_TTY parameter set to NONE and the WDB_TTY_CHANNEL parameter set to 0. See Console and Redirection for more information regarding the target server virtual console.
When multiplexing the virtual console with WDB communications, excessive output to the console may lead to target server connection failures. The following actions may help resolve this problem:
In a memory-constrained system, you may wish to create a smaller agent. To reduce program text size, you can remove the following optional agent facilities:
These components are in the development tool components>WDB agent components>WDB agent services folder path.
You can also reduce the maximum number of WDB breakpoints with the WDB_BP_MAX parameter of the WDB breakpoints component. If you are using a serial connection, you can also set the INCLUDE_WDB_TTY_TEST parameter to FALSE.
If you are using a communication path which supports both system and task mode agents, then by default both agents are started. Since each agent consumes target memory (for example, each agent has a separate execution stack), you may wish to exclude one of the agents from the target system. You can configure the target to use only a task-mode or only a system-mode agent with the WDP task debugging or WDB system debugging options (which are in the folder path development tool components>WDB agent components>select WDB mode).
If your application (or BSP) uses excHookAdd( ) to handle exceptions, host tools will still be notified of all exceptions (including the ones handled by your exception hook). If you want to suppress host tool notifications, you must exclude the component WDB exception notification. When this component is excluded, the target server is not notified about target exceptions, but the target will still report them in its console. In addition, if an exception occurs in the WDB task, the task will be suspended and the connection between the target server and the target agent will be broken.
By default, the target agent is initialized near the end of the VxWorks initialization sequence. This is because the default configuration calls for the agent to run in task mode and to use the network for communication; thus, wdbConfig( ) must be called after kernelInit( ) and usrNetInit( ). (See G. VxWorks Initialization Timeline for an outline of the overall VxWorks initialization sequence.)
In some cases (for example, if you are doing a BSP port for the first time), you may want to start the agent before the kernel starts, and initialize the kernel under the control of the Tornado host tools. To make that change, perform the following steps when you configure VxWorks:
InitGroup usrWdbInit {
INIT_RTN usrWdbInit (); wdbSystemSuspend ();
_INIT_ORDER usrInit
INIT_BEFORE INCLUDE_KERNEL
}
This causes the project code generator to make the usrWdbInit( ) call earlier in the initialization sequence. It will be called from usrInit( ), just before the component kernel is started.8
After the target server connects to the system-mode target agent, you can resume the system to start the kernel under the agent's control. (See 7.2.7 Using the Shell for System Mode Debugging for information on using system mode from the shell, and 10.6 System-Mode Debugging for information on using it from the debugger.)
After connecting to the target agent, set a breakpoint in usrRoot( ), then continue the system. The routine kernelInit( ) starts the multi-tasking kernel with usrRoot( ) as the entry point for the first task. Before kernelInit( ) is called, interrupts are still locked. By the time usrRoot( ) is called, interrupts are unlocked.
Errors before reaching the breakpoint in usrRoot( ) are most often caused by a stray interrupt: check that you have initialized the hardware properly in the BSP sysHwInit( ) routine. Once sysHwInit( ) is working properly, you no longer need to start the agent before the kernel.
|
|
WARNING:
Configuration of boot programs is handled independently of the project facility so normally you can configure your boot ROM differently than your other images. However, any changes you make to config.h that are not masked by project facility selections may be absorbed by your projects (see the warning in 4.1 Introduction). To prevent this, copy your BSP and create your boot image from the copy.
|
||||||||||||||||||
To customize a boot program for your development environment, you must edit installDir\target\config\bspname\config.h (the configuration file for your BSP). The file contains the definition of DEFAULT_BOOT_LINE, which includes parameters identifying the boot device, IP addresses of host and target, the path and name of the VxWorks image to be loaded, and so on. For information about the boot line parameters defined by DEFAULT_BOOT_LINE, see 2.5.4 Description of Boot Parameters and Help>Manuals Contents>VxWorks Reference Manual> Libraries>bootLib.
To build the new boot program, select Build>Build Boot ROM from the Tornado GUI. Then select the BSP for which you want to build the boot program and the type of boot image in the Build Boot ROM dialog box (Figure 4-1). Then click OK.
|
|
WARNING:
The TSFS boot facility is not compatible with WDB agent network configurations. See 4.7 Configuring the Target-Host Communication Interface.
|
||||||||||||||||||
To configure a boot program for TSFS, edit the boot line parameters defined by DEFAULT_BOOT_LINE in config.h (or change the boot parameters at the boot prompt). The boot device parameter must be tsfs, and the file path and name must be relative to the root of the host file system defined for the target server (see Configuring Boot Parameters and Target Server File System).
Regardless of how you specify the boot line parameters, you must reconfigure (as described below) and rebuild the boot image.
If two serial lines connect the host and target (one for the target console and one for WDB communications), config.h must include the lines:
#undef CONSOLE_TTY #define CONSOLE_TTY 0 #undef WDB_TTY_CHANNEL #define WDB_TTY_CHANNEL 1 #undef WDB_COMM_TYPE #define WDB_COMM_TYPE WDB_COMM_SERIAL #define INCLUDE_TSFS_BOOT
If one serial line connects the host and target, config.h must include the lines:
#undef CONSOLE_TTY #define CONSOLE_TTY NONE #undef WDB_TTY_CHANNEL #define WDB_TTY_CHANNEL 0 #undef WDB_COMM_TYPE #define WDB_COMM_TYPE WDB_COMM_SERIAL #define INCLUDE_TSFS_BOOT
For a NetROM connection, config.h must include the lines:
#undef WDB_COMM_TYPE #define WDB_COMM_TYPE WDB_COMM_NETROM #define INCLUDE_TSFS_BOOT
With any of these TSFS configurations, you can also use the target server console to set the boot parameters by defining the INCLUDE_TSFS_BOOT_VIO_CONSOLE macro in config.h. This disables the auto-boot mechanism, which might otherwise boot the target before the target server could start its virtual I/O mechanism. (The auto-boot mechanism is similarly disabled when CONSOLE_TTY is set to NONE, or when CONSOLE_TTY is set to WDB_TTY_CHANNEL.) Using the target server console is particularly useful for a single serial connection, as it provides an otherwise unavailable means of changing boot parameters from the command line.
When you build the boot image, select bootrom.hex for the image type (Building a Boot Image).
See the VxWorks Programmer's Guide: Local File Systems for more information about the TSFS.
If your boot strategy utilizes a boot ROM, and this boot ROM requires a new driver, you will need to rebuild the boot ROM. Boot ROMs are not yet fully supported as projects in Tornado 2.2. To build a boot ROM, Select Build>Build Boot Rom from the Tornado main menu bar. From the dialog, select the BSP and boot ROM target you wish to build.
If the boot ROM you wish to build is not shown, do the following:
1: The text and data sections of a relocateable object module are in transitory form. Because of the nature of a cross-development environment, some addresses cannot be known at time of compilation. These sections are modified (relocated or linked) by the Tornado object-module loader when it inserts the modules into the target system.
2: For information about munching, see the VxWorks Programmer's Guide: C++ Development.
3: You can modify the default behavior by un-checking the Show this window on startup box at the bottom of the window.
4: The default toolchain names for target simulators take the form SIMHOST_OSgnu (for example, SIMNTgnu).
5: See the GNU Make User's Guide for more information about make.
6: You can modify the default behavior by un-checking the Show this window on startup box at the bottom of the window.
7: VxWorks serial channels are numbered starting at zero. Thus Channel 1 corresponds to the second serial port if the board's ports are labeled starting at 1. If your board has only one serial port, you must change WDB_TTY_CHANNEL to 0 (zero).
8: The code generator for prjConfig.c is based on a component descriptor language that specifies when components are initialized. The component descriptors are searched in a specific order, with the project directory last in the search path. This allows the .cdf files in the project directory to override default definitions in the generic .cdf files.
