NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploying C/C++ Application on cRio 9068

Hi All

Anyone got any links for a newbie on how to deploy a C/C++ application on the cRio 9068 so it starts when system starts?

I have the development environment sorted out with Eclipse etc. and have an executable on the cRio; just stuck on which files to transfer where to cRio and how to get the application to automatically start when cRio restarts.

Sure this is pretty simple but most of what I can find on google doesn't deal with real time OS.

Thanks for the help

0 Kudos
Message 1 of 9
(6,320 Views)

jamie_mac, this is precisely part of the presentation that I'm putting together for NIWeek, so it is very, very fresh in my mind!

Basically, anything that is listed as an additional dependency in the Eclipse project needs to be made available on the target. In the case that you have a dependency that you simply downloaded and made it available to the Eclipse project, there's a good chance that you can install the library on your target via opkg.

If the library is not in the feed repository (e.g. you are using a library that you created in Eclipse) you will simply need to also copy that library over to the target and ensure that it is in one of the searched library directories (for user-installed libraries, the old convention is to use /usr/local/lib/, but pragmatically I recommend /usr/lib/) and run ldconfig to have the OS rebuild it's library loading cache.

Check to make sure that you can run the binary directly from a shell. If there are issues, the errors will likely give you some breadcrumbs to follow.

Once you are able to launch the binary from a shell, it is time to write a reasonable sysvinit script. While NI Linux RT is a real-time OS, at heart it is still a traditional Linux distribution. Any of the sysvinit-style how-to's will work for you. Let us know if you run into issues

Message 2 of 9
(4,455 Views)

Hi Jamie,

There are probably several ways to do so. Then it will also be different if you are dealing with a RT application or if it is a "standard" one that is (as a matter of fact) embedded in the RT target...

On my side, what I am using so far depends on what I want to deploy :

A- if it is a standalone application  without direct connection to a labview application

B- if it is a text based application compiled with gcc that you would like to use within labview

Of course NI guys would probably have better/enhanced ways to do it...

Short answer (that means probably more google search, but it should provide a starting point) :

For A, if you really want autoboot I would suggest that you use the traditional rc scripts and manage your application as a daemon:

-> cross compile your application using eclipse etc

-> upload it in /usr/local/bin (already in $PATH) with scp

-> create a rc rcscript in /etc/script.d refering to your application and create a symbolic link in the appropriate /etc/rcX.d

I haven't try so far to develop something in that way which could have an influence on the rt scheduler at the end but works as expected for the standard use

For B:

You can use an easy (but perhaps stinky) way which is a system exec node from labview to point to your external application

A more appropiate way to my mind would be to convert your application in a shared lib and to use it as a new labview block

-> cross compile your application as a shared library instead of a standalone dev

-> upload it in /usr/local/lib with scp then a traditional ldconfig on it

-> use the call library function node in your labview application

... but you should take into account the determinism of it if your application is RT related and/or if you launched additional threads from it.

Hope it helps!

Message 3 of 9
(4,455 Views)

BradM a écrit:

for user-installed libraries, the old convention is to use /usr/local/lib/, but pragmatically I recommend /usr/lib/

Thanks BradM, now I really feel like an old man 😉

0 Kudos
Message 4 of 9
(4,455 Views)

The primary reason for my recommendation is due to the fact that LabVIEW won't find libraries tucked into /usr/local/lib unless the soname is unversioned (e.g. libfoo.so instead of libfoo.so.1) and ldconfig is configured to examine /usr/local/lib.

0 Kudos
Message 5 of 9
(4,455 Views)

BradM a écrit:

The primary reason for my recommendation is due to the fact that LabVIEW won't find libraries tucked into /usr/local/lib unless the soname is unversioned (e.g. libfoo.so instead of libfoo.so.1) and ldconfig is configured to examine /usr/local/lib.

You are probably right but as I am really an old man, I always start by looking if /etc/ld.so.conf contains what is requested 😉 Then ldconfig do itself the magic trick of libs unversioning...

Nevertheless, everything is doable ... just a question of habits at the end!

0 Kudos
Message 6 of 9
(4,455 Views)