Communicating with C Compiler Toolchain on Remote Machine

[insane$object]

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.

[Michael.Phillips]

Hi,

There are several ways to integrate a non-Windows toolchain with the Microprocessor SDK. I would recommend a shared directory for the generated files, and then use ssh (possibly through the System Exec VI) to launch a script on the Linux machine. Another possibility is to use a Linux virtual machine inside of the Windows environment. Then you don't have to worry about network connections/speed.

[insane$object]

Michael,

Thanks for your reply.  I've been busy working on your suggestion of the shared directory.  I've successfully been able to get a LV based telnet connection running and command my Linux machine to mount a shared folder from my Windows machine.  I've added a subpanel to the target options; and so far so good.  I'll continue working on getting the scripting for the compiler & linker working, but I think it will just be a matter of working through the small issues as they creep up.  Thanks again for your suggestion.

While trying to develop plugin code to support this target; here are some issues that I came accross using LV Embedded 8.5; that I would appreciate you passing on to the developers so 8.6 can be that much better.

- 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.

- 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).

- 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.

- 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).

- 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.

Many of these issues are documentation related; and it's possible that I don't have all the docs.  I do have the porting guide (aug 07), release notes (2.5), Target distribution guide (aug 07), self paced training, etc. 

Please feel free to email me directly for any questions.  Thanks.

[Michael.Phillips]

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.

[insane$object]

Michael,

Thanks for your reply and clearing up some issues.

Continuing our discussion with the Target Editor Path Issue; when I select:
Target Editor >> Target Properties >> Category
The "Path to Subpanel VI" shows only the beginning of the path; the actual vi referenced is not visible.  You are right though; as trying to place the cursor in the path selection control (cursor is not visible when you do this); and playing with the left and right arrows; one eventually can see the vi name referenced.  This is really not intuitive (at least for me; that’s why I didn’t figure it out).  Also when one presses on the browse button; you would expect that the vi configured would be automatically selected in the path dialog, but is isn't.  Maybe for future versions; the path controls can be scrolling multi-line or have the browse button automatically select the existing vi.

Another weird behaviour; If you use the Target Editor; and say; add a Category in the Target Properties; referencing a subpanel vi, then save the xml file; close the Target Editor; and now go and open a project or create a new project; selecting the embedded target you were editing earlier; the new Category will NOT show up.  This drove me crazy; I ended up looking at the xml file manually to verify all was ok; and then opening up each vi referenced by the xml file to see if there were any linkage issues; but all was ok.  It turned out that LV somehow keeps the old xml config in memory and wouldn't use the version you edited (in either a new project or an existing project).  Quitting LabVIEW and restarting now made the new target options visible.  I believe this shouldn't happen; and any changes to the Target should be active once the Target Editor has either saved the configuration; or at least when the Target Editor is closed.  Please try it; and let me know if you can reproduce this behaviour.

I've been able to muddle through some example code to figure out what the "required" code, front panel controls and connector layout must be in order to get the target options working in the LEP vi's.  But these are internally agreed upon standards and calling conventions; agreeably necessary; that are called by the LabVIEW Embedded framework itself.  My documentation issue; is that when first looking at the example targets; its almost impossible to separate "required" items as described above; from the code the implemented for that particular target.  I understand it now; but at first these rendezvous and error queues in the LEP example files had me puzzled.  The “big picture” of the architecture is what I was missing from the documentation.  The best documentation I have for the MPU SDK is PJ’s course slides; about 100+ pages, but I think it’s a few years old; so the entire plugin scheme was probably still evolving.  It would be nice if this document were updated.

Thanks for all your help and feedback.  I’ll be working on scripting my gcc compiler; so I’m sure more issues will be forthcoming.

[Michael.Phillips]

Again, thanks for the feedback. I'm passing this on to our R&D and documentation teams.

---

Another weird behaviour; If you use the Target Editor; and say; add a Category in the Target Properties; referencing a subpanel vi, then save the xml file; close the Target Editor; and now go and open a project or create a new project; selecting the embedded target you were editing earlier; the new Category will NOT show up.  This drove me crazy; I ended up looking at the xml file manually to verify all was ok; and then opening up each vi referenced by the xml file to see if there were any linkage issues; but all was ok.  It turned out that LV somehow keeps the old xml config in memory and wouldn't use the version you edited (in either a new project or an existing project).  Quitting LabVIEW and restarting now made the new target options visible.  I believe this shouldn't happen; and any changes to the Target should be active once the Target Editor has either saved the configuration; or at least when the Target Editor is closed.  Please try it; and let me know if you can reproduce this behaviour.

---

This is how it works. I would also like it if the changes updated automatically, but unfortunately, that's much easier said than done. I will keep this suggestion in mind when discussing features for future releases.

---

I've been able to muddle through some example code to figure out what the "required" code, front panel controls and connector layout must be in order to get the target options working in the LEP vi's.  But these are internally agreed upon standards and calling conventions; agreeably necessary; that are called by the LabVIEW Embedded framework itself.  My documentation issue; is that when first looking at the example targets; its almost impossible to separate "required" items as described above; from the code the implemented for that particular target.  I understand it now; but at first these rendezvous and error queues in the LEP example files had me puzzled.  The “big picture” of the architecture is what I was missing from the documentation.  The best documentation I have for the MPU SDK is PJ’s course slides; about 100+ pages, but I think it’s a few years old; so the entire plugin scheme was probably still evolving.  It would be nice if this document were updated.

---

The LabVIEW Embedded Development Module pallette is probably one of the best ways to identify the "required" items. That said, there are forthcoming additions to the documentation for target creation, hopefully these will address several of your concerns.

[Hong.Zhang@agresearch.co.]

Hi Michael

Can I use labview Embedded Module to programm TI's CC2431? Please semd some information to me: Hong.zhang@agresearch.co.nz

Thanks

Hong