Hallo an alle älteren Forenbesucher, vielleicht gibt es ja noch jemanden, der sich mit dem Thema auskennt. Mich würde mal dringend interessieren, wie man ein CRT/Light Pen System durch einen LCD Touchscreen ersetzen kann. Mich interessiert erst mal nur die nackte Theorie. Meine Idee bis jetzt: Die Framebuffer-Karte misst ja offenbar die Zeit die der Elektronenstrahl braucht bis er am Light Pen angekommen ist. Ich vermute mal vom Zeitpunkt des H-Sync des Monitors an. Wenn ich also eine kleine MicroIntelligenz habe, die die Koordinaten des Touchscreens ausliest und auf das H-Sync Signal des Monitors wartet, um dann einen den Koordinaten entsprechenden Zeitraum zu warten um dann ein Signal an die Light Pen Logik abzusetzen ... puuuhhh ... komme ich der Sache damit auf den Grund? Inputs welcome :-) Frickolino
Frickolino schrieb: > Wenn ich also eine kleine MicroIntelligenz habe, die die Koordinaten des > Touchscreens ausliest und auf das H-Sync Signal des Monitors wartet, um > dann einen den Koordinaten entsprechenden Zeitraum zu warten um dann ein > Signal an die Light Pen Logik abzusetzen ... puuuhhh ... komme ich der > Sache damit auf den Grund? Genau das ist die Vorgehensweise. Allerdings brauchst Du auch noch V-Sync, um die Bildzeile zu bestimmen. Die Wartezeit nach dem H-Sync-Signal ist vom Pixeltakt abhängig, der bei EGA glücklicherweise feststehend ist; EGA verwendet bei 640x350/60Hz einen Pixeltakt von 16.257 MHz und eine Zeilenfrequenz von 21.8 kHz; eine Zeile ist also inklusive Austastlücke etwa 746 Pixel "lang". Entsprechend ist das Bild inklusive vertikaler Austastlücke 363 Pixel hoch. Mit einem µC müsste das hinzubekommen sein. Die SPI-Schnittstelle wird mit 16.257 MHz angesteuert, dabei werden kontinuierlich Daten in die SPI-Schnittstelle eingefüllt (das mit etwas über 2 MByte/sec). Diese Daten sind immer Nullen, außer bei Erreichen der gewünschten Position. Das dürfte durch zwei Pufferbereiche à 94 Byte umsetzbar sein, der eine bleibt komplett auf Null gesetzt, in den zweiten wird im gewünschten Byte an der gewünschten Bitposition eine 1 eingetragen. In der Zeilenschleife wird in Abhängigkeit von der aktuellen Zeilenposition entweder die Leerzeile oder die Zielzeile ausgegeben. Die SPI-Datenleitung wird mit dem "Lichtgriffel"-Eingang des Altsystemes verbunden. Mit einem Monoflop kann die Impulsdauer soweit verlängert werden, daß die Lichtgriffelmimik auch zuverlässig triggert.
Hallo Rufus, sauber! Das sind ja mal ne Menge Infos. Danke schonmal dafür. Hmm - irgendwie kann ich Dir aber noch nicht ganz folgen. Ich dachte eher dass das V-Sync Signal ja ganz oben links triggert und ich dann eine definierte Zeit abwarte um den LightPen zu simulieren. Ich glaube ein Bild lag so bei 16ms. Wenn also der Touchscreen mitten im Bild berührt wird, dann würde ich nach 8 ms dem Framebuffer vorgaukeln er hätte einen LightPen gesehen. Das Ganze natürlich in "genau". Würde dann also mit nem Oszi ermitteln, welche Zeitdifferenz zwischen Sync und LightPen Puls bei welcher Position entsteht. Dann mit nem AVR einen Touchscreen digital auslesen und Koordinaten in Delay umsetzen um dann den virtuellen Lightpen zu triggern. Wat meenste? Bin ich in der richtigen Spur?
Auch Dein Bildschirm ist zweidimensional. Dein Touchscreen gibt eine X- und eine Y-Koordinate von sich, und der Lightpenlogik willst Du diese auch übermitteln. Also musst Du, beginnend mit einem V-Sync-Impuls erst mal die Zeilen zählen, bis Du zur Y-Koordinate gelangst. Beginnend mit dem H-Sync-Impuls für diese Zeile musst Du nun die Pixel zählen, bis Du zur X-Koordinate kommst. Wenn Du den exakten Pixeltakt der Graphikhardware zur Verfügung stehen hättest, dann könntest Du natürlich auch den Pixeltakt beginnend mit V-Sync zählen und ausrechnen, wann der virtuelle Elektronenstrahl an Deiner Koordinate vorbeikommt. Ich denke aber, daß Du durch Auszählen von Bildzeilen die vertikale Positionierung und darauf aufbauend die horizontale Positionierung präziser hinbekommst - die vertikale ist exakt, die horizontale ist dann nur so inexakt wie die Abweichung zwischen Deinem eigenen Referenztakt und dem angenommenen Pixeltakt.
Vielen Dank für Deine Geduld. Das leuchtet mir soweit ein. Gibt es denn variable Frequenzen? Ich denke doch nicht. Der Multisync Monitor der momentan dranhängt zeigt fH=30.6kHz und fV=59.0Hz. Wenn ich also mal davon ausgehe, dass der Touchscreen mittig gedrückt würde, dann wäre dass doch übersetzt die 350/2 te Zeile auf dem CRT (Austastlücken unberücksichtigt). Bei einer angenommenen Zeilendauer von 32 uS wäre es dann nicht rein rechnerisch 350/2-1 Zeilen * 32 uS + 32/2 uS (die halbe Zeile) nach der V-Sync Flanke? Jetzt bin ich gespannt ...
Die alte Lightpen Hardware latchte mittels des Lichtpulses mehr oder weniger einfach die Adresse des Videoram der Grafikkarte, deswegen wurde der Lightpen auch direkt an die Karte angeschlossen. Die Latches wurden dann mittels Software gelesen und wieder zu XY umgerechnet.
Frickolino schrieb: > Wenn ich also mal davon ausgehe Kannst Du machen, aber das wird schlichtweg zu ungenau sein. Da Du aber sowieso einen µC verwenden solltest, kannst Du das ja einfach ausprobieren, erstmal mit "Deinem" Verfahren, und wenn das nicht reicht, mit den Vorschlägen von mir optimieren. Viel Erfolg dabei.
@ Rufus, ich verstehe was Du meinst. Bei einer Verweildauer von nur wenigen uS pro Zeile kann es leicht um ein oder mehrere Pixel kippen. Wie Du ja schon bemerkt hast bekommt man die Zeile mit dem x-ten H-Sync leicht getriggert. Die Position innerhalb der Zeile bleibt ohne Pixeltakt in jedem Fall schwer zu erzielen. Das Ganze "stinkt" schwer nach zeitkritischer Assemblerprogrammierung. Hast Du eventuell noch detailliertere Informationen zum EGA Timing? Ich hab mir schon die Finger wund gesucht und immer nur VGA Geraffel gefunden. Wenn ich wüsste wie klein die Auflösung sein muss könnte ich schonmal testen, ob ich das mit dem uC überhaupt so genau hinbekomme.
Frickolino schrieb: > Hast Du eventuell noch detailliertere Informationen zum EGA Timing? Die Angaben, die ich gemacht habe, sollten ausreichen. Die von Deinem Monitor angezeigten Werte widersprechen dem allerdings; EGA hat keine 30 kHz Zeilenfrequenz. Bist Du Dir sicher, daß das 'ne EGA-Karte ist?
Von den 30kHz war ich auch verwirrt. Es handelt sich um einen proprietären VME Grafikprozessor aus den 80ern. Hab dann doch noch zwei Zeilen dazu im Netz gefunden und es scheint tatsächlich eine VGA/XVGA Karte zu sein. Macht die Angelegenheit durch die höhere Frequenz nicht wirklich einfacher. Am Ausgang sitzt ein Bt471 RAMDAC. Dessen Clock müsste eigentlich die Pixelfrequenz darstellen. Würde es reichen die Pixelfrequenz zu kennen, oder brauche ich sie immer um einen Zähler zu bedienen? Ich könnte auf der Karte durchaus messen, aber dauerhaft anzapfen möchte ich sie nicht. Die Dinger kann man mit Gold aufwiegen, so selten sind die geworden. Da möchte ich kein Risiko eingehen ...
Frickolino schrieb: > Dessen Clock müsste eigentlich die Pixelfrequenz darstellen. > Würde es reichen die Pixelfrequenz zu kennen, oder brauche ich sie immer > um einen Zähler zu bedienen? Zwar wäre es präziser, wenn Du sie direkt verwenden würdest, wenn Du aber den Hsync-Impuls auswertest, um den Zeilenanfang zu bestimmen, dürfte die "Missweisung" durch einen eigenen Pixeltakt nicht kritisch werden. Allerdings ist der Pixeltakt bei VGA so hoch, daß die angesprochene Microcontrollerlösung nicht umsetzbar sein dürfte.
Ich nochmal: Hab's gerade nochmal weitergedacht. Mal angenommen der Pixeltakt wäre 25 MHz (was dem Oszillator neben dem RAMDAC Chip entspricht). Wenn ich jetzt einen 32 Bit Zählerbaustein mit Comparefunktion hätte (z.B. den LS7366R) und einen eigenen 25MHz Oszillator, dann müsste der AVR quasi nur die XY Koordinaten des Touchscreens auslesen, die Koordinaten in den gepixelten Timerwert umwandeln und in den Timer laden. Der Timer würde dann vom V-Sync gestartet und bekommt die Clock vom Oszillator und im Compare Fall löst er das virtuelle Light Pen Signal aus. Das bißchen Arbeit kann dann sogar noch ein Tiny bewältigen. Das sollte doch ziemlich genau werden, oder?
Nachtrag: ich bin voll mit Dir d'accord, dass der H-Sync der richtige Weg ist. Das Problem sehe ich in der Zeile selbst. Hier bedeuten 100ns Unterschied schon fast mehrere Millimeter. Und hier habe ich nichts mehr zum syncen ...
Frickolino schrieb: > Hier bedeuten 100ns > Unterschied schon fast mehrere Millimeter. Ja, aber die Abweichung zwischen dem "Original-Pixeltakt" und dem nachgebildeten wird nicht so groß sein, daß Du 100ns Versatz hinbekommen wirst. Du musst natürlich eine "Trimmfunktion" in Dein Konstrukt einbauen, mit der Du horizontalen und vertikalen Versatz des nachgebildeten "Lichtgriffels" kompensieren kannst, das brauchst Du schon, um die Austastlücken zu kompensieren. Poste doch mal ein Bild der VME-Bus-Graphikkarte, mit der Du Dich da beschäftigtst.
Trimmfunktion ist sowieso Pflicht. Dem VGA Standard entnehme ich einen Pixeltakt von 20.125 MHz - das haut schonmal hin. Eben mit dem Oszi gemessen: 34us high Level und 2us low Level auf dem HSync. Sollten eigentlich 32us H und 4us L sein ... hmmm ... 18ms H und ~0.1 ms L auf dem VSync. Kommt in etwa hin. Also -> VGA 640x480 Die GraKa ist absolut proprietär und offenbar für den OEM designed worden. Kein Industriestandard - keine Datenblätter. Dual Display - Dual Lightpen - 100% Blackbox http://www.fdtgb.co.uk/graphics.htm Apropos Austastlücken: Sind die nicht auch standardisiert? ich bräuchte ja eigentlich nur die Obere und die Linke.
Frickolino schrieb: > Dem VGA Standard entnehme ich einen Pixeltakt von 20.125 MHz - das haut > schonmal hin. 25.125 MHz. Typo? Graphikhardware mit HD63484. Fand' ich auch mal schick, wollte mir damit was basteln, dann aber ist irgendwas dazwischengekommen, und das Projekt kam nie über die drüber-nachdenk-Phase hinaus. Frickolino schrieb: > Apropos Austastlücken: Sind die nicht auch standardisiert? Naja, sehr theoretisch schon, aber in der Praxis nicht unbedingt. Ist schließlich keine echte VGA-Karte mit VGA-BIOS, die wegen identischer Hardware das Timing des IBM-Originals einhält. Mach das adaptierbar und gut ist.
Jepp Typo - 20,125 MHz Und Du hast schon wieder Recht. Kein IBM VGA - kein Standard :-) Bleibt das letzte echte Problem: Der LS7366R Das Teil gibts schon ne Weile nicht mehr bei Farnell. Gibt es denn Alternativen dazu? Also programmierbare externe 32 Bit Counter für 20MHz? Bin nicht erpicht auf CPLD und uC Programmierung für diese Anwendung. Dafür bin ich zu doof. Ein normales C-Programm krieg ich hin, aber nichts suuuper zeitkritisches in Assembler ...
Kann man vielleicht einfach TTL oder HCMOS-Zähler kaskadieren? 20 MHz müßten mit Standardteilen noch gehen.
Es sollte programmierbar sein und ohne ein weiteres Studium funktionieren. In meinem Fall also mit einem Pixelwert vorgeladen werden triggerbar sein und beim Match einen I/O Pin schalten. Eigentlich alles so, wie im uC Timer/Counter. Ich mag aber nicht sowas programmieren müssen - rabähhhhh
Frickolino schrieb: > Apropos Austastlücken: Sind die nicht auch standardisiert? > ich bräuchte ja eigentlich nur die Obere und die Linke. Hallo, beim offiziellen Timing für 640x480 ist eine H-Zeile 800 Pixel lang (bei 25,175 MHz), von denen 640 angezeigt werden. Du brauchst also einen Offest für vertikal; wenn du einfach durchzählst sind 800 Takte eine Zeile, aber viel sicherer ist es den H-Impuls auszuwerten, und von da gibt es nochmal einen Offset HSync->sichtbares Bild. Bei den alten Röhrenmonitoren war ja alles analog, da kam es nicht so genau drauf an, sondern da waren einfach Potis drin für V und H, mit denen man das Bild zurechtschieben konnte. So ungefähr solltest du das auch lösen, 2 veränderliche Parameter sollten reichen, da du die einzelen Zeiten für Front Porch, Sync Pulse Length usw. garnicht wissen musst. Da gibt es oft Variationen, oft werden auch Oszillatoren mit 25 MHz statt 25.175 verwendet oder sogar 24 MHz. Soll es ganz präzise sein, greift man am besten den Originalpixeltakt ab. Gruss Reinhard
Hallo Reinhard, danke für die Zusatzinformationen. Ziemlich genau das habe ich mittlerweile auch bei Tobias' Arbeit nachgelesen: www.uni-koblenz.de/~physik/informatik/ECC/vga.pdf Seite 7 ... Bei meiner Graka sind es offenbar 25,000 MHz. Ich bin sicher, dass die Grafikkarte noch einige Überraschungen birgt.
Frickolino schrieb: > Bei meiner Graka sind es offenbar 25,000 MHz. Nun, miss das genaue Timing der Graphikhardware, also die Zeilen- und Bildwechselfrequenz und baue Deinen Zählermechanismus darauf auf. Als Hardware dürfte sich ein FPGA/CPLD vermutlich recht gut eignen, da das deutlich weniger "Verdrahtungsaufwand" mit sich bringt als eine diskret aus einzelnen 74xx-Logikbausteinen aufgebaute Variante.
Hab bereits beide Frequenzen mit nem HP Counter gemessen. Leider hänge ich bei dem LS7366R Problem fest. Auf eine schnellere CPU zu gehen macht - denke ich - keinen Sinn, da diese ja > 40MHz laufen müsste und da sind wir bereits in dem für mich unbekannten ARM Bereich. Dann bleibt wohl nichts als das CPLD übrig. Ich melde mich dann in einem oder zwei Jahren wieder, wenn ich VHDL gelernt habe ... Bis dahin geht es vermutlich darum die LCD's durch Hologramme zu ersetzen :-)
Frickolino (CPLD Noob) schrieb: > Bis dahin geht es vermutlich darum die LCD's durch Hologramme zu > ersetzen :-) Lightpen war gestern, Schubsen auf dem Display ist heute und Gesten im freien Raum sind morgen - wird allerdings schon getestet. Gruss Reinhard
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.