![]() |
![]() |
![]() |
6.7 Using the pRISM+ Application Development Framework with SNiFF+
This section provides step-by-step instructions on how to use pRISM+ Application Development Framework with SNiFF+, how to start, how to configure the tools for your environment, and how to proceed with developing your application.
The material in the section is organized in terms of several typical usage scenarios, each with a distinct starting point. These starting points are as follows:
- Starting a New Project with pRISM+ on page 6-51
- Starting a Project from Your Existing Code Base on page 6-63
- Integrating a Custom Board Support Package into pRISM+ on page 6-82
- Converting a Project Made with pRISM+ Editor on page 6-87
- Starting with an Existing Application for a Previous Version of pRISM+/pSOSystem on page 6-87
If you are new to pRISM+, we strongly recommend that you start from Section 6.7.1, Starting a New Project with pRISM+ on page 6-51 and go through all the material in that section to familiarize yourself with the tools. After that, pick a starting point that is the closest to your real development needs and proceed from there.
6.7.1 Starting a New Project with pRISM+
Who Should Use This Procedure?
This usage scenario is intended for the following users:
- First time users of pRISM+ who would like an in-depth tutorial on the pRISM+ Application Development Framework.
- Platform developers who build Board Support Packages (BSPs) and application developers who work closely with pSOSystem.
- Users who are starting a brand new application with no legacy code base, and therefore want to begin development based on a pSOSystem sample application.
Step-by-Step Instructions
In this usage scenario, you are starting your development with a pSOSystem sample application. There is a variety of sample applications in
$PSS_ROOT/apps
directory, each illustrating one aspect of pSOSystem; for example, SNMP, NFS, etc. Choose one that is the closest to your application type. Once you have selected a sample application to begin with, pRISM+ will attach a Board Support Package (BSP) to this sample application. This way, when you generate a target executable, the executable will be able to run on the board supported by the BSP.The default Board Support Package is selected at installation time by the installer. To see or to change the setting of BSP for this pRISM+ Project, from the pRISM+ Manager, select pRISMSpace > Settings. (This is the case only if you have opened the pRISM+ Project at least once!)
When you are starting development in this mode, you will begin by opening a shared pSOSystem sample application project in your private workspace. After you begin, your private workspace will contain the following set of files:
sys_conf.h
-- pSOSystem configuration file that belongs to the sample application you have selected.drv_conf.c
-- pSOSystem driver installation file that belongs to the sample application you have selected.makefile
-- pSOSystem makefile that belongs to the sample application you have selected.readme.txt
-- pSOSystem sample application ReadMe..sniffdir
-- a directory used by SNiFF+.sniffprj
-- a directory used by SNiFF+.<source-file(s)>
-- source file or files that belong to the sample application you have selected.All files, such as the actual source files and header files that belong to the sample application are to be seen (on Windows: copies, on UNIX: symbolic links) in the Private Working Enmvironment (PWE) and other pSOSystem files necessary to build targets executables, are residing in the shared source workspace. You do not have private copies of shared files in your private workspace by default. Private, or local copies are made when you check files out from your source control tool through SNiFF+.
To this base line pSOSystem sample application you will:
- Add your own files into your private workspace directory.
- Modify the pSOSystem makefile in your private workspace to include new files you have added in your build.
- If necessary, switch between different BSPs in order to run your application on a variety of target hardware.
- Make target executable and proceed to debugging and testing.
Version Control
We strongly recommend that you put all your source files under source control before starting development. SNiFF+ supports a number of CMVC tools. If you are not currently using a CMVC tool, we advise using RCS, which is shipped with SNiFF+ and is preselected in the pre-parsed pSOSystem projects.
We recommend that you check the entire pSOSystem directory structure into your CMVC tool prior to using SNiFF+. For details on how to check source files into CMVC tools, contact your Systems Administrator and refer to the SNiFF+ User's Guide.
For the purpose of this tutorial, RCS is used as the version control tool and the entire pSOSystem source tree is checked in. All the examples used in this section assume this.
Start New pRISMSpace
Now you are ready to make a new pRISMSpace for your application. A pRISMSpace holds all the information regarding each pRISM+ session such as your host tools settings, your choice of targets, the location of your source project etc. This session information is stored in a pRISMSpace file
<name>.psp
, wherename
is a name you can give your pRISMSpace.
- To start a new pRISMSpace from the pRISM+ Manager, select File > New to start the pRISMSpace Wizard. This Wizard will guide you through the pRISMSpace configuration process.
- In the Tools Options dialog, select SNiFF+ as your project editor and click the Next button.
- In the Choose a starting point dialog, choose Start with a pSOSystem Sample Application and click the Next button.
- In the Choose a pSOSystem example dialog, you will see a list of sample applications. Choose an application that is the closest to the type of application you are developing. This tutorial uses
pdemo
, which is a simple sample application that demonstrates some basic uses of pSOSystem.Choose
pdemo
from the list, then click the Next button. This displays the last dialog of the Wizard, Finish this new project.- In the Finish this new project dialog:
- pRISMSpace Name is the name you use to identify your new pRISMSpace. It is always the same as the name of the sample application you opened.
- pRISMSpace directory is the directory that contains your pRISMSpace file,
pdemo.psp
. This directory is your private workspace directory.See the section What Really Happened? on page 6-75 for a detailed discussion of working with shared projects as a private user.
Congratulations, you have completed the steps to start a new pRISMSpace!
pRISM Manager will now call SNiFF+ with your project settings and start SNiFF+ for you. A log window now appears and it shows all the communication between pRISM Manager and SNiFF+. A little later, a SNiFF+ Project Editor Window appears with the pSOSystem sample application you chose and the BSP you chose (see Figure 6-18 on page 6-54).
NOTE: Once you have closed the pRISM+ Log Window, you may reopen the log window in the pRISM+ Manager menu View > Log Window.
FIGURE 6-18 First PE WindowBy completing the steps in previous sections, you have opened a pSOSystem sample application,
pdemo.shared
, as a private user. From the PE window, you see the source files in this projectpdemo.shared
as well as the project hierarchy.Working with the Sample Application
By completing the steps in previous sections, you have opened a pSOSystem sample application,
pdemo.shared
as a private user. Now you can browse all the files in the sample application, build the target of the project and begin development with this example.
NOTE: You should try to check in all files in the Version Control system. To achieve this, select all files and check them all in using the context menu of the PE. Refer to the SNiFF+ User's Guide or the Tutorial for further information. Now let us look at how to perform some basic tasks within this development framework.
Building a Target Executable
To build a target executable, do the following from the Project Editor window:
- Highlight the project for which you want to build an executable. In our case, highlight
pdemo.shared
.- From the Project Editor menu, choose Target > Make > ram.elf or another target.
In this usage scenario, you are using a pSOSystem makefile, not SNiFF+ generated makefiles.
Because file overriding is supported, any local copy of a source file will override the shared version of the same file. For example, if you checked out
demo.c
from your version control tool and modified it, the next time you compile, your modified version ofdemo.c
is used instead of thedemo.c
in the shared workspace, such as$PSS_ROOT
.Start a New File and Add It to the Project
To start a new file and add it to the project:
- Check out
pdemo.shared
, the PDF file, from version control so you can modify the project structure. You will also be prompted to reload the project. Perform the reload. The PE window will refresh its display.
FIGURE 6-19 Project Reloaded- Start a new file and add it to your project by selecting Project > Add New File to pdemo.shared.
- Enter the name of the new file you are about to compose (e.g.
new_source.c
) and add topdemo.shared
, then click OK.
The name of your file appears in the file list in the Project Editor window (see Figure 6-20 on page 6-57). Double-click the file name to open an editor window. There is a pSOSystem C-Source file template, which gets copied by SNiFF+ into the just created file. Refer to the SNiFF+ User's Guide for information about how to change the default new file template used by the SNiFF+ Source Editor when you create a new file.
FIGURE 6-20 new_source.c file Added to Project- Save your changes to the project structure by selecting Project > Save Project in the PE Window.
- Preserve the project structure change by checking in the modified PDF file for the project,
pdemo.shared
(choose File > Check In).
NOTE: An Update of the SSWE is not supported for pSOSystem standard applications. If you want others to see and share the changes in the SSWE, use a project started with an existing code base (See next section). For complete instructions on how to update SSWE, refer to the SNiFF+ User's Guide.
NOTE: You need to edit the makefile in order to add this file to your next build. There is no automatic makefile generation feature for pSOSystem standard applications!
Adding Files To and Removing Files From The Project
To add files to the project, or remove files from the project:
- Check out
pdemo.shared
, the PDF file, from version control so you can modify the project structure. You will also be prompted to reload the project. Perform the reload.- From the Project Editor window, choose Project > Add/Remove files to/from pdemo.shared. This will add or remove files to or from the
pdemo.shared
project from your private workspace directory.- Save your changes by selecting Project > Save in the PE Window. Preserve the project structure change by checking in the modified PDF file of the project,
pdemo.shared
.
NOTE: An Update of the SSWE is not supported for pSOSystem standard applications. If you want others to see and share the changes in the SSWE, use a project started with an existing code base (See next section). For complete instructions on how to update the SSWE, refer to the SNiFF+ User's Guide.
NOTE: You need to edit the makefile in order to add this file to your next build. There is no automatic makefile generation feature for pSOSystem standard applications!
Adding/Removing a Whole Directory of Code to/from pdemo.shared
To add a whole directory of code to
pdemo.shared
project:
- For the directory of code you want to add to
pdemo.shared
, recursively make shared source projects out of it and all of its subdirectories.- Check out
pdemo.shared
, the PDF file, from version control so you can modify project structure. You will also be prompted to reload the project. Perform the reload.- Add the new source project as a subproject to
pdemo.shared
by choosing Project > Add Subproject to pdemo.shared- Save your changes by selecting Project > Save in PE Window. Preserve the project structure change by checking in the modified PDF file of the project,
pdemo.shared
.
NOTE: An Update of the SSWE is not supported for pSOSystem standard applications. If you want others to see and share the changes in the SSWE, use a project started with an existing code base (See next section). For complete instructions on how to update SSWE, refer to the SNiFF+ User's Guide.
NOTE: You need to edit the makefile in order to add this file to your next build. There is no automatic makefile generation feature for pSOSystem standard applications!
Several methods can be used to perform step 1:
- Using instructions given in Section 6.7.6, Starting with an Existing Application for a Previous Version of pRISM+/pSOSystem on page 6-87. This is the recommended method.
- Using the SNiFF+ Wizard -- Refer to the SNiFF+ manuals for instructions on how to use this. Use this method only if you are a proficient user of SNiFF+ already.
- Manually make the project with SNiFF+. Use this method only if you are a proficient user of SNiFF+ already.
After you add a subproject or subprojects to
pdemo.shared
, note that you need to edit the makefile in order to reflect the changes you've made to your project in your next build.Modifying a Shared File
In the top part of the PE window's file list, the files whose names are in italics are local copies of the shared files. Other files are shared and should NOT be modified until you check the file into a version control tool and then check it out again. This effectively gives you a private copy of this file.
The file
sys_conf.h
file uses the pRISM+ Configuration Wizard as the default editor. After checking the file out of the version control system - here RCS - you have a copy of this file in your private directory, you can simply double click on it to modify it with the pRISM+ Configuration Wizard. If you choose to use the SNiFF+ Source Editor to editsys_conf.h
, you can access the simple edit function by performing a right mouse click.
NOTE: A right click on any file name will give you a local menu to perform copy, check in, check out, and edit functions.
Switching to Another BSP
pSOSystem comes with many Board Support Packages for off-the-shelf single board computers. One BSP is chosen as the default BSP at installation time by the installer. This BSP is then attached to all pSOSystem sample applications you open.
Figure 6-21 on page 6-60 shows an example of a Project Settings dialog. This figure shows the default BSP as
mbx8xx
, a PowerPC-specific BSP. If your target is a different processor, the default will be something different.To attach the sample application you are working with to another BSP, you must modify your pRISMSpace settings. To change your pRISMSpace settings, select PrismSpace > Settings from pRISM+ Manager, and then change the default Board Support Package.
FIGURE 6-21 Project Settings Dialog BoxFor your changes to take effect, you must quit out of SNiFF+ from the Launch Pad and then restart SNiFF+ from the pRISM Manager by clicking on the Development Tool button. This will let you reopen your sample application with another BSP.
If you have a custom BSP that you would like to integrate into the pRISM+ Application Development Framework, refer to the section Integrating a Custom Board Support Package into pRISM+ on page 6-82.
What Really Happened?
What really happened in your file system when you started a new pRISMSpace with a sample pSOSystem application?
On UNIX hosts, you can do the exploring from the command line.
On Windows hosts, take a look with one of the pRISM+ utility programs. From the Start button, select Programs > pRISM+ 2.0 $CPU_FAMILY> Utilities > Korn Shell $CPU_FAMILY (where $CPU_FAMILY can be 68k, ARM, MIPS, PPC or x86). This opens a Korn Shell window within the pRISM+ environment settings.
Your Private Workspace
Now, change directory to
$PSS_USER_PWE
, your Private Working Environment root directory. This is the root of your private workspace. You can confirm this by using the SNiFF+ Working Environment Tool.In the
$PSS_USER_PWE
directory you will immediately see a mirroring directory structure that resembles the pSOSystem top-level directory structure. This is because SNiFF+ created the directories when you opened a shared pSOSystem sample application project, namelypdemo.shared
.
FIGURE 6-22 Contents of pdemo DirectoryWhen a shared project is opened from a PWE, SNiFF+ always creates a mirroring directory structure in the private working space to mimic the directory structure of the shared source workspace. This mirroring directory structure in your private workspace is later used to hold the files you check out from the shared source workspace.
The
pdemo
directory shown in Figure 6-22 contains all files from the SSWE plus the filepdemo.psp
and the subdirectory.sniffdir
. Here is an explanation aof the purpose of the files:
Any new source files you add to
pdemo.shared
will be kept in thispdemo
directory.
FIGURE 6-23 Contents of Your Private WorkspaceBecause the files of the
pdemo
projects reside in$PSS_ROOT/apps/pdemo
in the shared source workspace, your private workspace for it is$PSS_USER_PWE/apps/pdemo
.Change directory to
$PSS_USER_PWE/apps/pdemo
to examine its contents.
NOTE: Depending on the type of sample application you have opened, the number of files might vary from what is shown in Figure 6-23. However, what is shown is typical of what happens after the opening of any shared pSOSystem sample application <sample_app>
.shared
.
Source Files and File Overriding
Notice that if you want to modify files in your private workspace of
pdemo.shared
, you need to check a copy out of the version control system.When you check out a version for local use from your version control tool, this local version of the file will override the file with the same name in the shared code base when you perform a build. pSOSystem makefile automatically handles this file overriding feature. For more details about file sharing and overriding, refer to the SNiFF+ User's Guide.
As a small experiment, you can right click on
demo.c
and choose Check in (if not already done). Then right click ondemo.c
again and choose Check out. After that, you will seedemo.c
in your private workspace as a writable file. Thisdemo.c
file will override the shareddemo.c
file in the shared source workspace (namely, under$PSS_ROOT/apps/pdemo
), the next time you compilepdemo.shared
.This concludes the tutorial on how to use pRISM+ to begin development with a pSOSystem sample application using SNiFF+.
6.7.2 Starting a Project from Your Existing Code Base
Who Should Use This Procedure?
This usage scenario is intended for the following users:
- Users who have gone through a pRISM+ tutorial and are now ready to begin development starting with their existing code.
NOTE: If the code base you refer to is a custom Board Support Package you have developed, go to Section 6.7.4, Integrating a Custom Board Support Package into pRISM+ on page 6-82. If you have not gone through a pRISM+ tutorial, begin with Usage Scenario 1 in the previous section.
- Application developers who have a medium- or large-sized existing code base which they would like to browse, build and eventually integrate with pSOSystem code to produce an embedded application.
- Users who are starting a brand new application with small- or no existing code base, who would like pRISM+ to automatically generate and manage makefiles for the project.
Step-by-Step Instructions
First pRISM+ will make a shared source project out of your code base. By default, the project is created recursively to include all directories and subdirectories in a source tree. Makefiles are generated when your project is created. Once your code is turned into a source project, you can then browse this code, add files to your project, automatically update makefiles, and continue your development.
Automatic makefile generation is by default enabled for this usage case. As pRISM+ is making source projects out of your code, when a makefile is not detected in a directory, pRISM+ will place a generated makefile there. pRISM+ will then update the makefile when new files are added and dependencies change as you add files to your project.
If you already have working makefiles for your code that resides within your code base, don't worry, pRISM+ will not overwrite your makefile. You can go on using your own makefile instead of generating new makefiles.
If you are starting with no code but anticipate your project code base to grow and eventually have a substantial amount of code, you can start by generating an empty source project. pRISM+ will then update the makefile when new files are added and dependencies change.
Once you have made source projects out of your own code base, pRISM+ will automatically integrate your code with the rest of pSOSystem code in order to produce a target executable.
Version Control
We strongly recommend that you put all your source files under source control before starting development. SNiFF+ supports a number of CMVC tools. If you are not currently using a CMVC tool, you are advised to use RCS, which is shipped with SNiFF+ and is preselected in the pre-parsed pSOSystem projects.
You are also recommended to check in the entire pSOSystem directory structure into your CMVC tool prior to using SNiFF+. For details on how to check in source files into CMVC tools, contact your Systems Administrator and refer to the SNiFF+ User's Guide.
For the purpose of this tutorial, RCS is used as the version control tool and the entire pSOSystem source tree is checked in. All the examples used in this section assume this.
Locate Your Existing Code Base
Before you start pRISM+, it is necessary that you set an environment variable which pRISM+ will use to locate your code base. For simplicity, we are now assuming that your code base has a single root. If your code base has more than one root, refer to the section Working with Multiple Source Trees on page 6-80.
While your code can reside anywhere in your file system, the need to integrate with pSOSystem code requires that your existing code base is located in a known location to pRISM+. pRISM+ uses the environment variable
$PSS_USER_SSWE
to point to your code.To point this environment variable to your code, edit
env$CPU_FAMILY.ksh
(on Windows hosts) orenvv
$CPU_FAMILY.csh
orenvv$CPU_FAMILY.[c]sh
(on UNIX hosts) in the pRISM+ installation directory.
PSS_USER_SSWE="$PSS_USER_SHARED/SharedProjectArea"
PSS_USER_SSWE="<location_of_your_code>"
where
location_of_your_code
is the root directory of your code.Upon a new pRISM+ installation,
$PSS_USER_SSWE
points to the default location$PSS_USER_SHARED/SharedProjectArea
, where $PSS_USER_SHARED points to$PRISM_INSTALL_DIR/users/common
. For a large existing code base, it is easier for you to redefine the environment variable than to copy your entire code base into the$PSS_USER_SHARED/SharedProjectArea
location.Once you have redefined
$PSS_USER_SSWE
, SNiFF+ will treat the directory that$PSS_USER_SSWE
points to as the Shared Source Working Environment root directory. SNiFF+ can then make a shared project for you out of the source code in$PSS_USER_SSWE
directory.You can then work with this shared project in your PWE,
$PSS_USER_PWE
, just as you can with any shared pSOSystem sample application, as illustrated in Section 6.7.1, Starting a New Project with pRISM+ on page 6-51.
NOTE: If you and your team are sharing this code, this step should be performed by a team shared code administrator. For more information on how to set up team-based development, refer to the SNiFF+ User's Guide.
NOTE: You must change $PSS_USER_SSWE
prior to invoking any pRISM+ tools for the change to take effect.
NOTE: Makefile generation is automatically enabled when you use pRISM+ in this usage scenario. If you want to take advantage of this feature, remove or rename any existing makefiles in your source tree. If SNiFF+ detects a makefile in a directory as a source project is being made, it will not overwrite the existing makefile even when Make Support is enabled.
This tutorial uses a small example to simulate an existing code base. This example code is derived from the
pdemo
pSOSystem standard application and is placed by default in the location$PSS_USER_SSWE
under the nameuser_pdemo
.Now you are ready to make a new pRISMSpace for your application. A pRISMSpace holds all the information regarding each pRISM+ session such as your host tools settings, your choice of targets, the location of your source project etc. This session information is stored in a pRISMSpace file
user_pdemo.psp
, since user_pdemo is the name you will give your pRISMSpace.
- To start a new pRISMSpace from the pRISM+ Manager, select File > New to display the pRISMSpace Wizard. This Wizard will guide you through the pRISMSpace configuration process.
- In the Tools Options dialog, select SNiFF+ as your project editor choice and click on the Next button.
- In the Choose a starting point dialog, choose Start with an existing codebase and click on the Next button.
- The Locate the code starting point dialog prompts for the location of your existing code base.
![]()
FIGURE 6-24 Starting With an Existing Codebase- The Set relinkable object name dialog prompts for the name to be used by pRISM+ to refer to the relinkable object made from your code.
NOTE: When you start pRISM+ in this mode, with an existing code base, automatic makefile generation is enabled by default. If your code base does not have working makefiles, pRISM+ can generate makefiles automatically and build a relinkable object out of your code base. This relinkable object is then linked with the rest of pSOSystem code when automatically the Convert to pSOSystem App Proj operation is performed followed by building of a target executable such as ram.elf
. For more information about the pRISM+ Hybrid Make Model, refer to Section 6.6.8, Hybrid Make Model on page 6-46.
For this tutorial example, you will name the relinkable object
user_pdemo.o
. This name will be entered into pSOSystem makefiles by pRISM+.
NOTE: Even if you are not using SNiFF+ to generate a makefile but want to use your existing makefiles, you can also enter a name for a relinkable object for the purpose of integration with pSOSystem code. After you do so, make sure you modify your makefile to make this relinkable object.
- The Finish this new project dialog prompts for the name of your pRISMSpace and shows the default location of your pRISMSpace file.
- pRISMSpace Name is the name you use to identify your new pRISMSpace. It is always the same as the name of the shared project you open as a private user.
- pRISMSpace directory is the directory which contains your pRISMSpace file,
user_pdemo.psp
. This directory is your private workspace directory. See What Really Happened? on page 6-75 for a detailed discussion of working with shared projects as a private user.- Click on the Finish button.
Congratulations, you have completed the steps to start a new pRISMSpace!
pRISM Manager will now call SNiFF+ with your project settings and start SNiFF+ for you. A log window appears and shows the communication between pRISM Manager and SNiFF+.
NOTE: Once you have closed the pRISM+ Log Window, you may reopen the log window in the pRISM+ Manager menu View > Log Window. A little later, a SNiFF+ Project Editor Window appears showing a shared source project made out of your code opened in your private working environment.
FIGURE 6-25user_pdemo.shared
in the Project Editor WindowFinally the user_pdemo source project is automatically Converted to a pSOSystem application project.
FIGURE 6-25apss_main.shared
in the Project Editor WindowWorking with Your Source Project
By completing the steps in the previous section, you have accomplished the following:
- Made a shared source project that a team can share and compile against.
- From your screen, you can see that you have also opened this shared project as a private user.
- Generated makefiles that were placed in your source directories when makefiles were not detected in the directories as the source projects were being made.
- Build a target executable (for example
ram.elf
) from the pSOSystem superprojectpss_main.shared
.Now you are ready to beginning development with pRISM+ Application Development Framework. Now let us look at how to perform some basic tasks within this development framework.
Start a New File and Add It to the Project
To start a new file and add it to the project:
- Check in all files of the newly created source project
pss_main.shared
and all subprojects of and includinguser_pdemo.shared
, then check out all PDF files from version control so you can modify the project structure. You need to reload the projectpss_main.shared
to have the display of the PE updated!- Create a new file and add it to your project by selecting the subproject where you want to add the file to (here:
demo.shared
) and using the menuProject > Add New File to demo.shared in the PE window.- In the New File dialog box, enter the name of the new file you are about to compose and add to
demo.shared
, then click OK.
The name of your file appears in the file list in the Project Editor window. Double-click the file name to open an editor window. There is a pSOSystem C-Source file template, which got copied by SNiFF+ into the just created file. Refer to the SNiFF+ User's Guide for information about how to change the default new file template used by the SNiFF+ Source Editor when you create a new file.
FIGURE 6-26 New File Added- Save your changes to project structure by select Project > Save demo.shared in the PE Window. Preserve the project structure change by checking in the modified PDF file
demo.shared
and the new source filenew_source.c
.- Update SSWE if you want others to see and share the changes. For complete instructions on how to update SSWE, refer to the SNiFF+ User's Guide.
After adding files to your project, you must update your makefile to reflect the changes. To update your makefile, select Target > Update Makefile in the PE window. SNiFF+ will then update your makefile automatically.
Adding Files To and Removing Files From the Project
To add files to or remove files from the project:
- Check out all PDF files from version control so you can modify the project structure. You will also be prompted to reload the project. Perform the reload.
- From the Project Editor window, choose Project > Add/Remove files to/from demo.shared. This will add files to or remove files from the
demo.shared
project from your private workspace directory.- Save your changes by selecting Project > Save in PE Window. Preserve the project structure change by checking in the modified PDF file of the project
demo.shared
.- Update SSWE if you want others to see and share the changes. For complete instructions on how to update SSWE, refer to the SNiFF+ User's Guide.
- You need to update the makefile in order to reflect the changes you've made to your project in your next build. To update your makefile, from PE window, select Target > Update Makefile. SNiFF+ will then update your makefile automatically.
Adding/Removing a Whole Directory of Code to/from a Project
To add a whole directory of code to the
user_pdemo.shared
project:
- Make a source project out of the directory (and all of its subdirectory) of code you want to add to
user_pdemo.shared
, and then save the project.- Check out
user_pdemo.shared
, the PDF file, for theuser_pdemo.shared
project, so you can modify the project structure.- Add this new source project as a subproject to
user_pdemo.shared
by choosing Project > Add Subproject to user_pdemo.shared.- Checkmark all subprojects of
user_pdemo.shared
, the projectsuser_pdemo.shared
andpss_main.shared
. Set the attributes of all projects selecting Project > Attributes oc Checkmarked Projects... in the PE Window.Press Set for All.
- Select the Build Options > Directives topic.
Checkmark beside the Generate button next to it.- Select the Build Options > Build Structure topic.
Checkmark beside the Generate button next to it.
Press OK.
The Update Makefile dialog comes up where you answer YES- Save your changes by selecting Project > Save in the PE Window. Preserve the project structure change by checking in the modified PDF file of the project, user_pdemo.shared.
- Update SSWE if you want others to see and share the changes. For precise instructions on how to update SSWE, refer to the SNiFF+ User's Guide.
Several methods can be used to perform step 1 on page 6-71. They are as follows:
- Using instructions given in Section 6.7.2, Starting a Project from Your Existing Code Base on page 6-63. This is the recommended method. Once you've source project out of the directory or directories of code you want added to your project, add them as subprojects to your project.
- If the root of this directory isn't under your current
$PSS_USER_SSWE
, refer to the section titled Working with Multiple Source Trees.- Using SNiFF+ Wizard using the Project Template
pRISM-User-Apps-Project.ptmpl
- Refer to the SNiFF+ manuals for instructions on how to use this. Use this method only if you are a proficient user of SNiFF+ already.- Manually make the project with SNiFF+. Use this method only if you are a proficient user of SNiFF+ already.
Modifying a Shared File
In the top part of the PE window's file list, the files whose names are in italics are local copies of the shared files. Other files are shared and should NOT be modified until you check the file into a version control tool and then check it out again. This effectively gives you a private copy of this file.
The file
sys_conf.h
file uses the pRISM+ Configuration Wizard as the default editor. After checking the file out of the version control system - here RCS - you have a copy of this file in your private directory, you can simply double click on it to modify it with the pRISM+ Configuration Wizard. If you choose to use the SNiFF+ Source Editor to editsys_conf.h
, you can access the simple edit function by performing a right mouse click.
NOTE: A right click on any file name will give you a local menu to perform copy, check in, check out, and edit functions.
Building a Target Executable
NOTE: For $CPU_FAMILY = x86 and $CPU_FAMILY = ARM:
You need to do a Target > Make > clean for thepss_main.shared
andbsp_src.shared
to generate the subdirectories for the object files!.
Now you are ready to build a pSOSystem-based target executable.
- To complete the target build, highlight pss_main.shared in the PE window and select Target > Make > ram.elf (or another kind of target executable).
Now you can proceed to downloading and debugging your module on the target.
Adapting the PrismSpace Settings
To reflect the
pss_main.shared
project structure the PrismSpace Settings in the pRISM+ Manager's menu PrismSpace > Settings need to be adapted. The filessys_conf.h
andram.elf
(or what ever is the Build Make Target) are located in the PrismSpaces subdirectorypss_main
.
FIGURE 6-27 pRISMSpace Settings in the pRISM+ ManagerSwitching to Another BSP
pSOSystem comes with many Board Support Packages for off-the-shelf single board computers. One BSP is chosen as the default BSP at installation time by the installer. This BSP is then attached to all pSOSystem sample applications you open. In our example, by examining the PE window, we can see that mbx8xx is set as the default BSP.
To attach the sample application you are working with to another BSP, you must modify your pRISMSpace settings. To change your pRISMSpace setting, from pRISM+ Manager, select PrismSpace > Settings and change the default Board Support Package.
FIGURE 6-27 pRISMSpace Settings for the BSP in the pRISM+ ManagerFor your changes to take effect, you must quit SNiFF+ from the Launch Pad and then restart SNiFF+ from pRISM+ Manager by clicking on the Development Tool button. This will let you reopen your sample application with another BSP.
If you have a custom BSP that you would like to integrate into the pRISM+ Application Development Framework, refer to Section 6.7.4, Integrating a Custom Board Support Package into pRISM+ on page 6-82.
What Really Happened?
On UNIX hosts, you can explore from the command line.
On Windows hosts, using one of the pRISM+ utility programs, take a look at what actually happened.
From Start, select Start > Programs > pRISM+ 2.0 $CPU_FAMILY > Utilities > Korn Shell $CPU_FAMILY. This opens a Korn Shell window with the pRISM+ environment settings.
Your Shared Source Workspace
First look at what happened in your shared code base. Change directory to
$PSS_USER_SSWE
; for example, to the location of your shared source workspace and then touser_pdemo
.
FIGURE 6-28 Shared Source WorkspaceIn addition to the files you have in your code base, there are now some new items in your directory:
Your Private Workspace
Next, let's turn our attention to the PE windows which shows your private view of the shared project
user_pdemo.shared
. Upon completing the steps above, you have in fact accomplished the following:
- Created a shared source project for your team.
- Opened
user_pdemo.shared
in your private workspace.- Generated makefile for your project
- Build a target executable (for example
ram.elf
) from the pSOSystem superprojectpss_main.shared
.Now let us look at what's taken place in your private workspace. Close examination of
$PSS_USER_PWE
directory will reveal that a new directory with the name of your source project has been created. For our example, in$PSS_USER_PWE
there is a new directoryuser_pdemo
which is the new private workspace for the shared projectuser_pdemo.shared
.When you check out files from SSWE, a copy is placed here for you to modify.
FIGURE 6-30 Private WorkspaceFor now, upon creation, it contains the following:
Source Files and File Overriding
Notice that in your local workspace, there are no other source files present from your shared source project because those files are shared.
When you check out a version for local use from your version control tool, this local version of the file will override the file by the same name in the shared code base when you perform a build. pSOSystem makefile automatically handles this file overriding feature. For more details on file sharing and overriding, refer to the SNiFF+ User's Guide.Using pss_main.shared Project
What Is It For?
pss_main.shared
is a pSOSystem superproject designed specifically for integration of your code with pSOSystem code. It is a generic pSOSystem superproject to be used as the parent of the source project you want to integrated with pSOSystem. It contains a set of essential pSOSystem files needed by every pSOSystem application, including a pSOSystem makefile which integrates your build into a pSOSystem build in order to generate a pSOSystem-based executable.Where Is It Stored?
pss_main.shared
is stored in a subdirectory in your shared source workspace; that is, in the directory pointed to by$PSS_USER_SSWE
. It was put there by the Convert to pSOSystem App Proj command when you created your project.What Does It Contain?
pss_main.shared
contains the following:
Using pSOSystem Application Signature Files (makefile, drv_conf.c, sys_conf.h)
Makefile in pss_main.shared
The makefile contained in
pss_main.shared
is a generic template pSOSystem makefile used to integrate a custom module in a pSOSystem build. This makefile is generic and might NOT include all the parts of pSOSystem code you would need for your application. For example, if you are using SNMP, you need to modify the makefile to include the pSOSystem SNMP library. You are responsible for making sure that this makefile is complete. Refer to pSOSystem sample application makefiles for what's needed from pSOSystem for each type of application.This makefile contains a macro
PSS_APPOBJS
which should contain the name of the relinkable object made from your custom module. This module is placed in the makefile by pRISMSpace Wizard when you configure this pRISMSpace. This macro can be modified by users. If there are other libraries you want to be linked into the final build, you can also add them here. For information on the make system, refer to Section 6.6.8, Hybrid Make Model on page 6-46.This makefile assumes that it resides in the same directory as the
sys_conf.h
anddrv_conf.c
files which comes in thepss_main.shared
project.sys_conf.h in pss_main.shared
The
sys_conf.h
file contained inpss_main.shared
is a generic templatesys_conf.h
file used to integrate a custom module in a pSOSystem build. Thissys_conf.h
file is generic and might NOT reflect the needs of your application. For example, you may be using more OS components than what the default is set for. You are responsible for making sure that this makefile is complete. Refer to thesys_conf.h
file in pSOSystem sample applications for what is needed from pSOSystem for each type of application.6.7.3 Integrating a Custom Board Support Package into pRISM+
Who Should Use This Procedure?
This usage scenario is intended for the following users:
- Users who want to integrate custom BSPs into the pRISM+ Application Development Framework and use them in the same integrated fashion as other BSPs shipped with pRISM+.
- Users who want to derive a custom BSP out of a pRISM+ BSP and be able to toggle between the derived BSP and the pRISM+ BSP frequently for development and testing purposes.
Step-by-Step Instructions
For a custom BSP to be integrated into pRISM+ you must first perform the following tasks so your custom BSP conforms to the form needed by pRISM+ for integration. These steps are as follows:
- Copy your custom BSP under
$PSS_ROOT/bsps
so it can be visible to the rest of pSOSystem code which references BSPs with an environment variable relative to$PSS_ROOT
.- Organize your BSP directory structure so that it follows standard pSOSystem BSP format.
- Create a file list which contains all the files (including path information) for your BSP. SNiFF+ will use this file list to create a source project for your BSP.
- Run the pRISM+ supplied script
plugins_create_bsp
to create a SNiFF+ project for your custom BSP.Upon completion of these steps, your BSP will be browser-ready and you are ready to continue with the development and testing of your BSP within the pRISM+ Application Development Framework.
Note that steps illustrated in this section show you how to integrate your BSP into the pRISM+ environment. If you need information on how to port a custom BSP to support this release of pSOSystem, refer to the pRISM+ Upgrade manual.
In this section we will use an example to illustrate the steps required to integrate a custom BSP into the pRISM+ environment for browsing, further development and integration with pSOSystem-based applications.
Copy Custom BSP into $PSS_ROOT/bsps
The pRISM+ development environment and tools are set up to allow users to build the same applications to run on many different target boards. pRISM+ accomplishes this by providing an easy toggling mechanism to allow users to work with many different BSPs. This is done with an environment variable
$PSS_BSP
which is defined relative to$PSS_ROOT
, the root directory of pSOSystem. This is why your custom BSP must reside inside the pSOSystem tree in order for the rest of pSOSystem source projects to have visibility of your custom BSP.Reorganize Your BSP Directory Structure
All pSOSystem BSPs have a certain directory structure as follows:
- Each BSP resides under the directory
$PSS_ROOT/bsps/<custom_bsp>
, wherecustom_bsp
is the name of a BSP.- Each BSP directory has a subdirectory
/src
which contains the source code for the BSP that's specific to this board.- Each
/src
directory contains a makefile, in the form of a pSOSystem makefile, NOT SNiFF+ generated makefile, which:
- Provides rules for compiling files in the /src directory.
- Includes other makefiles, such as
rules.mk
, to include other source files needed by this BSP. Most commonly, these other files are drivers code and devices code that are board-independent. pSOSystem driver code resides in$PSS_ROOT/drivers
directory and devices code reside in$PSS_ROOT/bsps/devices
directory.- When used for a make, produces an object library, called
libbsp.a
, which is placed in the parent directory of/src
, which is$PSS_ROOT/bsps/<custom_bsp>
.
NOTE: Make sure that you organize your custom BSP to conform to this basic structure.
NOTE: Your current BSP makefile might not contain all the drivers and devices you need out of the current pSOSystem now. Do not worry, they can be added later.
Create a File List for Your BSP
An important part of integration of your BSP into the pRISM+ environment is to make it browsing-enabled for SNiFF+. For SNiFF+ to be able to browse your code, you must first turn your source tree into a source project. pRISM+ provides you with a script which automatically performs this for a custom BSP which resides in
$PSS_ROOT/bsps/<custom_bsp>
and which conforms to the basic BSP directory structure described in the last section. This script requires a file list which contains all the files that make up your BSP, including the path for each file.Generate a file list that meets the following requirements:
- It contains a list of ALL files which make up your BSP, including drivers code and devices code
- Name this file list
.snifffl.lst
.- Place your .snifffl.lst in
$PSS_ROOT/bsps/<custom_bsp>/src
directory, wherecustom_bsp
is the name of your custom BSP.- First file name in this file should be from the
$PSS_ROOT/bsps/<custom_bsp>/src
directory, wherecustom_bsp
is the name of your custom BSP. You can place further file names of files in$PSS_ROOT/drivers
and$PSS_ROOT/bsps/devices
after that in the list.All standard pSOSystem BSP source projects are created by Integrated Systems using file lists such as the one you are creating for your BSP. Go to any pSOSystem BSP directory to see an example file list used by Integrated Systems to generate the standard BSP projects.
Armed with the file list, you are ready to run the script to perform the final integration of your BSP into pRISM+.
Run plugins_create_bsp to Create a SNiFF+ Project
To perform the final step of integration of your custom BSP into the pRISM+ environment, you need to run the
plugins_create_bsp
to create a SNiFF+ project for it.About plugins_create_bsp
bsp_src.shared
under$PSS_ROOT/bsps/<custom_bsp>/src/sniffprj
bsp.shared
under$PSS_ROOT/bsps/<custom_bsp>/sniffprj
- You have pRISM+ environment setup.
- You are using a makefile derived from a pSOSystem BSP makefile and not SNiFF+ generated makefiles.
plugins_create_bsp <bsp_dir> [ -f <file_list_file> ]
plugins_create_bsp
Usage Syntax:
where
bsp_dir
is$PSS_ROOT/bsps/<custom_bsp>
Using plugins_create_bsp
On Windows hosts, execute this shell script by following the steps below:
plugins_create_bsp <
- Start the pRISM+
Korn Shell
by selecting Programs > pRISM+ 2.0 $CPU_FAMILY > Utilities > Korn Shell $CPU_FAMILY from the Windows Start menu. This starts the Korn Shell window.- From the command line, execute
bsp_dir
> [ -f <file_list_file
> ]
On UNIX hosts, this script can be executed from a command line.
You will see SNiFF+ invoked by the shell script through
sniffaccess
program to create your BSP project. On completion of this final step, you have integrated your custom BSP into the pRISM+ environment.Verifying Your Integration
To verify that you have succeeded in integrating your BSP into pRISM+:
- Open any pRISMSpace you have made according to the steps illustrated in Starting a New Project with pRISM+ on page 6-51.
- Change the BSP settings of your previously made project by selecting PrismSpace > Settings > Board Support Packages. By now you should see your BSP added to the list.
- Select your BSP from the list.
- Shut down SNiFF+ from the SNiFF+ Launch Pad. There is no need to close the current pRISMSpace.
- Restart SNiFF+ again from the pRISM Manager by clicking on the "Development Tool" button (second from the left). This should bring up the pSOSystem sample application again with your BSP.
- Compile the BSP and the application.
NOTE: The default setting on installation time of this integration is selected to not support own drivers and device files.
This is due to compatibility to the Integration of SNiFF+ 3.0.2.
To change this selection, edit the file$PSS_ROOT/bin/win32/psosmake.ksh
by uncommenting the selection to support this.
To make use of this selection it is often necessary to review the files listed in the .snifffl.lst of the BSP. (See also theReleaseNotes.txt
for further information.)6.7.4 Converting a Project Made with pRISM+ Editor
Who Should Use This Procedure?
This usage scenario is intended for the following users:
- Those who use pRISM+ Editor to do their development but want to parse and browse their source files with SNiFF+.
- Those who have previously used pRISM+ Editor but want to change to using SNiFF+ to continue their projects.
Users of pRISM+ Editor who simply want to use SNiFF+ to browse their source files can treat the body of code they want to browse as an existing code base referred to in Starting a Project from Your Existing Code Base on page 6-63.
Users of pRISM+ Editor who want to change to using SNiFF+ to continue their projects should first evaluate their team development needs and then proceed with the instructions given in Starting a Project from Your Existing Code Base on page 6-63.
6.7.5 Starting with an Existing Application for a Previous Version of pRISM+/pSOSystem
![]() |
![]() |
![]() |