Official bladeRF forum

Hi All,

BladeRF runs well in Linrad now although the performance for HF on the J61 connector is far below what one would expect. I wonder if the strong digital feedback is a layout problem on the PCB or if it is inside the chip. This video shows details:
https://www.youtube.com/watch?v=A0uTrP9OCo8

Linrad currently loads dll files on program start. This is inconvenient and requires all users to install the dll files for all hardware. For that reason I want to load the dll for a specific hardware only when a user has selected it. Then an appropriate message can be given if something is missing. A bladeRF user has normally run the Windows installer so everything needed would be in place automatically.

There is a problem however. The file bladeRF.dll that works well when loaded at load-time does not work when loaded at run-time. I have made two test programs that illustrate the problem. The first one loads the dll at load-time (bladeRF is specified in the linker command) It works fine. The second file loads the library at run time and it fails. It does return 1 or 2 depending on whether I connect one or two bladeRF units, but the pointer "devices" is incorrect. The pointer value can be 3 or 4 which is clearly illegal. I have the source code so I know this should be impossible. I can however not generate a Windows dll from the source code so I can not insert debug statements.

The corresponding code works fine with PCIe-9842 and it works fine with bladeRF under Linux also. The only problem so far is the Windows dll for bladeRF. Do I have to load it in some other way or is there a system call I need to initiate something? I am using mingw32. I have tried 32/64 versions of XP and Win 7 and they all show the same error.

The bladeRF installer does not work properly under XP. It complains about missing entry points in msvcrt.dll and it crasches if I allow it to upgrade the
firmware. I think an installer for a program using Microsoft Visual C should supply the appropriate dll.

73

Leif / SM5BSZ

----------------- Working code. Link with bladeRF.dll----------------------
#include <windows.h>
#include <stdio.h>

#define uint8_t unsigned short int

typedef enum {
BLADERF_BACKEND_ANY, /**< "Don't Care" -- use any available backend */
BLADERF_BACKEND_LINUX, /**< Linux kernel driver */
BLADERF_BACKEND_LIBUSB /**< libusb */
} bladerf_backend;

#define BLADERF_SERIAL_LENGTH 33

struct bladerf_devinfo {
bladerf_backend backend; /**< Backend to use when connecting to device */
char serial[BLADERF_SERIAL_LENGTH]; /**< Device serial number string */
uint8_t usb_bus; /**< Bus # device is attached to */
uint8_t usb_addr; /**< Device address on bus */
unsigned int instance; /**< Device instance or ID */
};

int bladerf_get_device_list(struct bladerf_devinfo **devices);

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
int n_devices;
struct bladerf_devinfo *devices = NULL;
(void) hInstance;
(void) hPrevInstance;
(void) szCmdLine;
(void) iCmdShow;
printf("START");
n_devices = bladerf_get_device_list(&devices);
printf("\nn_devices %d",n_devices);
printf("\n[%d]",(int)&devices[0].serial);
printf("\n%s",devices[0].serial);
getchar();
return 0;
}
------------------------------ End of working code ---------------------------------

------------------------- Non-working code. Link without bladeRF.dll----------------------
#include <windows.h>
#include <stdio.h>

#define uint8_t unsigned short int

typedef enum {
BLADERF_BACKEND_ANY, /**< "Don't Care" -- use any available backend */
BLADERF_BACKEND_LINUX, /**< Linux kernel driver */
BLADERF_BACKEND_LIBUSB /**< libusb */
} bladerf_backend;

#define BLADERF_SERIAL_LENGTH 33

struct bladerf_devinfo {
bladerf_backend backend; /**< Backend to use when connecting to device */
char serial[BLADERF_SERIAL_LENGTH]; /**< Device serial number string */
uint8_t usb_bus; /**< Bus # device is attached to */
uint8_t usb_addr; /**< Device address on bus */
unsigned int instance; /**< Device instance or ID */
};

HANDLE bladerf_libhandle;
typedef int (WINAPI *p_bladerf_get_device_list)(struct bladerf_devinfo **devices);
p_bladerf_get_device_list bladerf_get_device_list;

void load_bladerf_library(void)
{
bladerf_libhandle=LoadLibrary("bladeRF.dll");
if(bladerf_libhandle == NULL)goto load_error1;
bladerf_get_device_list=(p_bladerf_get_device_list)
GetProcAddress(bladerf_libhandle, "bladerf_get_device_list");
if(!bladerf_get_device_list)goto load_error;
return;
load_error:;
FreeLibrary(bladerf_libhandle);
load_error1:;
printf("library load error");
exit(0);
}

void unload_bladerf_library(void)
{
FreeLibrary(bladerf_libhandle);
}

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
int n_devices;
struct bladerf_devinfo *devices = NULL;
(void) hInstance;
(void) hPrevInstance;
(void) szCmdLine;
(void) iCmdShow;
printf("START");
load_bladerf_library();
n_devices = bladerf_get_device_list(&devices);
printf("\nn_devices %d",n_devices);
printf("\n[%d]",(int)&devices[0].serial);
printf("\n%s",devices[0].serial);
getchar();
unload_bladerf_library();
return 0;
}
----------------------------- End of non-working code ----------------------

It looks like it might be due to the calling convention in Windows.

I am not an expert, but it looks like you're using WINAPI for your calling convention, and not doing a #include "bladeRF.h" where we explicitly declare the calling convention used with the library. My guess is that this is the problem.

Googling for WINAPI vs cdecl might be useful, but I think if you forward declare the functions in the library using the appropriate calling convention (aka: #include "bladeRF.h") then the compiler should be smarter about it?

This page goes into a lot of detail about Windows calling conventions.

Good luck and let us know how it goes.

Brian

Brian,

I believe you're onto something there...not that I know much about Windows development either...

WINAPI is a macro for __stdcall. The bladeRF CALL_CONV macro is defined as __cdecl, which is the default calling convention for MSVC.

Mixing these up would certainly cause strange behavior.


As far as the Visual Studio redistributables go...those should definitely be shipped with the installer, and clearly they're not. I believe Rob was using Visual Studio 2010 for that? (Googling the DLL in the error should tell you which one you need.) If I'm correct, a workaround would be to manually install them Windows 7, 8, etc should all have the 2010 redistributables by default. Not sure what the official stance is for bladeRF support on XP though (does it even support USB3 reasonably well, if at all?), considering that MS has put the 10 year old OS on the kill list.

Hello Brian,

Yes, all is clear now. I specified WINAPI for the load at run-time beleaving I did for load at load-time. Now, that was a mistake, as you can see in the code
snippets I did not specify WINAPI for load-time so I should of course not do it for run time. I just needed to remove "WINAPI". Now all is OK:-)

73

Leif