06-28-2020 04:03 PM
I've managed to get the runtime happy enough to run on the RockPi S, a 64bit quad core SBC that's a third the size of a Pi. The LabVIEW stuff is still 32bit of course but this opens the door for supporting even more devices.
One of the tricks I pulled to get it to work is to first enable armhf (32bit packages) on the RockPi, manually edit the lvrt20-schroot package metadata to remove its dependencies on schroot and python since it was trying to install the 32 bit versions, and just manually install those packages before manually installing the edited lvrt20-schroot package. I also needed to install netbase for the labview service to start and I installed binutils to get the tools on the RockPi to unpack and repack the package.
I'm looking to automate this process but I'm not sure how to do all the architecture specifications from the commandline. If anyone has insight on easy ways to accomplish this I'd love to hear them so I can extrapolate this to other devices as well (looking at the Banana Pi M2 Zero next).
This assumes you've got the RockPi up and running and can access it already:
ssh/console/shell into device
>mkdir lvrt20-schroot
>cd lvrt20-schroot
>echo "deb [trusted=yes] http://feeds.labviewmakerhub.com/debian/ binary/" | sudo tee -a /etc/apt/sources.list
>sudo apt-get update
>apt-get download lvrt20-schroot:armhf
>sudo apt-get install schroot python avahi-daemon netbase binutils nano
>ar x lvrt20-schroot_20.0.0-4_armhf.deb
>tar xzf control.tar.gz
>nano control
Remove the schroot, python entries from the Depends: line
Ctrl+x to exit, Y to save, use same filename
>tar --ignore-failed-read -cvzf control.tar.gz {post,pre}{inst,rm} md5sums control
>ar rcs lvrt20-schroot.deb debian-binary control.tar.gz data.tar.gz
>sudo dpkg --add-architecture armhf
>sudo dpkg -i lvrt20-schroot.deb
07-01-2020 02:19 AM
07-01-2020 02:22 AM
Is there a LabVIEW Community Edition for Linux/RockPI?
07-01-2020 05:27 AM - edited 07-01-2020 05:32 AM
zhaozilong@live.cn wrote:
After installing LabVIEW on RockPi, how do we use its IO or UART or IIC?
Most likely you can't with the current implementation of the Linx library. The GPIO lines, I2C, SPI and UART device names are specifically assigned for the Raspberry Pi and Beaglebone Black implementation of the shared library. The RockPi using a different CPU (RockChip 3308, 3328 or 3399) instead of the Broadcom one that the Raspberry Pi uses, means that the entire GPIO design as well as other on board IO peripeherals including I2C, SPI and UART are very likely using different Unix device names. The BeagleBone Black uses the Texas Instruments AM335x CPU and is requires in many aspects different device names in comparison to the Raspberry Pi and has its own liblinxdevice.so implementation.
For instance the Raspberry Pi uses the ttyAMA0 device name for the serial port, which is a very specific name, based on the Linux driver needed to access the on-chip serial port implementation. This almost certainly would never map to any non-Broadcom CPU device.
@ElioTx wrote:
Is there a LabVIEW Community Edition for Linux/RockPI?
No, and although it would be possible to make, it is a little more work than just recompiling the liblinxdevice.so shared library aside from the customization needed to make to the actual schroot install.
07-01-2020 08:37 AM
Yes so far this is just getting LabVIEW on Linux, not specifically Linx. If you know Linux and have done I/O stuff you'd be able to do some of that stuff through LabVIEW already. Most of the functionality is exposed through "virtual" files (most everything in linux is exposed as a file) and being able to configure and read/write GPIO can be done in this way if you're familiar with this capability. I also don't use the Linx serial VIs, I use VISA directly though I haven't tried that yet on the Rock Pi to see how well that works. Again, the serial port shows up as a regular file there just may be difficulties in getting it configured for baud rates, etc.
I do plan on porting the Linx layer over for the Rock Pi but that's going to be a while for me. This as least makes it easy for others to get started down this road and even on other devices besides the Rock Pi. I'm also working on some ideas for either updating or replacing Linx with a plugin based system that would make it easier to add supported devices to LabVIEW but my cup already runneth over from and over abundance of projects.
07-01-2020 11:26 AM
@ElioTx wrote:
Is there a LabVIEW Community Edition for Linux/RockPI?
No, I've just got the Raspberry Pi environment running on the RockPi. I'm running Debian on the Rock and as stated have done some work to get the LabVIEW runtime/linx environment from the Pi running on the RockPi's 64 bit OS. As evident from the list of steps to follow this is a manual process as the way Linx is setup it can't even identify the OS or board that I'm running (the Target Configuration wizard is completely useless aside from Pis and BBB, one of the things I'll be working on eventually). The linux runtime environment for Pis and BBB is just a public package feed hosted by MakerHub and can be added as a feed to any system that is capable of running 32bit ARM compiled software.
07-02-2020 02:09 AM
@DerrickB wrote:
Yes so far this is just getting LabVIEW on Linux, not specifically Linx. If you know Linux and have done I/O stuff you'd be able to do some of that stuff through LabVIEW already. Most of the functionality is exposed through "virtual" files (most everything in linux is exposed as a file) and being able to configure and read/write GPIO can be done in this way if you're familiar with this capability. I also don't use the Linx serial VIs, I use VISA directly though I haven't tried that yet on the Rock Pi to see how well that works. Again, the serial port shows up as a regular file there just may be difficulties in getting it configured for baud rates, etc.
Indeed, for the GPIO lines it's actually totally doable to just use LabVIEW file IO as they are exposed using sysfs as a stream interface As such each pin and its direction is simply a file name that you can read from and write to. It's not high performance but pretty decent for many applications, but it doesn't allow to set the IO configuration such as pull up or pull down. However I also found that the sysfs stream interface for GPIO is actually depreciated since kernel 4.8 and is expected to be removed in newer kernels coming out in the near future. One should now use the GPIO character device, which is much more powerful but also requires a more complex access. You can't control this with read() and write() anymore but instead need to use ioctrl() calls, so there is no easy way to use the LabVIEW Read and Write nodes anymore.
All the other interfaces do require some ioctrl() calls anyways and while it would be possible to create a handful or more wrapper VI for the glibc exported ioctrl() call, it's quickly getting a mess to implement and maintain. Also many ioctrl() calls are platform specific anyhow, so such a LabVIEW library would have the potential to grow unwieldy and difficult to maintain very quickly.
I have currently completely modified the Linx CPP sources to use a more plugin like architecture for the actual implementation, Eeach IO is now its own class and the LinxDevice is simply a manager with very little platform specific functionality aside from the initialization. And for the Raspberry Pi I overloaded the Digital IO functions with direct register mapped access to the chip to interface to the GPIO functionality. That shoud be higher performance but potentially can have bad effects as you can basically change the configuration of the GPIO lines behind the back of the OS and in that way disturb other OS drivers that use specific pins for the I2C, SPI and other such functionality. I'm not yet sure that this is going to be a good idea as it really has the potential for a Linx user to mess up things good.
I do plan on porting the Linx layer over for the Rock Pi but that's going to be a while for me. This as least makes it easy for others to get started down this road and even on other devices besides the Rock Pi. I'm also working on some ideas for either updating or replacing Linx with a plugin based system that would make it easier to add supported devices to LabVIEW but my cup already runneth over from and over abundance of projects.
You might want to look at my liblinxdevice implementation some day. It's on github, and currently simply a clone of the main Linx repository and it's currently a mess and just barely compiles. But I do believe to have a useful base to build on by now which also makes it easier to add new platforms and interfaces. I have mainly concentrated on getting the functionality for BeagleBone Black and Raspberry Pi ported as well as putting the remote interfacing for the Listener and Client all into the shared library as well. The LinxWiringDevice, which is the base class for the many Arduino boards is not yet worked on. Once that all works again, it's possible to wire whole networks of Linx devices together all through this interface (which for the most part is still byte compatible with the old Linx wire protocol).
07-02-2020 08:02 AM
@rolfk for sure! I'll definitely take a look over the next week or two, that sounds exactly like what I was looking for and would love to not duplicate your efforts! I could help with mirroring that effort on the LV tooling side. I've been out of the lower level embedded linux game for a while, sounds like I'll have to get up to speed on plans like deprecating the sysfs GPIO interfaces. Moving out of LabVIEW for those interfaces was definitely necessary either way; unless I'm just doing something silly the Flush File function gives errors so I was having to open and close files each time I wanted to change the value.
I'm getting in contact with a product planner at NI to try and find out more about the plan and future for Linx; it would be awesome to see the tools opened up more so that it's easier for people to add in new functionality and devices even if it ends up being an organized community effort. CE / Linx is an awesome start but it pales in comparison to the ecosystems provided by other maker communities and since there's no organized documentation around that I've been able to find it's impossible to get a feel for NI's plans for it.
07-02-2020 08:27 AM
Also, kudos on being the only fork of Linx with commits newer than anything in the makerhub master! (Yes I just checked them all to see if there was anyone else with similar efforts that wasn't way behind the makerhub repo)
12-30-2020 01:25 AM