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

[metux]

---

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

hmm, resource constrained ... I've grown up w/ 6510 and U880 CPUs - compared to that corexa9 is like superluminar speed ...   

And there is no alternative.

Reminds me to politians talk ...

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 to LLVM bytecode would make it CPU agnostic.

compiling them with a toolchain they have no real control over and keeps staying a moving target.

Right, a decade is like a blink of an eye for an old dinosaur.

Perhaps they just could have a look at how linux embedded experts cope w/ toolchains (hint: oselas)

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.

The kernel interfaces are fixed. The most relevant variation here are the actually existing devices and what they're actually used for (eg. on which port some relais module connected) - but that's a local configuration anyways. Just like on the desktop.  

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.

Same for Linux embedded. The abstraction layer is the kernel.

The big difference is that on typical desktop system, people just use the Distro-provided binary packages. But you'll still have to compile for the Distro, as soon as you're using any of its libraries (beginning w/ libc). Or link statically (or use chroot, containers, etc, etc, etc)

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, 

 ... and lots of standard device interfaces, eg. for industrial IO ... just as on the desktop. 

may be enabled in the kernel or not and even more maybe working reliable.

Just like on the desktop.

How about just telling the users exactly which kernel features are required ?

That's all ok as long as you work in your own toolchain environment 

Yes, your own toolchain. The user/bsp-vendor's toolchain, of course. Just use that.   

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

Just use standard infrastructure. It's all there. That already works for a lot of language environments, python, java, etc, etc. I don't see why adding yet another one should be that hard.

NI doesn't believe that engineers and scientist must always have solutions that work out of the box.

Believe!

Yeah, I see that. Many of the products work at all, due to the lack of / binary-only drivers (which in the end leads to the same effect: unusable).

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.

Just do proper packaging and offer package repos for the target distros.

Basicly you'd just have to set up a CI for deb and rpm based distros (should catch about 90% of the distros there) once, and do some tweaks here and there - then packaging for a hundred of different distros isn't so much more than a big for-loop.

But looking at their .rpm's - they don't even learned the fundamentals of packaging.

And those folks playing around in kernel space - nightmare.

That doesn't mean that NI doesn't support Linux too, as you can see,

No, they dont. Instead they just support a few specific distros of some specific releases with some specific kernel binaries. As soon as you have a different kernel (or even recompiled w/ certain changes), all hell breaks loose, because they dont even provide decent kernel drivers - proprietary kernel drivers are pure madness. 

This can't work. They just did it fundamentally, completely wrong.

Most users of that platform are in fact academic instititutions,

Academic institutions. A traditonal Unix world ...

As we've already seen, GNU/Linux isn't really supported - which other (still alive) Unix is supported ? FreeBSD ? Solaris ?

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. 

Kicking out a whole - strongly growing - market and bricking yourself into the ancient past is a successful path for the future ? Seriously ?  

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.

People who call themselves "economists" but don't know anything about the products their companies are the best candidates for demolishing a company. Just have a look at how eg. HP currently destroys itself - quite funny.

They rather take 1000 $ gain tomorrow, than 100$ every year for the next 20 years.

Regarding the current interest rates (unlikely to get up anytime soon), doesn't look like a good long term decision. Yes, in recent years big corporations usually just look for the quick penny - throwing everything that made them big in the first place - perfect way for economic suicide.

Even if interests would be a problem: NI is big enough to easily run its own bank - gives free money out of thin air.

But again: decisions are made by economists - the last group on earth you'd expect economic knowledge from. I more and more feel like being locked up in a Douglas Adams novel 😮 

[metux]

---

@rolfk wrote:

However looking at the SBRIO platform for instance there is certainly an offering from NI that can be used for embedded applications.

---

Could. Theoretically. If they ever solved the driver problem (IOW: releasing them under GPL).    

[metux]

---

@RSecrest wrote:

By using NI hardware, the software can be developed more quickly therefore offsetting the PROJECT cost and getting to a market more quickly.

Perhaps for a simple PLC application - no idea, not my area.

But for generic Linux applications it's in fact *very* *very* expensive.

No, I'm not talking about the hw costs - the development and maintenance costs - especially in the long term (note: in embedded world, 20yrs lifetime isn't unusual).

First, you'll have to have to specially tweak your application for that particular environment, because they break the Linux standard methods in so many ways. For example, you'll have to use their howmbrewn proprietary libraries even for trivial things IOs. Can't use the standard infrastructures like IIO.

Then you're bricked in to the factory-installed environment. Can't upgrade the kernel, and even when just recompiling their patched-to-death vendor kernel, you'll have to be very careful, so the binary-only kernel module still works (wont be reliable anyways). 

And assuming it's not your only target platform, you'll have lots of extra work to do for a decent long-term release engineeing. Can't use standard technologies.

But, again, Econ 101 dictates that it MUST make sense and have a return on investment.

---

Hmm, the biggest showstopper of making it a product usable for Linux applications, is the lack of usable drivers.

Solution: release them under GPL.

Required investement: near to 0 $.

Long-term savings: several man-years.

[metux]

---

@rolfk wrote:

One big problem of this which you shouldn't forget: LabVIEW without IO drivers is really more a toy than a useful programming environment.

IO drivers are the natural job of the OS.

Okay, the game launcher from Redmond doesn't offer much here (guess they still don't have trivial things like can sockets, etc), but it's not taken seriously in embedded world anyways.

Linux offers everything we need, eg. IIO, various field buses, etc, etc.

Just need to add a few little drivers for some chips here and there - not a big deal, if you have the full specs. 

Porting VISA to the iOS or Android platform is likely a very different beast of burdon and in the case of iOS burdoned with additional Apple license issues.

iOS isn't a general-purpose platform, more like a modern gameboy which happens to support phone calls.

Stock Android kernel is quite far from mainline, but I already have most (not yet mainlined) patches rebased on recent 4.x laying around here ...

Dreaming of DAQmx on either of those platforms is probably going to stay a wet dream forever.

---

If they'd release the source of their proprietary drivers as gpl, Linux/Android wouldn't be the big deal anymore.