Deploying a LabVIEW Embedded Module for Blackfin Processors Design to a Custom Target

The NI LabVIEW Embedded Module for ADI Blackfin Processors delivers a complete out-of-the-box solution for embedded design. It includes LabVIEW, VisualDSP++, the EZ-KIT Lite for Analog Devices ADSP-BF537 Blackfin Processor evaluation board, the VDK operating system. The LabVIEW Embedded Module for Blackfin Processors requires no run-time licenses on your target deployment device.

In this document, we will present a general outline on how to target LabVIEW code to a custom design based on the Analog Devices ADSP-BF537 or ADSP-BF533 Blackfin processors.

Overview

The Embedded Module for Blackfin Processors supports the BF533 and BF537 EZ-KITs. You can move to custom hardware by modifying the Linker Description File (LDF) to match the hardware layout of the custom memory layout.

The LDF file defines the system to the VisualDSP++ linker and specifies how the linker creates executable code. The Embedded Module for Blackfin Processors includes default LDF files for the BF533 EZ-KIT and the BF537 EZ-KIT. You do not need to add the default LDF files to the LabVIEW Embedded Project. If you modify the existing LDF files or create a new LDF file, you must add the LDF file as an external file in the Embedded Project. Refer to the LabVIEW Help, available by selecting Help»VI, Function, & How-To Help in LabVIEW, for more information about the LabVIEW Embedded Project and how to add external files.

The default LDF file for the BF533 EZ-KIT is located in the following directory:

labview embedded\resource\LabVIEW Targets\Embedded\vdk\bf533\build\lv_vdk

The default LDF file for the BF537 EZ-KIT is located in the following directory:

labview embedded\resource\LabVIEW Targets\Embedded\vdk\bf537\build\lv_vdk

If you are using a JTAG emulator with your custom design, you might need to modify the hardware debugger XML definition file to reflect the memory map of your custom design. This XML file is located in the following directory:

Analog Devices\VisualDSP 4.0\System\ArchDef\ADSP-BF537-proc.xml

Figure 1 shows part of the hardware debugger XML definition file modified for the Bluetechnix TinyBoard. Bluetechnix designs and sells compact single-board processor modules based on the Blackfin processor.


Refer to the VisualDSP++ Linker and Utilities Manual on the Analog Devices Web site for more information about the LDF file and how to modify it.

See Also:
Bluetechnix TinyBoard
Analog Devices Web Site

Build Process

Before going through the process of taking an application to a custom design, this section gives a general overview of the build process in the LabVIEW Embedded Module for Blackfin Processors.

A LabVIEW Embedded Project manages groups of VIs and build options to build Blackfin VIs into Blackfin applications. The Embedded Project also makes the necessary calls to the VDSP++ compiler and linker. The LabVIEW C Code Generator generates C code from the LabVIEW block diagram.

You use the Blackfin Build Options dialog box, shown in Figure 2, in the Embedded Project Manager to define the build options to use when you build a Blackfin VI into a Blackfin application using the debug or release build configuration.

• Select the Release build configuration and use the rest of the release build options to build a Blackfin application with compiler optimizations, which does not allow for C source-level debugging. Release builds are optimized for performance.

• Select the Debug build configuration and use the rest of the default build options to build a Blackfin application with no compiler optimizations, which does allow for C source-level debugging using VisualDSP++. The compiler generates debug information in the Blackfin application so you can step through the generated code using the LabVIEW block diagram or simultaneously step through the code using LabVIEW and VDSP++.

The debug build configuration produces debugger-compatible output by creating a .dxe output file.
The LabVIEW Embedded Project Manager calls the VDSP++ compiler to process the generated C code and any additional C files as shown in Figure 3. In addition, you can communicate to the Blackfin target using JTAG hardware or instrumented debug code. The Embedded Module for Blackfin Processors supports additional VisualDSP++ compiler flags.

Figure 4 shows tasks that are performed when you build a Blackfin VI into a Blackfin application and download the application to a Blackfin target. The VDSP++ assembler generates an object file by assembling source, header, and data files. The primary output of the assembler is a .doj object file.

The linker links separately assembled files (object files and library files) to produce .dxe executable files, .sm shared memory files, and .ovl overlay files, that you can download to the Blackfin processor. The linker output files are binary, executable, and linkable files (.elf).

