mikrocontroller.net

Forum: PC-Programmierung ECP unter Windows XP - inpout32.dll will nicht


Autor: Dierk (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dierk (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann mich Joline nur anschließen. Schneller als mit Delphi kommt man
nicht zu seinem Ziel, wenn man nicht gerade treiber programmieren will.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/skedgra...

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ..

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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....

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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Dierk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"<<

Autor: Vasja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Vasja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das nein will nicht das stecht etwas fehler ich weiss nicht wie weiter
geht

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wird nicht gerade besser.

This isn't really improving.

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe ich auf Arbeit, aber prinzipiell hier auch gut erklärt:
http://www.delphi-source.de/tipps/?id=53

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.