Anyone install windriver on linux yet?

[keen101]

Also, where did you get the evaluation version of LabView for Linux? I haven't been able to find one anywhere.

To be honest, i can't seem to find it again...

I went back to one page i thought i had been on, but can only find the windows trial version. Weird. I don't know, i was doing a lot of googling at the time, and was trying to find anything that had to do with labview and linux. Oh, well. It doesn't matter anyway i suppose.

Does anyone know how to obtain the Linux version of WindRiver? Is it included on the software DVD? Or do we have to request it from FRC team support?

[pogenwurst]

Originally Posted by keen101

Does anyone know how to obtain the Linux version of WindRiver? Is it included on the software DVD? Or do we have to request it from FRC team support?

It's not on the software DVD.

Though there is a native Linux version of LabVIEW, if I've understood the situation correctly, in order to program for a CompactRIO target you need to have the LabVIEW Real-time Module, which is Windows-only.

[pogenwurst]

I just spent some time fiddling with it, and it's of note that the redistributable compiler for VxWorks 6.3 (mentioned further up) runs and successfully compiles the example code that comes in the zip provided that you set the proper environment variables in the Wine registry.

The following is a modified version of the Makefile from the example code that allows it to be built through Eclipse on Linux:

# edit these as needed to fit your setup
WIND_BASE = "c:\gccdist\WindRiver\vxworks-6.3"
WINECMD = wine

# These variables control the compiler and linker flags. Change them as
# appropriate.
DEBUG_MODE = 0

ADDED_CFLAGS =

ifeq ($(DEBUG_MODE),1)
OBJ_DIR := PPC603gnu_DEBUG
CFLAGS = -g -mlongcall
else
OBJ_DIR := PPC603gnu
CFLAGS = -Os -fstrength-reduce -fno-builtin -fno-strict-aliasing -mlongcall
endif

LINKFLAGS = $(CFLAGS)
LIBPATH = 

# List all the *compiled* object files here, under the OBJ_DIR
# directory. Make will automatically locate the source file and
# compile it.
OBJECTS := $(OBJ_DIR)/example.o

# This is the name of the output shared library.
PROJECT_TARGETS := $(OBJ_DIR)/example.out

# If you have other VxWorks .a files to reference, list them here.
LIBS = 
LIBPATH = 

# Everything after this line should not need to be modified for
# basic compilation. However, significant changes to the build structure
# will probably involve modifying these lines.

CPU = PPC603
TOOL_FAMILY = gnu
TOOL = gnu
CC_ARCH_SPEC = -mcpu=603 -mstrict-align -mno-implicit-fp

IDE_INCLUDES = -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip 

# This basic rule compiles a .c file into a .o file. It can be adapted to
# all other source files that gcc can compile, including assembly (.s) and
# C++ (.cpp, .cc, .C, .cxx) files. To enable support for those extensions,
# copy this rule and modify its extension and compile flags for the
# required source file type.
$(OBJ_DIR)/%.o : %.c
	$(WINECMD) ccppc $(CFLAGS) $(CC_ARCH_SPEC) -ansi  -Wall  -MD -MP $(ADDED_CFLAGS) $(IDE_INCLUDES) $(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL) -D_WRS_KERNEL   $(DEFINES) -o "$@" -c "$<"

# Adapted rule for .cpp files
$(OBJ_DIR)/%.o : %.cpp
	$(WINECMD) c++ppc $(CFLAGS) $(CC_ARCH_SPEC) -ansi  -Wall  -MD -MP $(ADDED_CFLAGS) $(IDE_INCLUDES) $(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL) -D_WRS_KERNEL   $(DEFINES) -o "$@" -c "$<"

all : check_objectdir $(PROJECT_TARGETS) 

$(PROJECT_TARGETS) : $(OBJECTS)
	rm -f "$@" ctdt.c;$(WINECMD) nmppc $(OBJECTS) | $(WINECMD) tclsh $(WIND_BASE)/host/resource/hutils/tcl/munch.tcl -c ppc > ctdt.c
	$(WINECMD) ccppc $(LINKFLAGS) $(CC_ARCH_SPEC) -fdollars-in-identifiers -Wall $(ADDED_CFLAGS) $(IDE_INCLUDES) $(ADDED_INCLUDES) -DCPU=$(CPU) -DTOOL_FAMILY=$(TOOL_FAMILY) -DTOOL=$(TOOL) -D_WRS_KERNEL   $(DEFINES)  -o ctdt.o -c ctdt.c
	$(WINECMD) ccppc -r -nostdlib -Wl,-X -T $(WIND_BASE)/target/h/tool/gnu/ldscripts/link.OUT -o "$@" $(OBJECTS) $(LIBPATH) $(LIBS)  $(ADDED_LIBPATH) $(ADDED_LIBS) ctdt.o
	rm -f ctdt.c ctdt.o


check_objectdir :
	@if [ ! -d "$(OBJ_DIR)" ]; then\
		mkdir -p $(OBJ_DIR);\
	fi

