iow56 unter c++ Eingänge lesen (nur zufallswerte??)

[st0ne]

naja, irgendwie muss ich doch die funktionen der dll verfügbar machen in meinem programm... geht das leicht anders auch noch? oder hab ich das was nicht mitbekommen? ;-)

[Christoph Jung]

Man kann die iowkit.lib aufrufen und hat damit austomatisch die DLL-Funktionen parat.
Einfach:

#pragma comment(lib,"iowkit.lib")

nach den Header-Inludes aufrufen und schon sollten die Funktionen beiteistehen.
Das gleicher Ergebnis bekommt man, wenn man in den Projekteigenschaften unter Linker die iowkit.lib einträgt.

[st0ne]

bringt das irgendwelche vorteile? bzw. bringt meine version irgendwelche nachteile?

das ganze jetzt umzustellen ist schon etwas aufwand, da ich das ganze ja in eine klasse bzw. einen namespace gekapselt habe...

[Christoph Jung]

Vorteile sind nur, dass man sich keine eigene Klasse zusammenbauen muss.
Ich weiß aber nicht, ob nicht ein Zusammenhang besteht, wenn man die Funktionen selber importiert. Eine falsche Dekleration und schon kanns in die Hose gehen.

Das hilft aber beim aktuellen Problem nicht weiter.
Schonmal versucht die schleife mit weniger als 128 laufen zu lassen?

[st0ne]

ich habe nochwas rausgefunden...

bevor der absturz bei iowkitreadnonblocking passiert, wird der SPI bus initialisiert...

Code: Select all

		// Init SPI-Bus
		IOWKIT56_SPECIAL_REPORT rep56spec;
		memset(&rep56spec, 0x00, IOWKIT56_SPECIAL_REPORT_SIZE);
		rep56spec.ReportID = 0x08;
		rep56spec.Bytes[0] = 0x01; // Enable the SPI Bus
		rep56spec.Bytes[1] = 0x00; // Drive data on first edge
		rep56spec.Bytes[2] = 0xFF; // Divide Clock 24Mhz by 256 (N+1)
		int res;
		res = IOW::IowKitWrite(this->iowHandle, 1, (char*)&rep56spec, IOWKIT56_SPECIAL_REPORT_SIZE);

interessanterweise stürtzt iowkitreadnonblocking nur ab, wenn das iowkitwrite wohl schief gegangen ist... habe hier res=0 !

habe zuvor den rückgabewert nicht abgeprüft, deswegen habe ich nicht gemerkt dass beim schreiben was schief gegangen ist... der spi bus funktioniert allerdings seltsamerweise...

wenn res = 0 ist, und darauffolgend ein iowkitreadnonblocking folgt, dann stürzt das programm mit einer accessviolation ab...
bin irgendwie ratlos, vorallem warum das schreiben schief geht

[st0ne]

Schonmal versucht die schleife mit weniger als 128 laufen zu lassen?

nein, allerdings tritt der fehler schon beim ersten mal auf, danach halt noch 127x ;-)

[Christoph Jung]

Ok...
Wenn es beim ersten mal schon passiert, dann ist entweder der Import der Funktion falsch (falsche Variable wird angefordert/übergeben) oder das Handle ist ungültig. Was anderes fällt mir jetzt nicht mehr ein. Frage ist nur, wenn die selbe Funktion in einem anderen Fall funktioniert, dann fehlt auf jedenfall irgend etwas.

[st0ne]

hm, ja ich muss mir das morgen nochmal genauer anschauen, aber wie gesagt, der fehler tritt nur auf wenn die initialisierung des spi, also das iowkitwrite, anscheinend schief gegangen ist...
und das funktioniert normal immer wenn ich es aus anderen funktionen aufrufe... sehr seltsam das ganze...

[st0ne]

es ist seltsam, ich habe jetzt mal eine schleife in der funktion eingebaut die den spi-bus aktiviert, die solange läuft bis das iowkitwrite erfolgreich war, also der rückgabewert nicht 0 ist...

wenn ich die funktion aus einer anderen stelle im programm aufrufe funktioniert es einwandfrei... sobald ich es aus der serientestfunktion aufrufe, ist iowkitwrite immer 0...

[Christoph Jung]

Wenn es an einer Stelle geht und an einer anderen nicht, dann wird irgendwas nicht gesetzt oder falsch initialisiert.

[st0ne]

ich habe den fehler gefunden... hab mit dem tool SimpleHIDWrite mal nachgesehen wo das problem liegen könnte...
ist recht bescheuert sag ich jetzt mal ;)

bevor ich meinen Serientest starte, wird der prüfling in der testaperatur angeschlossen... dadurch scheint kurz die spannung vom io-warrior einzubrechen so das er einen reset macht...

man sieht dort deutlich das "Removall of Simple IO" und das "Arrival of Simple IO"...

das passiert allerdings in so kurzer zeit, das windows nichts meldet... naja, ziemlich blöd halt, somit stimmt dann das handle natürlich nicht mehr und man bekommt eine access violation...

eigentlich plausibel wenn man die ursache kennt :D

danke trotzdem für die hilfe!
super forum hier :-)