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

[st0ne]

hi,

passiert nicht in der Schleife, bei ersten mal setzen der Inputs auf high (rest mal auf 0) schreibe ich mit Write die bytes raus, und danach 50ms pause, und dann IowKitRead... und hier bleibt er hängen

sollte ich da einen read-timeout setzen, falls nichts anliegt? dachte nach einem write liegt eh ein report zum auslesen an... ;-)

naja, verständnis der API ist relativ, sooo gut ists jetzt im Datenblatt bzw. im API Pdf auch nicht beschrieben als das man es gleich mal abcheckt wie das teil zu bedienen ist ;-)

gruß

PS: ich sehe grad nebenbei die API Doku durch, und beim IOWKitWrite steht nirgends was davon das nach dem Write ein Report anliegt... auch im "Sample usage C" steht hier nichts davon...

[Christoph Jung]

Vielleicht mal lesen, was wir hier im Forum schreiben ?
Wenn man einen Schreibbefehl mit der ReportID 0xFF abschickt oder SPI nutzt bekommt man Antwort, nicht aber wenn man über 0x00 etwas schreibt.
Read Liefert etwas zurück, wenn sich der Status an den Pins oder etwas am Special-Mode tut. Wenn keine Änderung vorliegt passiert nichts. Darum gibts die Funktion IoWKitSetTimeout() um dann im Fall der Fälle nach x mS abbricht weil das Programm sonst hängenbleibt.

[friend-of-rq]

Hi st0ne,

wenn Du die Ports gezielt abfragen willst, solltest Du zu zuvor
die Funktion $FF (Out) Getting current pin Status anstossen.

Beim einlesen musst Du das erste Byte immer prüfen, damit Du die Antworten richtig zuordnest.

Beim IowKitRead / IowKitReadNoBlocking enthält DAT(0) immer die Report-ID
z.B.
0 (00h) = NULL ( z.B. nach TimeOut beim IowKitRead oder IowKitReadNoBlocking ohne Daten)
2 (02h) = I2C
3 (03h) = I2C
6 (06h) = LCD
9 (09h) = SPI
12 (0Ch) = RC5
25 (18h) = switch Matrix
26 (19h) = switch Matrix
255 (FFh) = Ports

Ich verwende in meinen Anwendungen fast nur noch IowKitReadNoBlocking.
In einer Schleife die zeitlich begrenzt ist frage ich mit IowKitReadNoBlocking die DLL ab.
Die Schleife endet wenn ein Ergebnis DAT(0) <>0 oder die zeit überschritten ist.
Mit TimeOut beim IowKitRead hatte ich Probleme, es kam zu Fehlermeldungen.

mfg
R.Greinert

[st0ne]

hi,

ich lese jetzt mit IowKitReadNonBlocking so oft aus bis ich 0xff als report bekomme, so scheint es jetzt mal zu funktionieren! :-)

danke für den tipp!!

gruß

[st0ne]

hallo,

muss das thema wieder aufrollen... habe ein neues problem :-(

hab mein programm jetzt auf einen anderen rechner kopiert, und jetzt bekomme ich eine "AccessViolation" beim IOWkitReadNonBlocking...
kurioserweise aber nicht immer...

was für gründe kann es für die accessviolation geben? ich kann dann nämlich nichtmal abfragen ob das IOWkitReadNonBlocking ok war oder nicht, da das programm an der stelle einfach abstürzt...

danke schon mal für die hilfe :-)
gruß st0ne

[Christoph Jung]

Ist auf dem anderen Rechner auch die DLL installiert / vorhanden?
Wurde das Programm mit statischen Verlinkungen erstellt? Wenn die Verlinkungen dynamisch sind kann es vorkommen, dass einige wichtige Programmelemente nicht in der Exe eingebunden sind. Und was das wichtigste ist, wurde eine Release-Exe erstellt oder wird versucht die Debug-Exe auf dem anderen System zu verwenden?

Ansonsten hilft da nur Debuggen, Debuggen und wieder Debuggen.

[st0ne]

hi,

danke für die antwort :-)

ich habe auf dem anderen rechner visual c++ express 2008 installiert, wie hier auch, und alle updates für .net die notwendig waren, und dann einfach das projektverzeichnis rüberkopiert und versucht dort zu kompilieren...

die dll's waren da alle im projektverzeichnis, sollte also alles vorhanden sein was notwendig ist...

gruß

[st0ne]

also es ist sehr seltsam. ich habe das iowkitreadnonblocking in einer funktion eingebaut, diese funktion rufe ich aus verschiedenen stellen des programms auf, lauter einzeltests (es ist ein hardwaretestprogramm).