clean :
	rm -f $(OBJECTS) $(PROJECT_TARGETS) $(wildcard $(OBJ_DIR)/*.unstripped)

.DUMMY: check_objectdir clean

Again, this is the example code that comes with the redistributable compiler, not any WPILib code. I imagine it can be made to work with that too, but I haven't tried yet.

I'll post back as I make progress.

[keen101]

Well, just requested a linux version of LabVIEW. Hopefully NI will send it....

The following is a modified version of the Makefile from the example code that allows it to be built through Eclipse on Linux:

cool. That would be ok, if you could get it to compile from Eclipse. I already have Eclipse installed. I've heard WindRiver is basically a modified Eclipse. If you could get it to work with Eclipse, then that should work. Keep me informed on any progress you make.

It's not on the software DVD.

Thanks. I didn't think it would be. I am going on a limb here, and gonna say that maybe we can get the Linux version of WindRiver by requesting it from frc team suport? I could be wrong. Maybe they haven't even perfected the Linux version yet. I really don't know. I can't seem to find documentation about it anywhere...

Though there is a native Linux version of LabVIEW, if I've understood the situation correctly, in order to program for a CompactRIO target you need to have the LabVIEW Real-time Module, which is Windows-only.

no, I'm pretty sure the real-time module is included with the linux version too.

If I made any comments about the Real-time module, it was that i am pretty sure the Real-time module on an everyday version of labview is very different from the FRC version. I think it's different because our cRIO's aren's standard cRIO's, they are custom built ones.

[pogenwurst]

Originally Posted by keen101

no, I'm pretty sure the real-time module is included with the linux version too.

http://digital.natinst.com/public.nsf/$CXIV/ATTACH-AEEE-7AVNNM/$FILE/readme_RT.html

Supported Platforms
The LabVIEW Real-Time Module supports Windows 2000/XP and Windows Vista (32-bit and 64-bit). The LabVIEW Real-Time Module does not support Windows NT/Me/9x.

http://www.ni.com/labview/requirements

LabVIEW Real-Time Module
LabVIEW Development System for Windows requirements plus:
200 MB additional available disk space

Apparently version 7.1 runs on Linux. That's no help, though.

[keen101]

The links you provided don't prove anything. Most of the documentation from ni is for windows anyway. that doesn't mean mac and Linux versions don't exist.

i remember seeing a real time module .rpm file with the linux tutorial. I could email it to you if you want to look at it. (if i still have it)

But, i have the feeling you just feel like arguing.

[pogenwurst]

Originally Posted by keen101

The links you provided don't prove anything. Most of the documentation from ni is for windows anyway. that doesn't mean mac and Linux versions don't exist.

i remember seeing a real time module .rpm file with the linux tutorial. I could email it to you if you want to look at it. (if i still have it)

But, i have the feeling you just feel like arguing.

I only intended to save you and others time.

I suspect that the RPM you're referring to is labview85-rte-8.5.1-1.i386.rpm. Unless I'm terribly mistaken RTE in this case stands for the LabVIEW Run Time Engine, which is used to deploy VIs on computers that don't have the full development system installed.

In any case, I will say no more, and wish you the best of luck with your search.

[keen101]

I only intended to save you and others time.

I suspect that the RPM you're referring to is labview85-rte-8.5.1-1.i386.rpm. Unless I'm terribly mistaken RTE in this case stands for the LabVIEW Run Time Engine, which is used to deploy VIs on computers that don't have the full development system installed.

In any case, I will say no more, and wish you the best of luck with your search.

well, i really don't know. I don't claim to know.

In either case i am going to assume to FRC version of LabVIEW for Linux is capable of programming the FRC nRIO just like the windows version. I'm going to assume they have included everything that would be needed.

[Roboj]

In either case i am going to assume to FRC version of LabVIEW for Linux is capable of programming the FRC nRIO just like the windows version. I'm going to assume they have included everything that would be needed.

This is not the case. There is no version of LabVIEW Real Time for Linux. As has been mentioned in other threads, it is possible to edit a program on LabVIEW for Linux but you need a Windows PC (or Windows VM) to build the application and use the interactive debugging capabilities targeted to the cRIO (i.e. the Real Time module)

[daltore]

This seems strange to me, there shouldn't really be an issue with realtime programming in Linux, there are entire realtime kernels out there (2 of my computers use them). Anybody know what the realtime module does that the regular LabView version doesn't?

[Greg McKaskle]

The realtime module implements the client protocol, the cross compiler, and integrates all of the configuration stuff for discovering the chassis, downloading, etc.

It isn't that these things can't be done with linux. They certainly can. Years ago there was an RT version for Mac OSX. But demand for the Mac and also for linux versions of RT seem to be low. With a product this complex, even testing on an OS adds up to significant time. So if there isn't apparent demand, it gets trimmed. Many of the developers at NI are linux fans and it isn't personal, it just comes down to supplying products that the majority of engineers need.

Greg McKaskle

[AustinSchuh]

I just succeeded in compiling and deploying code under Linux to the cRIO! I used wine to run the compiler and wput to upload it. I am going to write up a document on this in a bit and post it. I had to copy over the license file from Windows to get it working under Linux, so I'm not sure how that is going to work for people who don't install it under Windows first.

Off to work on getting the debugger working...