Infrarot Schnittstelle ansteuern

[c113plpbr]

Ich hab (bei meiner TV-Karte mitgeliefert) ne fernbedienung und nen sensor (am com 1 hängend), welche ich über nen Delphi-Prog gerne ansprechen würde ... (bzw. abhören). Nungut ... ich hab davon keine ahnung ... aber wie mir das scheint is das einfach nur nen fototransistor (oder auch fotodiode genannt) der irgendwie direkt mit (kabel natürlich) mit irgendwelchen pins des com-ports verbunden is ... wie mach ich das???

Danke im vorraus!
by Philipp

[Borti]

Hallo!
ich steh mit dem Lpt-port vor dem selben Problem. Zuerst einmal ist es wichtig die pin-Belegung des com-ports rauszufinden. Dann geht's mit der Software los: hast du windows 98 oder 95? wenn ja, kannst du das ganze über den assembler regeln, wenn nicht würd ich die einen treiber oder eine Komponente, die dir den Zugriff auf den Port erlauben, ans herz legen.
Gruß,
Borti

[c113plpbr]

Ich hab im moment Win 2000 vielleicht demnächst auch wieder xp. Du meinst, dass du ne Komponente hast? Kannst du mir die geben? (bzw. link)

thx, Philipp

[Borti]

mit einer komponente sieht es schlecht aus, aber schau mal auf http://www.geekhideout.com/iodll.shtml!
Mit dieser dll dürft's klappen.
gruß,
Borti

[c113plpbr]

So ... die DLL scheint zu funktionieren, aber jetzt brauch ich noch so ne art von 'PortID' für meinen Com1 (bzw. Com2)-Port. Kann mir da jemand weiterhelfen?
Ich muss dann ja quasi per 'PortIn'-funktion der DLL den Port abfragen. Soll ich da jetzt 'PortWordIn', 'PortDWordIn', oder einfach nur 'PortIn' verwenden? Und vorallem: muss ich vor dem ich das mache noch irgendetwas initialisieren, oder sowas? Nen beispielcode wäre hilfreich ...

thx, Philipp

[Borti]

Also,
Bei mir hat der Com1 die Adresse $3F8.
kannst du einfach rauskriegen, wenn du im Bios rumstöberst.
Oder schau in den Gerätemanager unter Anschlüsse/Com1/Ressourcen.
Dort gibt’s ein Feld, dass nennt sich E/A-Bereich. Hier stehen die Adressen drin der sechs Portregister. Bei mir 03F8-03FF. Hier nimmst du einfach die Adresse des ersten Registers (03F8), streicht die Null am Anfang weg und setzt ein $ davor, damit Delphi auch weiß, dass es sich um eine Hex-Zahl handelt. Somit haben wir als Adresse fürs erste Register: $3F8.

Wenn du nun die function PortIn benutzt, dann ließt du das Byte von der Adresse $3F8.
Bei PortWordIn ließt du die Bytes des Register $3F8 und des nächst höher gelegenem. Das heißt von $3F8 und $3F9.
PortDWordIn liefert die Bytes des Registers $3F8 und der 3 nächsten. Also von $3F8, $3F9, $3FA und $3FB.
Für die Register $3FC bis $3FF müsstest du halt mit einer höheren Adresse als $3F8 einsteigen. Ich glaub, aber, dass diese Register eh keine Verwendung haben. (Bin mir aber net so sicher, weil ich bisher nur mit dem LPT gearbeitet hab)
Ciao,
Borti;

[c113plpbr]

Danke, Borti. Nur, im Moment hab ich das Gefühl eine Datenschleuder Programmiert zu haben, die (fast) nur zufälliges zeug ausgibt: ich hab nen proggi geschrieben, das den anschluss alle ca. 200 ms abfrägt. Nun ist es aber so, dass ich für eine Taste auf der Fernbedienung ca. 5 verschiedene 'codes' krieg. Das ganze sieht dann in etwa so aus, wie in der angehängten 'keys1.txt'-Datei. Gibt es da eine Möglichkeit das ganze irgendwie zu 'verdeutlichen' bzw. vereinheitlichen?
Ich hab noch nen Problem: Ich bekommen nur ein 'Signal' vom com-port wenn das bei meiner TV-Karte mitgelieferte Fernbedienungsprogramm läuft. Kann ich das irgendwie ändern?