sobald ich ein und die selbe funktion mit genau den gleichen parametern bei einem "serientest" aufrufe, also wo alle einzeltests nach der reihe aufgerufen werden, dann stürzt iowkitreadnonblocking gleich beim ersten aufruf ab...

ich versteh nicht wo ich suchen soll, die einzeltests funktionieren ja einwandfrei...

[Christoph Jung]

Ohne ein wenig Quellcode des Problems kann man wenig sagen.

[st0ne]

Code: Select all

void IOWarrior::SetBit(char byte, int port)
	{
		IOWKIT56_SPECIAL_REPORT rep56special;
		IOWKIT56_IO_REPORT rep56;
		memset(&rep56special, 0x00, IOWKIT56_SPECIAL_REPORT_SIZE);
		memset(&rep56, 0x00, IOWKIT56_IO_REPORT_SIZE);
		rep56special.ReportID = 0xFF;
		rep56.ReportID = 0x00;

		
		IOW::IowKitWrite(this->iowHandle, 1, (char*)&rep56special, IOWKIT56_SPECIAL_REPORT_SIZE);
		memset(&rep56special, 0x00, IOWKIT56_SPECIAL_REPORT_SIZE);
		
		
		// Reports so lange auslesen bis die richtige Report-ID gelesen wurde, maximal knnen 128 Reports zwischengespeichert werden.
		for (int i = 0; !((i==128) || (rep56special.ReportID == 0xFF)); i++)	
		{
			Sleep(50);
			try
			{
				IOW::IowKitReadNonBlocking(this->iowHandle, 1, (char*)&rep56special, IOWKIT56_SPECIAL_REPORT_SIZE);
			}
			catch (AccessViolationException^ e)
			{
				System::Windows::Forms::MessageBox::Show(e->Message);
			}
			
		}
		

		for ( int i = 0; i < 7; i++ )
			rep56.Bytes[i] = rep56special.Bytes[i];
		
		// Den jeweiligen ausgang schalten
		rep56.Bytes[port] |= (BYTE) byte;
		
		// Immer auf 1 gesetzt, da eingang
		rep56.Bytes[3] |= 0xC0;
		rep56.Bytes[0] |= 0x01;

		IOW::IowKitWrite(this->iowHandle, 0, (char*)&rep56, IOWKIT56_IO_REPORT_SIZE);
		//Sleep(50);
	}

ok, das ist die funktion die ich aufrufe, bei einem einzeltest, wo die funktion öfters aufgerufen wird, funktioniert es einwandfrei, wird die serientestfunktion aufgerufen, wo genau die gleiche funktion auf die selbe art und weise aufgerufen wird, dann stürtzt es ab...
hab jetzt mal ein try/catch eingebaut, welches auch funktioniert, aber jetzt kommt halt einfach eine msgbox anstatt eines absturz, hilft nicht viel weiter ;-)

[Christoph Jung]

Sieht an sich alles korrekt aus.
Was passiert denn, wenn durch das Programm via Haltepunkt durchgesteppt wird. Also wenn der Haltepunkte bei catch() gesetzt wird.

Theoretisch sollte er wenn er einfach nichts zu lesen hat nach 128 versuchen in das catch() laufen und dadurch jetzt die Exception aufrufen.
Eine Exception tritt immer dann auf, wenn z.B. ein Handle ungültig ist oder eine Variable aufgerufen wird, die außerhalb der Spezifikationen genutzt wird. Z.B. ein Array[20] und es wird auf Array[20] zugegriffen. Dann kommt in der Regel eine Exception.

Also am besten mal einen Breakpoint auf catch() setzten und schaun was der Debugger so sagt zu den einzelnen Variablen.

Ansonten mal das IowKitReadNonBlocking() mit einer if-Anweisung verbinden. Also wenn nichts gelesen wird, dass dann alles andere übersprungen wird.

[st0ne]

if anweisung mit iowkitnonblockreading hab ich versucht, der absturz passiert genauso...

breakpoint auf "catch" bringt auch nix...

kann es sein dass das handle irgendwie ungültig werden kann?

[Christoph Jung]

Nein. Solange nicht irgendwo Handle = NULL; oder IowKitCloseDevice() aufgerufen wird sind die Handles gültig.

[st0ne]

hmm, ok, also dann vielleicht noch was mit der dll-import funktion, vielleicht hab ich da einen fehler?

Code: Select all

[DllImport("iowkit", SetLastError=true)] 
extern "C" int IowKitReadNonBlocking(int iowHandle, int numPipe, char* buffer, int length);

was mir weiters noch aufgefallen ist... zuvor initialisiere ich den SPI-Port, allerdings geht hier das schreiben schief, res = 0
danach kommt im grunde gleich mal diese funktion, könnte das vielleicht noch eine ursache sein?

[Christoph Jung]

Warum überhaupt einen DLL-Import?