Missing header files on Linux RT targets

[Krid]

Hi,

we are upgrading our PXI Controllers from Phar Lap ETS to Linux RT and therefore I need to port existing C code to Linux. 

I'm building directly on the target and in general things go well, but I can't find any header files to NI drivers like DAQmx or XNET.

DAQmx and XNET are installed on the target and I can link against the shared libraries. What is the "official" way to install the header files (e.g. NIDAQmx.h) to the Linux RT target? I guess I could just copy them from a Windows machine but that cannot be the intended way (I hope).

I'm using Linux RT System Image 20.5 and the Programming Environment is set to Other (C, C++, etc.).

Thanks!

Dirk

[rtollert]

This is all AFAIK:

Unfortunately, while NI Linux RT (unlike ETS) is capable of self-hosted development, such development (for NI packages) is not generally implemented, because it is still meant first and foremost to be an embedded OS. In other words, you're still expected to cross-compile, except with e.g. VS Code instead of MSVC.

For DAQmx, you might be able to work around this by schlepping a desktop Linux VM together, installing DAQmx, and developing against the drivers on the VM. But I'm not sure if that will help you for XNET.

[captain_only]

To confirm what rtollert said: The NI Linux Real-Time OS is intended to operate as an embedded OS much like Pharlap did. As a result, while we provide "-devel" packages for desktop Linux distributions like Ubuntu, we haven't yet produced them for NI Linux RT.

The intended way to build C applications for these targets is by cross-compiling from your host. For Windows, this document describes a way to do that. You can also do this from  desktop Linux; both DAQmx and XNET would be supported with headers.

This may not be the answer you're looking for, but I hope it still address the question. I'd like to hear more about your use case and whether this addresses it well enough.

Edit: I was referred to this document which explains how to use VSCode for cross-compiling.

[captain_only]

Another option is to install a desktop Linux to the PXI controller itself. Again, I'd like to hear whether that would work for your use case and why you'd pick one OS over the other.

[Krid]

I was not aware that remote development is not officially supported. I did follow the Eclipse based cross compiling tutorial a while ago (and it worked) but I didn't find it very efficient/comfortable to work with (partly because I'm not a big fan of Eclipse).

I like to use a CMake-based approach. For example, I have some code that I need to build for both Windows and Linux. Windows is my regular working environment, so instead of setting up a cross compiling toolchain for Linux, I run Ubuntu under Windows using WSL. 

For our PXI code I wanted to go a similar way. Instead of using WSL I setup a VM running NI Linux RT. The remote development works very well, as long as you don't use any NI-specific stuff because of

• missing header files (I will solve this by just copying NIDAQmx.h to my project directory)
• missing symbolic links to shared libraries (for example there should be a symlink nidaqmx.so pointing to nidaqmx.so.20.1.0)
  This makes CMake fail to find the daqmx library unless you specify the exact version.
• Possibly other things I haven't run into yet...

I haven't used a regular desktop Linux with NI hardware yet. Which distributions are supported? Would it be possible to install DAQmx + XNET under Ubuntu 20.04? That would allow me to build in my WSL environment (not sure about the binary/abi compatiblity to NI Linux RT in this case). Finally the code has to run under Linux RT because we need the hard realtime scheduling.