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

[st0ne]

irgendwas muss da definitiv bei mir im programm falsch sein, weil mit dem all in one testprogramm funktioniert der iow ohne probleme...

[Christoph Jung]

Ich habe mal einen Test gemacht und es funktioniert problemlos. So sieht meine Funktion aus:

Code: Select all

void CIoReconnectDlg::OnBnClickedButton5()
{
	UpdateData(TRUE);
	IOWKIT56_SPECIAL_REPORT rep56;
	IOWKIT56_IO_REPORT rep56io;
	int count = 0;
	BYTE puffer = 0x00;

	if(ioHandle != NULL)
	{
		rep56io.ReportID = 0x00;
		rep56io.Bytes[0] = 0x00;
		rep56io.Bytes[1] = 0x00;
		rep56io.Bytes[2] = 0x00;
		rep56io.Bytes[3] = 0x00;
		rep56io.Bytes[4] = 0x00;
		rep56io.Bytes[5] = 0xAA;
		IowKitWrite(ioHandle, IOW_PIPE_IO_PINS, (PCHAR) &rep56io, IOWKIT56_IO_REPORT_SIZE);

		memset(&rep56, 0x00, IOWKIT56_SPECIAL_REPORT_SIZE);

		while(count != 50)
		{
		 
         memset(&rep56, 0x00, IOWKIT56_SPECIAL_REPORT_SIZE);
         rep56.ReportID = 0xFF;
		 
         IowKitWrite(ioHandle, IOW_PIPE_SPECIAL_MODE, (PCHAR) &rep56, IOWKIT56_SPECIAL_REPORT_SIZE);
		 IowKitRead(ioHandle, IOW_PIPE_SPECIAL_MODE, (PCHAR) &rep56, IOWKIT56_SPECIAL_REPORT_SIZE);

		 if(puffer != rep56.Bytes[0])
		 {
			puffer = rep56.Bytes[0];
			result.Format(_T("%.2X %.2X %.2X %.2X %.2X %.2X"), rep56.Bytes[0],rep56.Bytes[1],rep56.Bytes[2],rep56.Bytes[3],rep56.Bytes[4],rep56.Bytes[5]);
			cListBox.AddString(result);
		 
			count++;
		 }

		 Sleep(50);
		 
		}
    }
	else
		cListBox.AddString(_T("Error"));

UpdateData(FALSE);

}

Zur erklärung:
Am Anfang setzte ich die Ports auf einen vordefinierten Wert (alles auf 0x00) und schreibe das in den IOW56.
Danach gehe ich in meine while-Schleife und lasse die 50x durchlaufen mit einem Sleep von 50ms.
Wenn An Port 0 eine Änderung ankommt, dann wird mir diese in eine Listbox eingetragen. Und ich bekomme immer da, was ich gerade
Als Eingang auf VCC gezogen hab.

[st0ne]

aha, ich schreibe die 0x00 natürlich nicht raus, vielleicht liegt auch hier das problem,

aaber, mir ist was aufgefallen
hab jetzt mal die lesefunktion in eine endlosschleife gegeben, mit singlestep immer durchlaufen und festgestellt, das ich den status erst richtig einlese, nachdem ich das 2. mal gelesen habe... grund dafür ist mir keiner bekannt, finde das sehr seltsam...

warum 50x einlesen?

[Guido Körber]

Wenn alle Ports auf Null gesetzt werden, dann gibt es keine Eingänge mehr...

[Christoph Jung]

ach das 50x war nur als begrenzung für den Test damit ich irgendwann auch wieder aus der while-Schleife rauskomme.
Grund für die "Phantom" Report ist der, dass die DLL und/oder das System die Ergebnise zwischenspeichert. Somit kommt bei einem Aufruf evtl. ein veralteter bzw. ein nicht abgeholter Report zurück.

[st0ne]

aha, dann ist vermutlich dass des rätsels lösung?
wie weiß ich wieviele reports da noch zwischengespeichert sind?

[Christoph Jung]

Das Einfachste ist nach jedem Schreibvorgang einen Lesevorgang auszuführen und die nicht benötigten Daten zu verwerfen.
Aber ob das die Lösung ist kann ich nicht beurteilen, da ich nicht das koomplette Programm kenne.

