is it possible to place shared library on the SD card?

[leo_v]

Hi, i'm using an sbrio 9637 to perform real time simulation. The one thing i'm trying to achieve is to be able to run different simulation configurations based on some large lookup tables generated in matlab. So my idea is to store data of the previously generated lookup table in an .so file and place it onto the SD card (offline, using let's say a windows system fat32). Then use the call library function node to get the interpolated data during initialization and run time. 

is this possible? i looked at the workflow of using .so from the call library function node, it only mentions how to place it under the \home\ directories, which i assume is on the onboard flash. 

otherwise, is it possible to access the SD card from C/C++ eclipse project? there are a few tutorials on how to do socket programming in the eclipse but not much mentioning of other on board resources, like the SD card or CAN/SPI/RS232, etc. 

appreciate if there are examples how to access these resources from the C/C++ env. either from .so or from executables. 

thx

gz

[Taggart]

I'm no linux expert, but it seems like a hardlink might work.

[GatorChomp · Accepted solution]

Hi leo_v,

Any particular reason you want to use an *.so file for a lookup table instead of using a file that can be read in LabVIEW using normal File I/O? E.g., a binary format or a *.csv? It seems to me that option would be more portable and less work than building a custom *.so for Linux Real-Time.

If the SD Card is the only removable storage on the sbRIO, it should be automatically mapped to "/u/" each time. See Writing to a USB Drive or SD from NI Real-time Device and Working with File Paths on Real-Time Targets, noting the Linux Real-Time sections. These file paths should apply to both LabVIEW and any C/C++ executable on a Linux RT system.

For LabVIEW: The Call Library Function Node can be given a full path once the file is accessible on the Real-Time system. Even if you placed it in one of the /home/ directories instead of in /u/, you would still be doing this unless that directory was on the LabVIEW search path (e.g., /usr/lib/). 

Regarding the C/C++ project, that's a bit trickier. You have two options I'd suggest:

1. Dynamically link the *.so using the compiler on the actual target. This saves any problems with resolving dependencies and the sysroot but does require knowledge of working with C compilers on embedded systems. You'd need:
   1. The *.so be in place on the system.
   2. The *.so be included in the include path for the compilation.
2. Dynamically link the *.so using the cross compile toolchain in Eclipse. This requires:
   1. The *.so be in the same location in both the sysroot used by Eclipse and on the deployed file system. This requires modifying the sysroot that ships with the cross compile toolchain. 
   2. The *.so be included for the Eclipse project/compilation search paths/includes.

In my opinion, using the Call Library Function Node is the "easier" option if you don't have experience with C/C++ cross compiling but there's no better time to start learning than the present.

[leo_v]

Charlie, Taggart

thanks for the prompt reply. I will give it a shot with the /u/ path then. 

Charlie, the reason to use the .so is for some already existing C routines to do interpolations beside the lookup table data. I agree that csv is easier to manipulate as data but i have some program code that i would need to reuse/generate externally as well. 

cheers

regards

gz

[leo_v]

glad to report back it works with /u/libname.*

thanks