To make a debuggable application, the linker processes data from the Linker Description File (.ldf) and one or more object (.doj) files. The LDF file contains the commands, macros, and expressions that control how the linker arranges the application in memory. The executable files contain application code and debugging information. When you save a LabVIEW Embedded Project, LabVIEW creates a folder that contains all of these files.
When you have finished debugging a Blackfin application, you can rebuild the application using the release build configuration to create a processor-loadable, or boot-loadable file. The loadable file can be automatically downloaded (booted) to the processor after power-up or after a software reset. The loader output file (.ldr) is essentially the same executable code as the input .dxe file. Figure 5 shows how the loader repackages the executable code.
This section explains the Linker Description File (LDF) in more detail. The LDF file describes the target system and maps the application code with the system memory and processor.

The LDF file creates an executable file by using the following:

• The target system memory map.
• Defined segments in the source files.

You must edit the LDF file for a custom design. Analog Devices recommends copying and modifying an existing LDF file rather than creating one from scratch. The LDF file includes the following parts:

• Memory map describes the physical memory of the processor.
• SEARCH_DIR, $LIBRARIES, and $OBJECTS commands define the path names that the linker uses to search and resolve references in the input files.
• MEMORY command defines the physical memory of the system and assigns labels to logical segments. These logical segments define program, memory, and stack memory types.
• SECTIONS command defines the placement of code in physical memory by mapping the sections specified in application files to the sections declared in the MEMORY command. The INPUT_SECTIONS statement specifies the object file that the linker uses to resolve the mapping.

  Using the VisualDSP++ Expert Linker to Create LDF Files
  

VDSP++ includes Expert Linker, which is a tool that helps you:

• Define a memory map for the target processor.
• Place the object sections of a project into the memory map.
• View how much stack or heap has been used after you run an application.

This interactive tool speeds up the configuration of system memory. It uses the application’s target memory description, object files, and libraries to create a memory map that you can manipulate to optimize the system memory usage.

Expert Linker works with the VisualDSP++ linker. Expert Linker displays the available project information in the LDF file as input. This information includes object files, LDF macros, libraries, and target memory descriptions. You can drag-and-drop in the Expert Linker to arrange the object files in a graphical memory-mapping representation.

VisualDSP++ contains sample LDF files or use the Expert Linker to create and customize a new LDF file. If you open an existing VisualDSP++ C project that includes an LDF file in VisualDSP++, the Expert Linker parses the LDF file and displays the memory map and object mappings for the target processor. You can use the Expert Linker to modify the memory map or object mappings. The Expert Linker saves the changes to the LDF file when you are ready to build the project . After you load and run your program, The Expert Linker indicates the used portion of the heap and stack. You can then reduce the size of the heap or stack to minimize the memory allocated for the heap and stack. Freeing up memory in this way enables you to use that memory to store other things, such as processor code or data.

Launch the Expert Linker from VisualDSP++ in one of the following three ways:

• Double-click the LDF file in the VisualDSP++ Project window.
• Right-click the LDF file in the VisualDSP++ Project window and select Open in Expert Linker from the shortcut menu.
• Select Tools»Expert Linker from the VisualDSP++ main menu.

Note: You cannot open the Expert Linker from within LabVIEW.

Refer to the VisualDSP++ 4.0 Linker and Utilities Manual or the VisualDSP++ online help for more information about Expert Linker and how to modify LDF files.

More Information

For detailed information, refer to the VisualDSP++ 4.0 Linker and Utilities Manual or online Help. Other manuals include: VisualDSP++ 4.0 User’s Guide, VisualDSP++ 4.0 C/C++ Compiler and Library Manual for Blackfin Processors, and VisualDSP++ 4.0 Loader Manual.

VisualDSP++4.0 Linker and Utilities Manual (Revision 1.0, January 2005)
Related Links:
Comparing Floating vs. Fixed Point Algorithm Implementation with the LabVIEW Embedded Module for Blackfin Processors
Determining When and How to Implement Callbacks into your LabVIEW Embedded Module for Blackfin Processors Design
Configuring Memory Map Settings for Optimal Performance with the LabVIEW Embedded Module for Blackfin Processors
Debugging Techniques for Code Development with the LabVIEW Embedded Module for Blackfin Processors
Performing Advanced Profiling on a LabVIEW Embedded Module for Blackfin Processors Application with VisualDSP++

Reader Comments | Submit a comment »