Targetting Raspberry PI

[Deborah_B]

Hi Andreev_S.V.,

Building on BradM's second point, you would need a LabVIEW Real-Time Deployment License for this. Please contact myself, deborah.yagow@ni.com, or your local NI Field Sales Engineer if/when you decide to move forward porting.

[Andreev_S.V.]

Hi Deborah,

thanks for good news! Actually, several years ago we did the similar thing by running NI LabVIEW RT PharLap/ETS on other hardware (of course, with proper payment to NI for the license). And I remember, that there was great documention from NI on how to install and configure that OS on regular PC/desktop hardware.

So, paying for the license for running NI LabVIEW RT (Linux) on other hardware is not a problem. My question actually was about the related documentation from National Instruments. Is there any documentation, help, examples on how to modify NI RT Linux to allow:

1) Booting NI RT Linux on non-NI hardware (other ARM-based SOC)?

2) Running of LabVIEW RT programs on that non-NI hardware?

And could you clarify some details about LabVIEW RT/RIO driver? Is source code open for community? Are there any documentation on how can we modify that driver to allow working on non-NI hardware?

Thanks in advance.

[Deborah_B]

Hi Andreev_S.V.,

We do not provide documentation for such modifications at this time. To provide more context, as Brad described above, we have made modifications to NI Linux RT specifically to optimize NI hardware support and I/O integration. These modifications don't translate to 3rd party hardware, and in some cases might even negatively impact performance on other hardware.

When looking to run a LabVIEW Real-Time Application on 3rd party hardware, there's no guarantee that the 3rd party device will actually deliver real-time performance -- this is something that we spend a lot of time testing and validating on our hardware. As such, we recommend either applying the PREEMPT_RT patch to the distribution supported on the 3rd party device, or using LabVIEW for Linux Desktop to develop your application. Achieving real-time performance with LabVIEW on 3rd party hardware is no trivial feat, and isn't something we offer with NI Linux Real-Time presently.

[ramses64]

Hi all,

Great New : Microsoft just annouced support Windows 10 for Raspberry Pi 2 , the new Raspberry Pi 2, Model B (http://fr.rs-online.com/web/p/processor-microcontroller-development-kits/832-6274/)

Does it mean that in the future, we could run ou exe on such boards ?

regards,

Vincent.

[BradM]

Hi ramses64!

Like you, I'm pretty excited about the RPi 2. It's a lot of power for not a ton of cash, and I'm sure there will be some great projects that are based on it.

That said, let's look at some of the details. Microsoft supports running Windows 10 on the thing through their development program. Looking at the board specifications, it's an ARM processor. Now, what that means is that, in order to run a program on the platform, it would need to be a Windows ARM .exe file. Currently, LabVIEW does not support that. Heck, I'd venture to say that 95%+ of Windows .exes have not been ported.

As such, the path of least resistance (and currently no NI support) would be running NI Linux Real-Time binaries on the controller. As Deborah_Y and I alluded to, this is not a simple task currently.

What is your interest in running LV on this target? Did you have some particular application in mind?

Thanks!

[SimGa]

Hi all,

the new Raspberry PI 2 Model B has an ARMv7 core. above you mentioned that labview RT is compiling files for armv7 only. If we neglect windows 10 on the Raspberry... Would it be possible to run labview RT applications on a Raspberry PI 2 with linux?

Thank you!

[ScotSalmon]

Quoting from the FAQ at https://decibel.ni.com/content/docs/DOC-35053 --

Question: Can I run NI software like LabVIEW Real-Time (proprietary, licensed product) on other third party hardware with armv7-a architecture like BeagleBone Black?

Answer: We are not planning to support LabVIEW Real-Time on 3rd party hardware at this time. You must purchase a LabVIEW Real-Time deployment license for every non-NI hardware target. Please contact deborah.yagow@ni.com or your local NI Field Sales Engineer if you decide to move forward porting to such hardware.

I just updated the FAQ to mention the RPi2 in that question also.

[Undefined]

You do pose an interesting question...

BradM wrote:

... What is your interest in running LV on this target? Did you have some particular application in mind?

Thanks!

The reasons for Microsoft porting to RPi is obvious... They want a share in IOT.

For a low cost device, such as the RPi, I can see interesting development using LabVIEW.

But that would be for another topic.

[BradM]

Welcome, n/0!

We're sensitive to the notion that, with a fairly potent embedded system that is easy to program, we lend ourselves well to the looming IoT future. I tend to agree that this would be an interesting idea and potentially unlock some cool applications.

As noted in the comment posted by ScotSalmon, interest can and should be directed to the listed email address so we can gauge interest in this use-case.

[rolfk]

Just to be a little more specific about the Microsoft Windows support for RPi. This is the Windows RT version. That is NOT the same as the Windows system on your normal desktop but basically a completely new system based on a .Net architecture and Windows like GUI but much of the internal kernel is completely different. The x86 centric kernel of the normal Windows version didn't lend itself to porting to embedded platforms like ARM at all. Windows RT is also what is used for the Windows Phone system.

In short it calls itself Windows but is in fact an almost entirely different OS. The only common thing between the desktop version and the RT version is the .Net CLR system which works very much like Java. A true .Net application is compiled to byte code and can then run on any .Net based system independent of the underlaying hardware. As of now, a large amount of applications that are distributed for desktop Windows are still (in part) compiled for the native x86 system underneath and therefore won't run on a Windows RT system at all.

And a CLR/Java approach for LabVIEW unfortunately isn't a very feasable task. CLR/Java works reasonably well for UI only applications but breaks fatally when you need to access underlaying hardware in a different way than what the runtime developer had envisioned.