LabView and Vex. Are they compatable?

[Rick TYler]

Originally Posted by kamocat

Sadly, the easiest way might be to translate it into C and then compile it with the MPlab software.
The other option is to buy a 60-day trial of the LabVIEW Embedded module for ARM processors, and work from the ground up with that. However, I don't even know if the VEX platform uses an ARM processor.

The VEX Controller v.5 is based on an 8-bit PIC processor. The two new processors are based on the STMicroelectronics ARM Cortex-M3 and the ARM9 processor. Check the VEX website for details. I have NO idea if you can port LabVIEW to either of these controllers.

[kamocat]

Originally Posted by Rick TYler

The VEX Controller v.5 is based on an 8-bit PIC processor. The two new processors are based on the STMicroelectronics ARM Cortex-M3 and the ARM9 processor. Check the VEX website for details. I have NO idea if you can port LabVIEW to either of these controllers.

The term "porting labview" is a bit misleading here.
What's typically done with RISC processors is the language is compiled directly for the processor. The cRIO, on the other hand, is actually running an operating system within which your program runs.

[Alan Anderson]

Originally Posted by kamocat

What's typically done with RISC processors is the language is compiled directly for the processor. The cRIO, on the other hand, is actually running an operating system within which your program runs.

I don't understand what you mean. You seem to imply an either/or situation where one does not exist. What you said is akin to "Most cars have four wheels. However, some cars use diesel fuel."

LabVIEW for FRC targets the cRIO's CPU directly and the resulting code is run under the vxworks OS.

[kamocat]

Maybe I'm putting too firm a boundary between "program" and "operating system". The program is indeed compiled; the operating system is not an interpreter, and so the program is compiled for the processor. I appologize I do not understand how that works, and I do not mean to be misinforming people by making statements about things I do not know.

In re-reading my post, it seems I mixed up the concept of creating code that will run on the Vex controller, and creating code that will function on the Vex controller. If you can get code to run on the Vex controller, it may still be a huge struggle to turn on a digital output.

[Greg McKaskle]

A LV diagram is always compiled to some lower level form before execution, and over the years several approaches have been added for reaching targets.

LV desktop and LV RT products compile the diagram directly to machine code for the CPU and OS ABI in use. The code is capable of calling binary library code and this is used for vision, memory management, etc.

LV embedded, also called LV PDA is the product that instead compiles the diagram and generates C source code which can be sent through the embedded C compiler of the HW platform being targeted. The runtime libs are provided as C code.

There are a few products developed for LEGO which compile the diagram and produce a VM bytecode which is then interpreted by the virtual machine running on the brick.

The most recent release of LV desktop and RT (LV 2010), compiles the diagram into LLVM bytecode and the LLVM backend tools are used to produce a more optimized machine code for the target processor.

As stated, at this time, the appropriate way to target the VEX HW would be to use the embedded version. Personally, I don't think it will produce a very satisfying result.

Greg McKaskle

[PortugazD.Ace]

This is what I would try:

1. Write the base program in LabView.
2. Write a translation DLL in C or C++
3. Include the DLL in LabView.
4. Download the program into a memory module
5. Hook up the memory module and run.