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.
The LINX toolkit does not report the correct version of RPi in error messages, but LabVIEW code can be deployed on the RPi 4.
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.
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.
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.
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:
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!
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).