I'm trying to install NI-VISA 17.0.0 on a Raspberry Pi 3 running openSUSE Leap 42.2. Everything is running on 64 bit but when I go to install, it gives me a message saying that the installer does not support 32-bit kernels. I'm currently running the default kernel 4.4.104-18.44 which, as far as I know, is a 64-bit kernel. Is there a way to get around this?
I would also like to know if there is a solution to this.
I tried installing the VISA drivers on a Raspberry Pi 3 too, under CentOS, and it seems impossible since the ARM processors on the Pis are not supported by the NI drivers.
Our lab's solution was to avoid the problem entirely by finding a cheap small desktop that has a regular Intel CPU, but it is nowhere near as convenient as using a Pi.
The Raspberry Kernel is differente from the normal CPU. I'm sure about this.
Second point is, for me the performance about Labview in Raspberry to became a problem for your test setup.
I talked to application engineer and currently NI VISA isn't supported for the Raspberry Pi's processor. Here's the full response.
"I've doing research on this topic and it unfortunately seems that it's not possible to install NI VISA in a raspberry pi, as it is mentioned on this forum post: Is there VISA libraries for ARM?
Also this other post mentions the same thing: LabVIEWMakerHub https://www.labviewmakerhub.com/forums/viewtopic.phpf=12&t=2340&p=9860&hilit=VISA+raspberry+pi#p9860...
This was a little confusing for me, since both the operating system and the fact that it is 64 bit is supported. From the conversations I've had with some colleagues it seems that the only LabVIEW/National Instruments-like software that is supported in Raspberry Pi's is LINX (I should warn that it was not developed by NI). It's available to be downloaded here: LINX by Digilent/LabVIEW MakerHub http://sine.ni.com/nips/cds/view/p/lang/en/nid/212478
As it is pointed out in the link for download and in the first forum post this allows to treat the Raspberry Pi's as targets for LabVIEW code."
Their code (especially NIKAL) is pretty unportable - they'll have to rewrite/redesign lots of it, as much is written with x86 specific assumptions.
The technically correct way would be publishing the necessary specs, so we can write free drivers (which of course are platform independent) and bring them into mainline. But I guess NI folks would rather die before publishing the specs.