Hobbyist Toolkit

cancel
Showing results for 
Search instead for 
Did you mean: 

LINX and Raspberry Pi4 Mis-identification Issues

Hi nickbike,
I think WS2812 support was only included for Arduino targets. It was not implemented in the RPi or BBB versions of LINX.  
Hopefully NI will add it in later versions of LINX. 

0 Kudos
Message 11 of 29
(2,678 Views)

The LINX toolkit does not report the correct version of RPi in error messages, but LabVIEW code can be deployed on the RPi 4.

0 Kudos
Message 12 of 29
(2,669 Views)

The LINX WS2812 functions are only supported on the chipKIT WF32 and Max32.

 

0 Kudos
Message 13 of 29
(2,646 Views)

A quick and dirty workaround to get the correct Pi Model number is to modify the Get Device Name vi to read from the "/proc/device-tree/model" file with a simple LabVIEW Read File function. Just wire -1 to the length and then the File IO will read the full length. A lot of things are actually possible in this way through the File IO functions in Linux including accessing the GPIO lines. It's not as performant as a dedicated device driver but for many purposes more than enough.

 

I have been working in the last two weeks on an updated version of the liblinxdevice.so shared library that fixes many of these things and also adds support for both SPI devices and many more things to the liblinxdevice shared library. I'm currently debugging it and it is still crashing but once I have something more robust I will post it together with the github link.

Rolf Kalbermatter
My Blog
0 Kudos
Message 14 of 29
(2,624 Views)

Thanks for the information, All.  I am particularly interested in support for SPI.  I actually thought it was supported because it shows up in LINX, but have not tried it yet.  (I confess I am en extremely naive user in the Pi/Linux environment.)

 

This is perhaps something for a different thread, but I understand the Pi Zero is not currently supported.  Is there any chance that it will be supported in the future?  It would be a really nice to use these in head sensor units connected to a master. 

0 Kudos
Message 15 of 29
(2,620 Views)

The Linx Toolkit for Raspberry Pi supports SPI but it only makes spidev0.1 available as SPI device 1 but not the spidev0.0. Adding that in the liblinxdevice shared library is a trivial fix but of course requires GCC recompilation of the shared library.

 

As to the Raspberry Zero, no there is no chance that this gets supported anytime soon as an embedded target where you can directly deploy LabVIEW VIs onto. It uses the BCM2835 CPU which has the ARMv6 architecture but the LabVIEW compiled code requires at least an ARMv7 architecture, which the BCM2836 on the Raspberry Bi 2 Model B has  (and all newer models after the Pi 2 have either a BCM2837 or BCM2711 CPU which also support the ARMv7 architecture).

I'm entertaining however the idea to create a Linx server from the existing code that could be recompiled for the Raspberry Pi Zero (and would most likely run on the older Raspberry Pi A and B too). In that way you could communicate to the Pi Zero in the same way as you can now to an Arduino and other such Linx supported lower end embedded controllers over a serial port or TCP/IP.

Rolf Kalbermatter
My Blog
0 Kudos
Message 16 of 29
(2,594 Views)

Hi Rolf,
Thank you for your posts. Good to hear from other people who are adding functionality to liblinxdevice_rpi2.so. 

There are a few targets in the makefile that can be used to create servers for the Pi Zero:

 

raspberryPi2BSerial
raspberryPi2BTcp
raspberryPi2BConfigurable

 

The server can be compiled as a normal application. It does not need to be run in the chroot.

It works with the PI Zero configured as a USB Ethernet gadget. I tested it on a sbRIO. The Pi Zero was recognized as a network interface by the NI Linux Real-Time kernel!

 

Cheers,
Andy.

0 Kudos
Message 17 of 29
(2,572 Views)

Indeed! I hadn't really looked at the Listener part so far besides making sure that the code still should compile. Getting that to compile on a Raspberry Pi Zero should be all that is needed.

 

But after hacking a few days away to add new features I had to make some changes to the whole object architecture. As it was it was way to unflexible to efficiently add support for multiple hardware targets. One single object hierarchy is nice if you only have a few device types to support but as it was you had a lot of code duplication between the Rasperrry Pi and Beagleone Black as most of it was simply Linux specific. And there is not a lot of a reason why the TCP/IP communication part needs to be seperate for Windows and Linux. The few differences in the Berkley Socket interface implementation are pretty easily abstracted away with a few stretegical ifdefs as we don't require fancy platform specific ioctls. Also I find it a bit complicated to have one huge object interface that provides everything. It's much more flexible to implement the different interfaces such as serial, TCP/IP etc. in a seperate class that is then simply used by the main class. Trying to solve that in a platform neutral way purely through inheritance is a nightmare as the different derived classes soon will exponentially grow as each platform needs its own custom layer for one of these interfaces. Instead it's much better to use composition for that.

 

Once this is all ready there can be also a real liblinxdevice.dll for Windows that implements a few local interfaces such as Uart, and remote interfaces to other Linx devices through built in TCP and Serial. Most of the inside in the Linx VIs will then be fully inside the shared library and therefore unneccessary. At the same time the library will also do much better error handling. As it was it did rely heavily on the caller to not make any mistakes in calling it with invalid device numbers/channels and any error returned by the shared library was turned into ONE generic "Unknown Linx Error". There is also no reason why the different communication interfaces couldn't support dynamic interfaces such as Uart ports that are mounted and unmounted through for instance plugging in an USB to Uart cable (if the underlaying OS is of course properly configured to regognice such devices and automount and unmount them).

Rolf Kalbermatter
My Blog
0 Kudos
Message 18 of 29
(2,527 Views)

Everyor, Now I also hve the same problem , I want to know is there a solution about it.

0 Kudos
Message 19 of 29
(2,183 Views)

@James.Jia wrote:

Everyor, Now I also hve the same problem , I want to know is there a solution about it.


There were several different problems mentioned in this thread. What specific problems do you have? Did you read the thread at all or just append a me-too post?

Rolf Kalbermatter
My Blog
0 Kudos
Message 20 of 29
(2,150 Views)