Lab View
Lab View
TM
Support Worldwide Technical Support and Product Information ni.com National Instruments Corporate Headquarters 11500 North Mopac Expressway Worldwide Offices Australia 1800 300 800, Austria 43 662 457990-0, Belgium 32 (0) 2 757 0020, Brazil 55 11 3262 3599, Canada 800 433 3488, China 86 21 5050 9800, Czech Republic 420 224 235 774, Denmark 45 45 76 26 00, Finland 358 (0) 9 725 72511, France 01 57 66 24 24, Germany 49 89 7413130, India 91 80 41190000, Israel 972 3 6393737, Italy 39 02 41309277, Japan 0120-527196, Korea 82 02 3451 3400, Lebanon 961 (0) 1 33 28 28, Malaysia 1800 887710, Mexico 01 800 010 0793, Netherlands 31 (0) 348 433 466, New Zealand 0800 553 322, Norway 47 (0) 66 90 76 60, Poland 48 22 3390150, Portugal 351 210 311 210, Russia 7 495 783 6851, Singapore 1800 226 5886, Slovenia 386 3 425 42 00, South Africa 27 0 11 805 8197, Spain 34 91 640 0085, Sweden 46 (0) 8 587 895 00, Switzerland 41 56 2005151, Taiwan 886 02 2377 2222, Thailand 662 278 6777, Turkey 90 212 279 3031, United Kingdom 44 (0) 1635 523545 For further support information, refer to the Technical Support and Professional Services appendix. To comment on National Instruments documentation, refer to the National Instruments Web site at ni.com/info and enter the info code feedback. 20052008 National Instruments Corporation. All rights reserved. Austin, Texas 78759-3504 USA Tel: 512 683 0100
Important Information
Warranty
The media on which you receive National Instruments software are warranted not to fail to execute programming instructions, due to defects in materials and workmanship, for a period of 90 days from date of shipment, as evidenced by receipts or other documentation. National Instruments will, at its option, repair or replace software media that do not execute programming instructions if National Instruments receives notice of such defects during the warranty period. National Instruments does not warrant that the operation of the software shall be uninterrupted or error free. A Return Material Authorization (RMA) number must be obtained from the factory and clearly marked on the outside of the package before any equipment will be accepted for warranty work. National Instruments will pay the shipping costs of returning to the owner parts which are covered by warranty. National Instruments believes that the information in this document is accurate. The document has been carefully reviewed for technical accuracy. In the event that technical or typographical errors exist, National Instruments reserves the right to make changes to subsequent editions of this document without prior notice to holders of this edition. The reader should consult National Instruments if errors are suspected. In no event shall National Instruments be liable for any damages arising out of or related to this document or the information contained in it. EXCEPT AS SPECIFIED HEREIN, NATIONAL INSTRUMENTS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AND SPECIFICALLY DISCLAIMS ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS RIGHT TO RECOVER DAMAGES CAUSED BY FAULT OR NEGLIGENCE ON THE PART OF NATIONAL INSTRUMENTS SHALL BE LIMITED TO THE AMOUNT THERETOFORE PAID BY THE CUSTOMER. NATIONAL INSTRUMENTS WILL NOT BE LIABLE FOR DAMAGES RESULTING FROM LOSS OF DATA, PROFITS, USE OF PRODUCTS, OR INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. This limitation of the liability of National Instruments will apply regardless of the form of action, whether in contract or tort, including negligence. Any action against National Instruments must be brought within one year after the cause of action accrues. National Instruments shall not be liable for any delay in performance due to causes beyond its reasonable control. The warranty provided herein does not cover damages, defects, malfunctions, or service failures caused by owners failure to follow the National Instruments installation, operation, or maintenance instructions; owners modification of the product; owners abuse, misuse, or negligent acts; and power failure or surges, fire, flood, accident, actions of third parties, or other events outside reasonable control.
Copyright
Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including photocopying, recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent of National Instruments Corporation. National Instruments respects the intellectual property of others, and we ask our users to do the same. NI software is protected by copyright and other intellectual property laws. Where NI software may be used to reproduce software or other materials belonging to others, you may use NI software only to reproduce materials that you may reproduce in accordance with the terms of any applicable license or other legal restriction.
Trademarks
National Instruments, NI, ni.com, and LabVIEW are trademarks of National Instruments Corporation. Refer to the Terms of Use section on ni.com/legal for more information about National Instruments trademarks. The Bluetooth word mark is a registered trademark owned by the Bluetooth SIG, Inc. Other product and company names mentioned herein are trademarks or trade names of their respective companies. Members of the National Instruments Alliance Partner Program are business entities independent from National Instruments and have no agency, partnership, or joint-venture relationship with National Instruments.
Patents
For patents covering National Instruments products, refer to the appropriate location: HelpPatents in your software, the patents.txt file on your media, or ni.com/patents.
Conventions
The following conventions are used in this manual: The symbol leads you through nested menu items and dialog box options to a final action. The sequence FilePage SetupOptions directs you to pull down the File menu, select the Page Setup item, and select Options from the last dialog box. This icon denotes a tip, which alerts you to advisory information. This icon denotes a note, which alerts you to important information. This icon denotes a caution, which advises you of precautions to take to avoid injury, data loss, or a system crash. This icon denotes a directory path. bold Bold text denotes items that you must select or click in the software, such as menu items and dialog box options. Bold text also denotes parameter names. Italic text denotes variables, emphasis, a cross-reference, or an introduction to a key concept. Italic text also denotes text that is a placeholder for a word or value that you must supply. Text in this font denotes text or characters that you should enter from the keyboard, sections of code, programming examples, and syntax examples. This font is also used for the proper names of disk drives, paths, directories, programs, subprograms, subroutines, device names, functions, operations, variables, filenames, and extensions. Bold text in this font denotes the messages and responses that the computer automatically prints to the screen. This font also emphasizes lines of code that are different from the other examples. Italic text in this font denotes text that is a placeholder for a word or value that you must supply. Text in this font denotes a specific platform and indicates that the text following it applies only to that platform or product.
italic
monospace
monospace bold
monospace italic
Platform
Contents
Chapter 1 Porting LabVIEW to a New Embedded Target PART I Essential Pieces to Porting LabVIEW Chapter 2 Example Targets
Selecting an Appropriate Example Target.....................................................................2-1 System Requirements for Example Targets...................................................................2-3 LabVIEW Directory Hierarchy......................................................................................2-4 Naming Conventions .....................................................................................................2-6 Example Targets..............................................................................................2-6 Plug-In Directories ..........................................................................................2-6 Plug-In VIs ......................................................................................................2-7 Subtargeting ...................................................................................................................2-7 Setting Up the Example Targets ....................................................................................2-8 Axiom CMD565 Example Target ...................................................................2-8 Axiom CMD565, VxWorks Example Target ...................................2-8 Axiom CMD565, eCos Example Target...........................................2-15 Freescale ColdFire, uClinux Example Target .................................................2-19 Installing the uClinux Image for the ColdFire Example Target .......2-20 Setting the MAC Address for the ColdFire Example Target............2-21 Configuring the ColdFire Example Target to Use DHCP or a Static IP Address .........................................................................2-21 Downloading and Installing the Sourcery G++ Lite Edition for the ColdFire Architecture .........................................................2-22 PHYTEC Example Target...............................................................................2-22 PHYTEC Connections ......................................................................2-22 Installing the RedBoot Bootloader....................................................2-24 Using the GNU Toolchain with the PHYTEC Example Target .......2-24 Spectrum Digital DSK6713 Example Target ..................................................2-25 Using the TI Code Composer Studio Toolchain with the DSK6713 Example Target .......................................................2-25 Unix Console and Unix UI Example Targets..................................................2-25 Unicon UCN2410-CWIFI Example Target.....................................................2-26
Contents
vi
ni.com
Contents
Expression Folding Patterns ..........................................................................................5-10 Pattern 1...........................................................................................................5-10 Pattern 2...........................................................................................................5-11 Pattern 3...........................................................................................................5-11 Pattern 4...........................................................................................................5-12 Pattern 5...........................................................................................................5-12 Pattern 6...........................................................................................................5-12 Pattern 7...........................................................................................................5-13 Pattern 8...........................................................................................................5-14 Signal Naming Convention............................................................................................5-14
vii
Contents
Contents
Enumerated Type Controls..............................................................................11-7 Fonts ................................................................................................................11-7 Graphs..............................................................................................................11-8 Plots on Waveform Graphs ...............................................................11-8 Plots on XY Graphs ..........................................................................11-8 Labels ..............................................................................................................11-9 Listboxes..........................................................................................................11-9 Multicolumn Listboxes .....................................................................11-9 Menus ..............................................................................................................11-9 Numeric Controls and Indicators.....................................................................11-9 Path Controls ...................................................................................................11-10 Picture Controls ...............................................................................................11-10 Events................................................................................................11-10 Showing Ampersands (&) in Picture Controls .................................11-11 Refnums...........................................................................................................11-11 Scaling Front Panel Objects ............................................................................11-11 String Controls and Indicators.........................................................................11-12 Using Password Display ...................................................................11-12 Tab Controls ....................................................................................................11-12 Time Stamp Controls and Indicators...............................................................11-13 Minimum and Maximum Time Values.............................................11-13 Editing Modes ...................................................................................11-13 Variant Controls ..............................................................................................11-13 Supported Properties .......................................................................................11-14 Generic Properties.............................................................................11-14 Array Controls and Indicators...........................................................11-14 Boolean Controls and Indicators.......................................................11-15 Cluster Controls ................................................................................11-15 Enumerated Type Controls ...............................................................11-15 Graphs and Charts.............................................................................11-15 Listbox Controls................................................................................11-16 Numeric Controls and Indicators ......................................................11-16 Ring Controls ....................................................................................11-17 String Controls and Indicators ..........................................................11-17 Time Stamp Controls and Indicators ................................................11-17 Waveform Charts ..............................................................................11-18 Waveform Graphs .............................................................................11-18 Supported Methods..........................................................................................11-18 Generic Methods ...............................................................................11-18 Graphs and Charts.............................................................................11-18 String Controls and Indicators ..........................................................11-19 Waveform Graphs .............................................................................11-19 VIs.....................................................................................................11-19 Unsupported Controls and Indicators..............................................................11-19
ix
Contents
ni.com
Contents
Chapter 15 Timing
Using the Target Editor to Define Timing Sources .......................................................15-1 CreateInternalTSource() ..................................................................................15-2 FireInternalTSource() ......................................................................................15-2 DeleteInternalTSource() ..................................................................................15-2 Using the Timed Loop VIs to Define Timing Sources ..................................................15-3
xi
Contents
Implementing the Instrumented Debugging Communication Layer for Your Embedded Target.......................................................................................................................... 17-3 DebugBytes..................................................................................................... 17-4 DebugConnect................................................................................................. 17-4 DebugDisconnect ............................................................................................ 17-5 PrepareConnection .......................................................................................... 17-5 DebugRead...................................................................................................... 17-5 ReleaseConnection.......................................................................................... 17-5 DebugWrite ..................................................................................................... 17-5 Assigning to Function Pointers ....................................................................... 17-6
xii
ni.com
Contents
xiii
Contents
xiv
ni.com
Use the LabVIEW Microprocessor SDK to port LabVIEW to any 32-bit microprocessor. By using a single development tool from concept to finished product, you can ease the development process and increase end quality while reducing time to market. The porting process includes several steps; some steps are required and some steps are optional depending on your target and the features you want to implement and support. The main steps to porting LabVIEW include the following: 1. 2. Obtaining the necessary toolchain and board support package (BSP) for your target. Compiling, downloading, running, and debugging a hello world application using the toolchain and BSP. This step verifies that the necessary toolchain is installed on the host computer and the board support package is installed and configured correctly. Porting the LabVIEW Run-Time Library to the target operating system. Creating and/or modifying the plug-in VIs for basic user actions and target-specific dialog boxes. Adding the target to the LabVIEW development environment.
3. 4. 5.
The actual amount of implementing versus reusing of example targets depends on how closely your target, operating system, and toolchain match one of the example targets, operating systems, and toolchains. While the example targets include common processor architectures, operating systems, and toolchains, the examples targets cannot cover everything.
1-1
Chapter 1
The Microprocessor SDK includes the LabVIEW C Code Generator, which generates C code based on the block diagram when you build an embedded VI into an embedded application. Next, the C code is passed with any external C code and the LabVIEW Run-Time Library through your third-party cross-compiler to create an executable file. This executable file is saved on the host computer. When you download, or deploy, an embedded application, your toolchain downloads the application, usually over serial, TCP, or JTAG. If you run the embedded application, the go command is sent for that application. A basic embedded application runs headless, which means it runs without a user interface, keyboard, mouse, and so on. If your target has an LCD and you implement user interface support, your embedded application might have a user interface. When you debug an embedded application, you create an interactive debug connection back to the host PC, usually over serial, TCP, or JTAG. Part I, Essential Pieces to Porting LabVIEW, contains information about the essential pieces to porting LabVIEW to a new embedded target. Part II, Advanced Porting Implementations, contains information about some advanced porting functionality that might be necessary depending on your target.
1-2
ni.com
Part I
Essential Pieces to Porting LabVIEW
Exactly how you port LabVIEW to a new embedded target depends on your target and functionality. The essential pieces to porting LabVIEW include the following: Selecting one or more example targets, if possible, to use as a starting point to implementing your own target Becoming familiar with important files related to porting, the LabVIEW C Code Run-Time Library, and the LabVIEW Analysis Library Understanding the LabVIEW C Code Generator, code generation attributes, and compiler options Using the Target Editor to create a new target Configuring the target syntax Implementing serial or TCP instrumented debugging Testing your target implementation
Some targets might require additional, advanced porting implementations. Refer to Part II, Advanced Porting Implementations, for more information about advanced functionality.
I-1
Example Targets
The LabVIEW Microprocessor SDK includes several example targets. Use the example targets as a starting point when you create new embedded targets. Example targets are located in the following directory:
labview\Targets\NI\Embedded
2-1
Chapter 2
Example Targets
The following table lists which example targets contain example implementations of different features. Use this table to find an example of a feature you are implementing for your target.
Pre-Built Run-Time Library Static Memory Model
Target Name
Instrumented Debugging
On Chip Debugging
Memory Mapping
Elemental I/O
IDE Integration
UI
Code Generation Only Axiom CMD565, eCos RAM Image Axiom CMD565, eCos ROM Image Axiom CMD565, VxWorks Module Axiom CMD565, VxWorks RAM Image Axiom CMD565, VxWorks ROM Image VxWorks Simulation Freescale ColdFire M5329EVB, uClinux PHYTEC LPC229x, eCos Spectrum Digital DSK6713, DSP/BIOS Unicon UCN2410-CW IFI, Linux
No
No
No
Yes
No
No
No
No
Serial
No
No
Yes
No
No
No
No
No
No
No
Yes
No
No
No
No
Serial
No
Yes
No
No
No
No
No
No
Yes
No
No
No
No
No
No
No
Yes
Yes
No
No
No
TCP TCP
No No
No Yes
Yes No
No No
No No
No No
No No
Serial RTDX
No No
Yes Yes
No No
Yes No
Yes No
No No
No No
TCP
No
Yes
No
No
No
No
Yes
2-2
ni.com
Chapter 2
Example Targets
Target Name
Instrumented Debugging
On Chip Debugging
Memory Mapping
Elemental I/O
IDE Integration
UI
Eclipse No No
No No Yes
No No No
Simulated No Simulated
Eclipse No No
No Yes No
2-3
Chapter 2
Example Targets
Target Name Spectrum Digital DSK6713, DSP/BIOS Unix Console Unix UI Unicon UCN2410-CWIFI, Linux Windows Console Application
Hardware Requirements DSP Starter Kit (DSK) for the TMS320C6713 None None Mobile Development Kit MKit UCN2410-CWIFI None
Software Requirements TI Code Composer Studio 3.1 Cygwin 1.5.x with gcc package Cygwin 1.5.x with gcc package Cygwin 1.5.x, FLTK toolchain
Contact the respective vendors for more information about their hardware and software products. Refer to ecos.sourceware.org/getstart.html for information about downloading and installing eCos. Refer to gcc.gnu.org for information about downloading and installing gcc. The VxWorks for LabVIEW Embedded Development Module Evaluation Kit includes the Tornado 2.2.1 integrated development environment and evaluation run-times for VxWorks 5.5.1 for the purpose of demonstrating the features, performance, and capabilities of these Wind River products in association with the LabVIEW Microprocessor SDK. Refer to windriver.com/alliances/eval-cd, click National Instruments Evaluation CD Program, and follow the instructions to receive the VxWorks for LabVIEW Embedded Development Module Evaluation Kit. Refer to windriver.com for more information about Wind Rivers Device Software Optimization products, including VxWorks real-time operating systems and Tornado, an integrated development environment.
2-4
ni.com
Chapter 2
Example Targets
subdirectories:
analysisContains the LabVIEW Analysis Library source
code.
includeContains the include files for the LabVIEW C Code Run-Time Library. This directory contains several subdirectories, but the os subdirectory is the directory you work with the most.
example targets use. Each subfolder contains only header files. Do not put C files in this directory. Instead, put the associated C files in the labview\CCodeGen\libsrc\os directory.
libsrcContains the same directory structure as the include subdirectory. Like the include subdirectory, this directory contains several subdirectories, but the os subdirectory is the directory you work with the most.
example targets use. Each subfolder contains only C files. Do not put header files in this directory. Instead, put the associated header files in the labview\CCodeGen\ include\os directory.
examplesContains examples. The lvemb subdirectory contains
some examples for working with interrupts and the Inline C Node.
helpContains help files. manualsContains PDF documentation for LabVIEW and any additional modules or toolkits. readmeContains readme files for LabVIEW and any additional modules or toolkits. Targets\NI\EmbeddedContains the target directory folders for
NI embedded targets. The target directory organizes targets into a hierarchy for greater reuse of target implementation code. This hierarchy organizes targets by operating systems. The Microprocessor SDK target implementationswhich contain the plug-in VIs, libraries, helper scripts, and other files required to implement a targetare located in this directory. The target directory hierarchy is OS-centric. The top-level targets are self-contained and do not rely on any subtarget implementations below the top-level target. In contrast, the subtargets reuse and rely on the top-level target implementation.
eioContains Elemental I/O implementations for embedded
targets.
2-5
Chapter 2
Example Targets
Note LabVIEW does not recognize targets outside of the labview\Targets\ company name\Embedded directory. You must create an Embedded subdirectory
under your company name directory when you create your target.
vi.libContains libraries of built-in VIs. The following subdirectories are important when porting LabVIEW:
builds an embedded VI into an embedded application. Use this directory for the VIs you want to add to the Functions palette. Create a subdirectory for your target.
LabVIEW Targets\EmbeddedContains the plug-in VIs and any utility or helper VIs. The VIs in this directory are not on the Functions palette or used by your users.
Naming Conventions
Targets, plug-in directories, and plug-in VIs have the following naming conventions.
Example Targets
National Instruments recommends, but does not require, you follow the same naming convention as the Microprocessor SDK example targets. The example targets have the following naming convention:
Hardware target, OS Hardware Variant
For example, Axiom CMD565, eCos ROM. Do not use underscores in the target name.
Plug-In Directories
Each example operating system contains OS-specific plug-in VIs. The top-level plug-in VI directories have the following naming convention:
labview\Targets\Company Name\Embedded\OS\ OS_LEP_TargetPlugin
2-6
ni.com
Chapter 2
Example Targets
Plug-In VIs
The plug-in VIs have the following naming convention:
LEP_OS_VIName.vi
Subtargeting
Some example operating systems contain multiple example targets. Example targets using these operating systems use the top-level plug-in VIs plus target-specific plug-in VIs. For example, the PHYTEC and Axiom CMD565 example targets use the eCos operating system. Those example targets use the plug-in VIs in the labview\Targets\NI\Embedded\ ecos\ecos_LEP_TargetPlugin directory plus target-specific plug-in VIs, which are in a target-specific subdirectory. These target-specific plug-in VIs might implement target-specific functionality or override OS functionality the top-level plug-in VIs implement. The top-level targets are self-contained and do not rely on any subtarget implementations below the top-level target. In contrast, the subtargets rely on the top-level target implementation. For example, the PHYTEC-specific plug-in VIs are in the following directory:
labview\Targets\NI\Embedded\ecos\phytec_lpc229x\ecos_Phytec_LPC229x_LEP_ TargetPlugin
The Axiom CMD565-specific plug-in VIs use the following naming convention:
LEP_ecos_cmd565_Build.vi
2-7
Chapter 2
Example Targets
2-8
ni.com
Chapter 2
Example Targets
PWR
COM-1 ON
1 2 3 4 5 6
COM-2
MCP565 TESTBOARD II
COM_SW ON
1 2 3 4 5 6 7 8
MAP_SW ON
1 2 3 4 5 6 7 8
ON
1 2 3 4 5 6 7 8
MODE_SW2 ON
1 2 3 4 5 6 7 8
MODE_SW3 ON
1 2 3 4 5 6 7 8
MODE_SW4 CFG_EN
2. 3.
Connect COM 1 to the available COM port on the host machine using a straight cable. A NULL modem cable does not work. Launch AxIDE or another communication program, Tera Term for example, and open a connection to the serial port. The communication settings are 9600, 8, 1, N. Power on the Axiom board. The Axiom Monitor appears.
4.
2-9
Chapter 2
Example Targets
5. 6. 7. 8. 9.
Press the <3> key to download to the external flash memory. Press the <2> key to select external flash on CS2. Press the <5> key to erase the external flash array. Press the <6> key to program the external flash array. Press the Upload button. Navigate to and run the following file. It takes a few minutes to program the external flash memory.
labview\Targets\NI\Embedded\vxworks\cmd565\bin\vxWorks_rom Resident.S19
10. Power off the Axiom board and configure the board as shown in the following figure.
2-10
ni.com
Chapter 2
Example Targets
PWR
COM-1 ON
1 2 3 4 5 6
COM-2
MCP565 TESTBOARD II
COM_SW ON
1 2 3 4 5 6 7 8
MAP_SW ON
1 2 3 4 5 6 7 8
ON
1 2 3 4 5 6 7 8
MODE_SW2 ON
1 2 3 4 5 6 7 8
MODE_SW3 ON
1 2 3 4 5 6 7 8
MODE_SW4 CFG_EN
11. Power on the Axiom board. The VxWorks logo appears on the terminal. The board is configured and ready to use. 12. Run an example application to verify the setup. Refer to the Running a VxWorks Example Application section for more information about how to run an example application.
2-11
Chapter 2
Example Targets
2-12
ni.com
Chapter 2
Example Targets
PWR
COM-1 ON
1 2 3 4 5 6
COM-2
MCP565 TESTBOARD II
COM_SW ON
1 2 3 4 5 6 7 8
MAP_SW ON
1 2 3 4 5 6 7 8
ON
1 2 3 4 5 6 7 8
MODE_SW2 ON
1 2 3 4 5 6 7 8
MODE_SW3 ON
1 2 3 4 5 6 7 8
MODE_SW4 CFG_EN
2. 3.
Connect COM 1 to the available COM port on the host machine using a straight cable. A NULL modem cable does not work. Launch AxIDE or another communication program, Tera Term for example, and open a connection to the serial port. The communication settings are 9600, 8, N, 1, N. Power on the Axiom board. The Axiom Monitor appears.
4.
2-13
Chapter 2
Example Targets
5. 6. 7. 8. 9.
Press the <2> key to download to the internal flash memory. Press the <E> key to erase the internal flash array. Press the <P> key to program the internal flash array. Press the Upload button. Power off and configure the Axiom board as shown in the following figure. Change the communication speed of the terminal program to 57,600 bps.
PWR
COM-1 ON
1 2 3 4 5 6
COM-2
MCP565 TESTBOARD II
COM_SW ON
1 2 3 4 5 6 7 8
MAP_SW ON
1 2 3 4 5 6 7 8
ON
1 2 3 4 5 6 7 8
MODE_SW2 ON
1 2 3 4 5 6 7 8
MODE_SW3 ON
1 2 3 4 5 6 7 8
MODE_SW4 CFG_EN
2-14
ni.com
Chapter 2
Example Targets
3. 4. 5. 6. 7.
2-15
Chapter 2
Example Targets
Complete the following steps to download to the internal flash array. 1. Configure the board as shown in the following figure. This is the default configuration that allows you to start the Axiom Monitor. Verify that CONFIG SWITCH 5 and 6 are set to ON to enable the internal flash array.
PWR
COM-1 ON
1 2 3 4 5 6
COM-2
MCP565 TESTBOARD II
COM_SW ON
1 2 3 4 5 6 7 8
MAP_SW ON
1 2 3 4 5 6 7 8
ON
1 2 3 4 5 6 7 8
MODE_SW2 ON
1 2 3 4 5 6 7 8
MODE_SW3 ON
1 2 3 4 5 6 7 8
MODE_SW4 CFG_EN
2-16
ni.com
Chapter 2
Example Targets
2.
Launch AxIDE or another communication program, Tera Term for example, and open a connection to the serial port. The communication settings are 9600, 8, N, 1, N. Power on the Axiom board. The Axiom Monitor appears. Press the <2> key to download to the internal flash memory. Press the <E> key to erase the internal flash array. Press the <P> key to program the internal flash array. Press the Upload button. Navigate to and run labview\Targets\NI\Embedded\ecos\ cmd565\bin\redboot.s19. Power off and configure the Axiom board. Change the communication speed of the terminal program to 57,600 bps.
3. 4. 5. 6. 7. 8. 9.
10. Power on the Axiom board. The RedBoot monitor appears. 11. Run an example application to verify the setup.
2-17
Chapter 2
Example Targets
PWR
COM-1 ON
1 2 3 4 5 6
COM-2
MCP565 TESTBOARD II
COM_SW ON
1 2 3 4 5 6 7 8
MAP_SW ON
1 2 3 4 5 6 7 8
ON
1 2 3 4 5 6 7 8
MODE_SW2 ON
1 2 3 4 5 6 7 8
MODE_SW3 ON
1 2 3 4 5 6 7 8
MODE_SW4 CFG_EN
2. 3.
Connect COM 1 to the available COM port on the host machine using a straight cable. A NULL modem cable does not work. Launch AxIDE or another communication program, Tera Term for example, and open a connection to the serial port. The communication settings are 9600, 8, N, 1, N. Power on the Axiom board. The Axiom Monitor appears. Press the <2> key to download to the internal flash memory.
2-18 ni.com
4. 5.
Microprocessor SDK Porting Guide
Chapter 2
Example Targets
6. 7. 8. 9.
Press the <E> key to erase the internal flash array. Press the <P> key to program the internal flash array. Press the Upload button. Power off and configure the Axiom board. Change the communication speed of the terminal program to 57,600 bps.
3. 4. 5. 6. 7.
2-19
Chapter 2
Example Targets
2.
3.
Use a USB cable to connect the USB-ML-CF emulator to the M5329EVB board and the host computer. The emulator is included with the M5329EVB board. Windows should recognize the emulator and install the necessary drivers. Power on the evaluation board. Select ProgramsCF Flasher 3.1 to launch CF Flasher. Refer to the CF Flasher documentation for more information about using CF Flasher. Click the Target Config button in the CF Flasher main dialog box to open the Target Configuration dialog box. Select M5329EVB from the Target Configuration list. Select PE_USB_ML from the BDM Communication list. Click the OK button to close the Target Configuration dialog box.
4. 5.
6. 7. 8. 9.
10. Click the Program button. 11. Unzip m5329evb.zip, located in the labview\Targets\NI\ Embedded\unix\m5329evb\bin\ directory, to a temporary location. 12. Navigate to and select m5329evb.bin. 13. When you are prompted for the start address, enter 0 and click the OK button. 14. Click the Program button.
Note
2-20
ni.com
Chapter 2
Example Targets
2-21
Chapter 2
Example Targets
Downloading and Installing the Sourcery G++ Lite Edition for the ColdFire Architecture
You must download and install the ColdFire uClinux version of the Sourcery G++ Lite Edition, which is the CodeSourcery version of the GNU toolchain, from the CodeSourcery Web site at www.codesourcery.com/gnu_toolchains/coldfire.
The PHYTEC example target uses the following hardware: phyCORE-ARM7/LPC229x Rapid Development Kit (Part Number KPCM-023-SK-2294) GPIO (General Purpose Input/Output) Expansion Board (Part Number PCM-989)
Refer to the PHYTEC Web site at www.phytec.com for more information about PHYTEC hardware.
PHYTEC Connections
You must establish the following connections on the expansion board between the I/O connector and Patch Field pins to use this target with the Microprocessor SDK.
Note
The LPC2294 Function column in the following table is the function to select when you configure the pin in software. Refer to the LPC2119/2129/2194/2292/2294 User Manual, available from the NXP Web site at www.nxp.com, for information about how to configure the pins.
2-22
ni.com
Chapter 2
Example Targets
Description LED 1 LED 2 LED 3 LED 4 LED 5 LED 6 LED 7 LED 8 DIP switch 0 DIP switch 1 DIP switch 2 DIP switch 3 KEY 4 (red) KEY 5 (blue) KEY 6 (black) Motor A Motor count AIN 0 AIN 1 AIN 2 VDD 3.3 V VDD 3.3 V
LPC2294 Function GPIO P1.16 (0) GPIO P1.17 (0) GPIO P1.18 (0) GPIO P1.19 (0) GPIO P1.20 (0) GPIO P1.21 (0) GPIO P1.22 (0) GPIO P1.23 (0) GPIO P0.10 (0) GPIO P0.11 (0) GPIO P0.12 (0) GPIO P0.13 (0) EINT1 (2) EINT2 (2) EINT3 (3) PWM5 (1) CAP1.2 (1) AIN0 (1) AIN1 (1) AIN2 (1) 8F 9E
Patch Field
I/O Connector LED IN 1 LED IN 2 LED IN 3 LED IN 4 LED IN 5 LED IN 6 LED IN 7 LED IN 8 Switch OUT 1 Switch OUT 2 Switch OUT 3 Switch OUT 4 /KEY OUT 4 /KEY OUT 5 /KEY OUT 6 MOT IN A (1) Count Out (3) Poti OUT 1 Poti OUT 2 Poti OUT 3 VCC VPoti
10C 10E 10B 11A 14A 14E 4F 5A 5C 5E 28B 28F 29A 8B 8D 17A 16F 16B 1A 1C
2-23
Chapter 2
Example Targets
labview\Targets\NI\Embedded\ecos\phytec_lpc229x\libs\redboot
4. 5. 6. 7.
Select LPC2294, XTAL Freq. [kHX]: 10000 from the Device list, which is the serial port on the host computer. Select 9600 from the Use Baud Rate list. Click the Upload to Flash button. On the board, press the Boot button to start the In-System Programmer (ISP) while you press the Reset button to reset the board.
Refer to the documentation on the PHYTEC CD that comes with the Rapid Development Kit for more information about writing the RedBoot bootloader.
If you do not install the toolchain into one of these directories, you must add the location to the Windows SYSTEM path variable.
2-24
ni.com
Chapter 2
Example Targets
Using the TI Code Composer Studio Toolchain with the DSK6713 Example Target
The Spectrum Digital DSK6713 uses the TI Code Composer Studio toolchain. Install Code Composer Studio from the CD in the DSP Starter Kit. Refer to the DSP Starter Kit (DSK) for the TMS320C6713 (16 Mb) Quick Start Installation Guide on the CD for hardware installation and set up instructions. The quick start guide is available with the DSP Starter Kit. If you install Code Composer Studio in the default location, refer to c:\CCStudio\docs\pdf\manuals_ccs_full_c6000.html for a complete list of related documentation, including how to set-up Code Composer Studio. If you install Code Composer Studio somewhere other than c:\CCStudio_v3.1, which is the default location, you must change the Compiler path and the Linker path in the Build Specification Properties dialog box for every LabVIEW project you create that uses the Code Composer Studio toolchain.
To use the Unix UI example target, you also must install the following GNU libraries: libjpeg-devel 6b-12 libjpeg62 6b-12 libpng12-devel version 1.2.12-x libpng12 1.2.12-x
2-25
Chapter 2
Example Targets
Refer to the Cygwin Web site at www.cygwin.com for download and installation instructions.
the following Cygwin GNU tools: 2. a. b. 3. binutils 20060817-1 or later gcc 3.4.4 or later gdb 20060706-2 or later make 3.81 or later Unzip the file to cygwin\opt\ where cygwin is where you installed Cygwin. This step creates an arm-linux-tools folder. Edit the Windows system PATH variable to include cygwin\opt\arm-linux-tools\bin.
Launch your terminal program and set the following serial port settings: Bits per second = 115200 Data bits = 8 No parity Stop bits = 1 No flow control
4. 5. 6. 7. 8. 9.
Plug in the hardware. The login prompt ucn-2410 login: appears after the hardware boots. Type root and press the <Enter> key. Leave the password blank and press the <Enter> key. At the ~# prompt, type cd /tmp and press the <Enter> key. At the /var/tmp # prompt, type rx lvprep.sh and press the <Enter> key. Using your terminal application, send the labview\Targets\NI\ Embedded\linux\UCN2410\drivers\lvprep.sh file using the Xmodem protocol.
2-26
ni.com
Chapter 2
Example Targets
10. Type rx lvprep.tgz and press the <Enter> key. 11. Using your terminal application send the labview\Targets\NI\ Embedded\linux\UCN2410\drivers\lvprep.tgz file using the Xmodem protocol. 12. Type chmod +x lvprep.sh and press the <Enter> key. 13. Type lvprep.sh and press the <Enter> key. lvprep.sh unpacks lvprep.tgz and makes the necessary symbolic links and file changes. 14. Type reboot and press the <Enter> key to reboot the board. The ucn-2410 login: prompt appears when the board completes rebooting. 15. Unplug and replug the USB cable so Windows recognizes the USB device. 16. Follow the instructions in the Microsoft Windows Hardware Update Wizard to install the driver located in the labview\Targets\NI\ Embedded\linux\UCN2410\drivers directory.
Note
Ignore the warning that the driver is not signed by Microsoft. 17. The USB connection to the board appears as a local network connection in Windows, so you must set an IP address for the network connection. Use the following IP addresses: Host IP address = 192.168.1.100 Subnet mask = 255.255.255.0 Default gateway = 192.168.1.100 (same as Host IP address)
By default, LabVIEW sets the board IP address, which is 192.168.1.1, in the Target Properties dialog box.
Note
If you want to set a password for the board, set the password on the board first and then add it to LabVIEW in your Target Properties dialog box.
2-27
How to port LabVIEW to a target is very target-specific, but you must be aware of and modify some important files that are fundamental to porting LabVIEW to a new target.
Plug-In VIs
Plug-in VIs customize the compiling and linking process, which include implementing basic user actions and target-specific dialog boxes. Refer to the target plug-in directories for different plug-in VI implementation examples.
These basic user actions build on one another. For example, if you download an application that is not built, LabVIEW builds the application before downloading it. If you run an embedded application that has not been downloaded, LabVIEW downloads the application before running it, and so on.
LEP_x_Build.vi is the main plug-in VI that implements the build user
action. This plug-in VI performs the following: Loads project configuration information. Creates the build folder on the host computer. Prepares the list of libraries, include directories, and source files for LEP_x_ScriptCompiler.vi and LEP_x_ScriptLinker.vi.
3-1
Chapter 3
Calls LEP_x_ScriptCompiler.vi to compile the source files into an object file. Calls LEP_x_ScriptLinker.vi to link the project libraries and the object files into an embedded application.
LEP_x_Run.vi is the main plug-in VI that implements the run user action.
Some example targets use different filenames for the plug-in VIs and some might contain additional or different plug-in VIs.
Some example targets use a different filename for the Target Properties dialog box and some do not contain any target properties at all.
LEP_x_ScriptCompiler.vi
LEP_x_ScriptCompiler.vi, where x is a subtarget and/or an OS, scripts your toolchain compiler and passes the compiler directives to the compiler from the command line. LEP_x_ScriptCompiler.vi is located in the following directory: labview\Targets\company_name\Embedded\os\os_LEP_TargetPlugin
where os is the target operating system. Some example targets include the target name in the subdirectory. You must implement LEP_x_ScriptCompiler.vi if you require behavior that differs from the default implementation. Use the base target default implementation of LEP_x_ScriptCompiler.vi for your OS and override only the necessary features. To override the default
3-2
ni.com
Chapter 3
implementation, wire an LEP_x_ScriptCompiler.vi VI reference to the Compiler Script input of LEP_x_Build.vi. Your custom implementation of LEP_x_ScriptCompiler.vi must have the same connector pane as the default implementation.
LEP_x_ScriptCompiler.vi can execute the C compiler directly by
calling the System Exec VI. You also can use a batch file to execute the compiler directly. Use a batch file if you need to set compiler-specific system variables before the compiler can execute. For example, the VxWorks example targets use a batch file because you must set the Tornado system variables before the C compiler executes.
This custom implementation overrides the default implementation of LEP_vxworks_ScriptCompiler.vi, LEP_vxworks_ScriptLinker.vi, and LEP_vxworks_Config.ctl. Notice the Case structure with target-specific VIs in this custom implementation. The VIs in the Case structure never execute, but are always loaded into memory. Because the VIs are loaded into memory, the Open VI Reference function can refer to VIs by name instead of absolute path. The VxWorks and eCos example targets do not have pre-compiled run-time libraries, so you must compile the run-time source files along with the generated and external C files.
LEP_x_ScriptLinker.vi
LEP_x_ScriptLinker.vi, where x is a subtarget and/or an OS, links all
intermediate object files, external libraries, run-time libraries, and operating system libraries into an embedded application. LEP_x_ScriptLinker.vi is located in the following directory:
labview\Targets\company_name\Embedded\os\os_LEP_TargetPlugin
3-3
Chapter 3
You must implement LEP_x_ScriptLinker.vi if you require behavior that differs from the default implementation. Use the base example target default implementation for your OS of LEP_x_ScriptLinker.vi and override only the necessary features. To override the default implementation, wire an LEP_x_ScriptLinker.vi VI reference to the LinkerScript input of LEP_x_Build.vi. Your custom implementation of LEP_x_ScriptLinker.vi must have the same connector pane as the default implementation. Some example targets avoid long command lines by using prjObjs.lst to obtain a list of all modules. LEP_x_Build.vi generates prjObjs.lst and lists all binary modules and libraries.
Note LEP_x_ScriptLinker.vi can execute the C linker directly by calling the System Exec VI. You also can use a batch file to directly execute the linker. Use a batch file if you need to set linker-specific system variables before the linker can execute. For example, the VxWorks example targets use a batch file because you must set the Tornado system variables before the C compiler executes.
This custom implementation overrides the default implementation of the LEP_vxworks_ScriptCompiler.vi, LEP_vxworks_ScriptLinker.vi, and LEP_vxworks_Config.ctl. Notice the Case structure with target-specific VIs in this custom implementation. The VIs in the Case structure never execute but are always loaded into memory. Because the VIs are loaded into memory, you can use the Open VI Reference function to refer to VIs by name instead of absolute path. VxWorks module targets do not link with the operating system libraries because the VxWorks module loader resolves all symbols. The VxWorks and eCos example targets do not have pre-compiled run-time libraries, so LEP_vxworks_cmd565_ScriptLinker.vi also must link with the run-time library intermediate files.
3-4
ni.com
Chapter 3
LVDefs_plat.h
LVDefs_plat.h contains basic constants and macros the LabVIEW
C Code Generator needs to generate C code. This file provides the mapping between generic function calls the LabVIEW C Generator generates to OS-specific run-time functions. It also contains platform defines for data types and feature flags that define which features are implemented for an OS. Each OS has a separate LVDefs_plat.h file, so if your OS matches one of the example operating systems, you do not need to create this file. LVDefs_plat.h is located in OS-specific folders in the following directory:
labview\CCodeGen\include\os\
lvEmbeddedMain.c
lvEmbeddedMain.c contains the main entry point for all applications the
LabVIEW C Code Generator generates. This file contains functions that perform set up and tear down of common pieces, such as occurrences and FIFOs. lvEmbeddedMain.c uses #ifdefs rather than separate files for each OS. The main function in lvEmbeddedMain.c initializes all global variables and then calls the top-level VI in the project. After the top-level VI has completed, a shutdown routine is completed. The following two macros define the initialization and shutdown routines:
LV_PLATFORM_INIT LVPLATFORM_FINI
You define these macros per target rather than per operating system. The labview\CCodeGen\libsrc\os folder hierarchy does not define LV_PLATFORM_INIT and LV_PLATFORM_FINI because a one-to-one mapping does not exist between operating systems and targets. For example, an eCos target on a Nintendo Gameboy Advanced device needs a certain LV_PLATFORM_INIT to set up the hardware, but an eCos target on the CMD565 does not. If you define LV_PLATFORM_INIT as a function, LV_PLATFORM_INIT is called before calling any VI and before performing any other setup. The target defines this function and you can implement it in any way that is appropriate for your target. If you define LV_PLATFORM_FINI as a function, LV_PLATFORM_FINI is called after all VIs have finished and any other tear down is complete.
National Instruments Corporation 3-5 Microprocessor SDK Porting Guide
Chapter 3
LVSysIncludes.h
LVSysIncludes.h is a list of header files for a target OS. Depending on the target OS, LVSysIncludes.h contains OS-specific header files,
toolchain-specific header files, and standard C header files. All but a few files in the labview\CCodeGen directory include this file. Each OS has a separate LVSysIncludes.h file, so if your OS matches one of the example operating systems, you do not need to create this file. LVSysIncludes.h is located in OS-specific folders in the following directory:
labview\CCodeGen\include\os\
TgtSupp.xml
TgtSupp.xml is the file LabVIEW uses to integrate your target into the
LabVIEW development environment. This target-specific file defines the target name, icons, and which plug-in VIs implement the basic user actions and menu items. Use the Target Editor to generate and modify the TgtSupp.xml file. Refer to Chapter 7, Creating a New Embedded Target, for more information about using the Target Editor.
TargetSyntax.xml
TargetSyntax.xml is the file LabVIEW uses to configure target syntax,
which determines the supported and unsupported features for a target. Use the Configure Target Syntax dialog box to create and modify the TargetSyntax.xml file. Refer to Chapter 8, Configuring the Target Syntax, for more information about configuring the target syntax for your target.
3-6
ni.com
The Microprocessor SDK includes the source code for the LabVIEW C Code Run-Time Library and the Analysis Library. Your target directory must include the LabVIEW C Code Run-Time and Analysis Libraries. Most of the example targets use a makefile to build the libraries. The Windows Console example target uses a Visual Studio project. Some example targets have prebuilt libraries while some targets build the libraries when you build an embedded VI into an embedded target. If you copy and rename an existing embedded target, LabVIEW relinks the LabVIEW C Code Run-Time and Analysis Libraries for your target.
4-1
Chapter 4
If you are porting LabVIEW to a new operating system, you must implement the necessary OS-specific components and be familiar with the LabVIEW C Code Run-Time Library #defines and feature flags. Refer to Chapter 13, Porting the LabVIEW C Code Run-Time Library to a New Platform, for more information about porting the LabVIEW C Code Run-Time Library to a new platform.
Analysis Library
To port the LabVIEW Analysis Library, you must have a C++ compiler that supports the C++ Standard Template Library (STL). Also, your target must support floating-point operations either natively or though an emulator library to support the LabVIEW Analysis Library. Look for an OS similar to your target OS and search the #ifdefs for that OS. Most of the porting work is done in the platdefines.h include file located in the following directory:
labview\CCodeGen\analysis\development\include
You can port the LabVIEW Analysis Library with or without BLAS/LAPACK, which is a set of highly optimized, open source math functions widely used in industry and academia. The Microprocessor SDK does not include BLAS/LAPACK because BLAS/LAPACK makes analysis functionality very large. BLAS/LAPACK is more appropriate for desktop PCs where large amounts of memory are available. Parts of the LabVIEW Analysis Library depend on BLAS/LAPACK, so define COMPILE_FOR_SMALL_RT to remove BLAS/LAPACK support. Most of the example targets define COMPILE_FOR_SMALL_RT in the makefile used to build the libraries. The Windows Console example target uses a Visual Studio project. The following directory contains the LabVIEW Analysis Library source code to convert LabVIEW data types to C data types:
labview\CCodeGen\analysis\LV\source
4-2
ni.com
Chapter 4
The C++ code in the LabVIEW Analysis Library does not use constructors and destructors. Ignore the peak detector and pulse duration functions because these functions assume LabVIEW internals that only apply to LabVIEW for Windows. The peak detector and pulse duration functions will crash and do not work on embedded targets. You also must set the following #defines:
LV_Embedded=1 NoFFTtablePersist=1 LVANALYSIS=1 ThreadsUsed=0 COMPILE_FOR_SMALL_RT=1 Note
The LabVIEW Analysis Library has some thread-safe guards that require more support functions, but thread-safe guards are not implemented. The LabVIEW Analysis Library relies on LabVIEW.lib, which is another library that you must build. LabVIEW.lib provides an interface between the LabVIEW C Code Run-Time Library and the LabVIEW Analysis Library. The source for the LabVIEW.lib source is located in the following file and contains functions for memory management and resizing of arrays.
labview\CCodeGen\libsrc\lvanalysis\arrresize.c
4-3
The LabVIEW C Code Generator, which is a component of the Microprocessor SDK, creates ANSI C code from a LabVIEW block diagram. You also can add pre-existing C code you might have. When you build a block diagram into an embedded application, LabVIEW traverses the block diagram and generates simple C primitives if possible. For example, the LabVIEW C Code Generator converts While Loops to while() statements and converts the Add function to a simple C operation. However, a straight mapping is not possible for more complex functions so the LabVIEW C Code Generator uses the LabVIEW C Run-Time Library, which is analogous to the LabVIEW Run-Time Engine in LabVIEW for Windows. An important part of porting LabVIEW to a new target involves porting the LabVIEW C Run-Time Library, which contains such things as communication, data manipulation, timing functions, and so on. The Microprocessor SDK includes the source code for the LabVIEW C Run-Time Library. The code that the LabVIEW C Code Generator generates passes through a cross-compiler. If you add pre-existing C code, the extra C files you provide also pass through the cross-compiler and are linked into an executable you can run on the embedded device, which is called a target in LabVIEW. You implement how this executable downloads, or deploys, to the correct memory location and begins running on the embedded target through standard communication protocols. JTAG emulator, RS-232, and Ethernet are common ways to handle the communication between LabVIEW and an embedded target, but you can use other communication protocols. Code generation options define how the LabVIEW C Code Generator generates C code. A VI Server call translates the VI hierarchy into C code. The LabVIEW C Code Generator generates each VI in the VI hierarchy into a separate C file using a C function name, which is more restrictive than a VI name, when a user builds an embedded VI into an embedded application. Any non-alphanumeric characters become underscores. If the VI name begins with a non-alphanumeric character, the LabVIEW C Code Generator prepends A_ to the beginning of the C function name.
5-1
Chapter 5
This VI Server call also generates the following header files when a user builds an embedded VI into an embedded application.
LVForms.h contains declarations for the entry point functions for
each VI.
LVGlobs.h contains declarations for global initialization functions
dead stripping.
LVDebugTable.h contains lookup information for serial, TCP/IP, and
CAN debugging. The input to this VI Server call is a variant that contains attributes (name, value pairs) that determine how the LabVIEW C Code Generator generates the C code from the block diagram. Any attributes you do not set use the default value. Many attributes determine how LabVIEW generates the C code. Most of the attributes are optimizations that make the generated C code smaller and run faster. The generated C code might differ in behavior from VIs you create under the My Computer target, which runs on Windows. Refer to the Code Generation Attributes section for information about the different attributes.
Note This VI Server call is licensed. The user must have a valid, activated Microprocessor SDK license to generate C code for the target you are creating.
BigEndian
Type: Boolean Default: FALSE
5-2
ni.com
Chapter 5
Specifies if a platform is big endian or little endian. The LabVIEW C Code Generator must know if a platform is big endian or little endian to generate C code in byte form for compound data.
DestinationFolder
Type: Path Default: <empty path> Indicates where you want the LabVIEW C Code Generator to save the generated C files. If the IncrementalBuild attribute is FALSE, LabVIEW overwrites any C files in the destination directory with the same name as VIs in the embedded VI.
ExpressionFolding
Type: Boolean Default: FALSE Generates better performing and more efficient code by collapsing groups of nodes into single expressions that most C compilers recognize. You cannot debug an embedded VI while using expression folding because expression folding eliminates some of the wires in the generated code. If you overrun the bounds of an array or divide by zero, the embedded application might crash. Refer to the Expression Folding Patterns section for a list of the patterns the LabVIEW C Code Generator recognizes.
GenerateCFunctionCalls
Type: Boolean Default: FALSE Determines the calling interface to subVIs if you set GenerateSerialOnly to TRUE. The LabVIEW C Code Generator uses default data when generating the calling interface to a subVI if an input to or output from the subVI is unwired, which increases the overall amount of generated code and data for a VI relative to what you might use in a normal C application. If all of the inputs and outputs are wired, the LabVIEW C Code Generator does not need the default data and can generate a more efficient interface.
5-3
Chapter 5
Set this attribute to TRUE to generate the interface to all VIs as C function calls without any default data initialization, which can reduce the code size by as much as 50% for a small VI. An error occurs if any input or output to any VI is unwired when the LabVIEW C Code Generator generates the C code. If you set GenerateCFunctionCalls to TRUE, you also must set GenerateSerialOnly to TRUE.
GenerateDebugInfo
Type: Boolean Default: FALSE Enables instrumented debugging and adds the necessary extra code to debug over serial, Ethernet, or CAN protocols if you set this attribute to TRUE. The extra code contains function calls that update the application state and communicate the state to the host computer for display. Setting this attribute to TRUE usually results in a 25%40% increase in code size. You cannot use the GenerateCFunctionCalls attribute with GenerateDebugInfo.
GenerateGuardCode
Type: Boolean Default: TRUE Determines whether to generate guard code. Guard code prevents a user from making common mistakes that can cause an application to crash. For example, guard code can prevent dividing by zero and indexing out of range in an array. Guard code makes an application slightly larger and slower so you are trading performance for reliability. Set this attribute to FALSE to not generate guard code, which makes the code smaller and faster but less safe and more likely to crash because of user programming mistakes. The following LabVIEW functions use guard code: All floating-point arithmetic operations Compound Arithmetic Index Array Quotient & Remainder Replace Array Subset
5-4
ni.com
Chapter 5
GenerateInlinePrintf
Type: Boolean Default: FALSE Indicates you want to use the C run-time library function printf if it is available for your target. For example, the Format Into String function in LabVIEW is implemented completely in the LabVIEW C Code Run-Time Library to support LabVIEW data types. However, if you use only integer, floating-point, or Boolean data, you can use the C library function printf instead. Set this attribute to TRUE to use printf when possible. The LabVIEW C Code Generator uses the LabVIEW C Code Run-Time library implementation if you cannot use printf. The printf function is usually smaller and faster than the LabVIEW C Code Run-Time Library version for simple data types.
GenerateIntegerOnly
Type: Boolean Default: FALSE Generates C code that does not have any floating-point declarations or operations if the block diagram does not contain any floating-point data types. You can link the generated code with a run-time library you compile with the _Integer_Only flag set to produce applications that run without hardware or software floating-point support.
GenerateLibraryInterface
Type: Boolean Default: FALSE Generates additional code so that external, non-VI code can call the VIs as if the VIs are library functions. This attribute is supported only for strings, 1D arrays, and flat clusters, which are clusters that contain only scalars. For example, you cannot use a cluster that contains a string. The LabVIEW C Code Generator generates a C function interface for each VI, which configures the inputs and calls the normal LabVIEW VI interface. The C function name is the same as the VI name unless the VI name contains a disallowed character, such as a space, in the filename. Underscores replace disallowed characters. The VI behaves the same as a VI running under the My Computer target, which runs on Windows, by
5-5
Chapter 5
using default data if any input or output is null. A header file is created that contains all of the function prototypes for the VIs that can be included where they are called. The header file has the same name as the top-level VI appended with Lib.h. Inputs are passed by value except structs, which are passed by address. A size parameter for both inputs and outputs follows the array and string parameters. For an array, the size is the total number of elements in the array. For a string, the size is the length of the string. If you pass in a multi-dimensional array, it is copied into an internal array with the LabVIEW data type determining the number of dimensions. All of the dimension sizes are set to 1 except for the innermost dimension, which is equal to the size passed in from internal data. For an output array, the data is block copied to the output up to the specified size limit. The easiest way to pass arrays is as 1D arrays that get reshaped as necessary on the block diagram.
GenerateSerialOnly
Type: Boolean Default: FALSE Determines whether to generate cooperative multitasking code. The default generated C code has the same execution behavior as LabVIEW VIs running under the My Computer target, which runs on Windows. For example, parallel While Loops run in parallel. However, the LabVIEW C Code Generator generates code that uses cooperative multitasking in a single thread. Additional threads are used only by Timed Loops. The generated C code is difficult to read and does not resemble human-written C code. Set this attribute to TRUE if you do not want to generate the cooperative multitasking code. The code is easier to read and usually runs much faster without the cooperative multitasking code. However, you lose the parallel execution behavior. Parallel While Loops execute in sequence with one While Loop executing only after the other While Loop completely finishes. This execution behavior most closely resembles subroutine priority VIs in LabVIEW Windows VIs. If you set the priority of an individual VI to subroutine on the Execution page on the VI Properties dialog box, the LabVIEW C Code Generator generates C code for serial only execution regardless of the value of GenerateSerialOnly. Setting GenerateSerialOnly to TRUE causes the LabVIEW C Code Generator to generate the C code for all VIs in the VI hierarchy as if all VIs are subroutine priority VIs. The main difference between the subroutine
5-6
ni.com
Chapter 5
priority setting in the VI Properties dialog box and the GenerateSerialOnly attribute is that subroutine Windows VIs do not allow asynchronous functions. Ordinary VIs that generate C code with GenerateSerialOnly set to TRUE can contain asynchronous functions, which the LabVIEW C Code Generator turns into synchronous functions and does not return to the caller until complete. TCP Read is an example of an asynchronous function.
Note
If you set UseStackVariables or GenerateCFunctionCalls to TRUE, you also must set GenerateSerialOnly to TRUE.
IncrementalBuild
Type: Boolean Default: FALSE Indicates whether to rebuild all files the LabVIEW C Code Generator generates every time a change is made or to rebuild just the files that changed. Set this attribute to TRUE to overwrite only the C files that are older than the VIs from which they are generated during code generation. For example, if MyProg.vi has a modification date that is more recent than MyProg.c, the LabVIEW C Code Generator rebuilds and overwrites the C file. Use incremental builds if you want to write and combine large applications with a makefile build process that does not rebuild everything every time a minor change is made.
Note If the VIs are in a .llb the LabVIEW C Code Generator regenerates all of the VIs in the .llb if any of the VIs in the .llb change.
interruptServiceRoutineVIs
Type: Path array Default: <empty array> Lists the VIs that are interrupt service routine (ISR) VIs, which are very specialized and restrictive VIs for use as interrupts. The Microprocessor SDK does not support the ability to set a flag in a VI indicating that the VI is an ISR VI. You must implement support for ISRs. Refer to Chapter 14, Implementing Interrupt Service Routine Support, for more information about implementing ISR support.
5-7
Chapter 5
MemoryModel
Type: Integer (0 = dynamic, 1 = static) Default: 0 Defines whether you are using a dynamic or static memory model. DynamicMemory is allocated and then freed as soon as possible, which keeps the memory use at any one time to a minimum. Memory management overhead might result in some jitter and reduced performance, but applications with a dynamic memory model have the smallest footprint possible. StaticNo memory allocation occurs while the application is running. All variables are declared as static in the generated C code and allocated prior to the main entry point. Static memory can provide good performance and low jitter, but static memory models might require more memory than other memory models. Refer to Chapter 22, Static Memory Allocation, for more information about supporting a static memory model.
OCDIComments
Type: Boolean Default: FALSE Determines whether to generate extra comments necessary for OCDI debugging. The LabVIEW C Code Generator places extra comments in the generated C code to help figure out where certain items, such as wires and nodes, are in the generated C code during OCDI debugging. These comments make the generated C code harder to read. Use this attribute to turn off these comments when you do not need them. Refer to Chapter 18, On Chip Debugging, for more information about implementing OCDI debugging.
Silent
Type: Boolean Default: FALSE Suppresses any dialog boxes that might appear while the LabVIEW C Code Generator generates the C code, which is useful for unattended testing.
5-8
ni.com
Chapter 5
TargetAlignment
Type: 32-bit integer Default: 4 Defines the alignment for such things as structures for the target. You must pass in the same number as you set in the ALIGNMENT macro in LVDefs_plat.h.
UseStackVariables
Type: Boolean Default: FALSE Determines whether to use stack variables to represent wires in the generated C code. Set UseStackVariables to TRUE to use stack variables. C stack variables cannot represent wires that execute parallel While Loops or For Loops because more than one C function can access wire values. However, if GenerateSerialOnly is TRUE, you can use stack variables because the LabVIEW C Code Generator generates the entire VI block diagram as one C function. The C compiler you use might be able to make more optimizations in the C code, which can result in a faster executable if the stack is large enough for the variables.
Note If you set UseStackVariables to TRUE, you also must set GenerateSerialOnly to TRUE.
5-9
Chapter 5
Pattern 1
Takes the pattern reference count-array index-primitive-array-replace and replaces it with a single array expression.
5-10
ni.com
Chapter 5
Pattern 2
Takes the pattern left shift register-reference count-array index-right shift register and eliminates the reference count.
Pattern 3
Takes the pattern global-reference count-array index-primitive-array replace-global and replaces it with an array expression directly on the global variable.
5-11
Chapter 5
Pattern 4
Takes the pattern global-reference count-array index-global and replaces it with an array index directly on the global variable.
Pattern 5
Takes the pattern global-reference count-array replace-global and replaces it with an array replace directly on the global variable.
Pattern 6
Folds function expressions for unary and binary operations into a single line of code and eliminates heap or stack variables. LabVIEW treats Quotient & Remainder functions with integer inputs and only one output wired as a binary operation for this pattern. If the output wire of a function branches, LabVIEW cannot include the function in the folded expression because the intermediate value is needed.
5-12
ni.com
Chapter 5
You must turn off the guard code generation option for this pattern to work.
Pattern 7
Folds expressions into a select statement and eliminates heap or stack variables.
5-13
Chapter 5
Pattern 8
Takes the pattern reference count-unbundle-bundle and eliminates reference counts and copies. This pattern works only if the elements unbundled and bundled are exactly the same.
Keep prefix names and tunnel abbreviation strings short to make comments more readable and to avoid truncated variable names or comments.
5-14
ni.com
Chapter 5
The following table shows the LabVIEW signal source and corresponding generated C variable name and comment.
LabVIEW Signal Source Front panel control Attribute Used Label Block Diagram Example Generated C Variable Name Motor_On Generated C Comment /* Motor On */
Constant
Label
Trigger_Level
/* Trigger Level */
Function
Over_Voltage_x_y__
Loop tunnel
Source name, LT
Trigger_Level_LT
Case selector
Source name, CS
Relay_CS
Case tunnel
Structure Label, CT
My_Structure_CT
/* My Structure: CT */
5-15
Chapter 5
Source name, SR
Sequence Local
Source name, SL
Init_SL
Sequence tunnel
Source name, ST
Level_Y_ST
/* Level Y: ST */
Structure terminal
Wave_Loop_i
/* Wave Loop: i */
5-16
ni.com
Chapter 5
Global variable
sensors_Temp_1
/* sensors: Temp 1 */
User VI
Filter_Analog
/* Filter: Analog */
Note
Generated variables must be unique. If multiple variables have identical names, the LabVIEW C Code Generator appends a sequential number to the end of the variable name to make the name unique.
5-17
Macros in LVDefs_plat.h define how to compile generated and external C code. LEP_x_ScriptCompiler.vi scripts the compiler and passes the directives to the compiler from the command line. This section lists some of the more common macros. Refer to the comments in LVDefs_plat.h for your OS for additional macros.
Note
Debugging Macros
The following list describes the debugging macros.
UsesSerialDebuggerDefine to enable debugging over a serial
line.
DBGBAUDSpecify the baud rate of the serial line for serial debugging. UsesTCPDebuggerDefine to enable debugging over a TCP/IP
connection.
UsesCANDebuggerDefine to enable debugging over a CAN bus. OCDI_RDMDefine to enable the Release Debug Mode for on chip
debugging.
BDTUseThreadSet to 1 to enable the Background Debug Thread
(BDT). The default is 1, which enables BDT, for targets that support threading and 0 for targets that do not support threading.
BDTSleepTimeSpecify the time in milliseconds that the BTD sleeps after updating a front panel indicator or a probe. The default is 50. Increase the time for targets with very slow communication channels and decrease the time if you want better interactivity with the front panel updating during a debugging session. BDTReconnectTryTimeSpecify the time interval in milliseconds that the target tries to reconnect to the host computer if disconnected. The default value is 5000.
6-1
Chapter 6
BDTHostConnectTimeSpecify the time in milliseconds to wait before the host connects to the target if you build the application with instrumented debugging. If the host computer does not connect to the target in the time you specify, the embedded application starts running. The default is 5000.
Feature Macros
The following list describes the feature macros.
CANSupportSet to 1 to enable VxWorks CAN support. To use the Embedded CAN VIs with your target, you must obtain a driver and libraries for the board from Wind River and compile it into your VxWorks image. SocketSupportSet to 1 to enable BSD (Berkeley Software
structures.
_TEXT_SECTIONDefines the input memory section for generated
code.
6-2
ni.com
Chapter 6
General Macros
The following list describes the general macros.
CHeadlessDefine this macro unless you implement a user interface for your target. The Unicon UCN2410-CWIFI and the Unix UI example targets are the only example targets that implement a user interface. _Integer_OnlyDefine for integer-only targets. CStaticDefine for the static memory model.
Simulation targets.
_vxworksimDefine for all VxWorks Simulation targets. _ECOSDefine for all eCos targets. linuxDefine for all Linux targets. dsp_biosDefine for all DSP Bios (TMS320) targets.
6-3
Use the Target Editor to create new embedded targets, modify existing targets, delete targets, and so on. You use the Target Editor to create and modify TgtSupp.xml, which is the file LabVIEW uses to integrate your target into the LabVIEW development environment. You can create new embedded targets from scratch or by copying an existing example target.
Tip
National Instruments recommends copying an existing target. Look for an example target that is similar to your target. If you cannot find a similar example target, use an example target with a similar OS, if possible. Use the Target Editor to explore Microprocessor SDK example target implementations.
National Instruments recommends using your company name, or some variation of your company name, when you create a new folder. For example, National Instruments targets are located in the labview\Targets\NI directory. 2. 3. 4. 5. Create an Embedded subfolder. LabVIEW does not recognize any targets not in an Embedded folder. Create a subfolder with your target name. Launch LabVIEW. Select ToolsMicroprocessor SDKTarget Editor from the Getting Started window, the Project Explorer window, or a blank VI to open the Target Editor.
7-1
Chapter 7
6.
Select FileOpen in the Target Editor and select the TgtSupp.xml file for the example target you are copying. TgtSupp.xml files are located in the target directory. For example, the TgtSupp.xml file for the Unix Console example target is located in the labview\Targets\NI\Embedded\unix directory. In the Target Editor, right-click the target you selected in the previous step, select Rename from the shortcut menu, and enter your target name. Select FileSave As and navigate to the directory you created in step 3 to open the Save Target As dialog box. (Optional) LabVIEW prepends prefixes to the plug-in directory and VIs themselves. Edit the prefix for your target in the Replace with text boxes.
7.
8. 9.
10. Click the OK button. LabVIEW copies, renames, and relinks the files for your new target. The copying, renaming, and linking can take a few minutes. Click the OK button to close the dialog box.
National Instruments recommends using your company name, or some variation of your company name, when you create a new folder. For example, National Instruments targets are located in the labview\Targets\NI directory. 2. 3. Create an Embedded subfolder. LabVIEW does not recognize any targets not in an Embedded folder. Create an OS subfolder. For example, all of the example targets that run eCos are in the labview\Targets\NI\Embedded\ecos directory. Open your OS subfolder and create a subfolder with your target name. Launch LabVIEW. Select ToolsMicroprocessor SDKTarget Editor from the Getting Started window, the Project Explorer window, or a blank VI to open the Target Editor. Select FileNew in the Target Editor.
4. 5. 6.
7.
7-2
ni.com
Chapter 7
8. 9.
Navigate to and select your Embedded folder. Right-click the Embedded folder in the Target Editor and select NewFolder from the shortcut menu. A New Folder folder appears under the Embedded folder.
10. Right-click New Folder and select Rename from the shortcut menu to rename the folder. Rename the folder to match the OS name you created in Windows Explorer. 11. Right-click your OS folder in the Target Editor and select NewTarget from the shortcut menu. A New Target item appears under the New Folder folder. 12. Right-click New Target and select Rename from the shortcut menu to rename the target. 13. Right-click your renamed target and select NewBuild Specification Type. 14. Right-click New Build Specification Type and select Rename from the shortcut menu to rename the build specification type.
Tip
Look at the example targets for examples of various build specification type names. 15. Select FileSave As in the Target Editor and select your target folder to open the Save Target As dialog box. 16. (Optional) LabVIEW prepends prefixes to the plug-in directory and VIs. Edit the prefix for your target in the Replace with text boxes. 17. Click the OK button. LabVIEW creates your TgtSupp.xml file, which is the file LabVIEW uses to integrate your target into the LabVIEW development environment. This can take a few minutes. Click the OK button to close the dialog box.
2.
7-3
Chapter 7
3.
Right-click the target and select Properties from the shortcut menu to open the Target Properties dialog box. Refer to the Configuring Target Properties section for information about how to use the Target Properties dialog box to configure the target properties.
4.
Right-click the build specification type and select Properties from the shortcut menu to open the Build Specification Type Properties dialog box. Refer to the Configuring Build Specification Type Properties section for information about how to use the Build Specification Type Properties dialog box to configure the build specification type properties.
5.
2. 3.
4.
7-4
ni.com
Chapter 7
5.
Navigate to and select or enter the relative path to the target icon file, which is the icon that appears in the Project Explorer window for your target, in the Project Explorer window icon text box. Icons must be in .png format. Icons are located in the following directory:
labview\resource\Framework\Providers\Icons
6.
Navigate to and select or enter the relative path to the directory that contains the TargetInfo.ini file, which is the file that defines the target-specific palette and controls, in the Path to TargetInfo.ini text box. You can reuse an existing configuration that works for a majority of embedded targets or you can copy and modify an existing TargetInfo.ini file. Most example targets use the dynamic memory allocation default configuration, which is located in the following directory:
labview\Targets\NI\Embedded\common\TargetInfo
The static memory allocation default configuration is located in the following directory:
labview\Targets\NI\Embedded\common\static\TargetInfo
7.
(Optional) Navigate to and select or enter the relative path to the subtarget directory in the Path to subtarget text box. You can use a single TgtSupp.xml file to define multiple targets. Use this text box when the TgtSupp.xml file defines a hierarchy of targets where the subtarget VIs call the base target VIs. (Optional) Navigate to and select or enter the relative path to the Elemental I/O configuration file (eio.xml). Leave the Path to Elemental I/O directory text box blank if you are not implementing Elemental I/O. (Optional) Navigate to and select or enter the relative path to the directory that contains your Funclist files. Leave the Path to the Funclist directory blank if you are not using Funclist files to override subVI calls with C function calls.
8.
9.
7-5
Chapter 7
5.
3.
7-6
ni.com
Chapter 7
Defining Events
Use the Events tab in the Target Properties dialog box to define the callback VI that is called every time a user removes your target from the Project Explorer window or closes a project. Navigate to or enter the relative path to the subpanel VI in the Path to OnRelease Plug-In VI text box. If you do not have an existing subpanel VI, click the Create New Subpanel VI button, shown at left, to open the Create New Subpanel VI dialog box. Refer to the Creating New Plug-In or Subpanel VIs section for more information about creating plug-in VIs.
7-7
Chapter 7
Configuring Licensing
Complete the following steps to use the License tab in the Target Properties dialog box to enter the licensing information National Instruments sends you if you are reselling your target. 1. Enter your OEM-specific or VAR-specific feature name in the Component Name text box. National Instruments assigns this name. The name matches the name in the OEM-specific or VAR-specific license file. Enter the OEM-specific or VAR-specific feature version in the Component Version text box. National Instruments assigns this version and the version matches the version in the OEM-specific or VAR-specific license file. Enter the OEM-specific or VAR-specific name used to activate the target in the Package Name text box. Enter the OEM-specific or VAR-specific version used to activate the target in the Package Version text box.
2.
3. 4.
Refer to the LabVIEW Embedded Development Module Target Distribution Guide, available by selecting StartAll ProgramsNational InstrumentsLabVIEW LabVIEW Manuals and opening EMB_Distribution_Guide.pdf, for information about licensing requirements if you want to resell your target and how to obtain the feature name and version.
Note
5.
(Optional) Select the Enable the Evaluate Button button if you want users to be able to evaluate your target in the license activation dialog box. Enter the text you want to display in the title bar of the license activation dialog box in the Dialog Box Title text box. Enter the URL for the Web page on ni.com where users can buy your target in the URL for Purchasing Web Page text box.
6. 7.
7-8
ni.com
Chapter 7
2.
3.
labview\resource\Framework\Providers\Icons
4.
Enter an ID in the Build Specification Type ID text box to identify the build specification type. Each target build specification type you create must have a unique name. Enter a name for the build specification type in the Default Build Specification Name text box, which is the name that appears when a user right-clicks Build Specification in the Project Explorer window and selects New from the shortcut menu. Enter the file extensions for the type of additional files a user can add to the project in the Additional Files text box. Users can add only the file types you enter. Enter the file extensions as a comma-separated list.
5.
6.
Note
7-9
Chapter 7
3.
7-10
ni.com
Chapter 7
4.
Repeat steps 1 through 3 for each new category you want to define. Click the red x button, shown at left, to remove the selected category.
3.
4.
7-11
Chapter 7
2.
Navigate to or enter the relative path to the plug-in VI you are creating in the Path to Plug-in VI text box. Click the OK button.
2.
Enter the category name, which is the name that appears in the Category list in the Target Properties or Build Specification Properties dialog box, in the Name text box. Navigate to or enter the relative path to the subpanel VI you are creating in the Path to Subpanel VI text box. Click the OK button.
4. 5.
7-12
ni.com
You can customize the LabVIEW editing environment so only features a target supports are available. Refer to the LabVIEW Embedded Development Module Target Distribution Guide, available by selecting StartAll ProgramsNational InstrumentsLabVIEWLabVIEW Manuals and opening EMB_Distribution_Guide.pdf, for more information about customizing the editing environment, which you must do if you plan on reselling your target. Target syntax determines the supported and unsupported features for a specific target. Configuring the target syntax limits features users can use when developing an embedded application to the features the target can support. Target syntax also prevents you or other users from importing unsupported VIs from other targets. Select ToolsMicroprocessor SDKConfigure Target Syntax to open the Configure Target Syntax dialog box. Use the Configure Target Syntax dialog box to create the TargetSyntax.xml file, which is the file LabVIEW uses to check the target syntax. This process overwrites the default TargetSyntax.xml file, which LabVIEW uses to determine target syntax. National Instruments recommends that you back up TargetSyntax.xml before modifying it.
Caution
type of front panel controls. For example, if you are creating an integer-only target and want the default data type for numeric controls to be a 32-bit signed integer numeric, create a custom int32 control.
8-1
Chapter 8
b. c. d. e. 2.
does not support. Edit the VIs described in step 1 by placing unsupported features on the block diagram of the appropriate VI. Save the VI.
For targets with very limited functionality, you also can create a VI that contains only the features that the target can support. Name supported functionality VIs LVESupportedxx.vi where xx follows the naming convention of the unsupported VIs.
Note
3. 4.
Select ToolsMicroprocessor SDKConfigure Target Syntax to open the Configure Target Syntax dialog box. On the Nodes tab, add the unsupported nodes. a. b. c. Navigate to and select LVEUnsupportedNodes.vi, which is the VI that contains the unsupported nodes. (Optional) Navigate to and select the VI that contains the supported nodes. Place a checkmark in the Unspecified nodes are unsupported checkbox if you are using both unsupported and supported VIs and you want nodes to be unsupported if the nodes are not in either VI. Navigate to and select LVEUnsupportedFunctions.vi, which is the VI that contains the unsupported functions. (Optional) Navigate to and select the VI that contains the supported functions. Place a checkmark in the Unspecified nodes are unsupported checkbox if you are using both unsupported and supported VIs and you want functions to be unsupported if the functions are not in either VI. Navigate to and select LVEUnsupportedTypes.vi, which is the VI that contains the unsupported data types.
5.
6.
8-2
ni.com
Chapter 8
b. c.
(Optional) Navigate to and select the VI that contains the supported data types. Place a checkmark in the Unspecified nodes are unsupported checkbox if you are using both unsupported and supported VIs and you want data types to be unsupported if the data types are not in either VI.
7.
On the SubVIs tab, add the unsupported subVIs. Unsupported subVIs must be the labview\vi.lib directory. a. b. c. Navigate to and select LVEUnsupportedVIs.vi, which is the VI that contains the unsupported data types. (Optional) Navigate to and select the VI that contains the supported subVIs. Place a checkmark in the Unspecified nodes are unsupported checkbox if you are using both unsupported and supported VIs and you want subVIs to be unsupported if the subVIs are not in either VI.
8.
contains the default data type. 9. (Optional) On the Misc. tab, adjust the settings for maximum recursion depth, variable support, and so on. You usually can keep the default miscellaneous settings. a. Enter a maximum recursion depth for supported data types in the Max Type Depth box. For example, a cluster of an array of integers has a type depth of 3. A cluster of an array of a cluster of strings has a type depth of 4. A value of -1 ignores the maximum type depth. Setting the Max Type Depth to prevent nested types from being recursive, which is not permitted by MISRA (The Motor Industry Software Reliability Association) automotive coding standards. b. Enter the maximum number of dimensions for arrays in the Max Array Dimensions box. A value of -1 ignores the maximum array dimension. Setting the Max Array Dimensions to 1 to restrict users to only optimized 1D array operations, which can increase application performance. c. Place a checkmark in the Support global variables checkbox if the target supports global variables.
8-3
Chapter 8
d. e. f.
Place a checkmark in the Support local variables checkbox if the target supports local variables. Select the Errors break the VI radio button if you want target syntax errors to break the VI. Select the Errors are considered warnings and do not break the VI radio button if you want LabVIEW to consider target syntax errors as warnings rather than errors.
10. Enter the directory path to the target in the Location of target field. 11. Click the Generate button to create TargetSyntax.xml, which is the file LabVIEW uses to check target syntax, in the target directory you specified in step 10. 12. Click the Save button to save the TargetSyntax.xml file. You must save the file as TargetSyntax.xml for LabVIEW to recognize the target syntax for your target.
Note Clicking the Generate button does not automatically save the TargetSyntax.xml file. You must click the Save button to save the file.
2. 3. 4. 5. 6. 7.
Note
You must regenerate and save the TargetSyntax.xml file if you modify any of the unsupported or supported VIs.
8-4
ni.com
You can use instrumented debugging with LabVIEW to communicate with an embedded application running on an embedded target to provide front panel connectivity, probes, and block diagram breakpoints. Instrumented debugging occurs through synchronization and data-transfer routines in the generated C code of an embedded VI. These routines use an underlying communication layer. If you are using serial or TCP communication, you do not have to implement this communication layer. Instead, you can use the existing communication layer the Microprocessor SDK example targets use. If you are using a communication protocol other than serial or TCP, you must implement your own communication layer. Refer to Chapter 17, Implementing Instrumented Debugging for a Custom Communication Layer, for more information about implementing instrumented debugging for a custom communication layer.
Serial Communication
If you are using serial communication, your LEP_x_Connect.vi and LEP_x_Debug.vi plug-in VIs must call the nitargetStartSerialDebug VI. Your plug-in VIs are located in your target directory. The nitargetStartSerialDebug VI is located on the Debugging Utilities palette and in the following directory:
labview\vi.lib\LabVIEW Targets\TargetShared
9-1
Chapter 9
TCP Communication
If you are using TCP communication, your LEP_x_Connect.vi and LEP_x_Debug.vi plug-in VIs must call the nitargetStartTCPDebug VI. Your plug-in VIs are located in your target directory. The nitargetStartTCPDebug VI is located on the Debugging Utilities palette and in the following directory:
labview\vi.lib\LabVIEW Targets\TargetShared
You must provide the TCP libraries for your target. If a Linux target and the host computer are different devices, you must build the run-time libraries with TCP_USE_LOCALHOST undefined and pass the IP address of the debugger as a command line argument to the embedded application. If a Linux target and the host computer are the same machine, define TCP_USE_LOCALHOST as 1.
Note
If you are implementing OCDI debugging or using another communication layer for instrumented debugging, such as CAN or RTDX, you must implement the communication layer for LabVIEW and the communication layer for your target.
9-2
ni.com
10
The LabVIEW Microprocessor SDK includes the LabVIEW C Generator Test Framework, which is an automated test framework, and C Generator-specific VI Analyzer tests. The LabVIEW C Generator Test Framework tests the LabVIEW C Code Run-Time Library. Use the automated tests to verify successful target implementations. The C Generator-specific VI Analyzer tests can assist you with developing embedded VIs. Use the C Generator-specific VI Analyzer tests to help optimize embedded applications for size and performance.
The LabVIEW C Generator Test Framework executes all the tests in a folder you specify in the LEP_AutoTest.ini file, which is located in the labview\autotest directory. When you run the tests, LabVIEW creates a folder with a date and time label and saves the test results as text files in that directory.
Tip You can specify where LabVIEW creates the results directory in the LEP_AutoTest.ini file. By default, LabVIEW creates the results directory in the labview\autotest\results\win32con directory.
10-1
Chapter 10
After LabVIEW runs all of the tests and saves the results, LabVIEW creates an index.html file that summarizes the test results. The summary file lists the test name and whether the test passed or failed. If the test failed, the index.html file provides a hyperlink to the test results text file that contains the errors. You can configure the LabVIEW C Generator Test Framework to email failed test results to the email addresses you specify in the [SendMail] section of the LEP_AutoTest.ini file.
Tip
Target-specific sequence files support text execution on actual hardware. You might need to implement target-specific sequence files to support the execution of tests on actual hardware. Refer to the win32con_Target.ini and ecos_cmd565_Target.ini sequence files for implementation examples. The example sequence files are located in the following directory:
labview\autotest\tests\Large semi-auto tests\arr-drv
Each test contains separate configuration files for each target. Add configuration files for all applicable tests when you create your new target.
Default Tests
The LabVIEW C Generator Test Framework includes a default set of tests to help you verify your target implementation. Most of the tests are generic and do not interact with any specific hardware. National Instruments strongly recommends that you add automated tests for your device drivers. The following table lists the default set of tests. Directory
analysis arr-* basic
Description Advanced analysis Array data types and functions Basic data types (mostly scalar) and operations that use these types Cluster data types and functions Complex data types and functions Comparison operators Front panel control constants
10-2
ni.com
Chapter 10
Directory
elementalIO express fileIO_* func* misc Queues&Notifiers string* timedLoop
Description Elemental I/O framework Express VIs File I/O functions Floating-point and integer math Application Control VIs and functions Synchronization VIs and functions String data type and functions Timed Loop structure and utility functions Unary functions Variant data type and functions Waveform data type and functions
10-3
Chapter 10
Description You can configure the LabVIEW C Generator Test Framework to automatically begin executing after 10 seconds unless you click anywhere in the LabVIEW C Generator Test Framework dialog box. Automatic test execution is useful for unattended or automated testing. To enable this feature, change this token to true. The default is false. Specifies the path to a summary report that lists which targets have been tested, the number of failed tests per target, and the number of memory leaks per target. Specifies the filename for the summary report. Specifies the folder target name, which is called the target URL. The target URL is located in the TgtSupp.xml file for your target. You must have at least one folder. Specifies the path to the test results for your target. You can use relative paths, which are relative to the labview\autotest directory. National Instruments recommends placing your tests in the autotest directory, if possible. The LabVIEW C Generator Test Framework creates a subfolder that uses the start date and time when the tests start executing. After the tests run, the framework generates an index.html file, which contains the test results, in the same subfolder. Specifies the path to the tests for your target. You can use relative paths, which are relative to the labview\autotest directory. National Instruments recommends placing your tests in the autotest directory, if possible.
ReportFolder
WorkFolder
TestFolder
10-4
ni.com
Chapter 10
Description Set this token to true to enable email notification. The default is false. Specifies the name or IP address of the SMTP server. Email address from which the email notification is sent. The email address to which the email notification is sent. Enumerate additional recipient email addresses on separate lines. For example:
[email protected] [email protected]
After you enable the email notification in LEP_AutoTest.ini, place a checkmark in the Send Mail checkbox in the LabVIEW C Generator Test Framework dialog box to email the name of failed tests and the path to the relevant index.html file.
10-5
Chapter 10
Description The name of the test. You must enclose test names in brackets. The test name cannot contain spaces. The name of the top-level embedded VI to build into an embedded application. The name of the test sequence VI. The default value is LEP_AutoTest_TestSequence_1.vi.
_Test_TopLevelVI_
_Test_SequenceVI_
10-6
ni.com
Chapter 10
Token
i_Test_BaudRate_
Description The baud rate of the capturing serial port. Only test sequences that capture output on the serial port use this token. The name of the capturing serial port. Only test sequences that capture output on the serial port use this token. The time interval in milliseconds to obtain the result before the test fails. Target-specific configuration tokens. Each target-specific configuration token is prepended with a letter that indicates the data type of the token.
b = Boolean value i = integer value p = path value s = string value
s_Test_ResourceName_
_Test_Timeout_
You have access only to the C Generator-specific tests unless you install and activate the LabVIEW VI Analyzer Toolkit.
10-7
Chapter 10
creates a file in the labview directory named cgenlog.txt. This text file contains various debugging diagnostic and error messages that occur as a result of instrumented debugging connections. Use this file to help you implement and troubleshoot your instrumented debugging implementation.
10-8
ni.com
Part II
Advanced Porting Implementations
Depending on your target, you might need to implement and port additional functionality. The additional pieces include the following: Implementing support for user interfaces Adding I/O through Elemental I/O Implementing ISRs Implementing timing Implmenting memory mapping Porting the LabVIEW C Code Run-Time Library to a new platform Implementing instrumented debugging for a custom communication layer OCDI debugging Understanding the LVM file Integrating LabVIEW with another IDE Overriding subVI calls to improve performance Implementing static memory allocation Implementing a target server
II-1
11
If your target has an LCD, you can implement user interface support. The Unix UI and Unicon example targets implement user interface support. The Unix UI example target is similar to the Unix Console example target. The example user interface support uses FLTK, which is an open source C++ graphical user interface toolkit. You must develop your own video driver if you want to port user interface support and use something other than FLTK. To implement user interface support, you must do the following: 1. Port the following three open source libraries to your target: Nano-X (version 0.91)low-level screen drawing functions You might have to develop a screen driver to work with your target. Also, Nano-X assumes you have a mouse, so if your target uses a touchscreen for input, you also have to develop a touchscreen driver that looks like a mouse to Nano-X. Refer to the Nano-X Web site at www.microwindows.org for more information about and documentation for Nano-X. nxLib (version 0.46)interface between FLTK and Nano-X FLTK (version 2.0.x-r5940)C++ graphics library FLTK assumes you have certain header files with certain functions. If these functions do not exist for your target, you must find a workaround. Refer to the FLTK Web site at www.fltk.org for more information about FLTK. The source code for these libraries are located in the following directory:
labview\CCodeGen\external
2.
After building the libraries, run and debug the libraries using your toolchain.
11-1
Chapter 11
3.
Build the LabVIEW C Code Run-Time Library and the fltkapi library, which is the interface between FLTK and the LabVIEW C Code Run-Time Library. The source code for the fltkapi library also is located in the labview\CCodeGen\external directory. You must define the following flags when you build the LabVIEW C Code Run-Time Library:
GUISupportEnables user interface support. FltkGUIEnables support for the FLTK widget library. Supports3DControlsEnables support for 3D controls. SupportsColorBGEnables support for background color. FP_SIZE_HORIZSpecifies the horizontal size in pixels of the
user interface. 4. Implement user interface settings in your Build Specification Properties dialog box.
11-2
ni.com
Chapter 11
11-3
Chapter 11
Boolean Controls
Boolean controls support the following: Labels Captions Boolean text Six types of mechanical action for Boolean controls, including Switch when pressed, Switch when released, Switch until released, Latch when pressed, Latch when released, and Latch until released.
Checkboxes
You cannot resize checkbox controls.
11-4
ni.com
Chapter 11
Boolean Text
The Square Button on the the Classic Boolean palette does not support Boolean text.
Charts
Charts support the following: Captions and labels Maximum of eight plots One horizontal scale on the bottom of the chart One vertical scale on the left side of the chart Numeric values, arrays of numeric values, and numeric clusters Autoscaling and visibility of the x- and y-axis and scale formatting Scale and cursor legends
Charts do not support the following: Duplicate scales Grids Plot legends
You cannot resize the x- or y-axis of a chart. The x-axis of a chart supports only integer numbers. Any floating-point numbers round to the nearest whole number. If you use a Property Node to change the update mode of a chart, the x-axis is reset to start at zero.
Color
FLTK supports 32 bits per pixel color. LabVIEW maps the colors you use in LabVIEW to the colors the video driver supports. Some Boolean controls support color differently than Windows. Refer to the Boolean Controls section in this chapter for more information about using color with Boolean controls.
11-5
Chapter 11
Combo Boxes
Combo boxes support the following: Captions Labels 16-bit signed integer numeric representation only
Combo boxes do not support the following: Digital displays Disabling individual items
Decorations
The following decorations are supported:
Note
Boxes Circles Horizontal Smooth Box Lines Triangles Vertical Smooth Box
Raised and recessed decorations appear flat. The following decorations are unsupported: Arrows Shadows
11-6
ni.com
Chapter 11
Enumerated type controls do not support the following: Digital displays Disabling individual items Text justification and underlining text
The text area of the enumerated type control is a string control on the target. Selecting items in enumerated type controls is different in embedded applications: Click the control to display the shortcut menu so all options are visible. Tap the increment and decrement buttons to cycle through the options.
Fonts
When you build a VI into an application, LabVIEW scales the fonts by the scale factor you enter in the build specification. The following fonts are available on the Unicon example target:
Note
Arial Arial Black Comic Sans MS Courier New Impact Condensed Tahoma Times New Roman
11-7
Chapter 11
Graphs
Graphs can display plots that contain any number of points of the following data types: A single array of values. Graphs interpret array data as points on the graph and increment the x index by one starting at x = 0. A cluster with an array of x values and an array of y values. A 2D array of values, where each row of the array is a single plot. An array of plots, where each plot is a cluster that contains an array of x values and an array of y values. An array of clusters of plots, where a plot is an array of points and a cluster contains an x and a y value. A cluster of x, delta-x, and an array of y values.
Graphs do not support the following: Duplicate scales Grids Plot legends
Plots on XY Graphs
Autoscaling the Y-axis for multi-plot XY graphs is not supported. Only one plot shows at a time if you enable autoscaling. You must disable autoscaling if you want multiple plots on an XY graph.
11-8
ni.com
Chapter 11
Labels
Word wrapping in free labels is unsupported. You must create new lines for text that spans multiples lines.
Listboxes
The following listbox elements are unsupported: Auto-size row height Editable headers Horizontal scroll bar Keyboard modes Index display Item dragging Moveable column separators Multiline input Multiple fonts in the same table Row and column headers Selection scrolling Smooth scrolling
Multicolumn Listboxes
The Top Left Visible Cell property returns only the top row element of the cluster.
Menus
Empty menus do not generate events. Customizing shortcut menus for front panel controls is unsupported.
11-9
Chapter 11
Numeric controls and indicators do not support the following: Radix or unit labels. Significant digits. Options in the advanced editing mode of the Display Format page of the Numeric Properties dialog box. SI (System International) or relative time notations. Time and date formats. Use a time stamp control instead. Dials, meters, and slides do not support digital displays or ramps. You cannot invert the scales for dials, meters, or slides. Scales must be linear. Dials, meters, and slides do not support transparency. Data ranges that are different than the display range. 64-bit signed or unsigned integers. If you use 64-bit signed or unsigned integers, LabVIEW generates 32-bit signed or unsigned integers when you build the VI into an application. Extended-precision, floating-point numerics. If you use extended-precision, floating-point numerics, LabVIEW generates double-precision, floating-point numerics. Two sliders on a slide control. If you use two sliders, an error occurs when you build the VI into an application, and the application contains only the first slider and its default value.
Path Controls
Path controls do not have the same functionality on embedded targets as on Windows. Applications translate path controls and indicators into string controls and indicators and treat the data as strings, which means the Browse button in the path control is not visible on the target.
Picture Controls
If you use a picture control, LabVIEW ignores the Erase First shortcut menu item and draws the new image over the previous image.
Events
You can use the following Control events with picture controls: Mouse Up Mouse Down Mouse Move
11-10
ni.com
Chapter 11
Refnums
You can add refnums to the front panel window, but refnums are not visible when you run the application on the target. VIs support the following refnums: Application Control File Menu Occurrence TCP Network Connection UDP Network Connection VI
11-11
Chapter 11
String indicators support all types of display modes, which includes the following: Normal '\' codes Hex Password
Note
The Limit To Single Line? property removes the scroll bars but does not limit the text to a single line when you use this property.
Tab Controls
Tab controls support the following: Decorations Free labels
The following configuration options are unsupported: Tabs on the left or right side of the tab control Disabled pages Variable size tabs Different color tabs Hidden tabs
11-12
ni.com
Chapter 11
Note
Although images are not support on the actual tabs, you can place images on tab control pages.
Editing Modes
The editing mode sets whether to edit the format and precision of the data using the default view or using format codes. You select the editing mode on the Display Format page in the Time Stamp Properties dialog box.
Variant Controls
Variant controls are supported but are not visible in the application running on the target. Variant data does not conform to a specific data type and can contain attributes. LabVIEW represents variant data with the variant data type.
11-13
Chapter 11
You cannot initialize variant data with default data in a VI. Placing a control, indicator, or constant that contains default data on the block diagram of the VI results in an empty LabVIEW variant.
Supported Properties
You can use the following properties with the Property Node. Each type of control has its own class. You receive a broken Run button if you attempt to use an unsupported property.
Note
If you pass a control reference to an embedded subVI, the control reference is not valid within that subVI.
Generic Properties
You can use the following generic properties on all supported controls: Bounds Bounds:Area Height Bounds:Area Width Disabled Key Focus Position Position:Left Position:Top Text (control and indicator labels only) Value Value (Signaling) Visible
11-14
ni.com
Chapter 11
Cluster Controls
You can use the following properties with cluster controls: Cluster Size Cluster Size:Height Cluster Size:Width Controls[]
11-15
Chapter 11
Display Format:Format Display Format:Precision Mapping Mode Name Label Plot Area:Colors:BG Color Plot Area:Colors:FG Color Range:Increment Range:Maximum Range:Minimum Range:Start Visible
Listbox Controls
You can use the following properties with listbox controls: Item Names Number of Rows Top Row
11-16
ni.com
Chapter 11
Response to Value Outside Limits:Maximum Response to Value Outside Limits:Minimum Text Colors:BG Color Text Colors:Text Color Visible
Ring Controls
You can use the following properties with ring controls: Number of Items (read only) Ring Text Strings [] Text Colors:BG Color Text Colors:Text Color
The Limit To Single Line? property removes the scroll bars but does not limit the text to a single line when you use this property except for string controls that use the password display type, which is always a single line with no scroll bars. Text Text Colors:BG Color Text Colors:Text Color
11-17
Chapter 11
Format String Response to Value Outside Limits:Increment Response to Value Outside Limits:Maximum Response to Value Outside Limits:Minimum
Waveform Charts
You can use the following property with waveform charts: Update Mode
Waveform Graphs
You can use the following properties with waveform graphs: Active Cursor Cursor Color Cursor Position Cursor Position:Cursor X Cursor Position:Cursor Y Cursor Style Visible
Supported Methods
You can use the following methods with the Invoke Node. Each type of control has its own class. You do not receive a broken Run button if you attempt to use an unsupported method, but you do receive an error when you build the VI into an application.
Generic Methods
You can use the following generic method on all supported controls and VIs except for graphs and charts: Reinitialize To Default
11-18
ni.com
Chapter 11
Waveform Graphs
You can use the following method with waveform graphs: Get Plot At Position
VIs
You can use the following methods in VIs: Abort VI Default Values:Reinitialize All To Default
11-19
Elemental I/O
12
Elemental I/O is a flexible, user-defined way to create I/O for LabVIEW embedded targets. Elemental I/O Nodes are portable across many targets. Although the I/O implementation might change among targets, you do not need to redevelop the application for another target. The block diagram can stay the same because the Elemental I/O Node itself does not change. Use Elemental I/O Nodes to create block diagrams that represent algorithms that you can reuse on many platforms. Compare Elemental I/O Nodes to Call Library Function Nodes or register-level programming where driver differences among embedded targets are fully exposed on the block diagram. Elemental I/O requires more work to implement and set up, but provides greater reuse than Call Library Function Nodes or register-level programming. Elemental I/O consists of the following: I/O devices I/O classes I/O pins I/O resources I/O plug-in VIs
National Instruments strongly recommends looking at the Simulated I/O implementation example as you implement your Elemental I/O. The Simulated I/O implementation example is located in the labview\Targets\NI\Embedded\eio directory.
I/O Devices
An Elemental I/O device is the software representation of hardware that performs I/O on an embedded target by using a collection of I/O resources, pins, and plug-in VIs to define the I/O for a target. You can reuse an I/O device on multiple targets so similar targets can share a single I/O device. For example, a PowerPC 565 ROM target and a PowerPC 565 RAM target might share a single I/O device.
12-1
Chapter 12
Elemental I/O
I/O Classes
Elemental I/O supports the following I/O classes: Analog In Analog Out Digital In Digital Out Digital Bank In Digital Bank Out Pulse Width Modulation Out
You can implement some or all of the supported I/O classes for an I/O device.
I/O Pins
A Elemental I/O pin is the software equivalent of a physical pin that connects an I/O device to the outside world. Resources can share pins because typically, there are fewer pins than resources. Pins are optional. Use pins if you have conflicting I/O devices.
I/O Resources
An Elemental I/O resource is the software equivalent of a circuit in the hardware that performs I/O. Resources use pins to connect the circuits to the outside world. An I/O device can have many resources. Elemental I/O resources bind the pins to the I/O classes. For example, the hardware an Elemental I/O device uses might have eight general purpose I/O pins that you can use for analog input, analog output, digital input, and digital output. You can bind a pin to a resource.
12-2
ni.com
Chapter 12
Elemental I/O
All Elemental I/O plug-in VIs use the standard 12 terminal connector pane. You must wire controls and indicators as specified by the connector pane of each template VI. The template VIs include all possible controls and indicators for the Elemental I/O plug-in VIs. Copy the template VIs for the target, replace the Project Attributes and Node Attributes cluster controls with type definitions or strict type definitions, and remove controls that you do not need. The template VIs are located in the following directory:
12-3
Chapter 12
Elemental I/O
Refer to the block diagram comments in the template VIs for more information about the Elemental I/O plug-in VIs, such as required and optional parameters. The Project Attributes cluster control is what appears on the I/O Node Project Panel page of the Elemental I/O Properties dialog box when a user right-clicks an I/O item in the Project Explorer window and selects Properties from the shortcut menu. The values you set in the I/O Node Project Panel page apply to all nodes that refer to this I/O item. The Elemental I/O framework passes the project attributes to the I/O Implementation plug-in VI and the I/O Property Node Implementation plug-in VIs for this I/O item. The Node Attributes control is what appears on the I/O Node Panel page of the Elemental I/O Node Properties dialog box when a user right-clicks an Elemental I/O Node on the block diagram and selects Properties from the shortcut menu. The values set in the I/O Node Panel page apply to this particular Elemental I/O Node only. The Elemental I/O framework passes the node attributes to the I/O Implementation plug-in VIs. Example plug-in VIs are located in the following directory:
labview\Targets\NI\Embedded\eio\simulatedIO
12-4
ni.com
Chapter 12
Elemental I/O
12-5
Chapter 12
Elemental I/O
Using the Elemental I/O Device Wizard to Create Elemental I/O Devices, Classes, Pins, and Resources
After you create the Elemental I/O plug-in VIs, use the Elemental I/O Device Wizard to define the Elemental I/O devices, classes, pins, and resources for an embedded target. The wizard determines which I/O resources are available for an embedded target, what attributes and I/O properties those resources have, and which VIs the Elemental I/O Node and Elemental I/O Property Node call to perform I/O operations. Complete the following steps to use the Elemental I/O Device Wizard. 1. Select ToolsProduct NameElemental I/O Device Wizard, where Product Name is the product menu item, to display the Elemental I/O Device Wizard. On the Name the Device page of the wizard, enter the name of the new Elemental I/O device. Enter a description for the Elemental I/O device in the I/O Device Description text box. LabVIEW displays what you enter here in the Select Elemental I/O dialog box.
2. 3.
Note You also can click the Load existing I/O target button to select an existing I/O device.
4. 5.
Click the Next button to display the Select the Elemental I/O Classes page. Select the I/O classes the device supports. The I/O classes only affect the icon that appears on the I/O Node and the name of the I/O folder in which the resources show up in the project. The I/O classes have no functional effect on the I/O. Click the Next button to display the Add I/O Resources page. Add I/O resources. Use this page of the wizard to name the I/O resources. These are the default names that appear when a user right-clicks the embedded target in the Project Explorer window and selects NewElemental I/O from the shortcut menu. Click the Next button to display the Add Pins page.
6. 7.
8.
12-6
ni.com
Chapter 12
Elemental I/O
9.
(Optional) Define the physical pins on the device. Use I/O pins to reserve shared resources. You might have physical pins on the device that can be used for analog or digital input but only one can be configured. In this case, you can name these pins and assign them to the I/O resources. When a user adds an I/O resource that uses a pin, the user cannot add any other I/O resource that uses that same pin. If you do not need to reserve shared resources, do not define any pins. If you have shared resources, National Instruments recommends defining the pins.
10. Click the Next button to display the Assign the Pins to Resources page. 11. (Optional) Define the connection between the I/O pins and the I/O resources you created. You can assign multiple pins to each resource, and you can assign the same pin to multiple resources. If you do not need to reserve shared resources, do not assign any pins to the I/O resources. If you do have shared resources, National Instruments recommends assigning pins to I/O resources. 12. Click the Next button to display the Add Implementation VIs to Resources page. 13. Associate the Elemental I/O plug-in VIs with the resources. For each I/O resource, you must have at least one read or write I/O Node Implementation plug-in VI. All other plug-in VIs are optional. 14. Click the Next button to display the Generating Elemental I/O VIs and Resource File page. 15. Select the target to which you want to add Elemental I/O and click the Select Target button. When you select a target, LabVIEW displays the path in the Output Directory. 16. Click the Generate button. The wizard creates a directory in the location you specify in the Output Directory and adds several VIs the Elemental I/O framework needs and an eio.xml file in the new directory. The eio.xml file contains the info from the Elemental I/O Wizard. The eio.xml file must be in the directory or subdirectory specified in the Output Directory box. 17. Click the Finish button to exit the wizard.
Note If you have more than one Elemental I/O device for a target, you select the Elemental I/O device by right-clicking the target in the Project Explorer window and selecting Select Elemental I/O from the shortcut menu.
12-7
Chapter 12
Elemental I/O
5. 6. 7.
12-8
ni.com
13
With the exception of the os directory, you usually do not have to modify the code in the labview\CCodeGen\libsrc subdirectories because the C files in these directories contain #include directives for a header file that contains #include directives for an OS-specific header file. The OS-specific header file contains macros and definitions. If you are porting LabVIEW to a new platform, you must do the following: Map the generic function calls to OS-specific function calls using #define statements Set feature flags Port OS-specific components (Optional) Override the default RT FIFO size limits (Optional) Define constants for static memory allocation support
#defines in LVDefs_plat.h
A series of #define statements map the generic function calls, such as StrCaselessCompare( x, y ), to OS-specific function calls, such as strcasecmp( x, y ) for Linux and VxWorks and _stricmp( x, y ) for Windows. Examples of some of the #defines in LVDefs_plat.h include the following:
#define BigEndianDefines the data storage format as big endian
or little endian. Define as 0 for little endian and 1 for big endian.
#define ALIGNMENTDefines the alignment of data. typedefsigned char int8;In the LabVIEW C Code Run-Time Library code, int8 is used everywhere and must be defined to a signed 8-bit integer.
13-1
Chapter 13
#define StrCopy(x, y) strcpy(x, y)In the LabVIEW C Code Run-Time Library code, StrCopy is used everywhere and
Feature Flags
The following are just some of the flags in LVDefs_plat.h. Feature flags turn on and off large sets of features that correspond to pieces of hardware that might be applicable for your target. Flag
HeapListSupport
Description Controls the freeing of memory blocks associated with VIs. If this flag is TRUE, the memory blocks are not freed until the embedded application exits, which speeds up application execution but greatly increases the memory footprint. Controls Bluetooth support. Bluetooth support has not been ported to any of the Microprocessor SDK example targets and operating systems, but the code is present. Controls infrared (IrDA) support. IrDA support has not been ported to any of the Microprocessor SDK example targets and operating systems, but the code is present. Controls serial communication support. Controls TCP and UDP support along with the SocketSupport flag in CCGNetConnSupport.c, which is located in the CCodeGen/libsrc/comms directory. Controls file I/O support. Controls support for the POSIX file system.
BluetoothSupport
IrDASupport
SerialSupport TCPUDPSupport
FileSupport PosixFiles
13-2
ni.com
Chapter 13
OS-Specific Components
Some functionality is OS-specific. The generated C code calls these OS-specific functions when the corresponding features are on the block diagram. If you do not want to port certain parts of this OS-specific code to a new platform, you must avoid using features that depend on the unported parts to avoid linker errors. Look at each file and determine if you must rewrite the file for a new platform. A copy of each file is located in each operating system folder in the following directory:
labview\CCodeGen\libsrc\os
Purpose: Called from LVEmbeddedMain.c to initialize and tear down critical sections.
LVCriticalSection LVCriticalSectionCreate()
Purpose: Allocates the critical section record and returns a pointer to it.
LVCriticalSectionDelete(LVCriticalSection critsect)
Purpose: Called to indicate when a section of code is entered that must not be interrupted.
LVCriticalSectionLeave(LVCriticalSection critsect)
Events: LVEvent.c
Note
The event functions are real-time events. The functions are not UI events.
13-3
Chapter 13
Occurrences and Timed Loops depend on LVEvent.c, which contains the following functions:
InitLVEvents(), UninitLVEvents()
Purpose: Triggers an event. All threads waiting on the event proceed with execution.
LVEventReset(LVEvent event)
Purpose: Resets an event so that subsequent waiters must wait for another LVEventSet call.
LVEventWait(LVEvent event, int32 millisec_timeout, Boolean *timedout)
Purpose: Waits on an event with a timeout. Suspends the executing thread until the event is set.
Threads: LVThreads.c
Timed Loops use LVThreads.c, which contains the following functions:
InitLVThreads(), UninitLVThreads()
Purpose: On some operating systems, threads are created in a suspended state. This function activates and runs a thread. This function might be a no-op if LVThreadCreate creates and activates threads.
Microprocessor SDK Porting Guide 13-4 ni.com
Chapter 13
LVThreadGetCurrentThreadId()
Purpose: Returns the ID of the thread from which the function is called.
LVThreadSetPriority(LVTHREAD_HANDLE h, LVTHREAD_PRIORITY p)
Purpose: Sets the priority of the thread from which this function is called.
LVThreadGetPriority(LVTHREAD_HANDLE h)
Purpose: Returns the priority of the thread referred to by the handle passed in.
LVTHREAD_PRIORITY LVThreadGetCurrentPriority()
Purpose: Returns the priority of the thread from which this function is called.
LVTHREAD_PRIORITY LVThreadGetInitPriority()
Purpose: Returns the priority when the thread from which this function was created.
LVTHREAD_PRIORITY LVThreadGetMainPriority()
Purpose: Suspends the thread for the time interval passed in.
13-5
Chapter 13
Purpose: Finds the ISR VI in the lookup table that param indexes.
InitOEMISRs(), UninitOEMISRs()
Purpose: Called from LVEmbeddedMain.c to initialize and tear down ISR VIs.
OEMISRRegisterHandler(uInt32 isr_vector, uInt32 isr_param, ISRFunc isr_runFunc, uInt32 *register_param)
Purpose: Searches for an empty slot in the lookup table, places ISRFunc in the table, and returns the index of the slot in the lookup table.
OEMISRUnregisterHandler(uInt32 isr_vector, uInt32 isr_param, ISRFunc isr_runFunc, uInt32 *register_param)
Printf: PDAStrSupport_os.c
This OS-specific C file implements printf, which uses the One Button Dialog function for non-UI targets. If you implement user interface support, use the CCG Console Out VI for printf functionality instead of PDAStrSupport_OS.c. If you do not implement user interface support, you can use PDAStrSupport_OS.c or the CCG Console Output VI.
13-6
ni.com
Chapter 13
Time: CCGTimeSupport_os.c
This OS-specific C file implements timing. It contains the following functions:
uInt32 LVGetTicks()
Purpose: Returns clock ticks in milliseconds. You must port this function because this function is used throughout the LabVIEW C Code Run-Time Library and generated C code.
Boolean DtToSecs(VoidPtr vpIn, DataType dt, uInt32 *pSecs )
Purpose: Converts a cluster containing date and time to seconds. This function is called directly from the generated C code to implement the Date/Time to Seconds function.
Boolean SecsToDt(void* pSecs, DataType dt, VoidPtr vpOut, DataType dtOut )
Purpose: Converts seconds to a cluster containing date and time. This function is called directly from the generated C code to implement the Seconds to Date/Time function.
Boolean LVGetDateTime(double dSecs, LVDateTime *pDateTime )
Purpose: Converts a time in seconds to date and time. If the seconds passed in is zero, this function returns the current time. This function is called directly from the generated C code to implement the Get Date/Time In Seconds function.
Serial: PlatformSerial_os.c
Use this OS-specific C file, which contains the following functions, for serial functions and for debugging over a serial connection.
SerialInit(SerialDevice ser, SerialConfig *cfg)
13-7
Chapter 13
CAN: PlatformCAN_os.c
Use this C file, which contains the following functions, for the Embedded CAN VIs and for debugging over a controller area network (CAN) connection.
MgErr LvCanOpen(uInt32 boardIdx, uInt32 controllerIdx, uInt32 *reference);
13-8
ni.com
Chapter 13
MgErr LvCanRead(uInt32 reference, uInt8 channelNum, int32 *bNewData, int32 *canID, uInt8 *len, uInt8 *data);
Purpose: Sets the CAN message filter for the specified open channel.
MgErr LvCanGetBaudRate(uInt32 reference, uInt32 *baudRate);
13-9
Chapter 13
TCP/UDP: CCGNetConnSupport.c
TCP communication is implemented on top of Berkeley sockets on all platforms and is used by TCP functions, UDP functions, remote Call By Reference Nodes, and TCP-based debugging. All Microprocessor SDK example targets support Berkeley sockets. The implementation file is CCGNetConnSupport.c, which is located in the following directory:
labview\CCodeGen\libsrc\comms CCGNetConnSupport.c can be OS-specific even though the file is located
Description Defines the maximum number of Generate Occurrence functions. Defines the maximum number of Wait on Occurrence functions. Defines the maximum number of ISR handler VIs. Defines the maximum number of critical section handles. Defines the maximum number of events. Defines the maximum number of external time sources. Defines the maximum number of Real-Time FIFOs. Defines the maximum size of an Real-Time FIFO in elements.
WAIT_ON_OCCURRENCE_MAX
13-10
ni.com
Chapter 13
The limit is the multiplier of these two numbers. The default values are both 64; thus the limit is 4,096. If you want to increase this limit, override the definitions in LVDefs_plat.h.
13-11
14
If you want to support interrupt service routines (ISRs) for your target, you must implement a set of functions in OEM_LVISR.c, which is located in the following directory:
labview\CCodeGen\libsrc\os\OS
where OS is the target operating system. The function prototypes are defined in LVISR.h, which is located in the following directory:
labview\CCodeGen\include\blockdiagram
ISR Functions
You must implement the following functions in OEM_LVISR.c if you want to support ISRs.
InitOEMISRs
Boolean InitOEMISRs();
Purpose: This function is called only by InitISRs. InitOEMISRs must do any required ISR subsystem initialization. Returns TRUE on success. Returns FALSE on failure.
UninitOEMISRs
Boolean UninitOEMISRs();
Purpose: This function is called only by UninitISRs. UninitOEMISRs must do any necessary ISR subsystem cleanup. Returns TRUE on success. Returns FALSE on failure.
14-1
Chapter 14
OEMISRRegisterHandler
Boolean OEMISRRegisterHandler (uInt32 isr_vector, uInt32 isr_param, ISRFunc isr_runFunc, uInt32 *register_param);
Purpose: This function is called only by ISRRegisterHandler. It performs the actual registration of the interrupt with the OS or with the hardware in the case of bare metal. isr_vector is the intended vector, isr_param is the parameter. Both isr_vector and isr_param are passed to ISRFunc isr_runFunc. register_param is an output parameter that is unique to this ISR registration instance. The register_param value is passed to OEMISRUnregisterHandler when unregistering the ISR. Returns TRUE on success. Returns FALSE on failure.
OEMISRUnregisterHandler
Boolean OEMISRUnregisterHandler (uInt32 isr_vector, uInt32 isr_param, ISRFunc isr_runFunc, uInt32 register_param);
Purpose: This function is called only by ISRUnregisterHandler. This function unregisters an ISR with the OS or with the hardware in the case of bare metal. register_param is the register parameter that OEMISRRegisterHandler returns. Returns TRUE on success. Returns FALSE on failure.
14-2
ni.com
Chapter 14
Allowable operations for an ISR VI are a subset of the allowable operations for a subroutine reentrant VI. Unallowable operations include asynchronous operations, such as file I/O, TCP/IP, Bluetooth, IrDA, and so on, plus any operations that can cause memory allocation, such as manipulating strings, arrays, and so on. The ISR VI parameters are meant to be general enough to handle most hardware and OS requirements. Depending on the platform, you might not need these parameters. If you do not need these parameters, you can optimize the ISR by passing zeros for the required parameters and have the ISR VI ignore them.
14-3
Timing
15
A Timed Loop executes a subdiagram, or frame, for each iteration of the loop at the period you specify. Use the Timed Loop when you want to develop VIs with multi-rate timing capabilities, precise timing, feedback on loop execution, timing characteristics that change dynamically, or several levels of execution priority. Embedded targets do not support timing source hierarchies in Timed Loops. You must define and implement your target-specific timing sources. You use the Target Editor to define the timing sources. Refer to the Defining Timing Sources section of Chapter 7, Creating a New Embedded Target, for information about the Timing Sources tab in the Target Editor. You must call the CreateInternalTSource() function for each timing source you define in the Target Editor before you call the top-level VI and after you initialize the run-time library. Define the LV_PLATFORM_RTL_INIT macro in LVDefs_plat.h as the name of the function to call before calling the top-level VI and after initializing the LabVIEW C Code Run-Time Library. Call the FireInternalTSource() function from driver code to generate the external timing source. You must call FireInternalTSource() with the same index as CreateInternalTSource() creates.
Note
Note FireInternalTSource() calls the LVEventSet() function, which not all targets can call from ISRs. If you cannot call LVEventSet() from an ISR, call FireInternalTSource() from a deferred interrupt handler.
Release all external timing sources when the embedded application finishes executing. Define the LV_PLATFORM_RTL_FINI macro in LVDefs_plat.h as the name of the function to call after the top-level VI finishes executing and before releasing the LabVIEW C Code Run-Time Library.
15-1
Chapter 15
Timing
LabVIEW adds the timing sources you define this way as options in the Configure Timed Loop dialog box.
CreateInternalTSource()
CreateInternalTSource(TextPtr sourceName, uInt32 iIntTSource)
Purpose: Creates an internal timing source with name sourceName and index iIntTSource. sourceName is the name of the timing source. Each timing source name must be unique. iIntTSource is a zero-based index parameter from <0, INT_TSOURCE_SIZE-1>. INT_TSOURCE_SIZE is a macro in LVDefs_plat.h that defines the total number of internal timing sources.
FireInternalTSource()
FireInternalTSource(uInt32 iCount, uInt32 iIntTSource)
Purpose: Generates the internal timing source that iIntTSource specifies. iCount is the number of iterations. iIntTSource is a zero-based index parameter from <0, INT_TSOURCE_SIZE-1>. INT_TSOURCE_SIZE is a macro in LVDefs_plat.h that defines the total number of internal timing sources.
DeleteInternalTSource()
DeleteInternalTSource(uInt32 iIntTSource)
Purpose: Deletes the internal timing source that iIntTSource specifies. iIntTSource is a zero-based index parameter from <0, INT_TSOURCE_SIZE-1>. INT_TSOURCE_SIZE is a macro in LVDefs_plat.h that defines the total number of internal timing sources.
15-2
ni.com
Chapter 15
Timing
For static memory models, you cannot use the timing source name as a terminal in the Timed Loop because the source name is a string and static memory models do not support strings. Implement the LVGetTicksExt () function to expose additional timing sources directly in the Configure Timed Loop dialog box, which means users do not have to use the Timed Loop VIs to create and generate timing sources. Adding additional timing sources make it easier for users to use your target because no additional programming is required to create and generate timing sources.
Note
15-3
Memory Mapping
16
Memory mapping maps particular code segments to particular RAM and ROM memory addresses on the processor. The LabVIEW Microprocessor SDK provides a framework to define memory layout and map input sections of generated C files into output sections of built embedded applications.
16-1
Chapter 16
Memory Mapping
LEP_x_SectionNames.vi
Defines the name of all memory sections users can map, such as RAM, ROM, and flash memory. Use descriptive names that users understand because users select the memory mapping from the names you implement in LEP_x_SectionNames.vi. This VI returns an array of strings that contain the list of section names.
LEP_x_MemoryMap_Default.vi
Defines the default mapping of VIs to memory sections on the target. This VI returns an array of configuration clusters. Each cluster corresponds to a VI type and contains a list of code sections and data sections that may be used for that VI type. The connector pane of this VI must match EMB_Utility_MemMap_VI_Default.ctl, which is located in the following directory:
labview\vi.lib\LabVIEW Targets\Embedded\Utilities\MemMap
LEP_x_MemoryMap_Cmp.vi
Implements the comparison operator for the configuration database. LEP_x_MemoryMap_Cmp.vi returns TRUE if the VI in the path control matches the VI in the VI Config cluster. You typically do not need to change this VI. The connector pane of this VI must match EMB_Utility_MemMap_VI_Compare.ctl, which is located in the following directory:
labview\vi.lib\LabVIEW Targets\Embedded\Utilities\MemMap
LEP_x_MemoryMap.vi
Reads the memory mapping configuration data from the .lvproj file, initializes the memory mapping framework, and displays the Map Memory dialog box to the user. You must change the paths to LEP_x_MemoryMapDefault.vi, LEP_x_MemoryMap_Cmp.vi, and the subVI calls to these two VIs.
16-2
ni.com
Chapter 16
Memory Mapping
Use EMB_Utility_MemMap_Init.vi to initialize the memory mapping framework. Call EMB_Utility_MemMap.vi to display the Map Memory dialog box to the user.
LEP_x_MemoryMap_Query.vi
Queries the memory mapping database for the memory section assigned to a given VI. LEP_x_ScriptCompiler.vi can call LEP_x_MemoryMap_Query.vi for each compiled source file to assign data structures and functions to explicit input memory sections. LEP_x_ScriptLinker.vi can call LEP_x_MemoryMap_Query.vi to generate or modify the linker definition file. You must change the paths to LEP_x_MemoryMapDefault.vi, LEP_x_MemoryMap_Cmp.vi, and the subVI calls to these two VIs. Refer to LEP_vxworks_cmd565_rom_MemoryMap_Query.vi, which is located in the following directory, for an example implementation:
labview\Targets\NI\Embedded\vxworks\cmd565\rom\ vxworks_cmd565_rom_LEP_TargetPlugin\
Refer to LEP_vxworks_cmd565_rom_ScriptCompiler.vi, which is located in the following directory, for an example usage:
labview\Targets\NI\Embedded\vxworks\cmd565\rom\ vxworks_cmd565_rom_LEP_TargetPlugin\
16-3
17
You can implement instrumented debugging with LabVIEW to communicate with an embedded application running on an embedded target to provide front panel connectivity, probes, and block diagram breakpoints. Instrumented debugging occurs through synchronization and data-transfer routines in the generated C code of an embedded VI. These routines use an underlying communication layer, which you must provide for your embedded targets and LabVIEW. You use plug-in VIs to implement the instrumented debugging communication layer for LabVIEW. You use C functions to implement the instrumented debugging communication layer on the embedded target. If you are using serial or TCP communication, you do not have to implement these communication layers. Instead, you can use the existing communication layer the Microprocessor SDK example targets use.
17-1
Chapter 17
Read VI Write VI
Place these VIs in your target directory. Refer to the Spectrum Digital DSK6713 example target for a host debugging implementation example. The host debugging plug-in VIs for the Spectrum Digital DSK6713 example target are located in the following directory:
labview\Targets\NI\Embedded\dsp_bios\DSK6713\TMS_TargetPlugin\debug_plugin Note
If you start with this example implementation, the labels of the controls and indicators must match your implementation exactly.
Open VI
Establishes a connection with the embedded target. Your Open VI must have the following parameters on the connector pane: connection dataA variant indicator. Place data for the debugging connection in this variant. You pass in this variant to all of the other debugging plug-in VIs. You can modify this variant so you can communicate between plug-in VIs you call at different times. error outAn error cluster indicator.
Close VI
Closes the connection with the embedded target. Your Close VI must have the following parameters on the connector pane: connection dataA variant control. You can modify this variant so you can communicate between debugging plug-in VIs you call at different times. error outAn error cluster indicator.
Read VI
Reads data from the embedded target. Your Read VI must have the following parameters on the connector pane: connection dataA variant control. The contents of this variant come from the last invocation of an instrumented debugging plug-in VI.
17-2
ni.com
Chapter 17
bytes to readA 32-bit signed integer numeric control that is the number of bytes read from the embedded target. connection IDA 32-bit signed integer numeric control that identifies the instrumented debugging session. error outAn error cluster indicator.
After the read has finished, your Read VI must call nitargetReadData.vi, which is located in the following directory:
labview\vi.lib\LabVIEW Targets\TargetShared nitargetReadData.vi sends the data that you read to LabVIEW. Wire the data read to the Data Read input in nitargetReadData.vi. Wire the connection ID from your Read VI to the Connection ID input in nitargetReadData.vi.
Write VI
Writes data from LabVIEW to the embedded target. Your Write VI must be blocking so when the VI finishes, LabVIEW expects this VI to send the data to the embedded application. Your Write VI must have the following items on the connector pane: connection dataA variant control. The contents of this variant come from the last invocation of an instrumented debugging plug-in VI. data to sendA string control. The contents of this string is the data to send to the embedded target. error outAn error cluster indicator.
Implementing the Instrumented Debugging Communication Layer for Your Embedded Target
To implement instrumented debugging for your embedded target, you must create an instance of the following C functions in the LabVIEW C Code Run-Time Library:
DebugBytes DebugConnect DebugDisconnect DebugRead
17-3
Chapter 17
Also, you must assign global function pointers to the functions you create so that the LabVIEW C Code Run-Time Library can use the functions for debugging connections.
Tip
Use new, unique names for your functions to avoid linker errors. The Microprocessor SDK provides examples of serial and TCP implementations for the target-side communication layer. The serial implementation is located in the following file:
labview\CCodeGen\libsrc\comms\SerialMessaging.c
If you are using TCP communication, you should not have to modify TCPMessaging.c unless you want to use a port other than 0.
DebugBytes
eRunStatus DebugBytes(uInt32* bytes)
Returns the number of bytes that bytes can read. Store 0 in bytes if no bytes are available. Return eFail if there is an error. Otherwise, return eFinished.
DebugConnect
eRunStatus DebugConnect(void)
Opens a connection to LabVIEW and establishes a connection to your Open host debugging plug-in VI. Return eFail if there is an error. Return eNotFinished if you cannot connect to the host. Return eFinished for a successful connection.
17-4
ni.com
Chapter 17
DebugDisconnect
eRunStatus DebugDisconnect(void)
Closes the current connection to LabVIEW. Return eFail if there is an error. Otherwise, return eFinished.
PrepareConnection
eRunStatus PrepareConnection(void)
Prepares a debugging connection. If you are using TCP/IP, this function opens a non-blocking TCP/IP port and listens for a connection. The DebugConnect function then accepts the connection. If you are using a GSM modem to connect to the host computer, this function configures the radio modem, starts the radio modem, and enters the PIN code. The DebugConnect function checks for and accepts pending calls. Return eFail if there is an error. Otherwise, return eFinished.
DebugRead
eRunStatus DebugRead(char** pData, uInt32 reqBytes, uInt32* actualBytes)
Reads the number of bytes reqBytes indicates. Returns the number of actual bytes read in actualBytes. actualBytes and reqBytes are equal when the read is complete. Allocate a buffer in pData to return the data. Return eFail if there is an error. Otherwise, return eFinished.
ReleaseConnection
eRunStatus ReleaseConnection(void)
Releases the resources the PrepareConnection function allocates. If you are using TCP/IP, this function also closes the listening port. Return eFail if there is an error. Otherwise, return eFinished.
DebugWrite
eRunStatus DebugWrite(const char* pData, uInt32 size)
Writes the data to which pData points. size indicates the number of bytes to write. Do not delete pData. Return eFail if there is an error. Otherwise, return eFinished.
17-5
Chapter 17
Assign the target-side instrumented debugging functions to the global LabVIEW C Code Run-Time Library function pointers in the DebugComm.c run-time source file in the CCGDebugInitializeComm() function. Add a new C preprocessor identifier that describes the debugger connection mechanism. Pre-existing identifiers include UsesTCPDebugger, UsesSerialDebugger, and UsesCANDebugger. When you script the compiler to build an embedded application, verify you are defining the new identifier if you are building an application you can debug. Make a new #elif case in CCGDebugInitializeComm(), and assign the follow function pointers:
CCGDebugConnect: Assign this pointer to the DebugConnect
function.
CCGDebugDisconnect: Assign this pointer to the DebugDisconnect function. CCGDebugRead: Assign this pointer to the DebugRead function. CCGDebugWrite: Assign this pointer to the DebugWrite function. CCGDebugBytes: Assign this pointer to the DebugBytes function. CCGDebugPrepareConnection: Assign this pointer to the PrepareConnection function. CCGDebugReleaseConnection: Assign this pointer to the ReleaseConnection function. CCGDebugWaitOnMessage: Assign this pointer to the CCGDebugGenericWaitOnMessage function. CCGDebugGetMsg: Assign this pointer to the CCGDebugGenericGetMsg function. CCGDebugSendMsg: Assign this pointer to the CCGDebugGenericSendMsg function.
17-6
ni.com
On Chip Debugging
18
Debug Process LabVIEW
You can use custom plug-in VIs to extend the on chip debugging (OCDI) debugging framework, which is compatible with the stabs format, to support various in-circuit emulators (ICE) and toolchains for your target. The following figure illustrates the OCDI debugging framework.
Generated C files
.c parser
Debug Database
Debug Daemon
C compiler
.lst files
.lst parser
.lvm file
Linker
.map file
.map parser
The core of the OCDI debugging framework is the debug database. The debug database contains a map of all possible signals, breakpoint, controls, and indicators in the physical memory of the embedded target. The debug database also contains line numbers and information for each node on the block diagram of the embedded VI. When you build an embedded VI into an embedded application using OCDI debugging options, the LabVIEW C Code Generator generates C files from the block diagram.
18-1
Chapter 18
On Chip Debugging
The C parser parses every C file the LabVIEW C Code Generator generates for special comments to initialize the debug database with breakpoint, signal, and control records. Your toolchain compiler outputs an intermediate object module and list files so the list parser can translate line numbers in the C code into relative symbol offsets. The list parser updates the line number to the function (name, offset) pair. The linker generates a map file that contains the absolute addresses for all symbols. The map parser reads the map file the linker generates and resolves all symbols in the debug database by iterating through and updating all of the records in the debug database. The debug database generates a LabVIEW map (LVM) file, which is an ASCII text file. The LVM file is the contents of the debug database and contains all of the information required to debug an embedded application without the source code and intermediate files. The debug daemon loads the LVM file when the debugging session is initialized. The debug daemon communicates with the emulator using the OCDI Debugging plug-in VIs, which implement a low-level interface to a third-party emulator library. Refer to Chapter 19, Understanding the LabVIEW Embedded LVM File, for more information about the LVM file. Refer to the following sections in this chapter for more information about the other pieces of the OCDI debugging framework.
simple_math.vi, shown in the following figure, is used as an example
You can use a JTAG, BDM, or NEXUS connection to perform on chip debugging of an embedded application.
18-2
ni.com
Chapter 18
On Chip Debugging
Debug Database
The debug database is a collection of records for all controls, signals, and breakpoints in the embedded application VI hierarchy. The debug database also contains C line number information for nodes on the block diagram. The build VI initializes the database before the first C file is compiled, usually in the setup stage of the build VI. The C parser inserts records in the debug database for all signals, controls, and breakpoints. The list parser maps the breakpoint line numbers into relative symbol offsets and updates all breakpoint records in the debug database. Finally, the map parser resolves all symbols and updates all database records so they contain absolute addresses of the embedded application. The database snapshot is then saved in the LVM file, which is located in the project build folder. The debug daemon automatically loads the LVM file every time you debug a built application. The debug database also contains additional index tables that improve the performance of the database so the debug daemon does not have to sequentially search object records. Index tables are not stored in the LVM file. Instead, the debug daemon re-indexes the database every time the LVM file is loaded.
C Parser
The C parser searches the generated C code for special comments and maps the comments to line numbers. When a user selects On Chip debugging in the Build Specification Properties dialog box, the LabVIEW C Code Generator adds a set of comments to the generated C code to indicate potential probes, breakpoints, controls, and indicators. For example, the following code sample shows the comments generated for simple_math.vi:
hA8EA7A0->sCA8/* n: MultiplyConstant */ = 5.0000000000000000000E+2; hA8EA7A0->sA9C/* n: DivideConstant */ = 1.0000000000000000000E+2; hA8EA7A0->sBEC/* n: NumberIn */ =NumberIn__1364; OCDI_BEGIN_NODE(profileInfo_simple_math, 0, 2) /* OCDI::Begin::Node(1, 2, 3) */ /**/ /* Multiply */ /**/ OCDI_CHECK_POINT(simple_math_OCDIFlag[0] & 0x1, &simple_math_OCDIFlag, 0)/* OCDI::BreakPoint::Node(1, 2, 3) */
18-3
Chapter 18
On Chip Debugging
hA8EA7A0->sB58/* n: Multiply: x*y */ = hA8EA7A0->sBEC/* n: NumberIn */ * hA8EA7A0->sCA8/* n: MultiplyConstant */; OCDI_END_NODE(profileInfo_simple_math, 0, 2) /* OCDI::End::Node(1, 2, 3) */ OCDI_BEGIN_NODE(profileInfo_simple_math, 1, 3) /* OCDI::Begin::Node(2, 3, 3) */ /**/ /* Divide */ /**/ OCDI_CHECK_POINT(simple_math_OCDIFlag[0] & 0x2, &simple_math_OCDIFlag, 1)/* OCDI::BreakPoint::Node(2, 3, 3) */ hA8EA7A0->sA08/* n: Divide: x/y */ = (float64)hA8EA7A0->sB58/* n: Multiply: x*y *//(float64)hA8EA7A0->sA9C/* n:DivideConstant */; OCDI_END_NODE(profileInfo_simple_math, 1, 3) /* OCDI::End::Node(2, 3, 3) */ if (NumberOut__616) { *NumberOut__616 =hA8EA7A0->sA08/* n: Divide: x/y */; } return eFinished;
This information, which is stored in the debug database, translates control and signal IDs into relative symbol addresses. The database records for all breakpoints only map breakpoint IDs into line numbers. For controls and indicators, the C parser does not store actual offsets because the parser does not know the layout of the _ControlData structure. Instead, the parser stores indexes to the _ControlData table. To convert the index value to the actual offset, you must multiply the index value with the size of the _ControlData structure and add the offset of the hValue variable. The list parser must resolve relative offsets of all breakpoints. You do not need to port the C parser because the parser is target independent. The C parser generates the bold portion of the following LVM file for simple_math.vi:
[simple_math.vi] Node(1,2,3)@92=0x4011BF Node(2,3,3)@99=0x40122B Location.Node(1,2,3)@[88..94] Location.Node(2,3,3)@[95..101] SID_2716=0x4727A0 SID_2904=0x4727A8 SID_3052=0x4727B0
18-4
ni.com
Chapter 18
On Chip Debugging
SID_3240=0x4727B8 SID_2568=0x4727C0
For nodes, the syntax for this portion of the LVM file is as follows:
Node(a, b, c)@x=...
where (a, b, c) represents the unique LabVIEW-generated coordinates that identify the node on the block diagram, and x represents the line number where the comment occurs. For node location information, the syntax for this portion of the LVM file is as follows:
Location.Node(1,2,3)@[123...456] Location.SNode(1,2,3)@[123...456] Location.SRN(1,2,3)@[123...456]
where Location.Node represents nodes, Location.SNode represents structures, and Location.SRN represents self-referencing nodes. [123...456] represents the line numbers in the generated C file. For controls and signals, the syntax for this portion of the LVM file is as follows:
CID_i=... SID_i=...
where CID represents Control ID, SID represents Signal ID, and i represents the unique LabVIEW-generated object ID.
C Compiler
The build plug-in VI calls a third-party target-specific compiler for each generated LabVIEW C Code Run-Time Library and external source file. The generated C code contains special comments that help the C parser find the symbols of all controls, signals, and positions of all possible breakpoints in the VI. The C compiler outputs an intermediate object module and a list file. The list file must contain enough information to enable the list parser to translate line numbers of the generated C files into relative symbol offsets. Executing the compiler with the correct debugging and list options is important for generating a list file that the list parser can understand.
18-5
Chapter 18
On Chip Debugging
Note
Parsing the list and map files is one way of extracting the necessary information to populate the LVM file. Your toolchain might provide a different way to extract the necessary information.
List Parser
The list (.lst) parser is a compiler-specific component. The example targets use a GCC-specific parser located in the following directory:
labview\vi.lib\LabVIEW Targets\Embedded\Debug\Map\GCC
You must implement your own list parser if your compiler cannot generate the list file in a compatible stabs format. If your compiler cannot generate the list file to map lines of compiled source code into relative symbol addresses, you cannot support breakpoints in the pure On Chip debugging mode. You still can build embedded applications in the On Chip (Release) debugging mode. The On Chip (Release) mode implements the OCDI_Checkpoint macro, so the running embedded application must evaluate simple checkpoint expressions every time the application approaches a possible LabVIEW breakpoint. The OCDI_Checkpoint macro is left blank for the pure On Chip debugging mode, which eliminates the need for the list parser, but slightly changes the timing of the embedded application.
Note
The OCDI_Checkpoint macro is defined in LVDefs_plat.h. The list parser serves two primary purposes in populating the debug database and generating the LVM file. First, the list parser helps to resolve the lines of C code to series of relative offsets based on one or two variables. This map does not contain entries for lines for which the C compiler does not generate assembly code. Second, the list parser populates data type alignment information that is specific to how the compiler handles the alignment of the LabVIEW data type structures. The list parser determines which nodes and signals to locate by querying the debug database, which the C parser populates. The following example shows the LVM file for simple_math.vi after resolving the signals and nodes to a series of hexadecimal offsets, which are shown in bold. The memory locations are still only known relative to yet unresolved symbols. Absolute memory address information is not available at this phase.
[simple_math.vi] Node(1, 2, 3)@64=simple_math_Run+0x58 Node(2, 3, 3)@68=simple_math_Run+0x6C
18-6
ni.com
Chapter 18
On Chip Debugging
The list parser also populates the debug database with information about the compiler byte packing. These descriptions are based on compiler-specific information and are necessary so that the debug daemon knows which bytes correspond to the actual binary data value of the control or signal. If you are sure that the compiler alignment options are fixed and you are not providing that level of control to users, generate this information as a static string. The bold portion in the following example defines the Boolean data type.
[Offset_Table] BigEndian=1 BooleanData=4 BooleanData.bInput=16, 8 BooleanData.bStatic=0, 8 BooleanData.bVal=8, 8 BooleanData.padding=1=24, 8 NumericData=12 NumericData.bInput=48,8 LVBoolean.h defines this data type in the following directory: labview\CCodeGen\include\frontpanel
The members of the following C data structure mirrors those listed in the LVM file.
18-7
Chapter 18
On Chip Debugging
where
L represents the length of the entire data type in bytes j represents the offset from the beginning of the data structure in bits k represents the length of the data member in bits
Refer to Chapter 19, Understanding the LabVIEW Embedded LVM File, for more information about the LVM file and the [Offset_Table]. In addition, the LVM file needs information from the LabVIEW project to completely decouple the LabVIEW development environment from the debugging interface.
Linker
The linker links all intermediate object files, external files, and operating system libraries to produce the application image. The On Chip debugging modes require the linker to generate the map file that is used to resolve symbols of the built image. You can execute the linker with the correct command line options to generate the map file in a format that the map parser can understand. You can execute the linker with command line options to remove all debugging information and all symbols unless you want to debug an embedded application at the source level. LabVIEW does not use the debugging information for the built application. The map file does not have to be generated for targets with downloadable module support, such as the VxWorks downloadable module. The target must resolve all symbols at the module load time.
Map Parser
The map parser runs through the map file (.map) the linker generates and creates a structure that maps symbol names to absolute addresses of the built image. The map parser is a linker-specific component that you must implement if your linker does not produce the map file compatible with the example map parser. The map parser then resolves all symbols in the debug database. The map parser does not execute for targets that build a downloadable module. The target must resolve all symbols at module load time.
18-8
ni.com
Chapter 18
On Chip Debugging
Map file parsing resolves the previously unresolved symbols and converts the relative addresses the list parser generates to physical address for the embedded target. The resolved addresses are shown in bold in the following LVM file for simple_math.vi:
[simple_math.vi] Node(1, 2, 3)@64=0x1476C Node(2, 3, 3)@68=0x14780 SID_2360=0xB5C50 SID_2212=0xB5C58 SID_3104=0xB5C60 SID_1988=0xB5C68 SID_1332=0xB5C70
When all of the symbols are resolved, the LVM file is ready for use with LabVIEW and the debug daemon.
Debug Daemon
The debug database provides a high-level interface LabVIEW uses to debug an application running on an embedded target. The debug daemon uses data from the debug database to translate LabVIEW object IDs into absolute addresses and absolute addresses of pending breakpoints back to LabVIEW IDs so LabVIEW can highlight the corresponding nodes. The debug daemon uses the OCDI debugging plug-in VIs, which are emulator-specific VIs that instrument actual emulator hardware. All OCDI debugging plug-in VIs must implement a common set of methods the debug daemon can call to set a breakpoint, clear a breakpoint, get a breakpoint, read target memory, write target memory, and so on. The debug daemon completely isolates LabVIEW and the emulator from each other. The LabVIEW debugger does not know anything about absolute object addresses and the user emulator interface. The OCDI debugging plug-in VIs do not have to deal with internal LabVIEW object IDs.
18-9
Chapter 18
On Chip Debugging
The On Chip debugging mode does not affect the execution of the built embedded application because this mode does not modify the generated C code. The On Chip (Release) debugging mode affects the execution of the embedded application because this mode adds extra checkpoint code for all possible LabVIEW breakpoints. Use the On Chip (Release) debugging mode in the following situations:
Note
If your C compiler cannot generate list files to map lines of generated C code to the relative symbol offsets. If you need to debug an optimized application. If your emulator has limited breakpoints. If you want to use hardware breakpoints.
Not all targets can support on chip debugging. On chip debugging might require special debugging hardware, such as JTAG, BDM, or a Nexus emulator.
If you have a DWARF parser, generate the LVM file instead of completing the following steps. 1. Call EMB_Debug_DD_Init.vi, which is located in the labview\vi.lib\LabVIEW Targets\Embedded\Debug\DD directory, from your build VI before the build script executes to initialize the debug database. Refer to LEP_vxworks_Build.vi for an example of how to use EMB_Debug_DD_Init.vi. LEP_vxworks_Build.vi is located in the following directory:
labview\Targets\NI\Embedded\vxworks\vxworks_LEP_TargetPlugin
2.
Call EMB_Debug_Map_Gcc_UpdateDD.vi, which is located in the labview\vi.lib\LabVIEW Targets\Embedded\Debug\ Map\GCC directory, for every compiled generated source file. EMB_Debug_Map_Gcc_UpdateDD.vi parses the source file and the list file the compiler generates and updates the debug database. LEP_x_ScriptCompiler.vi should call this VI only if the On Chip debugging mode is enabled in the Build Specification Properties
18-10
ni.com
Chapter 18
On Chip Debugging
dialog box. You must configure the compiler to generate the list file so that the list parser that EMB_Debug_Map_Gcc_UpdateDD.vi calls can understand it. Refer to the following example batch file, which executes a GCC compiler to compile the C file and generates the list file in stabs format.
labview\Targets\NI\Embedded\vxworks\cmd565\utils\compiled.bat
3.
Call EMB_Debug_Map_Gcc_ResolveSymbols.vi and EMB_Debug_Map_Gcc_ResolveExtraSymbols.vi after the build script executes to parse the map file and resolve all symbols in the debug database. Refer to LEP_vxworks_cmd565_ram_ScriptLinker.vi for an example of how to set the release debug only attributes, call the resolve symbols, resolve extra VIs to parse the map file the linker generates, and resolve all symbols in the debug database. EMB_Debug_Map_Gcc_ResolveSymbols.vi and EMB_Debug_Map_Gcc_ResolveExtraSymbols.vi are located in the following directory:
labview\vi.lib\LabVIEW Targets\Embedded\Debug\Map\GCC
4.
Call EMB_Debug_DD_Save.vi after the build script executes to save the contents of the debug database to the LVM file. You must save the LVM file in the project directory. The LVM file must have the same name as the LabVIEW project.
Refer to LEP_vxworks_cmd565_ScriptCompiler.vi for an example of retrieving configuration data, defining the release debug macro, and calling EMB_Debug_Map_Gcc_UpdateDD.vi to parse source and list files. LEP_vxworks_cmd565_ScriptCompiler.vi is located in the following directory:
labview\Targets\NI\Embedded\vxworks\cmd565\vxworks_cmd565_LEP_TargetPlugin Note
18-11
Chapter 18
On Chip Debugging
EMB_Debug_Map_x_UpdateDD.vi
Calls the C parser to initialize the debug database with all breakpoints, signal, and control IDs. The object absolute addresses are left blank at this phase. LEP_x_ScriptCompiler.vi calls the list parser to parse the list file the compiler generates and assigns relative symbol offsets to all objects in the debug database.
EMB_Debug_Map_x_ResolveSymbols.vi
Parses the file the linker generates and resolves all objects in the debug database. You must resolve the following two types of relative addresses: Relative addresses in the form of variable + offset. You must find the absolute addresses of the symbol, add the offset, and store the resulting address back to the debug database. For example, __ocdi1_heap + 0x345. Signals in the form of variable.member (type_code). You must find the offset of the member relative to the beginning of the variable and transform the offsets into a relative address of variable + member_offset. For example, __ocdi1_heap.c_error_in__no_error_((33,3,7)).
18-12
ni.com
Chapter 18
On Chip Debugging
types or is in the form of (type_code1, type_code2,and so on), where type_code1, type_code2 are numeric values for cluster data types as shown in the following code sample:
struct _ocdi1_heap { cl_00000 c_error_in__no_error_; /* c: error in (no error) */ int32 l_Constant; /* l: Constant */ int32 l_For_Loop_N; /* l: For Loop: N */ int32 l_sum; /* l: sum */ Boolean c_error_in__no_error__CS; /* c: error in (no error): CS */ } _DATA_SECTION __ocdi1_heap; /* hB3A9B04 */ struct _ocdi1_heap _DATA_SECTION *hB3A9B04 = &__ocdi1_heap; /* hB3A9B04 */ /* OCDI::Memory::Heap = __ocdi1_heap */ /* OCDI::Memory::Signal::0x20FC = __ocdi1_heap.c_error_in__no_error_ ((33,3,7)) */ /* OCDI::Memory::Signal::0x77C = __ocdi1_heap.l_Constant (3) */ /* OCDI::Memory::Signal::0x460 = __ocdi1_heap.l_For_Loop_N (3) */ /* OCDI::Memory::Signal::0x1218 = __ocdi1_heap.l_sum (3) */ /* OCDI::Memory::Signal::0x14CC = __ocdi1_heap.c_error_in__no_error__CS (33) */
The C parser uses the extra comments to generate the symbols for the signals in the form of variable.member (type_code). For example, __ocdi1_heap.1_Constant(3). Use the following VIs to compute the member offset from signal type information and target-specific alignment:
Emb_Debug_Map_RelativeAddress.vi Emb_Debug_Map_SignalOffset.vi
18-13
Chapter 18
On Chip Debugging
labview\vi.lib\LabVIEW Targets\Embedded\Embedded\OCDI
2. 3. 4. 5.
Copy the contents of the iOPEN directory, which contains the plug-in VI implementations for all WindRiver emulators. Rename all of the VIs in the directory you created in step 1 to match the name of folder. Do not rename EMB_Debug_OCDI.ini. Edit EMB_Debug_OCDI.ini so all tokens point to the VIs you renamed in step 3. Change the implementation of all VIs in the root directory. Implementation of some methods is optional.
An example list parser for GCC-compatible compilers that can generate list files in stabs format is located in the following directory:
labview\vi.lib\LabVIEW Targets\Embedded\Debug\Map
Refer to the following directory for examples of support for various emulators:
labview\vi.lib\LabVIEW Targets\Embedded\Debug\OCDI
18-14
ni.com
Chapter 18
On Chip Debugging
Refer to the GCC implementation for an example of how to implement these VIs. The GCC implementation is located in the following directory:
labview\vi.lib\LabVIEW Targets\Embedded\Debug\Map\GCC
EMB_Debug_Map_RelativeAddress.vi
Calculates the relative address of a symbol in the format variable + offset or variable.member (type_code).
relative address is the relative address to process. last base variable is the last base variable this VI generates. last offset is the last offset this VI generates. base variable is the base variable of the relative address. offset is the offset of the relative address. offset+size is the end offset of the symbol.
EMB_Debug_Map_SignalOffset.vi
Calculates the offset of a member in a structure based on the member type information and target alignment rules.
initial offset is the ending offset of the previous member of the structure. initial offset is 0 for the first member in the structure.
18-15
Chapter 18
On Chip Debugging
symbol is the symbol name in the form of variable.member (type_code). offset is the offset of the member in the structure. offset+length is the ending offset of the member in the structure.
IInit.vi
Establishes the debug connection to the hardware and returns the breakpoint occurrence by initializing a low-level emulator driver, connecting to the emulator, and returning a reference to the LabVIEW occurrence that the low-level driver signals every time the emulator encounters a breakpoint event on the target. You can spawn a background VI that polls a low-level emulator API for events and sets breakpoint occurrences as needed. How you implement this VI depends on the behavior of your emulator. You can use the build ID input to prevent users from downloading and debugging an embedded application from two different build specifications. Call the Occur() function to signal an occurrence from the driver DLL. You must include the driver DLL in the extcode.h header file, which is located in the labview\cintools directory, and link with labview.lib, which also is located in the labview\cintools directory.
Note
build ID is the ID of the build specification project item from which this VI is called.
18-16
ni.com
Chapter 18
On Chip Debugging
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. occurrence indicates a breakpoint occurrence, which the low-level emulator driver signals when a hardware or software breakpoint is encountered. You can set an occurrence from a driver VI or DLL. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
18-17
Chapter 18
On Chip Debugging
IClearBreakpoints.vi
Clears breakpoints on given absolute addresses.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. address list is an array of absolute breakpoint addresses. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred.
18-18
ni.com
Chapter 18
On Chip Debugging
code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IConfig.vi
Invokes an emulator-specific configuration dialog box. This VI is called when a user selects Configure from the build specification shortcut menu to configure the emulator. A use case for a configuration dialog box is if you want one configuration dialog box for multiple emulators.
build ID is the ID of the build specification project item from which this VI is called. target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code.
National Instruments Corporation 18-19 Microprocessor SDK Porting Guide
Chapter 18
On Chip Debugging
source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IContExecution.vi
Resumes execution of the target until the next breakpoint is encountered. This plug-in VI is called when an application a user is debugging stops because of a breakpoint event and the user clicks the Pause button or one of the single-stepping buttons to continue execution from the current position of the program counter.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and
18-20
ni.com
Chapter 18
On Chip Debugging
error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
18-21
Chapter 18
On Chip Debugging
IDownload.vi
Downloads the embedded application to target memory. This plug-in VI is called when a user selects Download from the build specification shortcut menu, which instruments the emulator to download the application using dedicated or just memory write functions. For example, some APIs have a download function and some do not. If an API does not have a download function, you must implement download using memory write functions.
build ID is the ID of the build specification project item from which this VI is called. target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. path is the absolute local path to the application image. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code.
18-22
ni.com
Chapter 18
On Chip Debugging
source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IExit.vi
Closes all connections and releases all resources associated with a specific target. The IRelease plug-in VI calls this plug-in VI when a user removes a target from a project or the project is closed.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this
18-23
Chapter 18
On Chip Debugging
information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IGetBreakpoint.vi
Retrieves the current breakpoint when the low-level emulator driver signals a breakpoint occurrence.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface.
18-24
ni.com
Chapter 18
On Chip Debugging
error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. address is the absolute breakpoint address. breakpoint indicates the active breakpoint. breakpoint must be TRUE only the first time a breakpoint occurs when this plug-in VI is called. breakpoint must be FALSE for all subsequent calls to this plug-in VI until the next breakpoint is encountered. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
18-25
Chapter 18
On Chip Debugging
IGo.vi
Executes the downloaded image on the target. This plug-in VI is called from the build specification shortcut menu and instruments the emulator to set the program counter initial value and continue execution.
build ID is the ID of the build specification project item from which this VI is called. target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error.
Microprocessor SDK Porting Guide 18-26 ni.com
Chapter 18
On Chip Debugging
status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IMemoryRead.vi
Reads one or more memory blocks from the target. LabVIEW combines front panel reads and probe reads into as few IMemoryRead plug-in calls as possible without further optimizations. This plug-in VI can join passed block requests into fewer, but longer, blocks with some overhead to improve overall emulator performance. The optimization algorithm depends on the type of emulator connection.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. address is an array of memory block base addresses. block size is an array of memory block sizes. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs.
18-27
Chapter 18
On Chip Debugging
status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. data is the target data. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IMemoryWrite.vi
Writes memory blocks to the target when a user changes the value of a front panel control while debugging.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface.
18-28
ni.com
Chapter 18
On Chip Debugging
address is an array of memory block base addresses. block size is an array of memory block sizes. data is the target data. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
18-29
Chapter 18
On Chip Debugging
IPauseExecution.vi
Pauses the execution of a debugged application when a user clicks the Pause button in LabVIEW and sends an indSuspend indication from another IDE back to LabVIEW. Implementing this VI is optional.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred.
18-30
ni.com
Chapter 18
On Chip Debugging
code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IRelease.vi
Closes all background VIs and releases the connection to the emulator API. How you implement this VI depends on the behavior of your emulator. The LabVIEW download, run, and debug commands call the IInit and IRelease plug-in VIs before and after each command, so this VI is called multiple times. You must ensure that the emulator does not reset the target every time the IInit plug-in VI is called, which would invalidate the target memory before the debug or run commands. If you try to call IRelease before the download, debug, and/or run commands, debugging and running the application does not work. National Instruments recommends connecting to the emulator only when the IInit plug-in VI is called for the first time or when the emulator is in a state that requires initialization. Do not disconnect from the emulator when the IRelease plug-in VI is called. The drawback of this recommendation is that LabVIEW keeps an open and active connection to the emulator. You must then release the debug connection and all associated resources from the IExit plug-in VI that is called when a target item is deleted from the project or the project is closed.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and
18-31
Chapter 18
On Chip Debugging
error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. end connection is TRUE if a users clicks the Abort Execution button when debugging a VI. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IResolveAddress.vi
Converts an address to a C filename/line number pair for dual debugging with another IDE. Implementing this VI is optional.
18-32
ni.com
Chapter 18
On Chip Debugging
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. address is the absolute breakpoint address. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. file name is the corresponding C file for the address. line number is the line number that corresponds to the address. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code.
18-33
Chapter 18
On Chip Debugging
source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IResolveSymbols.vi
Resolves relative breakpoint, signal, and control addresses on targets that use loaders or have operating systems that support dynamic linking. You must implement this VI if the final linking happens on the embedded target. If not, implementing this VI is optional. The loader or OS must expose the ability to return the absolute address of the symbols in the symbol list. LabVIEW uses the information this plug-in VI returns to resolve all symbols in the debug database.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. symbol list is an array of symbol names to resolve. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code.
18-34
ni.com
Chapter 18
On Chip Debugging
source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. address list is an array of absolute addresses of symbols in the symbol list. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
ISetBreakpoints.vi
Sets one or more hardware or software breakpoints on specified absolute addresses.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. address list is an array of absolute breakpoint addresses. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error
18-35
Chapter 18
On Chip Debugging
out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IStop.vi
Aborts the execution of a debugged application when a user clicks the Abort Execution button. Implementing this VI is optional.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface.
18-36
ni.com
Chapter 18
On Chip Debugging
error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
18-37
19
The LabVIEW map (LVM) file is an ASCII text file that the debug database generates. The debug database contains a map of all possible signals, breakpoints, controls, and indicators in the physical memory of the embedded target. The debug database also contains line numbers and information for each node on the block diagram. LabVIEW uses this information to map the current debugging position in a C file to a node on the block diagram. LabVIEW assigns each object an object ID. The LVM file resolves each object ID to a physical memory address on the target. Also, you can map physical memory addresses back to the associated LabVIEW object IDs for real-time interaction between LabVIEW and an embedded application.
Note The LVM file described here is not the same text-based measurement file (.lvm) that is used in VIs for Windows, but the file extensions are the same.
19-1
Chapter 19
19-2
ni.com
Chapter 19
ClusterControlData.pDefaultVal=32,32 ClusterControlData.pOldVal=0,32 ClusterControlData.pSmallCls=128,1024 ClusterControlData.pVal=64,32 EnumCtlData=20 EnumCtlData.bInput=136,8 EnumCtlData.bStatic=128,8 EnumCtlData.datatype=0,32 EnumCtlData.defaultVal=64,32 EnumCtlData.nValue=32,32 EnumCtlData.numItems=96,32 NumericData=24 NumericData.bInput=48,8 NumericData.bStatic=40,8 NumericData.datasize=32,8 NumericData.datatype=0,32 NumericData.pData=64,128 NumericData.padding1=56,8 PictInfo=52 PictInfo.bHidden=384,8 PictInfo.bounds=128,64 PictInfo.color=352,32 PictInfo.currentBackColor=224,32 PictInfo.currentForeColor=192,32 PictInfo.currentTextColor=256,32 PictInfo.currentX=64,32 PictInfo.currentY=96,32 PictInfo.dc=32,32 PictInfo.dirty=16,16 PictInfo.hDefaultValue=320,32 PictInfo.hPictCode=288,32 PictInfo.refcnt=0,16 ReleaseDebugMode=0 StringData=16 StringData.bStatic=64,8 StringData.bufferLen=32,32 StringData.len=0,32 StringData.pValue=96,32 StringData.padding=72,24 _ControlData=20 _ControlData.controlIdx=0,32 _ControlData.dataType=96,32 _ControlData.fieldType=128,32 _ControlData.hValue=64,32
19-3
Chapter 19
_ControlData.parentIdx=32,32 _LVGraphData=16 _LVGraphData.bStatic=64,8 _LVGraphData.datatype=0,32 _LVGraphData.dtDataIn=32,32 _LVGraphData.vhDataIn=96,32 _OCDI_Alignment=16 _OCDI_Alignment.el_1=0,8 _OCDI_Alignment.el_2=64,64 _PDAArr=12 _PDAArr.arr=64,32 _PDAArr.datatype=0,32 _PDAArr.fill=56,8 _PDAArr.refcnt=32,16 _PDAArr.staticArray=48,8 _PDAStr=12 _PDAStr.len=32,32 _PDAStr.refcnt=0,16 _PDAStr.staticStr=16,16 _PDAStr.str=64,16
VI Section
Each source VI is a separate section in the VI section part of the LVM file. The following types of VIs are not included in the LVM file: Reentrant VIs VIs that you cannot debug, which occurs when you do not set the Execution:Allow Debugging VI property
SNode Entries
SNode(id1,id2,id3)@lineNumber=absolute address
Description: Maps the LabVIEW diagram structure node to the line number in the C file and the absolute address. This entry determines the emulator breakpoint address when a user sets a breakpoint on the block diagram. This entry also locates and highlights the LabVIEW diagram structure when the executable hits the breakpoint. Parameters:
id1,id2,id3 are the internal LabVIEW IDs that locate the LabVIEW
19-4
ni.com
Chapter 19
lineNumber is the line number in the C file that implements the structure
node.
absoluteAddress is the absolute address of the code that implements the structure node on the target.
Example:
SNode(10,11,11)@527=0x16340
Node Entries
Node(id1,id2,id3)@lineNumber=absoluteAddress
Description: Maps the LabVIEW VI node to the line number in the C file and the absolute address. This entry determines the emulator breakpoint address when a user sets a breakpoint on the block diagram. This entry also locates and highlights the block diagram node when the executable hits the breakpoint. Parameters:
id1,id2,id3 are the internal LabVIEW IDs that locate the LabVIEW
Example:
Node(13,14,17)@563=0x16580
SRN Entries
SRN(id1,id2)@lineNumber=absoluteAddress
Description: Maps the LabVIEW self-referencing node to the line number in the C file and the absolute address. A self-referencing node is a node that maintains pointers to the controls, indicators, and constants on the block diagram. This entry determines the emulator breakpoint address when a user sets a breakpoint on the block diagram. This entry also locates and highlights the LabVIEW self-referencing node when the executable hits the breakpoint.
19-5
Chapter 19
Parameters:
id1,id2,id3 are the internal LabVIEW IDs that locate the LabVIEW
Example:
SRN(17,13)@627=0x168A4
Location.SNode Entries
Location.SNode(id1,id2,id3)@[startLine..endLine]
Description: Maps the LabVIEW diagram structure node to the first and last line in the generated C code that implements the structure. This entry locates the structure node when a user sets a breakpoint or single-steps in the generated C code. This entry is used only when you have integrated the LabVIEW debugger with an IDE. Parameters:
id1,id2,id3 are the internal LabVIEW IDs that locate the LabVIEW
Example:
Location.SNode(10,11,11)@[523..540]
Location.Node Entries
Location.Node(id1,id2,id3)@[startLine..endLine]
Description: Maps the LabVIEW node to the first and last line in the generated C code that implements the node. This entry locates the LabVIEW node when a user sets a breakpoint or single-steps in the generated C code. This entry is used only when you have integrated the LabVIEW debugger with an IDE.
19-6
ni.com
Chapter 19
Parameters:
id1,id2,id3 are the internal LabVIEW IDs that locate the LabVIEW
Example:
Location.Node(13,14,17)@[559..565]
Location.SRN Entries
Location.SRN(id1,id2)@[startLine..endLine]
Description: Maps the self-referencing node to the first and last line in the C file. This entry locates the self-referencing node when a user sets a breakpoint or single-steps in the generated C code. This entry is used only when you have integrated the LabVIEW debugger with an IDE. Parameters:
id1,id2,id3 are the internal LabVIEW IDs that locate the LabVIEW
Example:
Location.SRN(17,13)@[626..628]
SID Entries
SID_signalId=absoluteAddress
Description: Maps the block diagram signal ID to the absolute target memory address. This entry determines the absolute target address of the signal variable when a user sets a probe on the block diagram. Parameters: signalID is the internal LabVIEW signal ID that locates the signal on the block diagram.
19-7
Chapter 19
CID Entries
CID_controlId=absoluteAddress
Description: Maps the front panel control ID to the absolute target memory address. This entry determines the absolute target address of the control variable when a user opens a front panel window. Parameters: controlID is the internal LabVIEW control ID that locates the control on the front panel window.
absoluteAddress is the absolute address of the control variable in the
Offset_Table Section
The [Offset_Table] section defines sizes and offsets of internal LabVIEW Embedded Run-Time Library structures and other attributes. The LVM file contains a single [Offset_Table] section.
ArrayControlData Entries
ArrayControlData=structureSize ArrayControlData.bStatic=memberOffset, memberSize ArrayControlData.dataType=memberOffset, memberSize ArrayControlData.elt_datatype=memberOffset, memberSize ArrayControlData.hValue=memberOffset, memberSize ArrayControlData.hDefaultValue=memberOffset, memberSize ArrayControlData.nDims=memberOffset, memberSize
Description: Describes the layout of the ArrayControlData structure in the target memory. The LabVIEW debugger uses the ArrayControlData structure information to access the front panel array control data structures.
19-8
ni.com
Chapter 19
Parameters:
structureSize is the size of the ArrayControlData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVArrayControl.h
Example:
ArrayControlData=24 ArrayControlData.bStatic=64,8 ArrayControlData.dataType=160,32 ArrayControlData.elt_datatype=128,32 ArrayControlData.hDefaultValue=32,32 ArrayControlData.hValue=0,32 ArrayControlData.nDims=96,32
Endianness Entry
BigEndian=bigEndian
Description: Indicates the endianness of the target. Parameters: bigEndian determines the endianness of the target. 0 = little endian 1 = big endian Example:
BigEndian=1
BooleanData Entries
BooleanData=structureSize BooleanData.bDefaultVal=memberOffset,memberSize BooleanData.bInput=memberOffset,memberSize BooleanData.bStatic=memberOffset,memberSize BooleanData.bVal=memberOffset,memberSize
19-9
Chapter 19
Description: Describes the layout of the BooleanData structure in the target memory. The LabVIEW debugger uses the BooleanData structure information to access the front panel Boolean control data structures. Parameters:
structureSize is the size of the BooleanData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVBoolean.h
Example:
BooleanData=4 BooleanData.bDefaultVal=16,8 BooleanData.bInput=24,8 BooleanData.bStatic=0,8 BooleanData.bVal=8,8
ClusterControlData Entries
ClusterControlData=structureSize ClusterControlData.bInput=memberOffset,memberSize ClusterControlData.bStatic=memberOffset,memberSize ClusterControlData.datatype=memberOffset,memberSize ClusterControlData.pBigCls=memberOffset,memberSize ClusterControlData.pDefaultVal=memberOffset,memberSize ClusterControlData.pOldVal=memberOffset,memberSize ClusterControlData.pSmallCls=memberOffset,memberSize ClusterControlData.pVal=memberOffset,memberSize
Description: Describes the layout of the ClusterControlData structure in the target memory. The LabVIEW debugger uses the ClusterControlData structure information to access the front panel cluster control data structures. Parameters:
structureSize is the size of the ClusterControlData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
19-10
ni.com
Chapter 19
Location:
LVClusterControl.h
Example:
ClusterControlData=152 ClusterControlData.bInput=1192,8 ClusterControlData.bStatic=1184,8 ClusterControlData.datatype=1152,32 ClusterControlData.pBigCls=96,32 ClusterControlData.pDefaultVal=32,32 ClusterControlData.pOldVal=0,32 ClusterControlData.pSmallCls=128,1024 ClusterControlData.pVal=64,32
EnumCtlData Entries
EnumCtlData=structureSize EnumCtlData.bInput=memberOffset,memberSize EnumCtlData.bStatic=memberOffset,memberSize EnumCtlData.datatype=memberOffset,memberSize EnumCtlData.defaultVal=memberOffset,memberSize EnumCtlData.nValue=memberOffset,memberSize EnumCtlData.numItems=memberOffset,memberSize
Description: Describes the layout of the EnumCtlData structure in the target memory. The LabVIEW debugger uses the EnumCtlData structure information to access the front panel enumerated type control data structures. Parameters:
structureSize is the size of the EnumCtlData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVEnumCtl.h
Example:
EnumCtlData=20 EnumCtlData.bInput=136,8 EnumCtlData.bStatic=128,8 EnumCtlData.datatype=0,32 EnumCtlData.defaultVal=64,32
19-11
Chapter 19
EnumCtlData.nValue=32,32 EnumCtlData.numItems=96,32
NumericData Entries
NumericData=structureSize NumericData.bInput=memberOffset,memberSize NumericData.bStatic=memberOffset,memberSize NumericData.datasize=memberOffset,memberSize NumericData.datatype=memberOffset,memberSize NumericData.pData=memberOffset,memberSize NumericData.padding1=memberOffset,memberSize
Description: Describes the layout of the NumericData structure in the target memory. The LabVIEW debugger uses the NumericData structure information to access the front panel numeric control data structures. Parameters:
structureSize is the size of the NumericData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVNumeric.h
Example:
NumericData=24 NumericData.bInput=48,8 NumericData.bStatic=40,8 NumericData.datasize=32,8 NumericData.datatype=0,32 NumericData.pData=64,128 NumericData.padding1=56,8
PictInfo Entries
PictInfo=structureSize PictInfo.bHidden=structureSize PictInfo.bounds=structureSize PictInfo.color=structureSize PictInfo.currentBackColor=structureSize PictInfo.currentForeColor=structureSize PictInfo.currentTextColor=structureSize
19-12
ni.com
Chapter 19
Description: Describes the layout of the PictInfo structure in the target memory. The LabVIEW debugger uses the PictInfo structure information to access the front panel array picture control data structures. Parameters:
structureSize is the size of the PictInfo structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
PictInfo.h
Example:
PictInfo=52 PictInfo.bHidden=384,8 PictInfo.bounds=128,64 PictInfo.color=352,32 PictInfo.currentBackColor=224,32 PictInfo.currentForeColor=192,32 PictInfo.currentTextColor=256,32 PictInfo.currentX=64,32 PictInfo.currentY=96,32 PictInfo.dc=32,32 PictInfo.dirty=16,16 PictInfo.hDefaultValue=320,32 PictInfo.hPictCode=288,32 PictInfo.refcnt=0,16
19-13
Chapter 19
Description: Indicates the debugging mode for the built application. An application built in the release debugging mode uses a single breakpoint and does not require the .text section to be located in RAM. A typical use case for this entry is debugging an application running in ROM and/or using hardware breakpoints. Parameters:
debugMode determines the debugging mode.
StringData Entries
StringData=structureSize StringData.bStatic=memberOffset,memberSize StringData.bufferLen=memberOffset,memberSize StringData.len=memberOffset,memberSize StringData.pValue=memberOffset,memberSize StringData.padding=memberOffset,memberSize
Description: Describes the layout of the StringData structure in the target memory. The LabVIEW debugger uses the StringData structure information to access the front panel string control data structures. Parameters:
structureSize is the size of the StringData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVString.h
19-14
ni.com
Chapter 19
Example:
StringData=16 StringData.bStatic=64,8 StringData.bufferLen=32,32 StringData.len=0,32 StringData.pValue=96,32 StringData.padding=72,24
_ControlData Entries
_ControlData=structureSize _ControlData.controlIdx=memberOffset,memberSize _ControlData.dataType=memberOffset,memberSize _ControlData.fieldType=memberOffset,memberSize _ControlData.hValue=memberOffset,memberSize _ControlData.parentIdx=memberOffset,memberSize
Description: Describes the layout of the _ControlData structure in the target memory. The LabVIEW debugger uses the _ControlData structure information to access the list of front panel control data structures. Parameters:
structureSize is the size of the _ControlData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVCCG.h
Example:
_ControlData=20 _ControlData.controlIdx=0,32 _ControlData.dataType=96,32 _ControlData.fieldType=128,32 _ControlData.hValue=64,32 _ControlData.parentIdx=32,32
19-15
Chapter 19
_LVGraphData Entries
_LVGraphData=structureSize _LVGraphData.bStatic=memberOffset,memberSize _LVGraphData.datatype=memberOffset,memberSize _LVGraphData.dtDataIn=memberOffset,memberSize _LVGraphData.vhDataIn=memberOffset,memberSize
Description: Describes the layout of the _LVGraphData structure in the target memory. The LabVIEW debugger uses the _LVGraphData structure information to access the front panel graph control data structures. Parameters:
structureSize is the size of the _LVGraphData structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVGraph.h
Example:
_LVGraphData=16 _LVGraphData.bStatic=64,8 _LVGraphData.datatype=0,32 _LVGraphData.dtDataIn=32,32 _LVGraphData.vhDataIn=96,32
_OCDI_Alignment Entries
_OCDI_Alignment=structureSize _OCDI_Alignment.el_1=memberOffset,memberSize _OCDI_Alignment.el_2=memberOffset,memberSize
Description: Describes the layout of the _OCDI_Alignment structure in the target memory. The LabVIEW debugger uses the _OCDI_Alignment structure information to access the cluster signal and control cluster member data structures.
19-16
ni.com
Chapter 19
Parameters:
structureSize is the size of the _OCDI_Alignment structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
LVCCG.h
Example:
_OCDI_Alignment=16 _OCDI_Alignment.el_1=0,8 _OCDI_Alignment.el_2=64,64
_PDAArr Entries
_PDAArr=structureSize _PDAArr.arr=memberOffset,memberSize _PDAArr.datatype=memberOffset,memberSize _PDAArr.fill=memberOffset,memberSize _PDAArr.refcnt=memberOffset,memberSize _PDAArr.staticArray=memberOffset,memberSize
Description: Describes the layout of the _PDAArr structure in the target memory. The LabVIEW debugger uses the _PDAArr structure information to access the front panel array signal and control data structures. Parameters:
structureSize is the size of the _PDAArr structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
CCGArrSupport.h
Example:
_PDAArr=12 _PDAArr.arr=64,32 _PDAArr.datatype=0,32 _PDAArr.fill=56,8 _PDAArr.refcnt=32,16 _PDAArr.staticArray=48,8
19-17
Chapter 19
_PDAStr Entries
_PDAStr=structureSize _PDAStr.len=memberOffset,memberSize _PDAStr.refcnt=memberOffset,memberSize _PDAStr.staticStr=memberOffset,memberSize _PDAStr.str=memberOffset,memberSize
Description: Describes the layout of the _PDAStr structure in the target memory. The LabVIEW debugger uses the _PDAStr structure information to access the front panel string signal and control data structures. Parameters:
structureSize is the size of the _PDAStr structure in bytes. memberOffset is the offset of the structure member variable in bits. memberSize is the size of the structure member variable in bits.
Location:
CCGStrSupport.h file
Example:
_PDAStr=12 _PDAStr.len=32,32 _PDAStr.refcnt=0,16 _PDAStr.staticStr=16,16 _PDAStr.str=64,16
19-18
ni.com
Chapter 19
3.
Resolve breakpoint addresses and symbols. For all breakpoints, call EMB_Debug_DD_GetBP.vi in a loop to map the breakpoint line numbers into absolute target addresses. Call EMB_Debug_DD_SetAbsoluteBP_Address.vi to update the absolute address of each breakpoint record. Resolve memory records. For all memory records, call
EMB_Debug_DD_GetMem.vi in a loop to map the memory line
4.
You must resolve all breakpoints, symbols, and memory records when an embedded VI is built into an embedded application. Resolving is the most complicated part of generating the LVM file because it involves integration with your third-party resolver that can parse the built application and resolve all memory symbols and map breakpoint line numbers to absolute target addresses. 5. Use EMB_Debug_DD_GetSetAttrib_Numeric.vi and EMB_Debug_DD_GetSetAttrib_Numeric_Pair.vi to set all of the attributes in the [Offset_Table] section.
Note
You must set all attributes in the [Offset_Table] section to ensure the LabVIEW debugger correctly dereferences the pointers. 6. Call EMB_Debug_DD_Save.vi to save the debug database to the LVM file.
19-19
Chapter 19
EMB_Debug_DD_GetBP.vi
Queries the debug database for the breakpoint record with a matching breakpoint ID. You must call this VI in a loop when all breakpoint records are in place to resolve the line numbers of all breakpoints. Place this VI in a While Loop and wire Breakpoint ID to the iteration (i) terminal of the While Loop. Terminate the loop when EMB_Debug_DD_GetBP.vi returns error code 5001 (ErrNotFound). You must resolve Breakpoint Line to the absolute target address and call EMB_Debug_DD_SetAbsoluteBPAddress.vi to update the absolute address of the resolved breakpoint record. You can ignore the following outputs: Breakpoint Index Breakpoint Actual Index Breakpoint Step Out Index Breakpoint Type Sub VI Name Breakpoint Relative Address Breakpoint Address
Breakpoint ID is the incrementing zero-based breakpoint record. target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error
19-20
ni.com
Chapter 19
Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. Breakpoint Index is an internal LabVIEW breakpoint indicator. You can ignore this output. Breakpoint Actual Index is an internal LabVIEW breakpoint indicator. You can ignore this output. Breakpoint Step Out Index is an internal LabVIEW breakpoint indicator. You can ignore this output. VI Name is the name of the VI for which this breakpoint belongs. Breakpoint Type is an internal LabVIEW breakpoint type indicator. Possible values for this output are Node, SNODE, IUse, AfterSNode, and SRN. You can ignore this output. Breakpoint Line is the line in the generated C file that contains the breakpoint OCDI comment. Sub VI Name is the name of the subVI. This output is valid only when Breakpoint Type is IUse. You can ignore this output. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred.
19-21
Chapter 19
code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. Breakpoint Relative Address is the relative address of the breakpoint address. This output is used only for relocatable modules when the absolute address cannot be resolved at build time. The format of the relative address is <symbolName>+0x<Offset>. Breakpoint Address is the absolute address for the breakpoint. For relocatable modules, set this output to 0. You can ignore this output.
EMB_Debug_DD_GetMem.vi
Queries the debug database for the memory record with a matching memory ID. You must call this VI in a loop when all memory records are in place to resolve the relative addresses of all signals and controls. Place this VI in a While Loop and wire Memory ID to the iteration (i) terminal of the While Loop. Terminate the loop when EMB_Debug_DD_GetMem.vi returns error code 5001 (ErrNotFound). You must resolve Relative Address to the absolute target address and call EMB_Debug_DD_SetAbsoluteMemAddress.vi to update the absolute address of the resolved memory record.
target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. Memory ID is the zero-based memory record ID. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it
19-22
ni.com
Chapter 19
runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. VI Name is the name of the VI for which this breakpoint belongs. Signal/Control ID is an internal LabVIEW signal ID or control ID. Memory Type is the type of memory record. Possible values are Signal or Control. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. Relative Address is the relative address of the signal or control. The format of the relative address is <symbolName>+0x<Offset in hex>. Address is the absolute address for the control or signal.
19-23
Chapter 19
EMB_Debug_DD_Init.vi
Initializes the debug database. This VI deletes all of the records from the debug database. Call this VI before you call the EMB_Debug_DD_ParseCFile.vi.
target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred.
19-24
ni.com
Chapter 19
code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
EMB_Debug_DD_ParseCFile.vi
Parses the C source file for OCDI comments and appends new records to the debug database. Call this VI for each C file the LabVIEW C Code Generator generates. You resolve all symbols and breakpoint line numbers before the debug database is saved in the LVM file.
target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. Path is the path to the generated C file. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code.
19-25
Chapter 19
source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. VI Name is the name of the VI. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
EMB_Debug_DD_Save.vi
Serializes the debug database to the LVM file. You must call this VI when all symbols are resolved and the offset table attributes are set.
target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. Path is the path to the generated C file. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this
19-26
ni.com
Chapter 19
information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
EMB_Debug_DD_SetAbsoluteBPAddress.vi
Sets the absolute address of a given breakpoint record.
target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. Breakpoint ID is the incrementing zero-based breakpoint record. Breakpoint Address is the absolute address for the breakpoint.
19-27
Chapter 19
error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
19-28
ni.com
Chapter 19
EMB_Debug_DD_SetAbsoluteMemAddress.vi
Sets the absolute address of a given memory record.
target ID is the ID of the target used to support concurrent debugging sessions. Wire 0 to this input when you call this VI from a build plug-in VI. Memory ID is the zero-based memory record ID. Address is the absolute address for the memory record. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error.
19-29
Chapter 19
status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
19-30
ni.com
20
You can integrate side-by-side debugging sessions with LabVIEW and another Integrated Development Environment (IDE) if you fully implement OCDI debugging for your target. Traditional embedded developers can use their C knowlege to debug LabVIEW embedded applications using a familiar IDE in parallel with LabVIEW. LabVIEW developers can use the side-by-side debugging sessions to understand what C code the LabVIEW C Code Generator generates for each block diagram object in an embedded VI. Refer to Chapter 18, On Chip Debugging, for information about implementing OCDI debugging.
20-1
Chapter 20
20-2
ni.com
Chapter 20
Eclipse
Install Eclipse SDK version 3.2.2 for Windows. Refer to the Downloads section on the Eclipse Web site at www.eclipse.org for download and installation instructions.
Note
20-3
Chapter 20
7. 8. 9.
Click the Finish button. Click the Install All button. Click the Yes button to restart the Eclipse SDK workspace.
Click the OK button on the Edit Local Site dialog box. Click the Finish button. Select LabVIEW Embedded Eclipse plug-in 1.0.1 and click the Next button. Review the license agreement and click the Next button. Click the Finish button.
10. Click the Install All button. 11. Click the Yes button to restart the workbench.
20-4
ni.com
Chapter 20
Implementation Example
The Unix Console example implementation uses TCP/IP to communicate between LabVIEW and Eclipse. If the communication fails, you see a TCP Write or a TCP Read error. Restart Eclipse and remove the Console_Application project LabVIEW creates in Eclipse before launching a new debugging session from LabVIEW. Removing the Console_Application project allows Eclipse to properly recover.
Debugging Backend
Eclipse uses gdb as a debugging backend. Eclipse and gdb are designed for user interaction. Memory access occurs only when you pause the application being debugged. The application might fail when you debug a running embedded application using IDE integration with Eclipse because Eclipse and gdb slow down the update rate for controls, indicators, and probes. LabVIEW must interrupt the application before reading from or writing to the target memory. Single-stepping or pausing the application is not an issue. The Unix Console example target includes a Show source code shortcut menu item that appears on each block diagram object if you are in an active debugging session. Select Show source code to see the C code the LabVIEW C Code Generator generates for that object. The IShowSource plug-in VI implements the shortcut menu item and functionality.
Right-click the Unix Console example target in the Project Explorer window and select Properties from the shortcut menu to open the Target Properties dialog box. You can use LEP_unix_TargetConfigDialog.vi as a starting point to implement your own version.
Note
If you use the Unix Console implementation as a starting point, use the Documentation page in the VI Properties dialog box to change the context help for each control.
20-5
Chapter 20
IInitIndication.vi
Initializes the IDE indication occurrence. You can use this VI to spawn a background VI to listen for events from the IDE.
build ID is the ID of the build specification project item from which this VI is called. target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE.
20-6
ni.com
Chapter 20
code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. indication occurrence is the occurrence used for indicating IDE events. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IGetIndication.vi
Retrieves the last event from the IDE.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it
20-7
Chapter 20
runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. indication type is the type of event. c file name indicates the C file where the event occurred. This output is required for the following event types: indBreakpointHit indBreakpointAdd indBreakpointRem indSuspend
line number is the line number at which the event occurred. This output is required for the following event types: indBreakpointHit indBreakpointAdd indBreakpointRem indSuspend
error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error.
20-8
ni.com
Chapter 20
status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. data is a generic, IDE-specific output that contain different data. For example, it might contain the stack trace when an indSignal event is received.
IShowCrash.vi
Called when LabVIEW receives an indSignal event.
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. VI Name is the name of the VI that caused the crash. This string is empty if LabVIEW cannot obtain the mapping. index is the index of the LabVIEW object that caused the crash. data is a generic, IDE-specific output that contain different data. For example, it might contain the stack trace when an indSignal event is received. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error
20-9
Chapter 20
out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
IResolveAddress.vi
Converts an address to a C filename/line number pair for dual debugging with another IDE. Implementing this VI is optional.
20-10
ni.com
Chapter 20
target ID is the ID of the target project item from which this VI is called. Use target ID to distinguish between concurrent debug connections to different targets over the same plug-in interface. address is the absolute breakpoint address. error in (no error) describes error conditions that occur before this VI runs. The default is no error. If an error occurred before this VI runs, the VI passes the error in value to error out. This VI runs normally only if no error occurred before this VI runs. If an error occurs while this VI runs, it runs normally and sets its own error status in error out. Use the CCG Error Handler VI to display the description of the error code. Use error in and error out to check errors and to specify execution order by wiring error out from one node to error in of the next node. You can use this information to decide if functionality if you want to bypass functionality in the event of errors from other VIs. status is TRUE (X) if an error occurred before this VI or function ran or FALSE (checkmark) to indicate a warning or that no error occurred before this VI or function ran. The default is FALSE. code is the error or warning code. The default is 0. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code. source specifies the origin of the error or warning, and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string. file name is the corresponding C file for the address. line number is the line number that corresponds to the address. error out contains error information. If error in indicates that an error occurred before this VI ran, error out contains the same error information. Otherwise, it describes the error status that this VI produces. Right-click the error out indicator and select Explain Error from the shortcut menu for more information about the error. status is TRUE (X) if an error occurred or FALSE (checkmark) to indicate a warning or that no error occurred. code is the error or warning code. If status is TRUE, code is a nonzero error code. If status is FALSE, code is 0 or a warning code.
20-11
Chapter 20
source describes the origin of the error or warning and is, in most cases, the name of the VI that produced the error or warning. The default is an empty string.
20-12
ni.com
21
Funclist files contain entries that enable you to override subVI calls with C function calls. For example, the Semaphore VIs use a CIN, which embedded targets do not support. For embedded targets, the Semaphore VIs have an alternate implementation that makes direct calls to a C function instead. Funclist entries is how you provide an alternative implementation. Using Funclist removes the overhead of subVI calls and can produce substantial performance improvements in LabVIEW embedded applications. SubVI calls have overhead to support multithreading, reentrancy, front panel controls and indicators, and so on. Funclist is useful when you wrap high performance, target-specific C function calls into subVIs. Creating subVI wrappers provide a better experience in LabVIEW so you can have the best of boththe ease of use of LabVIEW and the performance of an optimized C function call. Refer to the LabVIEW Embedded Development Module Target Distribution Guide, available by selecting StartAll Programs National InstrumentsLabVIEWLabVIEW Manuals and opening EMB_Distribution_Guide.pdf, for information about additional ways to wrap C functions so the functions are easier to use in LabVIEW.
Caution
National Instruments originally created Funclist for internal use only. Funclist entries have specific formatting requirements and contain little error checking. If the formatting is incorrect, you receive compiler errors and LabVIEW might crash when you build an embedded VI into an embedded application. Refer to the Format of Funclist Entries section in this chapter for information about the formatting requirements.
21-1
Chapter 21
You also can supplement Funclist with your own target-specific Funclist files. Each Funclist entry must contain the following three tags: <VI Name> <Function> <Feature>
<VI Name>
The first line of a Funclist entry is the name of the VI you are overriding enclosed in a <VI Name> tag. You must change the VI name in the following ways: Convert spaces to underscores. If the VI begins with an underscore, prepend A__ to the VI name.
<Function>
The second line of a Funclist entry contains the line of C code that replaces the subVI call enclosed in a <Function> tag. If you call a function, the second line contains the function parameters. You can pass the parameters directly or with ArgList. National Instruments strongly recommends that you pass the parameters directly.
21-2
ni.com
Chapter 21
input or output and the way the LabVIEW C Code Generator passes the parameter. Refer to the following bullet for more information about how the LabVIEW C Code Generator passes the parameter. n is the number of the input or output on the connector pane.
Note
The numbering on the connector pane is not intuitive. You might have to use trial and error to find the correct number. Use the following characters to indicate how the LabVIEW C Code Generator passes the parameter:
I is an input passed by reference. i is an input passed by value. o is an output passed by reference. it is the type of input.
Place a value in parentheses after a format code to specify a default, or unwired, value for the input. For example, if you want to pass input 3 by reference with Null as the default value, the syntax is @I3(Null).
Using ArgList to pass parameters has the following requirements: Do not place an @ at the beginning of the line of C code. Specify %s for the ArgList input and a second %s for the ArgList output. The function you call must unpack the input and output values from
ArgList.
<Feature>
The third line of a Funclist entry contains a string that describes the feature you are overriding enclosed in a <Feature> tag. You can use any string for the third line as long as the string is a valid C identifier and the string is unique to the other Feature strings in the Funclist file.
21-3
Chapter 21
You also can supplement Funclist with your own target-specific Funclist files. Target-specific Funclist files override the common Funclist files. Target-specific Funclist files override subVIs per target so you can have different overrides if you implement more than one target. Entries in target-specific Funclist files must follow the formatting requirements, but the XML filenames do not have formatting requirements. Place all target-specific Funclist files in a Funclist folder in your target directory. When LabVIEW launches, LabVIEW loads the common Funclist files in alphabetical order. When you create an application instance for your target, LabVIEW loads any target-specific Funclist files in alphabetical order. To override an entry in the common Funclist files, use the same name in the <VI Name> tag in your target-specific Funclist entry.
21-4
ni.com
Chapter 21
If you receive compile errors in LVFuncsUsed.h, verify that the third line in the Funclist entry is a valid C identifier. Refer to the <Feature> section in this chapter for information about the string on the third line.
Note
Implementation Example
National Instruments has implemented many subVIs for the Microprocessor SDK example targets using Funclist files, which are located in the following directory:
labview\CCodeGen\Funclist
21-5
22
The LabVIEW Microprocessor SDK supports building embedded applications that do not allocate memory when running. Embedded applications that you build using a static memory model are more deterministic and might run faster than applications using a dynamic memory model because static memory models do not have to make malloc() and free() calls. If you build an embedded application using the static memory model, the generated code and the LabVIEW run-time code do not allocate dynamic memory during execution. Instead, the LabVIEW C Code Generator analyzes the block diagram to determine the maximum amount of memory the application requires and declares global variables to pre-allocate the required memory chunks. However, it is not possible to determine the maximum amount of memory required for a block diagram in all cases. For example, the LabVIEW C Code Generator cannot estimate the maximum amount of memory required if a block diagram contains either of the following: Variable-size array constants Building arrays using the indexing tunnel of a loop with an unknown number of iterations
If the LabVIEW C Code Generator cannot estimate the amount of memory required for an application that uses static memory allocation, the Run button on the block diagram breaks and an error message indicates the problem.
22-1
Chapter 22
dynamic memory management calls, such as malloc, realloc, and free, as no-ops. Additional function arguments are produced that are pointers to global variables the LabVIEW C Code Generator declares. The functions use macros to use the global data in these extra function arguments instead of calling malloc. A single LabVIEW target cannot support both memory models. You must create two separate targetsone for static memory and one for dynamic memory. You must compile both a static memory and a dynamic memory version of the pre-built run-time libraries and link the correct one when a user builds an embedded VI into an embedded application. An embedded application must be either completely static or completely dynamic. As part of creating separate targets, you must create separate TargetSyntax.xml files for each target. Use the TargetSyntax.xml file located in the following directory as a template for dynamic memory targets:
labview\Targets\NI\Embedded\common
Use the TargetSyntax.xml file located in the following directory as a template for static memory targets:
labview\Targets\NI\Embedded\common\static
The static memory version of TargetSyntax.xml restricts the target syntax to support only fixed-size arrays. Variable-size arrays and strings are not supported. All scalar data types are supported without any limitations. You must enable the ability to set a dimension size for static memory targets. Place a checkmark in the Enable Set Dimension Size for arrays (Static Memory Allocation) checkbox in the Target Editor, which enables a Set Dimension Size shortcut menu option for block diagram array constants. Refer to Chapter 7, Creating a New Embedded Target, for more information about the Target Editor.
22-2
ni.com
Chapter 22
OEM-Defined Limitations
You define certain static memory model limitations with the following macros: The NODE_MAX macro limits the number of external timing sources. The FIFO_MAX macro defines the number of RT FIFO instances you can use and does not support array elements. The FIFO_SIZE_MAX macro defines the maximum number of RT FIFO elements. The GENERATE_OCCURRENCE_MAX macro and the WAIT_ON_OCCURRENCE_MAX macro limits the number of Generate Occurrence functions and Wait on Occurrence functions, respectively. The ISR_HANDLE_MAX macro defines the number of interrupt handles you can use.
User Limitations
Embedded VIs for static memory model targets have the following limitations: The String data type is not supported. Only fixed-size array constants are supported. To specify the type and size of an array constant, right-click the array constant and select Set Dimension Size from the shortcut menu. You cannot access the String element of the error cluster. The Insert Into Array function is not supported. You can index tunnels in a For Loop, but you must define the number of iterations. Target syntax checking does not support constant folding, so you must wire a constant to the count (N) terminal of the For Loop. You cannot wire the name of the Timed Loop external source to the Source input because the string data type is unsupported. Enter the name of the external timing source in the Source name text box in the Configure Timed Loop dialog box. Open the Configure Timed Loop dialog box by right-clicking the Timed Loop on the block diagram and selecting Configure Timed Loop from the shortcut menu. Remove the checkmark from the Use terminal checkbox. Enter 1 in the Period box.
22-3
Chapter 22
You cannot wire string constants to the Create External Source VI, Fire External Source VI, or Delete External Source VI. You must use a fixed-size array constant to specify the name of the external timing source. For example, if you want to create an external timing source named foo, you must create a fixed-size array constant of 3 with values 102, 111, and 111. Verify the representation is 8-byte unsigned integer (U8) or 8-byte signed integer (I8). The RTFIFOCreate VI uses a string input to specify the name of the RTFIFO instance. You specify the name using a fixed-size array of bytes, which is the same way you specify the external timing source names. Refer to the previous bullet for more information. The static version of the RT FIFO does not support arrays. TCP functions and UDP functions are not supported. The LabVIEW Analysis Library is not supported.
22-4
ni.com
23
Use the Target Server to download, execute, and monitor an embedded application over a TCP connection. The Target Server provides a way to download and run an embedded application without requiring both a serial and Ethernet connection. To use the Target Server with an embedded target, the target must have a TCP connection, a TFTP client, and a telnet server. You use a configuration cluster in the Target Server Utilities VIs to define command strings and corresponding regular expressions to parse the command output. If you implement a Target Server, users open it by right-clicking a build specification under your target in the Project Explorer window.
LabVIEW displays the Target Server window when the embedded provider calls the following utility VIs, which are located on the Target Server Utilities palette: TargetServer_DownloadCmd TargetServer_RunCmd TargetServer_ShowWindowCmd
23-1
Chapter 23
All embedded applications that you launch using the Target Server close when the Target Server shuts down.
Telnet Client
Use the Telnet Utilities VIs to implement a simple telnet client.
Implementation Example
The Freescale M5329EVB example target uses the Target Server. The following directory contains the plug-in VIs for the Freescale M5329EVB example target:
labview\Targets\NI\Embedded\unix\m5329evb\unix_m5329evb_LEP_TargetPlugin
23-2
ni.com
As an OEM/VAR, you must consider providing technical support for your product if you decide to bundle and resell your target. Customers will contact you to purchase your target, obtain a valid serial number, and receive technical support for your target. You are the expert for your target, but National Instruments can help you with general support issues. In addition to the Microprocessor documentation, you also have access to the LabVIEW Embedded Discussion Forum and training. The LabVIEW Embedded Discussion Forum provides a discussion forum for the Microprocessor SDK and other LabVIEW Embedded products. You can access the forum by visiting ni.com/info and typing edmforum. On site training at National Instruments corporate headquarters or Web-based training available upon request.
Visit the following sections of the award-winning National Instruments Web site at ni.com for technical support and professional services: SupportTechnical support resources at ni.com/support include the following: Self-Help Technical ResourcesFor answers and solutions, visit ni.com/support for software drivers and updates, a searchable KnowledgeBase, product manuals, step-by-step troubleshooting wizards, thousands of example programs, tutorials, application notes, instrument drivers, and so on. Registered users also receive access to the NI Discussion Forums at ni.com/forums. NI Applications Engineers make sure every question submitted online receives an answer. Standard Service Program MembershipThis program entitles members to direct access to NI Applications Engineers via phone and email for one-to-one technical support as well as exclusive access to on demand training modules via the Services Resource Center. NI offers complementary membership for a full
A-1
Appendix A
year after purchase, after which you may renew to continue your benefits. For information about other technical support options in your area, visit ni.com/services, or contact your local office at ni.com/contact. Training and CertificationVisit ni.com/training for self-paced training, eLearning virtual classrooms, interactive CDs, and Certification program information. You also can register for instructor-led, hands-on courses at locations around the world. System IntegrationIf you have time constraints, limited in-house technical resources, or other project challenges, National Instruments Alliance Partner members can help. To learn more, call your local NI office or visit ni.com/alliance.
If you searched ni.com and could not find the answers you need, contact your local office or NI corporate headquarters. Phone numbers for our worldwide offices are listed at the front of this manual. You also can visit the Worldwide Offices section of ni.com/niglobal to access the branch office Web sites, which provide up-to-date contact information, support phone numbers, email addresses, and current events.
A-2
ni.com