TOC PREV NEXT



6.6 pRISM+ Make Support

The pRISM+ Application Development Framework offers comprehensive make support which is pSOSystem-centric yet flexible enough to be extended to your environment. You can use the supplied pSOSystem makefiles or use SNiFF+ makefile generation feature to automatically generate makefiles for your code base.

pRISM+ make support is also scalable, designed to address the need of single developers as well as team developers. This section describes the make support provided by the pRISM+ Application Development Framework.

6.6.1 pRISM+ Make Options at a Glance

pRISM+ offers many make options ranging from simple to very advanced. These make options are summarized below. Extensive details will be offered in subsequent sections.

6.6.2 pSOSystem Application Make Structure

This section describes pSOSystem makefiles structure. pSOSystem is supplied with makefiles for building sample applications, BSP libraries, OS libraries and other libraries that come in source form with pSOSystem. These makefiles can be used with or without SNiFF+. When used with SNiFF+, pSOSystem makefiles provide overriding of SNiFF+ Workspaces.

NOTE:   This document briefly explains SNiFF+ workspaces and general concepts. For detailed information refer to the SNiFF+ User's Guide.

This section is a reference for anybody modifying, using, and writing makefiles for pSOSystem. pSOSystem makefiles can be divided into three categories:

Sample Application Makefiles

Every sample application comes with a makefile to build the application targets. This makefile ties the application to the rest of pSOSystem. It serves as a definition of files that are needed for pSOSystem to build a target executable. If you want to expand pSOSystem makefiles for your project, you should begin with this makefile.

Each sample application makefile or application makefile imports common definitions and rules from the config.mk file in $PSS_ROOT/configs/std directory. This makefile is included by every application makefile. Each sample application makefile also includes the bsp.mk file from the BSP directory. Each sample application makefile might also include one or more drivers/<drv_name>/rules.mk file if the application uses driver drv_name.

If the application is built in the SNiFF+ environment, a sample application makefile also includes the file configs/std/$(SNIFF_MAKE_CMD).mk. This file is kept for compatibility reasons. The inclusion of this file has no effect.
In the integration of SNiFF+ 3.0.2 in pRISM+ 2.0 it implemented workspace overriding for pSOSystem applications in case of SNiFF+.

NOTE:   SNIFF_MAKE_CMD is defined to snf_gnu.

The following sections are brief summaries of the makefiles included by the sample application makefile.

$PSS_ROOT/configs/std/config.mk

This makefile contains common compiler defines and options, rules for making configuration file objects (psoscfg.o, pnacfg.o etc.). It also includes rules for all the common application targets such as ram.elf, ram.hex etc. This makefile is included by every sample application makefile.

$PSS_ROOT/bsps/<bsp_name>/bsp.mk

This makefile contains board specific defines and targets (for example, DFP=H). This is included by every application makefile. It is also included by the BSP makefile.

$PSS_ROOT/drivers/<drv_name>/rules.mk

This makefile contains rules for making <drv_name> driver (for example, PPP). It is included by an application makefile if the application needs the <drv_name> driver.

BSP Makefiles

Every Board Support Package comes with a makefile to build an object library. This makefile normally resides in $PSS_ROOT/bsps/<bsp_name>/src directory. Each BSP makefile provides a definition of all other files that are needed from pSOSystem in order to build a BSP library. To expand the pSOSystem BSP makefile for your custom board support package, you should begin with this makefile.

Each BSP makefile includes $PSS_ROOT/bsps/<bsp_name>/bsp.mk file to get the BSP specific defines.

It also includes $PSS_ROOT/drivers/rules.mk, $PSS_ROOT/bsps/devices/rules.mk and $PSS_ROOT/bsps/devices/$CPU_FAMILY/rules.mk. These rules.mk files contain rules for making objects from the source files in the respective directories.

This makefile also includes the $(SNIFF_MAKE_CMD).mk file. This is for compatibility reasons. (See also above)

The following are brief summaries of the makefiles included by BSP makefiles.

$PSS_ROOT/drivers/rules.mk

Contains rules to make the high level drivers from the drivers directory. It is included by BSP makefiles using drivers from this directory.

$PSS_ROOT/bsps/devices/rules.mk

Contains rules for making low level device drivers which come from $PSS_ROOT/bsps/devices/<device_name> directory. It is included by every BSP makefile.

