PicoRadio Test Bed Workspace Setup:
ARM Project

1. Install the ARM project.
   
   
   • Go to <your workspace directory>\ARM\main.
     
     
   • Double click on ARM_Project_Template.apj.  It should start the ARM Project Manager if the ARM tools are installed. 
     
     
   • Select Save As from the File menu and save the template under a name of your choice.  
     
     
   • Delete ARM_Project_Template.apj.  Basic ARM support is now installed.  
     
     
   • Explore around the organizer view in the Project Manager to get a feel for what's there.  In particular, {Debug,Release}/Sources contains the basic .c files for an executable, including main() and a command line parser that you can customize.  {Debug,Release}/Subprojects contains a list of ARM services supported by the PRTB environment.  Debug and Release are the default variants; a variant is a different compilation context (e.g. Debug compiles with -g, among other things).  From now on, I'll use the term <variant> to represent one of these.
     
     
   • Your default project is now installed.

   The default project is compilable.  Try clicking on the full wall icon and see what happens (you might want to maximize the project window first).  The executable will be placed in a directory named for the variant, and a link will appear in <variant>/Image depending on which variant is selected.  If  ARM Executable Image (root of the project tree) is selected, it will rebuild the variant that was last built.

    

2. Add any pre-existing .c files to the project.
   
    
   • Put any pre-existing 'C' files in the <your workspace directory>\ARM\src directory.
     
       
   • Expand one of the variants.  It doesn't matter which one; additions or changes to sources or headers are global across variants.
     
     
   • Click on Sources and select Project/Add Files To Sources.  
     
     
   • Navigate to <your workspace directory>\ARM\src, and add the relevant files to the project.  

   When you compile, the Project Manager will check dependencies and place links to headers in <variant>/Included Files.  If the compiler can't find a header file, click on ARM Executable Image, select Project/Tool Configuration for <your project>.apj/{armcc,armasm}/Set, find the Include Files or Include Paths tab, and add the path to the missing include file.  For .c files, edit armcc and for .s files, edit armasm.

    

3. Modify the default code.
   
   
   • Expand one of the variants.  Again, it doesn't matter which one for editing source.
     
     
   • Expand Included Files.  
     
     
   • Double click on application.h (at the bottom).
     
     
   • Take a look at the DEF_XILINX_FILENAME and  DEF_XILINX_HEADER constants.  These point to the location of Xilinx program definition files for debug and standalone mode, respectively.  The initial default paths point to real files that can be used - they are compilations of the default Xilinx workspace template.  About the only useful thing you can do with these initial files is to set the LEDs, but at least they will help you get started.  
     
     Both files are generated automatically by the Xilinx compilation procedure - the names differ only in the file extensions.  When you've finished the Xilinx setup, come back to this file and change the paths to point to your custom Xilinx .raw and .h files.  Normally, these will be <your workspace directory>/Xilinx/compiled/<name of your top level schematic>.{raw,h}.  The .raw file is loaded via the serial port during debugging (if not overridden by the command line argument -p or a menu command), and the .h file is compiled into the ARM image for ROM-based operation.
     
     
   • Close application.h
     
     
   • Expand Sources.
     
       
   • Double click on application.c.  This is where the entry point to your code will go, or all of your code if it's fairly small (you can always add source files to the project if application.c gets too big).  
     
     
     app_Init() is run once on startup.  This is where you would put any initialization code, such as starting global timers, registering interrupt service routines, or initializing ARM GPIO pins.  There are a couple of example lines in app_Init() - take a look.  
     
     app_Main() is called periodically.  This is where you would put your event loop, if you have one.  
     
     You can leave one of these functions empty if you don't need it, but DON'T delete either of them! For instance, it's possible that you won't need to initialize anything.  Or, your application might be entirely interrupt driven, in which case you won't need a main function. If you want to use FIQs, put your interrupt code in user_FIQISR() and add one call to interrupt_InstallFIQHandler() in app_Init() for each interrupt source.  There can be only one FIQ handler, and user_FIQISR() is it.  That's why interrupt_InstallFIQHandler() does not have a pointer argument for an Interrupt Service Routine.  It installs user_FIQISR() for every interrupt source, so you have to do source discrimination in user_FIQISR().

    

4. Write your app code, and hit the half wall icon (incremental build).  Debug the code as needed. Good luck.

Maintainer: Fred Burghardt
Modified: October 11, 2000