What is the proper method to access exported functions in a DLL compiled for a CE (Arm) target?

[David Goldberg]

I have been trying without success to access functions in a DLL that is targetted for Windows CE.  My Labview application target is an Arm-based TouchPanel device.

[Cory_K]

Try looking through this.

Once you load the dll, you can specify the function name in the dialog window.

[David Goldberg]

I have been trying to use the Call Library Function Node without success.  I am running LabView 2010, SP1 on 32-bit Windows XP, with the TouchPanel module.  When I select my CE-targeted DLL in the call library function node, I receive the error dialog show in the attachment.  The error is "The library selected is not valid for the current platform..."

[Cory_K]

If you are running 32-bit XP, and you are getting that error, then the DLL was probably written for a 64-bit machine.

Where is the DLL coming from? Is it a Windows DLL? A driver? Did you write it?

You should see if there is a way to acquire a 32-bit version.

[David Goldberg]

The DLL is compiled by me as 32-bit Smart Device DLL, using Visual Studio 2008.

[David Goldberg]

Thanks for your patience in trying to help me on this subject.

The following article (http://digital.ni.com/public.nsf/allkb/517300B49212795986256DDD00623FEE) goes a long way in explaining how to access external code from within a TouchPanel application.  However, it seems to indicate only how to access functions within .C files that LabView must be capable of compiling at VI build time.  (It states that the .c file must be included in the Build Specification).  I have followed these steps succesfully using a test Win32 DLL that I prepared.

However, I do not think that this covers my needs.  I believe the above-mentioned article explains how to statically link in external C code (from a C file) at VI build time, but my actual needs are to access the external code from a DLL (self authored) at run-time on the target device (touch panel), which I believe the article does not actually cover.

Am I missing something in the articles explanation?

Thanks,

Dave

[rolfk]

Well, you can't load an ARM DLL into a VI that is loaded on Windows. The ARM DLL has a different object format, that the Windows loader doesn't know and even if it did, the Intel CPU can't interpret the ARM opcodes in that DLL.

In order to be able to load and debug your application on your host system, you need to create a so called stub library. This is a DLL, compiled for the host system, that provides one equally named function for every function in the target DLL, that you want to call. You create such a DLL in Visual Studio, by taking the header file and adding an (empty) function body to each function you want to call, and then compiling this into a DLL.

Of course you won't be able to debug the DLL call itself on the host system, unless you fill in some sensible functionality into the stub function yourself, but you can load the VI hierarchy and debug other aspects of your application.

I haven't played with this specific part of mobile development yet but I believe that you can debug the VI in question from your host system when you start it under the mobile target. But you still need to provide the stub DLL, so that LabVIEW can load the VI into memory. The actual execution happens on the target and the data is transfered back to the host  system through a debug channel to be displayed in that VI, but the stub DLL is required so LabVIEW can load the entire VI hierarchy to allow debugging the VI.

[David Goldberg]

Rolf, thank you very much for your interest in answering my question.

I have performed the steps you describe above in creating a Win32 stub DLL.  I then added a Call Library Function Node to my VI and called a function within the DLL.  However, at VI compile time, I received the error "myFunction is a Missing VI or C File".  They way I resolved this was to include the ".c" file that contained the function within my Build Specification.  LabView was then able to compile completely.  However, this is where my disconnect is...The actual stubbed function has now been absorbed into the compiled application and the application is not trying to access the function in an external DLL file anymore.  I actually need to call the function that exists in the true DLL on the TouchPanel target, much like a standard Windows program will load a DLL at run time.  Again, your help is appreciated.

[PaulRB]

Hi,

You will need to create an import library file (.lib) from your dll in order to call it from the touch panel. Once you have created that, you will have to include the .lib file (not the .dll) in the additional files setting of the build. Finally, you should put the .dll in the '\Windows' directory of the touch panel. This should allow you to call the .dll from your touch panel.

You can take a look at the example Calling External Code - DLL Method.lvproj in Example Finder for more detailed instructions.

Thanks,

[David Goldberg · Accepted solution]

All,  thank you very much for all of your help.  I was still unable to find a method that was not producing an error when compiling...calling for a vi or a C file to be inlcuded.  (ex: [function] is a missing vi or C file).  I also tried including my DLL's import library, as stated above in Paul's email, but I still received the same error.  This has only been an issue for me while testing with non-Win32-based targets...in this case an Arm-based, CE 5.0 TouchPanel device.

However, I did find a workable and fairly straightforward solution:

Instead of attempting to include the DLL import library as a dependent file for the vi, I changed from building a DLL (and associated import lib) to building a static library (.lib) and then included that .lib as the dependent file in the build specification.  This had the affect of linking the object code statically, rather than expecting the vi compiler to compile C source code or to link a DLL import library for a non-Win32 target.  It was then also not necessary to include the additional step of installing the DLL on the target device.  The library I created is just a simple interface to another DLL already on the target device that had trouble interfacing to Labview directly.  Since it is only playing a simple interface role, this static library solution woked well because it was not critical to have its functions available as a separately upgradeable DLL.