Communicating with C Compiler Toolchain on Remote Machine

Question

Hi,
I'm trying to develop a target for LabVIEW Embedded where the C compiler resides on another machine.  I have a Debian Linux machine hosting my BSP development for my target (MPC5121e); gcc cross-compiler w/patches, ltib, u-boot, etc. is all configured and running; linux loads on my target and NFS mounts a file system hosted on this machine. 
All of the target examples for LV Embedded have the development tools hosted on the same machine as LabVIEW (Windows); though some use Cygwin to "fake" out a linux development toolchain.  I'm trying not to duplicate my linux hosted development toolchain on Windows; though possible; it will probably create a whole host of other problems.  Thus; is there a "proper" way of calling a toolchain hosted on another machine?  Should I still use the system exec wrapper? RPC calls? or some type of script to ftp the files to the remote machine and compile them?  Any suggestions or documentation would be greatly appreciated.
Thanks.

Answer 1

Wow, thanks for all this feedback! I'll address some of the issues below:
- While using the target
editor; if path to LEP file is too long; the actual file name isn't
shown; and there isn't a way to see it by browsing; thus you must
manually view the TgtSupp.xml file to see what it is.
I'm not seeing this behavior. If the path to the plug-in VI is too long, it will wrap the name. If you place your cursor in the field and move it with the arrow keys, you should be able to see the full VI name, line by line. If you see different behavior, let me know what page/tab of the Target Editor you see it in and I will try to reproduce it.
- If there is an error in one of the LEP vi's (i.e. vi is not executable for linkage or other reasons); there is no indication of this while either using the target editor or when configuring a project for that embedded target.  Weird stuff happens such as LEP's pointed to by the Shortcut Menu Items & Category tabs via Target Editor; sometimes do not show up in the project manager.  I've spent way too much time trying to figure this out.  I eventually printed out the TgtSupp.xml file and manually opened up each LEP vi to ensure they opened without errors (which naturally occur when you're trying to develop a new target).
As I develop plug-in VIs, I do so with them in the Windows target context, so that I can verify that they should run properly. Also, I set the INI token projectDebugPumpOSMsgs=True (per the readme) so that I can debug plug-in VIs. It is true that the target editor does not warn you when you give it paths to broken VIs. A more proactive detection of broken VIs by the Target Editor could make things easier on LV MPU SDK developers.
- Need better description / documentation on
calling details for LEP functions; i.e. - wrapper functions that are
there to integrate with the rest of the development system.  The
developer shouldn't have to look at example code in order to reverse
engineer this stuff.
I assume you are talking about the architecture of some of the example targets that use VI references for many of the example targets. This architecture scales very well when making new targets, but it is probably overkill when you just want to make a single target, and it is probably easier to just have a simple set of VIs to build/download/run/debug. Which VIs would you like to be more well-documented?
- Need some documentation of the mechanism
used to store parameters for targets & build options.  This is some
black-box infrastructure that doesn't appear to be described anywhere;
with password protected vi's.  Again; the developer shouldn't have to
look at example code in order to reverse engineer this stuff when
developing their own target.  The
LEP_Utilities_GetSetProjectData_Variant does have a help file, but I
haven't seen documentation on how to "properly" use these in any of the
manuals, training or even example code (comments).
The LEP_Utilities_GetSetProjectData is a very important part of creating VIs. The VI documentation describes its behavior, although I'm sure it could use some more explanation. When you set project data, you are essentially telling LabVIEW that you want to save that variable to the lvproj file (on next project save). This data can be saved for the entire target, or per build specification. Getprojectdata allows you to retrieve that information the next time the project is opened. The Embedded Development Module palette contains many VIs that can be used in the creation of a new target. Please let me know if you find the VI documentation for any of these to be insufficient.
- How are
embedded target lists unified across the targets directory; i.e.
targets/NI/embedded/unix and targets/mycompany/embedded/unix; I've seen
some strange behaviour when selecting a target at the project level
because of this.  This may be due to the fact that I copied a target
from the targets/NI/embedded/unix and put it into
targets/mycompany/embedded/unix for modification; maybe a taboo; but I
could not find any documentation on this.
All sorts of cross-linking errors might occur from copying a directory of plug-n VIs. The Porting Guide describes the directory architecture. This architecture is important because when LabVIEW is opened, it looks in these specific locations to populate the available embedded targets. You can use the Target Editor to create copies of targets (use Save/Save As), and this will relink/rename VIs.
Please keep the feedback coming, and let me know if you have further questions.
Michael P
National Instruments