$PSS_ROOT/bsps/devices/$CPU_FAMILY/rules.mk

Contains rules for making CPU_FAMILY-specific files from the $PSS_ROOT/bsps/devices/$CPU_FAMILY directory. It is included in every BSP directory.

Makefiles to Build System Libraries and Other Libraries

$PSS_ROOT/sys/os directory contains makefiles to build the system libraries libsys.a.

Putting It All Together

To generate a target executable, execute the make command on the project makefile in the sample application directory. This makefile calls config.mk, bsp.mk and rules.mk to compile the operating systems configuration code, BSP configuration code, and any high-level driver code this application needs.

The object files generated are then linked with a BSP library (determined by the environment variable $PSS_BSP) and the OS library to generate a target executable, such as ram.elf.

The OS libraries are built during the installation. By default, they are not recompiled with each application build. These libraries need to be recompiled only if you have made modifications to files in any of the $PSS_ROOT/bsps directories or the $PSS_ROOT/sys directory$CPU_FAMILY like applying a Service Pack or adding new pSOSystem components as pHILE+, SNMp, etc..

6.6.3 Make Attributes of pSOSystem Source Projects

In the previous section the pSOSystem make structure was described. This section examines how pSOSystem make is integrated with SNiFF+. This will be done by examining the make attributes of pSOSystem projects. Using the pdemo sample application, you will examine the various aspects of Make Attributes. Double-clicking on a project name in the PE window displays the project's attribute sheets. Use the SNiFF+ Reference Guide for descriptions of all make attributes. This section only explains parameters relevant to pSOSystem integration.

Build Options

Figure 6-14 on page 6-40 shows the Build Options category in the Attributes dialog box for pdemo.shared.

If you follow the procedures in Section 6.7, Using the pRISM+ Application Development Framework with SNiFF+ on page 6-50, the pRISMSpace Wizard ensures that you use the correct make command based on your starting mode. You do not need to modify project make attributes when you follow the procedures given in Section 6.7.


FIGURE 6-14 Build Options Category in Attributes Dialog Box

Project Targets

Figure 6-15 on page 6-41 shows the Build Options >Project Targets category in the Attributes dialog box for pdemo.shared.

6.6.4 Making a pSOSystem Target Executable

Using the pdemo.shared example, to make the ram.elf target, select Target >Make >ram.elf in the PE window.

6.6.5 Using pSOSystem Makefiles

pSOSystem makefiles are the default makefiles used by pRISM+ and integrated into the SNiFF+ Make Support structure.

pSOSystem makefiles represent the way pSOSystem is built and tested. All the tests done on pSOSystem are based on builds done with these makefiles. For these reasons you should not fundamentally alter the structure of these makefiles or attempt to regenerate these makefiles with SNiFF+.

pSOSystem makefiles have been extended for the integration with SNiFF+. Although pSOSystem makefiles implement workspace overriding when used with SNiFF+ Working Environments, these makefiles themselves do not have SNiFF+ awareness. For example, when you start your development based on a pSOSystem sample application, by default you will start with a pSOSystem makefile. When a new file is added to this project, the pSOSystem makefile is not automatically updated with the new file information. The makefile should be updated for the change to take effect.

pSOSystem was not compiled using SNiFF+ generated makefiles for many reasons. Each pSOSystem application defines multiple targets, for execution in RAM, in ROM, in .elf format or .hex format, etc. Each of these targets is built using a different set of files out of the same pSOSystem source tree. pSOSystem makefiles provide the mapping for what is needed for each target. These targets require specific ordering of object files at link time. Many of the pSOSystem files require specific compiler flags on a per-file basis. These special make requirements makes it impractical to use SNiFF+ generated makefiles to compile pSOSystem code because too many projects would have to be made, i.e., one separate for every target. This is also the reason why Integrated Systems discourages you from regenerating makefiles with SNiFF+ to compile pSOSystem sample applications.

6.6.6 Using the SNiFF+ Makefile-Generation Feature

SNiFF+ provides automatic make support for multi-platform development that can be configured to work with any compiler, linker, archiver, and other build tools of your choice. Once a project source tree is constructed using the SNiFF+ Project Editor, makefiles can be automatically generated for this project. When additional files are added to the project source tree, the generated makefiles are automatically updated to reflect the changes. The SNiFF+ automatic makefile generation feature is tightly integrated with the project management aspects of SNiFF+, namely the Workspace and Working Environment concepts. Together they allow a team of engineers to share and compile against a common code base between them.

