Hi,
I would like to start using VM8090 boards for our company and would need to get them to work with our native C++ application. Can anyone tell me if this is posiible please and if so if there is a sample application available?
Thank you!
Patrick
What do you have so far?
You mention you have an application already, does it have any classes for serial communications?
Hi,
I already access various circuit boards that are linked to our application: I have a FTDI interface and a Win32 interface that is also use for communication with an FTDI chip.
My company uses native C++. I have read ( support.microsoft.com/kb/828736 ) that in order for me to gain access to your managed VB .dll, then if I understand correctly, you would need to export a .tlb file to provide a COM way for native C++ to interact with your board. If any of the above information is incorrect then please forgive me. I am very eager to get a solution to this, if I can do so then we intend to package one of your circuit boards with each of our products.
Thanks,
Patrick
The board uses simple serial communication (RS232), in the Windows API this can be achieved with the standard file IO functions CreateFile, ReadFile and WriteFile. The native DLL that is provided with the board is written in C. I would absolutely not recommend using the .NET DLL in C++.
Hi,
if a native C .dll is available then that would be great news! Can you tell me where I can find it please? On receiving the circuit board, I went to :
velleman.eu/support/download … 8090&type=
and downloaded “Complete software package, Build 100820”
Once downloaded and extracted, the following files are installed:
C:\Program Files\Velleman>tree /f
Folder PATH listing for volume OS
Volume serial number is 00000200 E061:9670
C:.
±–K8090
¦ unins000.dat
¦ unins000.exe
¦
±–Demo
¦ K8090.exe
¦
±–Drivers
¦ K8090.cat
¦ K8090.inf
¦
±–Help
¦ K8090D_DLL.pdf
¦ K8090_GettingStarted.pdf
¦ K8090_ProtocolManual.pdf
¦
±–Kits.NET
¦ Velleman.Kits.dll
¦
±–Samples
¦ ¦ K8090_VisualBasic.pdf
¦ ¦
¦ ±–Visual Basic 2008 Express Edition
¦ ¦ Velleman.Kits.dll
¦ ¦
¦ ±–Sample01
¦ ¦ ¦ MainForm.Designer.vb
¦ ¦ ¦ MainForm.resx
¦ ¦ ¦ MainForm.vb
¦ ¦ ¦ Sample01.sln
¦ ¦ ¦ Sample01.vbproj
¦ ¦ ¦
¦ ¦ ±–bin
¦ ¦ ¦ ±–Debug
¦ ¦ ¦ Sample01.vshost.exe
¦ ¦ ¦ Sample01.vshost.exe.manifest
¦ ¦ ¦
¦ ¦ ±–My Project
¦ ¦ Application.Designer.vb
¦ ¦ Application.myapp
¦ ¦ AssemblyInfo.vb
¦ ¦ Resources.Designer.vb
¦ ¦ Resources.resx
¦ ¦ Settings.Designer.vb
¦ ¦ Settings.settings
¦ ¦
¦ ±–Sample02
¦ ¦ MainForm.Designer.vb
¦ ¦ MainForm.resx
¦ ¦ MainForm.vb
¦ ¦ Sample02.sln
¦ ¦ Sample02.vbproj
¦ ¦
¦ ±–My Project
¦ Application.Designer.vb
¦ Application.myapp
¦ AssemblyInfo.vb
¦ Resources.Designer.vb
¦ Resources.resx
¦ Settings.Designer.vb
¦ Settings.settings
¦
±–Tools
K8090C.exe
“K8090D_DLL.pdf” reads as if this might be the .dll that I would need to interact with from C++, however there is no such .dll in the installer. All that I have instead is:
“Kits.NET -> Velleman.Kits.dll”
“Samples -> Visual Basic 2008 Express Edition -> Velleman.Kits.dll”
Although these are binary files, I compared them using WinMerge and found them to be practically the same file. I also tried to view what functions were available to be called inside these functions using Dependency Walker ( dependencywalker.com ) and failed to find any functions exposed for native C++ to call. Are these then both managed .dll files?
The methods listed in “K8090D_DLL.pdf” are completely different from all the functionality that appears to be available in “K8090_VisualBasic.pdf” eg there are methods named Connect(), ToggleRelay(), Disconnect() that are not mentioned elsewhere. Is there a full SDK available of all functions that can be called by C++ and some sample code?
If there is a native C .dll, as you have said, perhaps it is not part of this installer? Or perhaps as I said before, do I need a .tlb file from you to interact with your managed .dll? Please advise how I can continue, I have a very short deadline on this and unfortunately may need to look into alternative circuit boards soon if it turns out that this board cannot be interacted with via C++. If we can resolve this soon then I will be very happy to ship one of your products with each of our products.
Thanks,
Patrick
I believe it is installed to the %windir%\system32 folder under the filename K8090D.dll
The C source code for Visual Studio can be found here:
K8090D Project (zip)
You might have to adjust it to suit your needs, it’s pretty basic/simple…
Hi,
thank you for your help. Ok I have now found “C:\Windows\SysWOW64\K8090D.dll” and looking at it in Dependency Walker it looks like there are functions exposed here that native code can call, though these functions seem to be completely different to the ones available in the VB .dll. Is there any reason for this? Does native code not have access to the same functionality?
I also tried to access the link to the C source code that you sent ( velleman.eu/images/tmp/K8090D.dll ) but it apepars to be dead. Can you repost this please?
Thanks,
Patrick
Oh I’m sorry I mistyped the link, it’s actually a zip archive with the source code to create the native dll. The link has been corrected, it should work now 
The VB.NET dll is an Assembly (.NET library), it cannot be compared to a native dll in any way.
The link works again thank you, I got and extracted the .dll inside it and it is binary identical to the .dll found in “C:\Windows\SysWOW64”.
You said previously that there is a “C source code for Visual Studio” demo available, can you tell me where this is please?
Hi,
thank you for the Visual Studio .dll solution. I have been looking through it and am currently doing some testing prior to adding this to our codebase.
I have noticed that the source code for the .dll uses the __cdecl calling convention instead of __stdcall, which was what the “K8090D_DLL.pdf” claimed.
Also different from the .pdf is that this source code uses HK8090 instead of HANDLE:
HK8090 WINAPI OpenDevice( IN LPCSTR szPort );
HANDLE WINAPI OpenDevice( __in LPCSTR szPort );
#defines look different:
COMMAND_SWITCH_RELAY_ON
CMD_SWITCH_RELAY_ON
this #define does not exist:
#define CMD_FIRMWARE_VERSION 0x71
Should I expect the source code to look exactly like the functions as documented in the .pdf? I do not want to code this now only for a future Velleman .dll to cause me to need to recode the logic somehow. Is there more recent source code that I should be using?
Thanks,
Patrick
Regarding the calling convention, I try to follow best practice, which is why I use the WINAPI macro defined in <windef.h>. The DLL provided was built with WINAPI resolved to __stdcall.
Looking at the actual source code in my SDK it has more conditions, but it should still resolve to __stdcall.
HK8090 is an alias for a windows HANDLE. This is done for clarity or maintainability in case the data type should change.
#define HK8090 HANDLESource code is normally not downloadable, so there is no need to compare the defines in the DLL and the documentation. Developers only need to know the function prototypes and which command has which value, which is what they find in the DLL’s documentation.
Hi,
thank you for all your previous help. I now have the circuit board added to our software and will begin releasing it very soon.
I would like to know something about 32/64-bit support please. Our native C++ application is 32-bit and appears to be working well with your circuit board. In this coming year we hope to move our application to become 64-bit. Will K8090D.dll still work for us or would you need to provide a different .dll? How might this work?
Thanks,
Patrick
A 64-bit Windows application can not load a 32-bit DLL. But since you have the source code, you can recompile the DLL for 64-bit. This should all be a piece of cake for a C++ developer 
Hi,
well it would be something that I could compile but I used your supplied 32-bit .dll instead as it was proven to work. As mentioned previously, I had noticed that the source code for the .dll differed from the .dll and sdk you supplied in that:
- __cdecl calling convention instead of __stdcall
- uses HK8090 instead of HANDLE
-
#define CMD_FIRMWARE_VERSION 0x71 does not exist
Since there may have been further differences that I was not aware of, I was instructed to use the officially supplied 32-bit .dll. Similarly, my boss and I would like to get the official 64-bit .dll that is tested and approved by Velleman. Since the need for 64-bit compatability will continue to be requested by all users over time, can you provide this please?
Thanks,
Patrick
You could also use the k8090.h and k8090.c without compiling it into a DLL. Both the source code and protocol are very very simple. We can’t provide a 64-bit version of the compiled DLL.
I’m sorry, I don’t understand. Why can you not provide a 64-bit .dll?
I’m sorry, I don’t understand.
Why can you not add the provided source code to your project and compile it with your native compiler?
Hi MostlyHarmless,
given that I have noticed that:
- __cdecl calling convention instead of __stdcall
- uses HK8090 instead of HANDLE
-
#define CMD_FIRMWARE_VERSION 0x71 does not exist
and any number of unknown other subtle differences may exist for all I know, then the source code that I was supplied earlier in this thread does not exactly match the 32-bit binary that is shipped by Velleman. If there is an official 64-bit tested .dll from them then there is no concern on my part that I may be passing code onto customers that is not in accordance with Velleman. I would also be concerned that such code may become bust in the future by further modifications they may make to the source code without my ever being aware of it.
pocruadhlaoich,
and I am exactly the other way around. I would be concerned passing along binary DLLs to my customer that I have no chance of knowing what they do and where I had to rely on another vendor to fix bugs, should they turn up.