Hi, ich versuch gerade mit Delphi 3 die Pins des Parallelports unter XP zu schalten. Dazu habe ich die inpout32.dll von http://www.logix4u.net eingebunden - source code meines Projektes im Anhang. (Wer es testen will findet die zugehörige dll und die sys-Datei im Link oben) Die inpout32.dll und die hwinterface.sys liegen bei mir im Projektverzeichnis, außerdem in c:\Windows\System32 Am ECP-Port sind 8 Leds über Transistoren als Treiber angeschlossen, sie leuchten alle von vornherein schon - d.h. sie reagieren überhaupt nicht auf mein Programm... Was ist hier das Problem? Ich versuche im Programm den ECP Port in den Standardmodus zu versetzen, aber da tut sich irgendwie nix. Grüße, Dierk
Hi, habe das Programm jetzt ergänzt. Es läuft unter XP, wenn der LPT-Port mittels Porttalk freigeschaltet wird... (benötigt die DLLs von oben) zur Installation des Porttalk treibers sind allerdings einmalig Administratorenrechte erforderlich. Jetzt kann man zumindest mal den Port und die Timergenauigkeit mit dem Oszi testen. Es ist im Moment leider nur der Standard-Timer implentiert, man sieht schon so daß er völlig ungenau ist - gibts Vorschläge (Programmiertipps oder Delphi-Komponenten) wie ich das besser hinkriege? Er sollte noch unter Delphi 3 laufen... Grüße, Dierk
Die Timerauflösung des Systemtimers (die üblicherweise 10 msec beträgt) lässt sich aus einer Anwendung durch Verwendung der Multimediatimer auf 1 msec erhöhen. Dazu mmsystem.h einbinden* und die Funktion timeBeginPeriod mit der gewünschten Timerauflösung in msec aufrufen. Das - aus einem Usermode-Programm aufgerufen - beeinflusst erstaunlicherweise den Systemtimer und somit die über den Scheduler erzielbare Timerauflösung. Soll beispielsweise ein Devicetreiber diese erhöhte Timerauflösung nutzen, ist das am einfachsten durch ein Usermode-Programm hinzubekommen - dem Devicetreiber wird keine so leicht zugängliche API zur Verfügung gestellt. Anzumerken bleibt noch: Windows ist kein Echtzeit-OS, so daß bei Usermode-Programmen nicht davon ausgegangen werden kann, daß sie irgendwelche knappen Timingvorgaben einhalten können. Wer damit eine Steuerung realisieren will, die im Millisekundenbereich auf irgendwas reagiert, der macht was grundlegendes falsch. *) ich will gar nicht erst wissen, was für seltsame Klimmzüge man veranstalten muss, um äquivalente Dinge in Delphi zu machen. Ist Delphi 3 nicht noch eine 16-Bit-Umgebung gewesen? Dann ist der Aufruf von Systemfunktionen wohl nicht möglich. Aber: Ich kenne Delphi nicht und ich will's auch gar nicht näher kennenlernen.
@Rufus T. Firefly >Aber: Ich kenne Delphi nicht und ich will's auch gar nicht näher >kennenlernen. So habe ich auch einmal gedacht, bis mich durch einen Kunden "gezwungen" wurde, damit zu arbeiten. Und heute nehme ich, wenn ich in meiner Entscheidung frei bin, nur noch Delphi. Warum sollte man alles umständlich von Hand programmieren, wenn es dafür fertige Komponenten gibt? Der von Hand geschriebene Code ist in Delphi gegenüber einer Lösung in C(++) meist nicht viel länger, aber auf jeden Fall viel übersichtlicher. Heutzutage zählt für viele Kunden einfach nur Geld. Und Zeit(einsparung z.B bei der Fehlersuche) ist Geld. Ich glaube, nicht umsonst hat Microsoft den Chefentwickler von Delphi massgeblich mit der Neuentwicklung von C# betraut. Sooo schlecht kann Delphi ja dann nicht sein. Ich will hier keinen Glaubenskrieg entfachen, aber es schadet nicht, wenn man sich auch einmal andere Dinge jenseits von C(++) anschaut. Vielleicht auch nur, um das Beste von allem zu kombinieren... Joline P.S. Seit Version 2 erzeugt Delphi 32-Bit-Windows-Anwendungen.
Ich kann mich Joline nur anschließen. Schneller als mit Delphi kommt man nicht zu seinem Ziel, wenn man nicht gerade treiber programmieren will.
Delphi bringt einem aber nur was, wenn man die Scheuklappen nicht absetzt - mit dem erworbenen Programmierwissen kann man nur auf gerade mal zwei Plattformen (Windows und Linux) was anfangen. Weder für systemnahe Programmierung (Treiber, wie von Thorsten richtig erwähnt) noch Programmierung auf Systemen, die weder Linux noch Windows einsetzen, bringt einem das was. Bereits ein echtes Unix à la FreeBSD ist ein Ausschlussgrund - die Verwendung eines Microcontrollers erst recht. Damit scheidet Pascal für mich aus; warum soll ich auf jedem System schon wieder eine andere Programmiersprache verwenden, und dann auch noch eine, die nur von einem Hersteller proprietär gepflegt wird? (Hinweis: Auch VB fasse ich nicht an)
Hi, was ist eigentlich der Unterschied zwischen Multimedia-Timer (=1 ms) und die Granularität des Schedulers mittels API Call auf 1 ms zu setzen? Heißt das dann, alle Threads werden 1000 mal in der Sekunde aufgerufen? Ich meine, beides macht 1 ms was ist besser? Wenn man beides zusammen implementiert ist es dann wieder schlecht oder? zu Delphi: ich komme aus der Pascal-Ecke und mag den strukturierten Programmcode. Es ist gut lesbar und geht halt schnell, Pointer und komplexe Records sind sobald Daten verwaltet werden ziemlich genial... und wenn die Befehle nicht reichen kann man problemlos Assembler einbinden. Nur die Doku zu den API-Calls und systemnaher Progr. finde ich unzureichend.
Hi, hab inzwischen speziell zu diesem Thema ein paar interessante Links dazu gefunden: Granularität des Schedulers: http://www.wideman-one.com/gw/tech/dataacq/skedgran/skedgran.htm Timing mit Windows: http://www.wideman-one.com/gw/tech/dataacq/wintiming.htm PORT I/O mit Delphi: http://www.wideman-one.com/gw/tech/Delphi/iopm/index.htm Freischalten von Ports mit PORTTALK: http://www.beyondlogic.org/porttalk/porttalk.htm
Eine verbreitete Variante von Porttalk wurde mal im DDJ unter dem Namen giveio.sys veröffentlicht. Was bei diesem Ansatz leider gar nicht möglich ist, ist die Verwendung von Interrupts. Möchte man akzeptable Reaktionszeiten auf externe Ereignisse, so ist derartiges nur durch Hardwareinterrupts zu erreichen - mit giveio/porttalk geht das nicht. Das Verwenden von Hardwareinterrupts bedeutet im Grunde genommen, daß man einen Devicetreiber schreiben muss, was aufgrund der katastrophalen Dokumentation des DDK sehr problematisch ist und außerdem nur mit C/C++ möglich ist (meines Wissens nach hat sich noch keiner die Mühe gemacht, das DDK delphikonform aufzubereiten, bezweifle auch, daß das geht). Abhilfe versprechen hier kommerzielle Toolkits, wie sie beispielsweise von Firmen wie Kithara (www.kithara.de) angeboten werden, mit denen man auch aus Anwenderprogrammen (die auch in Delphi geschrieben sein dürfen) Interrupthandler und ähnliche Dinge veranstalten kann. Für präzisere Timer als in Millisekundenauflösung gibt es dort ein "Timer Plus Module", das Timerfrequenzen bis ca. 100 kHz ermöglichen soll. Leider sind derlei Toolkits so hochpreisig, daß sich ein privater nichtkommerzieller Einsatz im Grunde genommen verbietet. (Entwicklerversion des "Timer Plus Module" ohne Laufzeitlizenzen kostet bereits 650 EUR, mit zehn Laufzeitlizenzen sind's dann schon fast 1100 EUR) Kithara bietet immerhin Demoversionen (zeitlich beschränkt) zum Download an, und die Tatsache, daß das eine Firma aus Berlin ist, lässt hoffen, daß der Support besser ist, als der einer Firma aus Redmond ... Wäre interessant, ob mittlerweile derartige Funktionalität auch im OpenSource-Bereich zu finden ist ..
"Wäre interessant, ob mittlerweile derartige Funktionalität auch im OpenSource-Bereich zu finden ist .." Hi, genau das frage ich mich auch gerade. Es sollte sowas wie einen "allgemeinen Port-Treiber" geben dem man "sagen" kann daß er bei Eingang eines Interrupts am gewünschten Port den Scheduler veranlassen den diesen Port geöffentet haltend habenden (urg) Prozeß / bzw. Thread aufzurufen? D.h. es soll etwa sowas möglich sein: man "meldet" sein Programm bei Programmstart bei diesem "Treiber" an, übergibt die gewünschte Port-Nr., z.B. 378h, und wenn Daten am Port eingehen veranlaßt der Treiber daß in nullkommanix mein Thread aufgerufen wird, der sich dann um die Daten kümmern darf... damit das auch möglichst sofort geschieht könnte man die Priorität des Threads hoch setzen, und denn Thread nach Abarbeitung der Datenroutine über Sleeping oder Waiting Calls beenden oder? Das System soll ja möglichst wenig CPU-Last abgeben und "responsive" bleiben... Der Umweg über den Scheduler ist doch in jedem Fall nötig? Oder geht sowas evlt. direkt über eine Art Interrupt-Hooking, bzw. Manipulation in den Ebenen dahinter, d.h. statt des zugehörigen Gerätetreibers ruft das System meinen Programmcode auf...? Was bedeuten würde das ich sozusagen einen Port komplett "kapern" könnte und er dann nur noch mir gehört. (Es ist keine kommerzielle Anwendung um die es hier geht sondern ein Windows-Rechner soll für Meß- und Steueraufgaben eingesetzt werden... Geld für kommerzielle Lösungen ist nicht vorhanden) Grüße, Dierk
Sowas geht nicht. Interrupts werden von Hardwarebausteinen ausgelöst, wenn die von ihnen definierten Bedingungen erfüllt sind. Die PC-Hardware löst keine Interrupts aus, wenn auf irgendwelchen I/O-Ports irgendetwas geschieht, ebensowenig, wie sie das tut, wenn irgendwelche Speicherzellen sich ändern. Die Druckerschnittstellenhardware kann - potentiell - einen Interrupt auslösen (das ist i.d.R. IRQ 7), wenn die Hardwareregister der Schnittstelle entsprechend programmiert sind. Dazu empfiehlt es sich, die Dokumentation der Hardware der parallelen PC-Schnittstelle zu studieren. Andere Hardware (wie beispielsweise die serielle Schnittstelle) löst Interrupts aus, wenn sich Handshakeleitungen ändern oder wenn Zeichen empfangen/gesendet werden - näheres ist dem Datenblatt des 8250 oder nachfolgend (16550 etc.) zu entnehmen. Wie gesagt - ein universeller "Löse mir einen Interrupt aus, wenn sich ein Port ändert"-Treiber ist bereits aus Hardwaregründen gar nicht zu machen.
Ja gemeint waren nur Ports mit eigenem Hardware-Interrupt. "Die Druckerschnittstellenhardware kann - potentiell - einen Interrupt auslösen (das ist i.d.R. IRQ 7), wenn die Hardwareregister der Schnittstelle entsprechend programmiert sind. Dazu empfiehlt es sich, die Dokumentation der Hardware der parallelen PC-Schnittstelle zu studieren." Ok, danke, nun stellt sich die Frage: sind diese Register bei Windows XP durch den XP-Treiber des Parallelports nicht bereits sowieso gesetzt? Oder werden sie nur "bei Bedarf" gesetzt (von wem?), wenn z.B. ein Programm "offiziell" über Handle Daten rausschickt (wobei sich mir gleich die nächste Frage stellt: wieso brauche ich z.B. Porttalk, könnte man nicht den Windows-Gerätetreiber für den LPT direkt ansprechen, oder wäre das eine Ebene zu tief bzw. darf ein User-Mode Programm sowas gar nicht - meine Kenntnisse in der Systemprogrammierung sind halt leider noch etwas beschränkt)? Wenn ich z.B. einen Oszillator an ein Pin des Parallports anschließe, der mit z.b. ~ 6000 hz schwingt (die verbesserte Version wäre, man stellt die Frequenz über 2 Pins je nach Bedarf ein, z.B. in Stufen von 16384 Hz als Ausgangsfrequenz bis hinunter zu 1 Hz) - dann soll jedes mal ein Interrupt erzeugt werden, welcher dann das System bzw. den Scheduler oder was auch immer veranlassen soll, meinen Thread aufzurufen, der dann ein paar sehr kurze Berechnungen ausführt, evtl. Daten auf dem Port ausgiebt, und ansonsten sofort wieder die Kontrolle an andere Programme abgibt... Wo muß ich suchen, damit ich ein Tool bzw. die Source finde, was mir sowas erlaubt (zunächst einmal ohne selber einen Treiber entwickeln zu müssen), d.h. wenn ein Interrupt am LPT eingeht, mein Programm "unverzüglich" ausgeführt wird? Grüße, Dierk
Die Hardware der PC-Parallelschnittstelle löst üblicherweise gar keine Interrupts aus, auch wenn das konzeptionell vorgesehen ist. Da sie mittlerweile verschiedenste Betriebsarten (Standard, EPP und ECP) kennt, die teilweise sogar DMA-Betrieb zulassen, ist sie jedenfalls nicht mehr sonderlich trivial. Das einfache "Befummeln" à la giveio/porttalk geht jedenfalls von der Standardhardware aus, wie sie bereits im XT verbaut wurde. Um die Entwicklung eines eigenen Treibers kommst Du nicht umhin, vor allem nicht, wenn Du mit 6 kHz Takt auf Interrupts reagieren willst - oder Du kaufst Dir das Toolkit von Kithara (bzw. etwas äquivalentes). Um mit dem vorhandenen Parallelporttreiber zu kommunizieren, müsstest Du auch einen Devicetreiber verwenden - der Parallelport ist primär ein Ausgabeport und daher unterstützt der Treiber keinerlei Benachrichtigung über Gewackel an den Handshakeleitungen. Eine Schnittstelle, die tatsächlich Interrupts beim Gewackel an Leitungen auslösen kann, von dem man sogar im Usermode benachrichtigt wird, ist übrigens die serielle Schnittstelle - aber auch hier wird die Granularität des Schedulers nicht umgangen. Ein Thread, der Interesse an Statusänderungen einer Handshakeleitung angemeldet hat, wird vom Scheduler als nächstes aufgeweckt, wenn denn ein Ereignis (sprich: ein Hardwareinterupt) aufgelaufen ist - aber eben nicht unmittelbar. Usermodeprogramme (also auch Threads in selbigen) werden überhaupt nicht von Interrupts angesprochen; alles, was mit von Dir genannten Geschwindigkeiten geschieht, kann nur auf Devicetreiberebene (Kernelmode) abgehandelt werden. Das Kithara-Toolkit erlaubt es, Codeteile aus einem Usermode-Programm gewissermaßen im Kernelmode laufen zu lassen, so daß die veränderten Bedingungen für diesen zum Tragen kommen. Damit erspart man sich den Griff zum DDK und dessen hüstel knapper Dokumentation. Insgesamt sinnvoller scheint mir hier ein Überdenken des Grundkonzeptes - ein PC, auf dem ein aktuelles Windows läuft, ist schlichtweg ungeeignet für Steuerungsaufgaben, sofern es um kritische Timinganforderungen im einstelligen Millisekundenbereich oder gar drunter geht. Hier scheint mir ein Microcontroller zum Abhandeln des Timings angesagter, der über eine geeignete Schnittstelle - timingunkritisch - mit dem PC kommuniziert.
"Insgesamt sinnvoller scheint mir hier ein Überdenken des Grundkonzeptes - ein PC, auf dem ein aktuelles Windows läuft, ist schlichtweg ungeeignet für Steuerungsaufgaben, sofern es um kritische Timinganforderungen im einstelligen Millisekundenbereich oder gar drunter geht." Hi, laut Microsoft und Intel soll sich das ändern... http://www.intel.com/hardwaredesign/hpetspec.htm http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx?pf=true#img3 Wie teste ich, ob eine HPET auf meinem Motherboard bereits vorhanden ist (soweit ich weiß, wird die Hardware von noch nicht standardmäßig unterstützt, oder doch)? Oder ist das mit dem HPET nur ein Windei gewesen? Wenn man sich die Argumentation auf der Microsoftseite durchliest könnte man das fast glauben... "nicht unser Betriebssystem, sondern diese bösen Timer sind schuld" Grüße, Dierk
Hallo, ich benutze ebenfalls Inpout32, aber zur Ansteuerung eines LC-Displays. Mein Programm habe ich in VB geschrieben. Ich wollte das sich die Anzeige ständig aktualisiert. Die Anzeige braucht grob berechnet zum "anzeigen" der 4x20 Zeichen 10 ms. Pro Zeichen muss ich 3mal das "Out" verwenden. Und jedes nach jedem ein Delay setzen, damits die Anzeige verarbeiten mag. Unter VB gibts aber keine eigentliche Delay Funktion. Die von mir verwendeten Möglichkeiten sind entweder zu langsam, oder viel zu CPU-lastig. Wäre es schlauer mein Programm in C++ zu programmieren? Gruss THomas
@Thomas: das <a href=http://www.thescarms.com/vbasic/timer.asp>hier</a> dürfte dich interessieren... Was ich nicht verstehe, wieso willst du dein LDC alle 10 ms auffrischen? So schnell kann das eh kein Mensch lesen... und das LCD kann's nicht so schnell anzeigen. Du kriegst mit MMT Callbacks bestenfalls 1 ms hin, wenn drei portausgaben pro Zeichen notwendig sind, braucht es wohl 60 ms für 20 Zeichen... ist das zu langsam?
Hallo, ich wills nicht alle 10 ms auffrischen. Nach meinem Datenblatt sind 10ms schon möglich fürs display. dies wären 240ms für 40, also etwa 4mal die Sekunde Ich dachte so an 10mal die Sek, aber ich versuch das bestmögliche. Die Zeichen werden ja nacheinander ans Display geschickt. Ich möchte nur das es das Auge nicht sieht. Es soll so ausehen als ob die 80 Zeichen gleichzeitig erscheinen würden ! Danke für den link !
Hallo,
ich habe gesehen daß schon einige das Progrämmchen runtergezogen haben
deswegen gibt es jetzt eine verbesserte aber trotzdem schlechte Version
des Tools mit Source in meinem anderen Thread
>>Festplattenzugriffe unter Win98 "verhindern"<<
hallo euch Ich wollte gerne habe bei den programmen wie kann ich das offen Z.b Jpg das kann kucken aber diese programmen IGM3 kann nicht sehen das möchte ich programm habe und wie kann ich finden und konnte mich Informiert Grüsse an Vasja
Vasja, Dein Posting ist leider vollkommen unverständlich, auch kann ich keinen Bezug zum Thema des Threads erkennen. Vasja, your posting is completely undecipherable; I also can't discern any connection to this thread's subject.
Das nein will nicht das stecht etwas fehler ich weiss nicht wie weiter geht
Das wird nicht gerade besser. This isn't really improving.
Hi Leute, bei meinem Logikanalyser habe ich auch den Parallelport verwendet. Als Timer habe ich einen extra Tread eingerichtet, der pollt über Getperformancefrequency und getperformancefrequencycounter mit einigen usekunden genauigkeit. Ich such das mal raus... Die Zugriffsproblematik stellte sich seinerzeit nicht (Win98) Axel
habe ich auf Arbeit, aber prinzipiell hier auch gut erklärt: http://www.delphi-source.de/tipps/?id=53
Bitte 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.