thx im vorraus!

[Borti]

Was da schief gelaufen ist, hab ich keine Ahnung! :?:
also, die ersten 8 hex-zahlen sind ja die basisaddressen. die dürften eigentlich schon gar nicht vorkommen. Was für eine functiuon hast du denn nun benutzt? PortIn,PortWordIN oder PortDWordIn?
Aus was besteht dein angehängter file überhaupt? du spichst von 5 verschiedenen Codes-ich kann aber nicht wirklich erkennen, wo einer deiner codes anfängt bzw. endet.
das Fernbedienungsprogramm kann vielleicht konflickte zwischen beiden programmen auslösen, was zu deinem Datenwust führt. Aber wieso funktioniert dann das Programm nicht ohne das Fernbedienungsprogramm? :?: :?: :?:
was mich auch noch stutzig macht ist, dass dein in deinem Protokoll Hex_Zahlen drinstehen, obwohl delphi bytes, word und dwords nicht als hex-zahl, sondern als integer zurückgibt.
schreib doch einfach mal mit der io.dll daten auf den com1 und schau, ob du die selben daten auch wieder einlesen kannst.
Gruß,
Borti

[c113plpbr]

Du musst die datei mit dem Windows-Texteditor (notepad) öffnen, da wird das korrekt angezeigt, mit den Tabulatoren. Das in der Datei sollen Spalten darstellen (mit tabulator getrennt). Die Werte in der ersten zeile definieren nur die spalte darunter. d.h. das was unter $3F8 steht, is das was ich da empfangen hab. Dazu hab ich das ganze in Hex Konvertiert, weil es mir so lieber is ...
(benutzt hab ich nur PortIn, und jeden pin einzeln abgefragt) ... dazu, ist die datei von unten nach oben zu lesen, d.h. das was unten steht kam als erstes rein (aus anzeigegründen so gemacht) ...
Kapiert? Ändern tut sich eigentlich am Signal nur was auf $3F8 und $3FD, wobei sich bei $3FD nur dann auf 61(hex) ändert, wenn ich nen knopf gedrückt halte, sonst scheint er immer 60(hex) zu sein.
$3F8 dagegen scheint irgendwas mit den tasten zu tun zu haben ... nur wie in der vorigen datei zu sehen war, hab ich auf eine taste auf der fernbedienung (ziffer 4) 34, FE, 74 und 7E rausgekrigt (ich hab natürlich in verschiedenen intervallen gerückt, usw, aber immer nur diese eine taste) ... das is doch nicht normal ...
Das mit dem schreiben (auf den comport) muss ich mal probieren, aber soll das funktionieren, oder nicht?
Vielleicht versuche ich es auch mal mit openfile, und ohne dll ...

[Borti]

Hey, c113plpbr
mir ist da noch was aufgefallen:
die Kommunikation zwischen Peripherie und CPU läuft ja folgender Maßen ab:
1. Ruhezustand
2. Peripherie meldet sich beim CPU (sobald du eine Taste auf deiner Fernbedienung drückst)
3. Datentransfer (Peripherie übermittelt, welche Taste gedrückt worden ist)
4. Quittierung von CPU (CPU teilt der Peripherie mit, dass er die Register des Ports gelesen
hat und die Peripherie diese jetzt überschreiben darf)
1.wieder Ruhezustand

Mit unserem Programm hören wir nur abschnittsweise diese Kommunikation ab, da die Daten wahrscheinlich schneller übertragen werden, als wir mit unserer Frequenz von 50Hz abhören. Daher kommt wahrscheinlich auch der Datenwust zusammen. Darüber hinaus hören wir nur mit, und geben der Peripherie keine Antwort, wie es im Schritt 2 und 4 nötig wäre. Daher läuft die Kommunikation auch nur, wenn das Programm vom Hersteller nebenbei läuft, das die Antworten für uns übernimmt.
Ich an Deiner Stelle würde mich mal mit dem Hersteller in Verbindung setzen und nachfragen, wie genau die Kommunikation abläuft und was für Bytes hierbei gesendet werden.
Gruß,
Borti