pRISM+ supports and extends this SNiFF+ feature with some additional pSOSystem specific make support files as well as a mechanism to allow SNiFF+ "made" modules to be incorporated back into a pSOSystem build in order to produce a target executable. Together with modification to pSOSystem makefiles, pRISM+ offers a powerful solution for team-based development projects based on pSOSystem.

Refer to the SNiFF+ User's Guide for detailed information about the SNiFF+ Make Support system. This section documents only the integration of SNiFF+ with pSOSystem.

SNiFF+'s Makefiles and Make Support Files

Refer to the SNiFF+ User's Guide for information about SNiFF+'s makefiles and Make Support files.

pRISM+ Specific Makefiles

In addition to the standard SNiFF+ Makefiles and Make Support Files, there are several additional files to support the use of the automatic makefile generation feature for pSOSystem-based applications. They are as follows:

pRISM+ Platform Makefile

In addition to SNiFF+ Makefile and Make Support files, also located in $SNIFF_DIR/make_support is a platform makefile that supports the use of the SNiFF+ automatic makefile generation feature for pSOSystem-based applications. Each platform makefile is unique for a pRISM+ for a specific processor family.

An example of the platform makefile for pRISM+ for PowerPC using the Diab Data compiler on Windows NT is a file named diabppc_win32.mk.

(These platform makefiles are compatible for use with SNiFF+ 3.0.2 and 3.2 as well.)

This platform makefile is included by the SNiFF+ general makefile general.mk. All the pRISM+ specific make options are specified in this file. These options include compiler, assembler, linker, and archiver invocation commands and options.

Per-File Compile Options

SNiFF+'s Make Support uses all compile options on a per-platform basis. This means that the compiler options in the pRISM+ platform makefiles are used for every file for this platform. However, in embedded development it's common to compile files with per-file options. To support this, an additional macro, COPT_PER_FILE is defined in general.c.mk to allow you to specify compile options on a per-file basis.

If a file with the .cop extension exists, the content of it is passed to the compiler when compiling the corresponding .c, .cc, .cxx, and .s files. For example, if you want to set the Diab compiler option -Xrtc for the source file demo.c in order to use RTA Suite to perform run-time error checking on this file, you need to make a file named demo.cop to include -Xrtc. This .cop file should be kept in your private workspace.

6.6.7 Generating Makefiles for Your Project

When to Use This Feature

pRISM+ provides integration to support use of the SNiFF+ makefile generation feature because it is a very powerful paradigm for building large applications and for managing a team build environment. It is not recommended that you remove pSOSystem makefiles and regenerate them using this makefile generation feature for the following reasons:

Use SNiFF+ to generate makefiles for your code base only. pRISM+ provides mechanisms for you to integrate your modules that are compiled with SNiFF+ generated makefiles in to a pSOSystem based build. This is the base of the Hybrid Make Model which is recommended by Integrated Systems to users who want to use the automatic makefile generation feature.

How to Use This Feature

In order to use the makefile generation feature, you must create a source project for your code base. The SNiFF+ Shared Sourec Working Environment SSWE:pSOSystem-$CPU_FAMILY-User is specifically designed to hold your code.

To make this SSWE contain your code, edit the $PSS_USER_SSWE environment variable in the start-up script in your pRISM+ installation directory; define $PSS_USER_SSWE to point to a directory, where your code is in a subdirectory.

After editing the start-up script file, you need to restart SNiFF+ for the new setting to take effect. For further information refer to Appendix E.7

Now you are ready to make a source project under the SSWE:pSOSystem-$CPU_FAMILY-User which will enable sharing of the new project.


FIGURE 6-17 SNiFF+ Working Environments Window

Once such a project is made, you can compile by selecting Target >Make >Update Makefile followed by Target >Make ><your target> in the PE window. Refer to Section 6.7, Using the pRISM+ Application Development Framework with SNiFF+ on page 6-50, for additional step-by-step instructions.

6.6.8 Hybrid Make Model

The Hybrid Make Model is the method you use to combine the SNiFF+ automatic makefile generation with the pSOSystem make system in order to produce a pSOSystem-based target executable. This make model offers the best of both worlds:

