header files to libraries

[mk92]

Hey Guys,

I'm developing C++-Code for a sbRIO-9607.

Does anyone know where I can find the header files for the shared libraries in /usr/local/natinst/lib/?

Or am I supposed to always open them dynamically?

Thanks for your answers!

Markus

[BradM]

What library do you intend on using there? What's the larger project that you have in mind?

[mk92]

I'm using libNiFpga.so to communicate with the FPGA program. There I got a .h and .c from the FPGA Interface C API when generating the header file for the FPGA-VI. 

Now I want to use the UserLED. The LabVIEW-VI point on the shared library ni_emb.so, so I can open it dynamically and use the function 'LedOutput'. 

But I thought there should be the header files available anywhere so I don't have to always open the library dynamically. 

In future there will be much more complex project where they have to use more than just one library and then it would be a mess...

[BradM]

ni_emb.so is not intended on being linked to directly, it's primary purpose is largely to abstract-away differences in the underlying platforms to present a more unified interface to LabVIEW RT.

You'll need to either dynamically load and resolve the symbols you need or replicate the behavior for your application.

[mk92]

Okay, but even if I want to open the library dynamically I have to know at least the prototypes or something.

So there is no way to get the header files or any documentation anywhere?

How is one suppost to develop for this board using C/C++ then?

[BradM · Accepted solution]

Hi mk92,

The points you bring up are valid. The majority of folks that I've talked with who do C/C++ (or even Python) development on these targets focus on interacting with the FPGA which, as you've found, is pretty reasonable. The other interface to the system that is often-used is the System Configuration API. It is just the case that there's little interest in providing a C/C++ interface to the fairly limited functionality that ni_emb provides (note: that while I say "limited", for historical reasons, there are many symbols in the file, but they often turn right around and call other libraries)

However, neither the LVFPGA CAPI nor System Configuraton provide access to the LEDs. Here, the controller follows the upstream Linux approach and exposes LEDs under the /sys/class/leds sysfs folder, meaning that, unless you need your interaction with LEDs to be cross-platform, you can directly use those pseudofiles.