Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW for Linux on single board computers (e.g. Beaglebone)

Greetings fellow wire workers.  Has anybody considered using one of the SBCs listed here as a target for their LabVIEW programs ?  Has anyone successfully done it ?  For example something like the Beaglebone SBC (http://beagleboard.org/bone , http://en.wikipedia.org/wiki/BeagleBone#BeagleBone ).

The Beagleboard-xM for example has been demonstrated using Angstrom Linux,[13] Fedora, Ubuntu, Gentoo[14] and Maemo Linux distributions,[15]

Is there a moderate chance that LabVIEW for Linux would be able to work with the standard inclusion of peripherals such as Ethernet , USB, USB-OTG, RS-232, MicroSD/MMC card slot ?  I expect to need to write my own drivers for other peripherals such as I2C, SPI and the general purpose I/O lines etc. 

We are seriously entertaining the idea and unless somebody can point out some really difficult problems we might encounter, we plan to buy a couple to evaluate their suitability.

rgds

Peter Badcock

ResMed Ltd

Peter
0 Kudos
Message 1 of 34
(31,616 Views)

The board you are considering runs an ARM processor, but LabVIEW for Linux is only supported on x86 processors. If you find one that runs an x86 processor (maybe an Atom or some other mobile processor) then it should be possible.

0 Kudos
Message 2 of 34
(9,621 Views)

Thanks Adam.  What happens if I try to run LV for Linux on an ARM platform, will it simply not launch, or just behave unpredictably?

Peter
0 Kudos
Message 3 of 34
(9,621 Views)

x86 and ARM are two completely different CPU architectures. The ARM CPU has no idea what to do with the x86 Opcodes in the Linux for x86 LabVIEW executable.

But Linux will already refuse to load the executable since it is not a compatible executable format. It's even more different than trying to run a MacOS X program under Windows (without any form of emulator). And no, running LabVIEW under an x86 CPU emulator on an ARM embedded system is definitely killing its performance to 0.5% if such an emulator would exist.

Rolf Kalbermatter
My Blog
Message 4 of 34
(9,621 Views)

Thanks Adam and Rolf.    It is really dissapointing that NI continues to hold its cutomers hostage to using its own embedded HW which is so expensive, relatively inflexible, large form factored and hardly state of the art.    I have tried so many ways to use LV on non NI embedded platforms and perhaps the only viable option left is to investigate the Intel Atom x86 range of embedded solutions running Linux.

LabVIEW sales would increase generously if NI was to release LabVIEW which targets ARM based SBCs/SOMs running say Linux.  NI doesn't do this because they prefer to make exorbitant (per unit) profits from their own embedded H/W sales.   Embedded computing is here to stay ond growing exponentially.  NI recognise the need to give more embedded solutions in their roadmap, but fall short in a major way by choosing not to support (in any serious way) any embedded H/W platform other than their own. (e.g. the ARM generation of embedded offerings.)  They have a token gesture solution for CortexM3 and ARM7, but they are dinosaur platforms and LabVIEW runs at ONLY 6-16% efficiency when using more than one loop on those boards (see here).   NI market LV as a general purpose programming language.  I think it is difficult to make more such a claim anymore when LabVIEW does not target the worlds fastest growing embedded controller (ARM).  Of course NI will lose H/W sales, but that will be more than made up for by the increase in LabVIEW sales, not to mention the added respect/kudos they will get too.

NI's share price continues to fall (30% down over the last year relative to the Dow Jones US Technology Index) and I think the best way to arrest this decline is to give their customers the means to program such targets lest they end up using other programming languages to do so.

Peter
Message 5 of 34
(9,621 Views)

While it's understandable that you are disappointed the issue is actually a little different than what you think. The reason LabVIEW supports only embedded targets from NI out of the box is that there is a HUGE effort to create a LabVIEW environment to run on any specific embedded target. With their own targets NI has the whole system under control and can make sure it runs smoothly. With COTS embedded targets that is far from true. There are virtually 100ds of different ARM embedded targets (and quite a few other CPU families) with many of them suporting several very different kinds of (RT) OSes. Each of these targets has a specific hardware device selection with many of them requiring their own specific device drivers that adapt to the OS of choice. Putting a LabVIEW system on such a hardware is anything but trivial and quite impossible for NI to do even for a few selected hardware targets. They did it with LabVIEW ARM Toolkit for a few (not using Linux but the Keil RT OS) and almost nobody is using it because it's quite expensive and of course not the HW and/or OS of their choice.

Yes NI of course would like to sell you their hardware and the seemless LabVIEW support for them has a price. And that is not because they want to rip you off, but because targetting any embedded hardware is a very expensive task. NI simply can't support every OS/HW variant out there and if they would try they would be faster out of business than you would need to burn your NI shares :-).

LabVIEW for Linux already shows that it is not as trivial than compiling the LabVIEW source code for the specific OS. Installing LabVIEW on any of the not officially supported Linux x86 distributions is already quite a roulette game, and the embedded target market with different CPUs exponentially multiplies these variations even more. NI doesn't even have an ARM compiler for LabVIEW so far, although that is supposedly not as hard anymore to add since they use the llvm compiler now. Not as hard is however not automatically easy.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 34
(9,621 Views)

How disappointing. As a C programmer the world is my oyster and I can program any platform from desktops, PDA, mobile phones to any microcontroller. With LabVIEW, in effect, there is only the desktop.

National Instruments could extend the LabVIEW Embedded for ARM Tier 1 boards to include 1 (one) more contemporary popular development board, but choose not to. There are only two Tier 1 boards and they are over 6 years old! The effort to introduce another ARM development board is very small. NI could release an inexpensive RIO platform (look up Xilinx Zynq) with a small form factor that plugs into your product (rather than the other way around) for less than $150 (the Zynq chip sells for less than $30 in single units). The list goes on. For more details, see the bottom of the first post on http://forums.ni.com/t5/LabVIEW-Embedded/LabVIEW-Embedded-Performance-Testing-Different-Platforms/td....

Technically, National Instruments is spot on. However their marketing is killing the company - as highlighted by Peter and the dramatic stock price reduction for NI.

National Instruments are trying to herd their relatively small LabVIEW user base that wants to expand into the embedded environment into CompactRIO (very expensive), sbRIO (no prices on the website!) or C Code Generator (ridiculously expensive).

Development environments are evolving at a rapid and exciting pace. National instruments needs to innovate if it is to prosper. And as a LabVIEW programmer, I’m in a symbiotic relationship with National Instruments that needs it to prosper.

National Instruments are exploiting customers to satisfy shareholders. However, in the end neither is satisfied. I may be a single user in the wilderness, but I suspect that my opinion is shared amongst all (non-academic) users who wish to go beyond the desktop. The ability to satisfy shareholders is unquestionable - the share price tells all. Iceberg straight ahead ... what to do.

0 Kudos
Message 7 of 34
(9,621 Views)

Hi Rolf.  The explanation you present for NI choosing not to target COTS embedded would be believable a few years ago, however given over 6 years has passed since the last ARM targets were introduced, clearly NI do not want to keep releasing new targets otherwise they would have done so by now.  It does not take 6 years to target a couple of new platforms that have a good "out of box" experience.  In fact earlier this year, NI quoted us only a couple of months work for them to target a new Tier 1 platform of our choosing (which was able to run the Keil RT-OS).   Only a couple of months for NI to write the drivers for a majority of the peripherals.    And perhaps a couple more months to target all the peripherals on one Tier 1 board.     Of course we would have paid them for their efforts, but why should we do that when NI could simply have done it themselves and released a new set of Tier 1 products ?   Here are the reasons why we didn't go down that route:

  • NI would not commit to supporting LabVIEW Embedded for ARM in future LabVIEW releases.  We won't invest our time and $$ in a solution that isn't maintained by NI.
  • LV is grossly inefficient when running parallel loops under the Kiel RT-OS
  • We didn't want to be party to NIs strategy of forcing people to use NI  H/W (by discouraging them from publicly releasing a new Tier 1 as opposed to a private release for just us)

It isn't as hard as you make out for NI to target a new Tier 1 device.

NI choosing to use the LLVM Compiler in LabVIEW now makes it so much easier for NI to target ARM and other platforms.

The other option NI has (which they must seriously consider to stay afloat) is to provide only a limited amount of functionality for a larger set of COTS embedded targets.  The community would then take hold of that and start helping each other to write the drivers for other peripherals.  NI refuses to let their customers do this because :

  • They incorrectly believe engineers and scientists must always have solutions that work first time out of the box
  • They are being greedy in trying to keep the lions share of profits to themselves through their own H/W sales.

All my claims can be ignored, but it is impossible for NI to ignore their dropping share price (30% drop in 1 year is bad).  The strategy I propose will generate good will amongst its customers and help NI sales increase.   For NIs sake, I really hope there are some NI product managers reading this thread.

Peter
0 Kudos
Message 8 of 34
(9,621 Views)

Well, you name a few reasons why supporting the ARM targets you would like is not something NI sees much benefit in. The translation of entire LabVIEW VIs into C code is a rather complex and inefficient way to generate code for those typically resource constrained targets. And there is no alternative. LabVIEW is a very complex language to represent in C. It's also not the aproach NI takes for their own targets. Instead they compile a LabVIEW runtime for their hardware target that can execute VIs unaltered without the cumbersome steps of converting them into C, compiling them with a toolchain they have no real control over and keeps staying a moving target. The ARM Toolkit (and the already discontinued AD Blackfin Toolkit) were attempts to see if it could be made workable. The result clearly was that: yes it does work, but no not very well or fast. That added with the sales figures for those Toolkits clearly showed that there has been a lot more effort invested into them, than it has returned so far and chances are not that big that this is going to change, since the aforementioned drawbacks are inherent to these Toolkits and can't really get taken away, without limiting the scope of features considerably that can be used in VIs for those platforms. Once you take out things like inherent multitasking, the translation and execution of code gets a lot easier, but that removes a key feature of the LabVIEW language from it.

The C Code Generator is a way to make use of the already exisiting LabVIEW to C translation engine, without tying it into a specific environment or trying to make entire VI Hierarchies completely into C code. It works and has its niche usecases, but its pricing, while not even extreme in comparison to other EDA tools like FPGA compilers, is kind of prohibitive.

And yes LLVM makes supporting other CPUs a lot easier, but the CPU compiler is only a small part (albeit a complex one and one only few experts can manage) of supporting a new platform. It all needs to be tied together, many corner cases, exemptions, differences and variations need to be identified, fixed, worked around or otherwise prevented and last but not least, a considerable amount of every single release for every single platform is the testing, packaging and testing again. But with embedded targets (and even more so when using Linux on them) the system is very loosely defined in comparison to the existing Desktop solutions. For a Desktop it is relatively easy to create an executable that runs on a large scale of hardware platforms, since the underlaying OS like Windows or MacOSX takes care of almost all differences that might exist there. For embedded devices all your executable can assume is that there is some CPU, some working memory, probably some form of disk that can be accessed through the OS, maybe a network, and everything else may or may not exist, may be enabled in the kernel or not and even more maybe working reliable. That's all ok as long as you work in your own toolchain environment tailored to that target but makes building a LabVIEW runtime engine rather hard and one that works on more than a few very specific targets almost impossible.

NI doesn't believe that engineers and scientist must always have solutions that work out of the box. But a vast majority of customers do expect a seemless work flow from their tools, and don't want to be bothered to figure out how to install a Linux platform with all their sometimes conflicting dependencies to support a new software tool. That doesn't mean that NI doesn't support Linux too, as you can see, but the money clearly is not there. Most users of that platform are in fact academic instititutions, and to make raw sales figures look even worse, they almost never pay the normal license price.

And taking NI share prices in this discussion is clearly a misconception. First, shares have been droppping all over almost every technical company in the last year, as investements into new projects have been cut down considerably because of the anticipated economical crisis. It's simply representing the overal sentiment in technological investments. But if anything would influence that in a positive way, it would be probably more in the decision to throw out Linux, and several other supported platforms in favor of NI's proprietary solutions that succeed in locking customers more into the NI way. That they don't do that is something I find positive. And I'm not saying that it would be a good thing to drop all minor platforms and what else, but those economists who decide about what a company share should be valued, have no technological heart but only an economical, and current economics tend to look only until tomorrow. They rather take 1000 $ gain tomorrow, than 100$ every year for the next 20 years. Who cares if a company goes belly up after they garnished the 1000$ gain?

NI's business model has never been about creating low cost products that make their profit in selling it many million times. It's also not what I think would be a good business model to do.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 34
(9,621 Views)

rolfk wrote:

....The translation of entire LabVIEW VIs into C code is a rather complex and inefficient way to generate code for those typically resource constrained targets. And there is no alternative. LabVIEW is a very complex language to represent in C. .....

And yes LLVM makes supporting other CPUs a lot easier, but the CPU compiler is only a small part (albeit a complex one and one only few experts can manage) of supporting a new platform. It all needs to be tied together, many corner cases, exemptions, differences and variations need to be identified, fixed, worked around or otherwise prevented........

but makes building a LabVIEW runtime engine rather hard and one that works on more than a few very specific targets almost impossible.

When you describe it in those terms it does appear a daunting exercise if one takes a target agnostic approach.    However, whatever the obstacles, NI needs to at least be on a par with what MS are doing with their .NET Micro Framework that targets tens of different COTS embedded platforms.  NI aren't anywhere close and aren't even planing to.  Telling their customers it is too hard to target COTS embedded platforms and they instead must pay a premium for NI H/W will not keep customers at NI, it will tempt them to jump ship.

The C Code Generator is a way to make use of the already exisiting LabVIEW to C translation engine, without tying it into a specific environment or trying to make entire VI Hierarchies completely into C code. It works and has it's niche usecases, but it's pricing, while not even extreme in comparison to other EDA tools like FPGA compilers, is kind of prohibitive.

I'm glad at least one other person has taken the time to actually ask NI for a price of their C Code generator. There is NO way they will sell more than a couple of licenses at that price.  I could employ a juinor programmer for a year for the amount they are asking.    That C Code generator is part of LV Embedded for ARM which costs about 1/4 the price.  The prices for both those prodicts are simply artifically created to seriously reduce demand. There is no viable competitor product so the prices aren't driven by market forces.and NI are free to set the price wherever they choose.     At those prices, clearly NI don't want people to buy it because it will enable people to target ANY embedded platform they desire (to varying dergrees of success depending on their C skills).  That would cause NI to lose H/W sales which would be unfathomable to them.  Can you see any other justification for such high prices in the absence of a competitor ?

And taking NI share prices in this discussion is clearly a misconception. First, shares have been droppping all over almost every technical company in the last year

If you have a look at this link I gave in my post above you will notice that the index I compared NI to was the Dow Jones U.S. Technology index which is very comprehensive and includes 157 constituents/companies.  That index has risen 10% over the past year which means that almost every technical company has not dropped, In fact on overage the top 157 (by market cap.) have risen by 10%.  NI has fallen by 20% which is a 30% fall relative to that index.   I agree economists can be short sighted.  Market analysts spend their living pouring through info from everywhere including posts such as these in order to come up with their buy/sell recommendations.   In fact they will have read the following Embedded Systems Outlook from NI (here) and then attempted to match NI's claims with reality.  If they see sufficient disparity they will be advising their clients to hold or sell NI stocks.

NI's business model has never been about creating low cost products that make their profit in selling it many million times. It's also not what I think would be a good business model to do

I know, but something is wrong with that model if it doesn't serve the needs/wants of an increasing number of their existing customers.  I'm certainly not alone in my desire to run LV on embedded targets other than NI H/W.

Peter
Message 10 of 34
(9,621 Views)