BioSemi.nl

In the Labview_DLL_SyncTest example there is a source code of LabView_DLL library (LabView_DLL.cpp). Besides the standard and provided in the same example headers (labview_dll.h and bsif.h), LabView_DLL.cpp also depends on a header ioctls.h, which is not included in the example.
Is it possible to get this header ioctls.h and the sources of all other dependencies (e.g., BSIF_GET_STRIDE(), BSIF_GET_SYNC() and BSIF_GET_BYTES_PER_MSEC() routines) needed to build the LabView_DLL from sources?

The BioSemi download package for Windows doesn't contain everything needed to re-build LabView_DLL.dll.
No one has ever wanted to.

Routines BSIF_GET_STRIDE(), BSIF_GET_SYNC() and BSIF_GET_BYTES_PER_MSEC() are all entry points into the
USB ring buffer control routine bsif_winusb.cpp. You would need this routine, in .obj form at least, to re-build.

File "ioctls.h" contains a copyright notice from a third party. I'm not sure it can be legally distributed. It holds
parameters used by the firmware download routines that are included near the end of labview_dll.cpp.
It has nothing that effects ring buffer control.

If you surround the firmware download routines with #ifdef ... #endif to remove them from the compile, then ioctls.h
isn't needed. Notice that when labview_dll.cpp is compiled on Linux or OSX, these routines are effectively disabled.

Under Windows you can avoid them by changing labview_dll.cpp in the following way:

1. Surround the #include with a conditional compile control to remove it from the
compile.

e.g.

#ifdef DOWNLOAD_FIRMWARE // <--- Add this line
#include "ioctls.h"
#endif // DOWNLOAD_FIRMWARE // <-- Add this line

2. Surround the download routines themselves with the same conditional compile
directives. That removes DOWNLOAD_FX2, RESET_FX2, DOWNLOAD_FX2_EEPROM and
DOWNLOAD_FX2_IIC_FIRMWARE from the compile.

e.g.

...

#ifdef DOWNLOAD_FIRMWARE // <--- Add this line
//************************
BOOL LINKAGE DOWNLOAD_FX2(void)
//************************
{
if (useBSIFLib == TRUE)
{
fprintf(stderr, "*** download_fx2 not implemented! ***\n");

...


#endif // DOWNLOAD_FIRMWARE // <--- Add this line
//************************
PCHAR LINKAGE GET_DRIVER_INFO(PCHAR infoBuffer, SIZE_T infoSize)
//************************
{
char stringBuffer[200];

Thank you pmac for such extensive reply!

I afraid, your solution would not work. The constants/defines IOCTL_BUFFER_POINTER (0x00222002?) and IOCTL_USB_WRITE (0x00222006?) are still missing, but they are needed in READ_POINTER() and USB_WRITE() routines. I believe, the IOCTL_* constants are defined in the ioctls.h header. The obj/static-lib built from bsif_winusb.cpp would solve the problem of the missing BSIF_GET_STRIDE(), BSIF_GET_SYNC() and BSIF_GET_BYTES_PER_MSEC() routines.

I can understand, that BioSemi is not interested (and perhaps is not allowed) to reveal the full source code of the LabView_DLL. May be acceptable solution would be in providing static libs of bsif_winusb and reduced version of the iotcls.h, which would not violate any license/copyright.

Nikolay

Hi Nikolay,

Before 2009 BioSemi distributed a Windows kernel-mode driver only. Since 2009 BioSemi has been also
distributing a Windows user-mode driver. Most users now install only this user-mode driver.
The kernel-mode driver actually won't install on many newer versions of Windows, for example all 64 bit
versions.

"labview_dll.cpp" supports both the user-mode and kernel-mode drivers. The constants you tripped on are
used by the kernel-mode driver support in "labview_dll.cpp". If you don't use the kernel-mode driver, I
suggest you comment out the calls to "DeviceIOControl" in READ_POINTER and USB_WRITE. When you do this
in the READ_POINTER routine, the variable "ret", used in the following "return ret", becomes undefined.
Comment out this return line also.

I notice that the software that supports this forum allows attachments. I'll try attaching the 32 bit
and 64 bit versions of bsif_winusb.obj. They have the same name but come from separate directories so
I'll append a 32 and 64 to the names to distinguish them.

As I said, no one has tried this before. I hope this works for you.

Paul

P.S. Trouble: ".obj" attachments are not allowed! They must not support binaries. Also, personal e-mail
through the forum doesn't seem to allow attachments at all. If you send me a real e-mail address through
the forum's private message feature, I could e-mail you the .obj files.