The Hybrid Make Model combines control with flexibility. Integrated Systems strongly recommends that pRISM+ users avoid regenerating pSOSystem makefiles with SNiFF+. The Hybrid Make Model is the recommended method if you want to use the SNiFF+ Make Support system with pRISM+.

This section explains the benefits of this make model and integration that exists in the pRISM+ Application Development Framework to support this model.

Who Should Use the Hybrid Make Model?

The Hybrid Make Model is designed for the following users:

How Does Hybrid Make Model Work?

The Hybrid Make Model works as follows:

pss_main.shared Project

pss_main.shared is the top-most pSOSystem super project which integrates your code base with pSOSystem code. pss_main.shared contains a set of four files that are essential to every pSOSystem application: sys_conf.h, drv_conf.c, readme.txt and a pSOSystem makefile.

The sys_conf.h and drv_conf.c files used in pss_main.shared are generic template files. They are sufficient for a simple application such as the pdemo sample application but they might not reflect the needs of your application entirely.

Compare the sys_conf.h and drv_conf.c files in a pSOSystem sample application (one that closely resembles the type of application you are developing) with the template files. If there are differences, you can either import the needed changes, or simply copy the sys_conf.h and drv_conf.c from the pSOSystem sample application that closely resembles the type of application you are developing.

If your application code already contains sys_conf.h and drv_conf.c, your working version should replace the template version.

The pss_main.shared makefile is a slightly modified pSOSystem application makefile. The structure and function is similar to all the pSOSystem makefiles that can be found in any pSOSystem sample application in $PSS_ROOT/apps directory. This makefile, however, differs slightly from other pSOSystem sample application makefiles in the following aspects:

6.6.9 Doing Team-Based Builds

SNiFF+'s make system is integrated tightly with the concepts of workspace and overriding of workspaces.

To support this team-build concept consistently, for files that are compiled with SNiFF+ generated makefiles as well as those made by pSOSystem makefiles, pSOSystem makefiles have been written to support the concept of workspace as well. These extensions in pSOSystem makefiles assist the team of developers in sharing a common pSOSystem.

This section describes the sharing of pSOSystem code in a team build environment.

SNiFF+ and Overriding of Workspaces

A workspace is a directory tree in the file system in which complete SNiFF+ projects or parts of projects reside. SNiFF+ distinguishes between workspaces that are owned by only one developer (Private Workspaces or PWSs) and workspaces that are shared by a team (Shared Workspaces or SWSs).

A workspace can share files that it does not have, but contained in another workspace. For example, private workspace can share files with the shared workspace. A practical application of Private Workspace and Shared Workspace file sharing allows individual team members to build against a common code base without having to maintain local copies of the common files.

A workspace can override another workspace. Files in one workspace can hide files that have the same name and relative position in another workspace. For example, suppose both PWS and SWS contain files apps/pdemo/demo.c. The apps/pdemo/demo.c file in PWS hides the same file in SWS.

A practical application of file overriding between workspaces allows a team member to check out a copy of a shared file into his Private Workspace. After some modifications, this modified version of the file will be used in his next build, overriding the original shared version of the file with the same name in the Shared Workspace.

Both sharing and overriding of files in workspaces are collectively referred as overriding in this document.

Sharing of pSOSystem Code

In the pSOSystem context, $PSS_ROOT serves as the root of the SSWE. A PWE is used for every developer in the team in his own $PSS_USER_PWE directory which defaults to the $HOME/psos$CPU_FAMILY_pwe directory. When a shared project is opened in a developer's PWE, the pSOSystem application and the BSP is located in the PWE.

NOTE:   On Windows a local copy, on UNIX a symbolic link is used to refer to the files in the SSWE. For detailed information refer to the SNiFF+ User's Guide.

The common projects of pSOSystem as include.shared, config_std.shared and sys_os.shared are distributed as frozen project descriptions and read-only file attributes to avoid accidental modification. They are located in the shared area and not copied or linked to the PWE. pSOSystem makefiles understand SNiFF+ workspaces and they implement sharing and overriding. Because of this feature, users on the same development team can effectively share on common pSOSystem tree.

6.6.10 Building from the Command Line

Use the command psosmake <target_name> to build from the command line.


TOC PREV NEXT