Abstracting the hardware
Tuesday was a very big day for my group and the timing is rather interesting.Monday, Apple announced they were switching from PowerPC to Intel x86 processors. Mac software developers everywhere were both overjoyed that they were getting a faster processor and dismayed that now they have to do some work just so their software keeps working. Software is very sensitive to its operating environment and needs to be modified or recompiled when the environment changes in unanticipated ways. Fortunately, changing processors is actually less of a problem these days than changing operating systems. Applications written in C on WindowsCE basically runs on MIPS, X86, or ARM systems. It needs a recompile and it needs to be tested, and tested, and tested (write once, test multiple). Software written in interpreted languages like Java, Javascript, or PHP don't even need to be recompiled. They just need to be tested on the different platforms. It's the testing, though, that can eat up a lot of time and expense. Why all the testing? There are subtle differences between each implementation of the environment. Javascript apps run differently in Internet Explorer than in Mozilla. Java apps have different environments on Sun versus Windows versus Mac.
LabVIEW (the code representing the development or execution environment), over its history, has been shipped on Macintosh (68k and PowerPC for MacOS "Classic" and MacOS X), Win3.1 through WinXP (x86 CPUs), Sun Solaris (on SPARC processors), SCO Unix, Linux, HPUX (on PA-RISC), Concurrent PowerMAX, PalmOS, PocketPC (ARM), Windows CE, RTX, and PharLap. In fact, it has outlived most if not all of the compilers used to create it. Every time we ship LabVIEW, the testing needs to be duplicated across each platform, at least for the places the are different between them. Over time, we've dropped some platforms when the sales we got from that platform no longer covered the cost of testing and support.
Sometimes, we do ports of LabVIEW internally to satisfy some curiosity or as a one-off experiment. We did a version of LabVIEW with the Jet Propulsion Laboratory to see whether it made sense to write software for space flight applications in G. The experiment is still going on but the results look promising.
We have talented developers but at the end of the day, you can only support a limited number of configurations. We commonly get requests for LabVIEW to run on some hardware that we don't currently run on, be it a military VME controller running VxWorks, an automotive telematics system running QNX, or an engine controller for a train running a custom operating system. Building a new version of LabVIEW to run on these platforms just hasn't been an option. Before today, we always had to say no. But today we announced the LabVIEW Embedded Development Module and we don't have to say "no" any more.
Over Christmas break, when no one was around, I got a week to play. I took a development version of the software and found the cheapest embedded target I could: a Linksys WRT54G router. $69 from Frys. Linksys runs Linux on the box and some enterprising hackers had figured out how to write applications that would run on the unit. It took me a little bit of time but in about a week I had adapted LabVIEW to run on the unit using the Embedded Development Module. When I hit the run button on my VI, it would take the VI, convert it to C, script the compiler for the platform (GCC) to build the application, call some scripts to download the code to the router, start the program running, open a TCP/IP connection back to the host, and let me interact with the application just like I was talking to a LabVIEW RT target. I had a new toy and grinned ear to ear. LabVIEW running on a router of all things. Even better, it ran as a multitasked application so my Linksys box actually routed packets while my application was running. The Linksys box has no real I/O but it has 5 Ethernet ports and a WiFi antenna. I'm sure someone could do something with it. The best I could do was write a program to control an ENET-GPIB box connected to an instrument. $69 instrument control. How fun.
Linksys also makes a device with an Ethernet connection and a USB master connection. Wonder what I can do with that USB port....
posted by Joel @ 8:23 AM
7 Comments:
That is really pretty geeky, setting LabVIEW up on a router. I just wish I had the time and patience to accomplish something like that. Good work!
It was surprisingly easy. It actually took me longer to get gcc cross-compiled for the router than it did to get LabVIEW going on it. If I hadn't found something called Crosstool, I never would have been able to build gcc.
Wow, that's fantastic!
I thought the wrt54G actually had headers for at least 2 serial ports. I found some pages that describe the neccesary hack
That opens a whole realm of possibilties! I happen to have 2 wrt54G's. Do you expect the possibilty that people will start sharing the code that is target specific? I understand from the tutorial for the embedded module that before you code any G, you need to port the runtime and such first..
Yes, we're absolutely going to share the instructions and plug-ins required to get it up. I need to make a web page for it first. We're also experimenting with having a public source code control server based on Subversion that allows people to contribute plug-ins, modify the ones we did, and co-develop them with others. We hope to have it up in a few weeks.
That is great news! I think this will cause a quantumleap forward for Labview in embedded applications, despite the cost of the module. Another hardware that comes to my mind is gumstix.
The availability of these kinds of "generic" COTS embedded platforms will allow Labview programmers to come out with all kinds of dedicated smart hardware.
Originally, I wanted to have this up during the beta program and so we couldn't have NDA software up on Sourceforge. We considered it for after release but there are some ways in which this code isn't compatible with the GPL and needs to be access-restricted to just people who buy the module. So, yes we considered it but it doesn't quite look right for this application.
Answers as best as I know:
1) Doesn't work with LabVIEW for Linux, only LabVIEW for Windows.
2) Not sure what you mean about "vs LabVIEW RT". Yes, they are different. Quite different under the hood. They each have their purpose. In some cases, RT is much more appropriate, in some cases Embedded is much more appropriate. It's best to talk to an NI salesperson to get more details. You could also look at ni.com/embedded to look at the capabilities of the LabVIEW Embedded Development Module and see how it compares to LabVIEW RT.
3) In theory, you could use the Embedded module on our PXI hardware on another OS. It would technically work but I'm not sure you want to do it. We don't supply board support packages for other OSes for our hardware so you'd have to get that OS working on the hardware yourself. Our driver support and toolkit support on other OSes is more limited. And the LabVIEW Embedded Development Module is more expensive than LabVIEW RT. Maybe your application would really benefit from doing this however. You need to talk to an NI sales person more about it to look at your needs.
4) You definitely cannot substitute the OS that LabVIEW RT runs on. That was one of the main points of my article. The technology we use for LabVIEW RT really doesn't allow it without NI doing a lot of special work.
Post a Comment
<< Home