Hobbyist Toolkit
LINX and Raspberry Pi4 Mis-identification Issues
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.
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.
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).
@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?
