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

[st0ne]

hi leute,

hab jetzt schon einiges im forum gelesen und versucht den iow56 vernünftig zum lesen zu bringen.
leider ohne erfolg :-(

ich möchte den status der pins abfragen und nicht warten bis sich was geändert hat. darum verwende ich iowkitRead in verbindung mit dem special report, da es readimmidiate nicht gibt auf dem iow56....

gut, hier mal mein code:

Code: Select all

IOWKIT56_SPECIAL_REPORT rep56special;
memset(&rep56special, 0x00, IOWKIT56_SPECIAL_REPORT_SIZE);
rep56special.ReportID = 0xFF;
int read = 0;
while ( read != IOWKIT56_SPECIAL_REPORT_SIZE )
{
	IOW::IowKitWrite(this->iowHandle, 1, (char*)&rep56special, IOWKIT56_SPECIAL_REPORT_SIZE);
	read = IOW::IowKitRead(this->iowHandle, 1, (char*)&rep56special, IOWKIT56_SPECIAL_REPORT_SIZE);
}

so gehört das doch normal oder? zumindest finde ich das in den anderen threads so.
ab und zu scheinen die eingelesenen ports zu stimmen, aber zu 90% sind es zufallsdaten...

was mache ich falsch?

System ist Windows XP
IO-Warrior 56
dll 1.5

gruß st0ne

[Christoph Jung]

Nach dem Schreiben sollte man ebenfalls einen memset() einbauen, damit die Rückgabewerte auch wirklich 0x00 sind, also rep56special gesäubert wird.
Zudem wird eine while-schleife hart durchgelaufen. Es wäre sinnvoller einen Timer zu nutzen oder im while eine Pause einzubauen, da der IO-Warrior nicht
so schnell ist wie das System und da dann die Anfragen durcheinander kommen können (Datenblatt befragen...). Man muss auch dran denken, dass Windows kein Echtzeitsystem ist. Soll heißen, dass windows im normalfall ein Delay von 15-18ms hat.

[st0ne]

Hi,

danke für die Info, werde das delay mal probieren, in dem fall muss es eh nicht echtzeit sein. hätt ich von usb/windows auch nicht erwartet ;-)

das ganze wird bei mir einfach mit eine Button aufgerufen, also läuft nicht die ganze zeit in einer schleife

das seltsame ist allerdings, das ich im einzelschritt auch unterschiedliche werte rausbekomme, und da sind teilweise zeiten von mehreren sekunden dazwischen...

gruß

[Christoph Jung]

Wie lang ist denn das USB-Kabel? Länger als 5 Meter verursacht Fehler. Auch sollte man die Finger von verlängerungen lassen. Einen Hub als Verlängerung nutzen ist allerdings möglich (der "Frischt" die Daten wieder auf).
Ist das auf ein Starterkit aufgebaut oder eine Eigenentwicklung?

[st0ne]

kabel hängt mit ca. 1.3m direkt am pc, SPI übertragung funktoiniert auch problemlos, werde morgen mal probieren ein delay einzufügen, vielleicht bin ich einfach zu schnell für den iowarrior ;-)

gruß

[st0ne]