Evtl. die while-Schleife nach meiner Vorlage ändern und schauen was dann passiert (ohne != 50 sondert mit den eigenen Eckpunkten).
Allerdings könnte es ein Problem mit der Hardware geben, denn bei jedem Reinschreiben in den IO-Warrior wird das Eingang zum Ausgang.

Was ist denn am IO-Warrior angeschlossen und was wird dort getriggert?

[st0ne]

es gibt 3 geräte die am SPI port hängen, und brauche für jedes ein eigenes chipselect und ein paar statusleitungen...

ich hab jetzt mal probiert einfach mehrmals hintereinander in einer schleife zu lesen, das ich sicher den letzten report bekomme, aber irgendwie hängt er sich da beim schreiben vom 0xFF auf pipe 1 auf, und das nicht immer...

ich probier das mal aus mit lesen nach dem schreiben... Bleibt beim ausführen vom IowKitRead das dann nicht hängen? oder wird nach jedem schreibvorgang auch ein report ausgelöst den man mit dem iowkitread abholen kann?

meiner meinung nach müsste sowas alles die API machen ;-)
auch einzelne ausgänge auf 1 oder 0 setzen sollte von der API erledigt werden, damit man nicht selber umständlich herumprogramieren muss nur um einen pin zu setzen ohne das die anderen mit 0x00 oder 0xFF beschrieben werden ;-)

[Christoph Jung]

Wenn man den Pinstatus des IOW56 ausliest bekommt man den aktuellen Status des IOW. Wenn sich da was aufhängt ist das schlecht und das hat nichts mit der API zu tun. Dieser Special-Mode liefert IMMER einen Status zurück, wenn er geschrieben wird. Darum ja das Write/Read in der Schleife.

Jeder Schreibvorgang der eine Änderung an den IO-Pins vornimmt wird mit mit einer Antwort quittiert. Also wenn nach der Schleife nochmal Write ausgeführt wird und sich dort nur 1 Bit ändert muss zwangsläufg gelesen werden. Warscheinlich werden genau diese Reports die "Phantome" sein.
IowKitRead() wartet so lange, bis eine neue Antwort am IO-Warrior anliegt. Dies kann man aber mit ReadNonBlocking oder IowKitSetTimeout begrenzen. Das Read sollte natürlich hinter einem Write-Befehl folgen!

Die Schleife darf das Lesen und Scheiben des USB und den IO-Warrior nicht überfordern. Darum sollte die schleife mit einem Sleep von 50ms versehen werden (am besten am Ende der Schleife einfach Sleep(50); rein ). Oder man verwendet gleich einen Timer für diese Arbeit.

[st0ne]

super! danke für die erklärung :-)
so versteht man auch endlich was da drin so vorgeht ;-)

wie ist das wenn ich auf die SPI schnittstelle was geschrieben habe, wird das auch quittiert? also sollte ich da wohl auch mal kurz was lesen oder?

[Christoph Jung]

Ja jedes erfolgreiche Write wird Quittiert. Egal ob I²C, SPI, IO.
Steht aber alles im Datenblatt...

[Guido Körber]

Da SPI nicht zwischen Lesen und Schreiben unterscheidet, wird auf jede SPI Transaktion mit einem Report vom IO-Warrior geantwortet in dem die gelesenen Daten stehen.

[st0ne]

hm, das ist echt seltsam, ich hab nach jedem write auf pipe 0 jetzt mal ein read gemacht, mal funktionierts, mal bleibt er hängen... ob da die 50ms reichen?

[st0ne]

hm, nö, selbst mit 1000ms geht nix, ist echt seltsam, er wartet beim read so lange bis ich den taster auf der platine drücke...

[Christoph Jung]

Es wird bei jedem IowKitRead() auf den Timeout gewartet, also wenn das in einer Schleife passiert, dann jedesmal beim Durchlauf. Steht alles in der Doku zur API.
Ich glaube hier herscht ein allgmeines Problem mit dem Verständnis der API oder an einem falschen Ansatz für das Programm.