Anyone install windriver on linux yet?

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

[pogenwurst]

Originally Posted by 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...

Excellent!

The redistributable version from NI (there's a link to it earlier in the thread) that I mentioned I'd gotten running & building under Wine comes with a license, so that shouldn't be a problem.

[AustinSchuh]

I just got the debugger working using only my makefile and Hyperterminal! That was with a serial cable though. I'm going to talk to Brad about installing Telnet or something more secure so that I can get rid of the serial cable.

I figured out how to do it outside eclipse under Windows by launching wtxregd, tgtsvr, and then windsh, but the tgtsvr daemon won't work for me under wine, so that idea failed.

My brother and I are going to write a gdb interface on top of the kernel shell so we can use Clewn, a piece of code that integrates GDB in with VIM.

As soon as I clean up the loose ends that I still have left, I'm going to write up docs on the whole process and post them.

[keen101]

Was that only with WINE?

WINE is at least something, maybe also a VM like Virtualbox could work too.


But, is there anyway to get it working with the native version of Eclipse? I'd rather have a native program than something that works under WINE.

[AustinSchuh]

Originally Posted by keen101

Was that only with WINE?

WINE is at least something, maybe also a VM like Virtualbox could work too.

I was able to use QEMU accelerated with the kqemu kernel module to run XP to run the servers and connect to the cRIO. But I found that I was then using Windows under Linux, and that wasn't the route that I wanted to go down. If I am going to do that, I would rather just use XP. XP would at least be more responsive.

Originally Posted by keen101

But, is there anyway to get it working with the native version of Eclipse? I'd rather have a native program than something that works under WINE.

I am pretty certain that once I get it to act like gdb that it is possible to use Eclipse again. You can use Eclipse to run and debug normal Linux applications, and it uses gdb for that. Personally I dislike using anything other than VIM and Makefiles, so my goal is to get things working with VIM and my makefiles.

Until they give us Linux binarys, there is no way to avoid wine or a VM. I guess you could compile your own cross compiler, but that sounds like a lot of unnecessary work and that could introduce problems in the output executable. I find WINE to be just fine for running command line utilities from Windows, though not as good for GUIs. I ran the command line compilers for the previous year's controller using WINE without any problems. This was using a Makefile though, not using MPLAB.

[spicyj]

Originally Posted by AustinSchuh

I guess you could compile your own cross compiler, but that sounds like a lot of unnecessary work and that could introduce problems in the output executable.

I think I did it. After installing the latest WindRiver update on Windows, copy the entire C:\WindRiver\vxworks-6.3\target\ directory to your Ubuntu box, and put it in a directory that we'll use for the build files (~/frc/ or similar works just fine).

On your Ubuntu box, cd to the directory you just made for the build files, then run these commands in order: http://pastie.org/352039 (you can change $PREFIX to change the install directory). Those instructions should be accurate for building gcc to cross-compile to Ubuntu. Included is a patchfile for what seems to be a fix to be a small problem with the libgcov code.

When you finish, you should have a complete cross-compiler suite in /usr/local/powerpc-wrs-vxworks, complete with binaries, headers, and static libraries. PLEASE tell me if you find any errors with what I've written up. (P.S. Whenever you use this compiler, you should need to have $WIND_BASE and $WIND_USR set; also required is a preprocessor flag _WRS_KERNEL which you can specify on the gcc command line using the argument -D_WRS_KERNEL.)


Now that the compiler works (well, for me, at least), it seems like it's time to try to get the SimpleRobot kernel-module example code template to compile using this compiler. Right now I'm getting problems with case sensitivity and load path order. Can someone try to get that working? My Makefile attempt is at http://gist.github.com/43030.

My final concern is how to upload an application to the cRIO into the RAM (not saving into flash memory). Seems like FTP is only for using the flash memory, but for code debugging, RAM is much less dangerous. Anyone figure out how to do this? Maybe we need to reverse-engineer the communications between Workbench and the cRIO.

[AustinSchuh]

Originally Posted by spicyj

My final concern is how to upload an application to the cRIO into the RAM (not saving into flash memory). Seems like FTP is only for using the flash memory, but for code debugging, RAM is much less dangerous. Anyone figure out how to do this? Maybe we need to reverse-engineer the communications between Workbench and the cRIO.

I have succeeded in getting RAM debugging to work. Reverse engineering sounds like a big challenge, so I wouldn't recomend it. When I get home from Robotics today, I'll read through the documentation I wrote to get it to work, run a copy by Brad to see how it looks, and then work on getting it posted.

[keen101]

cool. keep up the good work. I'm very interested in this. Unfortunately i don't have a copy of our software yet, so i can't try it yet. I will be sure to try it when i can.

[spicyj]

Originally Posted by AustinSchuh

Reverse engineering sounds like a big challenge, so I wouldn't recomend it.

I'm not sure it would be that hard, as it's all over the network and easily sniffable. Anyway, if you've got how to do it, please share!

Also, it looks like pogenwurst is right. LabVIEW for Linux doesn't have the proper tools: http://www.chiefdelphi.com/forums/sh...6&postcount=18.

[ratdude747]

hate to revive an old thread... but here i go!

does the frc edition of labview include the linux files? if so, ut better not be tarballs! (i use ubuntu but i am good at alien). all i would want it to do for now is code writing practice (and to settle a bet with a windows fanboy).

[daltore]

No, there is no Linux version on the FRC disk. The FRC LabView installer is only for Windows because, as previously discussed, there is no NI realtime engine for Linux (or Mac for this purpose). I once found a trial version of LabView for Linux, but it was RPM based, and even with alien, it never worked. Now, it was also on a crappy computer, but sorry, I doubt it will work.