Probleme bei Portierung von Labview-Sensortreiber (DLL) nach C



  • Hallo zusammen,

    folgendes Problem: Ich habe einen Bluetooth-Sensor zu dem ein Labviewtreiber mitgeliefert wurde (inkl. DLL, aber ohne Header). Ich würde den Sensor gerne in Matlab nutzen. Da das aber bisher nicht funktioniert und ich in Matlab nicht wirkich hinter die Kulissen schauen kann, hatte ich mir überlegt, die Kommunikation erstmal in C/C++ zu programmieren, um das besser nachvollziehen zu können. Außer Grundlagen (vor einigen Jahren) habe ich aber mit C/C++ nichts mehr gemacht; das nur als Info zum fachlichen Hintergrund.

    Über den Labviewtreiber habe ich nun den Ablauf der Kommunikation "reverse engineered" (welche Funktion muss wann wie aufgerufen werden) und einen eigenen Header zusammengefrickelt (entsprechend den Funtionsprototypen in Labview). Normalerweise müsste man das ja jetzt 1 zu 1 auf C/C++ umsetzen können, denn der DLL ist es egal, von welchem Programm aus ihre Funktionen aufgerufen wird, solange das mit der Schnittstelle passt (würde ich mal meinen).

    Nun zu meinem Problem: Nachdem ich nach Sensoren gescannt habe und versuche mich auf den Sensor zu verbinden, klappt es manchmal oder manchmal wird auch ein Fehler geworfen. In dem Fall, indem es klappt, gibt die Funktion auch ordnungsgemäß 0 zurück, aber der nächste Befehl im Code (einfache printf) wirft dann einen Fehler. Die Fehler sehen in der Art aus:

    "Ausnahme ausgelöst bei 0x001EF594 in bt_test.exe: 0xC0000005: Zugriffsverletzung beim Ausführen an Position 0x001EF594."

    Ich vermute mal, dass da unzulässig auf einen Speicherbereich zugegriffen werden soll. Gibt es da ein prinzipielles Vorgehen, wie man bei solchen Problemen vorzugehen hat?

    Ich habe den Teil des Codes, bei dem der Fehler auftritt, mal hier noch angehängt. Ich weiß nicht, ob ihr mit den Infos was anfangen könnt, ich liefere gerne aber alles nach, was noch benötigt würde. Ich wollte nur niemanden mit unnötigem Ballast zuschütten, da mir die Erfahrung fehlt, was ihr da benötigen würdet.

    Arbeite mit Visual Studio Express 2019, falls es von Belang ist.

    			while (NumDevices < 1)	// nach Devices scannen
    			{
    				hDev = (*pD2PIO_OpenDeviceListSnapshot) (hInit, deviceType, commTransportId, &NumDevices, &DeviceListSignature);
    				Sleep(50);			// 50 ms warten
    			}
    
    			// ersten Sensor auswählen (N = 0)
    			ret_value = (*pD2PIO_DeviceListSnapshot_GetNthEntry) (hDev, N, pDevnameBuf, DevnameBufsize, pDevFriendlyNameBuf, DevFriendlyNameBufsize, &pRSSI_level);
    
    
    			while (hGDX_FOR == NULL) // auf Sensor verbinden
    			{
    				hGDX_FOR = (*pD2PIO_Device_Open) (hInit, pDevnameBuf, &parmsPtr, parmsLen, timeoutMs, &notificationCallbackFunc, &pContextInfo);
    				Sleep(500);
    			}
    
    
    			while(pDeviceOpenStatus != 4)	// Status zyklisch abfragen, bei 4: Verbindung erfollgreich aufgebaut
    			{
    					ret_value = (*pD2PIO_Device_GetOpenStatus) (hGDX_FOR, &pDeviceOpenStatus);
    					//Sleep(50);
    					//printf("%d\n", pDeviceOpenStatus);
    			}
    
    			printf("Hello World!\n");	// hier wird dann ein Fehler geworfen, teilweise auch schon während obiger while-Schleife
    
    

    Die einzelnen Funktionspointer pD2PIO_OpenDeviceListSnapshot, pD2PIO_DeviceListSnapshot_GetNthEntry etc. rufen die jeweiligen Funktionen aus der DLL auf.



  • Zeige mal die Funktionsprototypen - evtl. sind doch einige Typen der Parameter falsch?
    Ist es denn ein 32 oder 64bit Projekt (ich tippe zwar auf 32bit wegen "0x001EF594", aber besser nachfragen)?

    Und warum rufst du die Funktionen per Zeiger auf und nicht direkt?



  • Ich hab den Fehler zwischenzeitlich gefunden, es war in der Tat ein Fehler beim Prototyp einer vorangegangenen Funktion. Korrekt, ist 32 bit. Den Aufruf per Zeiger habe ich aus irgendeinem Wiki-Beispiel zum Aufruf von DLL-Funktionen. Für den Moment ist mein Problem gelöst, jetzt knoble ich über dem nächsten - so geht es schon seit Tagen. Aber danke für die Hilfe und evtl. muss ich mich später nochmal melden.


Log in to reply