LabVIEW
NJPROG DLL Import to wrapper
Solved!
Hello,
I am trying to import Nordic Semiconductor's NRFJPROG DLL libraries to wrappers using LabVIEW import shared library function.
I got the dll and the header files from https://www.nordicsemi.com/Products/Development-tools/nRF-Command-Line-Tools
Issue is the shared library is not able to import all the commands required as you can see in the attached image.
I believe the message on the right is an example of the error and not the actual error.
I also tried the solution suggested in https://forums.ni.com/t5/LabVIEW/C-DLL-with-Import-Wizard-Issues/td-p/3679813 where they ask you to put return type behind the function attributes but it didn't work for me.
Please find the DLL and the header file attached.
Thanks,
Rahul Deka
That header file references following header file
#include "DllCommonDefinitions.h"
Do you have that available?
Did you add the directory where this additional DLL file is contained to the Import Library Wizard step before starting the import?
It also uses <stdint.h> which you also have to provide to it in some ways!
Hi Rolf,
Attached is the whole utility folder.
DllCommonDefinitions.h can be found in the include folder.
<stdint.h> and <stddef.h> is not part of the included header files. I did, however, got them from github and they still didn't work.
https://github.com/openbsd/src/blob/master/sys/sys/stdint.h
https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/stddef.h
I get a different error message when I do include them. See the attached image for reference.
Hope this gives you a better idea of the problem.
Thanks,
Rahul
Well. you can't just copy some stddef.h or stdint.h or other standard C header from the internet to your machine and hope to be done with it!!!
Those headers are specific to an OS and have many other, and often very OS specific dependencies. Yours were downloaded from some Open BSD and GCC sources and mixing and matching headers from different sources is simply a recipe for chaos!!!!! Also they are neither for a Windows system and even need to be specific for the OS version you are running on!!!
If you want to have a valid header selection for your OS you need to download the ENTIRE headers for that OS to your system. Under Windows the most "easy" solution for that is to download and install the Windows SDK. Easy in quotes since it is a huge download and you need to watch out what version you download. Another option is to install a Visual Studio version, either a commercial one or the free Visual Studio Code version. These come with at least a minimal set of headers for your Windows system and the more extended ones come with the full SDK for Windows.
All that said, you can most likely get away with not caring about these standard headers and simply provide the necessary defines yourself in the Import Library Wizard one by one.
The basic ones are very simple:
int8_t=signed char
uint8_t=unsigned char
int16_t=signed short
uint16_t=unsigned short
int32_t =signed int
uint32_t= unsigned int
uChar_t=unsigned char
Apologies for my ignorance. I haven't coded with C and C++ for almost a 6 years now so my knowledge on C and C++ headers and libraries is limited.
But your suggestion worked. I added those defines manually and that did help.
Only a few DLL wrappers left
I only need the open_dll wrappers and I think I am set.
Can you suggest definitions to fix that?
Also, how did you come up with the definitions? Or are they just a list of most common definations?
Thanks,
Rahul
@RahulDeka01 wrote:
Only a few DLL wrappers left
There are some callback definitions. You can NOT make callback definitions with the Call Library Node, so those functions with callback parameters you can only call when the function allows to set that parameter as a NULL value.
Well, technically you can create callback pointers in LabVIEW but it is so complicated and results in a true maintenance nightmare. If you have the knowledge to do that, you are much simpler off by creating a wrapper DLL in C++ that translates the callback into a LabVIEW user event or similar instead. If creating a wrapper DLL to implement a callback function sounds to you like a herculean task, then don't even start to think about trying to do it all natively in LabVIEW. It's even more complicated.
I only need the open_dll wrappers and I think I am set.
Can you suggest definitions to fix that?
Well it is unclear if you can pass NULL to that msg_callback pointer. If that is an option you can edit the header file for now to define this to be an uintptr_t pointer variable instead (adding a definition for uintptr_t=void*, then after the Import Library Wizard is done, making sure that the Call Library Node is configured for this parameter to be a Numeric, Pointer Sized Unsigned Integer passed by value. Then pass a 0 constant to it. But if the function does not allow to pass in a NULL pointer value and simply crashes sooner or later as it tries to reference that invalid value, then you have bad luck and your adventure of using the Import Library Wizard stop here. That would be the point where you have to start digging up your C++ compiler from about 6 years ago and start programming C(++).
Also, how did you come up with the definitions? Or are they just a list of most common definitions?
When I'm not programming in LabVIEW, I'm programming in C code to be used in LabVIEW. That helps a lot and those C99 datatypes defines are by now quite common, but they are in addition to the original C definition and not usually built in defines but even in the most recent compiler versions solved by standardized header files. It would probably be safe to add them as (overwriteable) defines to the Import Library Wizard itself but that component hasn't seen any love for many years and likely won't be looked at again by NI.
It's usefulness is very limited. Importing C APIs is simply not something that can be fully automated. The C syntax is not complete enough to describe all the intricacies of calling functions, and lacks absolutely any way of specifying memory management constraints. This means that even if the Import Library Wizard imports all functions without error, you can and should not assume that the resulting code is correct. In the best case it is inefficient but quite often it is simply wrong in a way that will at some point crash. So you have to go through each and every function and verify by hand that what the Import Library Wizard created is in fact doing the right thing! There is NO way around that! If you can't do that, using the Import Library Wizard is actually creating an additional problem, not solving one!
Command line access of such programming tools is THE standard way of interfacing to them. On Unix system it is actually still the dominant way to do things. On Windows there are two potential drawbacks to going that route.
- If it is a Microsoft command line program, they like to translate the standard IO text and sometimes even the commands itself according to the currently installed Windows locale. Quite a mess!
- Creating a process on Windows is relatively expensive. So if you want to do a lot of calls to a command line tool in a tight loop, this seriously can impact the execution speed. For once in a time (and I'm talking less than once every few seconds) calls, that can be however fully ignored as it will not dominate the execution time of your program significantly.