also die sleeps helfen nichts :-(
die ersten zwei bis drei werte liest er richtig, ab dann meistens 0xff oder werte die ähnlich sind wie sie sein sollten...
sehr mysteriös das ganze...

gibts sonst noch vorschläge?

[Christoph Jung]

wie lange wird denn zwischen den Abrufen gewartet?
Vllt. könnte ein wenig Quellcode helfen. Bitte mal die komplette Funktion posten.

[st0ne]

hier mal eine funktion

Code: Select all

	int IOWarrior::SetPort(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;

		int read = 0;
		while ( read != IOWKIT56_SPECIAL_REPORT_SIZE )
		{
			IOW::IowKitWrite(this->iowHandle, 1, (char*)&rep56special, IOWKIT56_SPECIAL_REPORT_SIZE);
			read = IOW::IowKitRead(this->iowHandle, 1, (char*)&rep56special, IOWKIT56_SPECIAL_REPORT_SIZE);
		}
		for ( int i = 0; i < 7; i++ )
		{
			rep56.Bytes[i] = rep56special.Bytes[i];
		}

		rep56.Bytes[port] |= (BYTE) byte;
		
		return IOW::IowKitWrite(this->iowHandle, 0, (char*)&rep56, IOWKIT56_IO_REPORT_SIZE);
	}

momentan hab ich die sleeps wieder entfernt, aber ich hatte ca. 10ms gewartet, kann auch mal länger probieren...
nur im einzelschritt hab ich auch schon sekunden gewartet und es war trotzdem das falsche ergebnis, also hier vermute ich weniger das problem...

gruß

[Christoph Jung]

Um das nochmal festzuhalten:

Windows hat von Haus aus eine Verzögerung von 15-18ms. In der Regel sind Programme nicht in der Lage unter die 25ms zu kommen. Das kann nur geschehen, wenn die Prozess-Priorität der Anwendung auf Zeitkritisch / Hoch gesetzt wird. 10ms Sleep hat da überhaupt keine Wirkung.
Der Einzelschritt der IDE ist NICHT mit einem Sleep gleichzusetzten, da dies von der IDE und nicht vom Programm aufgerufen wird. Mag sein, dass es in manchen fällen klappt, aber das sollte man nicht als zuverlässige Fehler-korrektur nutzen.

Dann versteh ich nicht, warum am ende der schleife nochmal auf den IO-Warrior geschrieben wird. Welchen Sinn soll das haben?

[st0ne]

ich lese die ports ein, und maskiere dann mit dem pin was ich setzen will, drum wird danach geschrieben, da ich die anderen nicht verändern will ;-)

ok, ich kann mal einen sleep von 300ms oder so probieren, ist zwar etwas lahm dann, aber wenns selbst dann nicht geht fällt mir schön langsam nichts mehr ein :-(

[st0ne]

300ms bringt auch nix

[Christoph Jung]

Bevor das jetzt hin und her geht, schicken Sie mir das Projekt per E-Mail an jung(at)codemercs(dot)com zu. Vorzugsweise als ZIP.

[st0ne]

"sie" können gerne "du" zu mir sagen ;-)

naja, jedenfalls geht das nicht so einfach, die IOW ansteuerung ist nur ein kleiner teil von dem projekt, da wird noch einige andere hardware angesteuert die bei nichtvorhanden sein das programm blockiert bzw. nicht hochstartet...

aber vielleicht liegt es auch daran? hab die Funktionen der dll so implementiert, schreiben funktioniert halt problemlos, drum denke ich auch nicht dass das die ursache ist...

Code: Select all

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

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

habe übrigens beides probiert, das normale Read und das mit NonBlocking... beides zeigt die selbe charakteristik...

interessant ist auch das ab da wo es nicht mehr funktioniert, nur port 0 bis 3 daten enthält, ab port 4 ist immer 0x00 obwohl dort alles 0xFF sein sollte...

gruß

[Guido Körber]

ich lese die ports ein, und maskiere dann mit dem pin was ich setzen will, drum wird danach geschrieben, da ich die anderen nicht verändern will

Falsche Strategie.

Der IO-Warrior liefert den Eingangsstatus an den Pins zurück, also den Logikpegel der extern am Pin anliegt, nicht den Ausgangsstatus. Wenn Sie also die Portdaten einlesen, bitmaskieren und dann zurückschreiben, sind aus Eingängen die auf Null waren Ausgänge auf Null geworden.

[st0ne]

hm, ok, klingt eigentlich logisch... hab ich nicht bedacht... werde das mal ändern damit die eingänge immer 1 bleiben...

aber das löst leider immer noch nicht das problem das die pins dann falsch eingelesen werden ;-)