mikrocontroller.net

Forum: PC-Programmierung Parallel Port (lpt1) lesen per DMA


Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte mit einem PC (Windows XP) 8 Eingänge einlesen. Dazu bietet 
sich natürlich der parallele Port an. Das klingt zunächst nach 
inpout32.dll. Aber die Sache hat einen Haken: Ich möchte die Eingänge zu 
genau definierten regelmäßigen Zeitpunkten lesen, genauer gesagt mit 
einer Frequenz von 10kHz. Dadurch kann ich Zeiten mit einer Genauigkeit 
von 0.1ms messen. Wenn ich aber den Port mit _inp auslese, habe ich 
keine Kontrolle darüber, wann der Wert tatsächlich übernommen wird. Das 
ist eben Software Timing.

Ich dachte mir daher, man könnte den ECP Modus gewinnbringend für ein 
Hardware Timing einsetzen, Handshake siehe zum Beispiel hier:

http://www.beyondlogic.org/ecp/ecp.htm

Die Idee ist, dass man den ECP Reverse Data Cycle implementiert. Der PC 
leitet dabei per nReverseRequest einen Lesezyklus ein. Die Schaltung 
würde dieses Signal einfach wieder in nAckReverse einspeisen. PeriphACK 
kann man konstant auf high legen. Der eigentliche Trick jedoch ist, an 
PeriphClk einen konstanten 10kHz Takt anzulegen. Mit jeder positiven 
Flanke werden die Daten eingelesen, jedenfalls so lange, wie die 
Schnittstelle einliest. Da die Daten im ECP Modus per DMA eingelesen 
werden, sollte der Rechner keine Mühe haben, mit den 10kHz mitzuhalten.

Die Frage ist nun, wie sieht das mit der Software aus? Ich dachte 
eigentlich mit CreateFile("LPT1") und ReadFile wäre die Sache geritzt. 
Aber ich habe gelesen, dass ReadFile am parallelen Port nicht 
implementiert ist. Diese Funktionalität fehlt anscheinend in parport.sys 
ganz einfach! Ich habe es noch nicht ausprobiert, da ich die Hardware 
noch nicht aufgebaut habe, aber ich habe das jetzt schon mehrfach im 
Internet gelesen.

Was habe ich sonst noch für Möglichkeiten, die DMA-Fähigkeiten des 
parallelen Ports für's Einlesen zu verwenden? Ich wollte eigentlich 
nicht einen eigenen Druckertreiber schreiben. Das Problem muss ja schon 
uralt sein, hat da nicht jemand eine Lösung? Es geht ja nur darum, Daten 
vom parallelen Port einzulesen, nichts Spezielles.

Nur zum Vergleich: Die günstigste Lösung von National Instruments für 
Datenakquisition auf 8 Leitungen mit Hardware Timing kostet 749 Euro. 
Dazu ein Kabel für 119 Euro und ein Schraubklemmenblock für 149 Euro. 
Das muss doch billiger gehen!

Vielen Dank im voraus für jegliche Hilfe!

Schöne Grüße,
Marcus

Autor: Mars (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Warum muss es gerade der Parallel Port sein? Wie du bereits geschrieben 
hast ist der Zugriff auf die LPT alles andere als einfach und auf 
neueren Systemen ist diese Schnittstelle auch nicht mehr vorhanden.
Mit dem FTDI FT2232 sollte sich dein Problem relativ leicht und 
kostengünstig lösen lassen.

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Nullahn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für genaues Timing kannst du Windows normalerweise vergessen.

Aber die Druckerschnittstelle kann auch externen Interrupt.

Besser mit uC Messen und dann reinholen.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mars,

danke für Deine Antwort. Tja, warum gerade der Parallelport? Naja, 
vielleicht bin ich auch einfach zu sehr ein Pfennigfuchser. Ich denke 
mir halt, da ist ja schon die ganze Hardware da, alles was ich noch 
brauche ist ein konstanter Takt. Da widerstrebt es mir irgendwie, 
zusätzliche Hardware zu bauen. Dein Tip ist nicht schlecht, ich habe mir 
mal das Datenblatt angeschaut. Trotzdem bin ich mir skeptisch, ob ich 
mir das antun will. Ich hatte halt gehofft, dass das Einlesen vom 
Parallel Port ja sicherlich schon gelöst ist. Dann wäre es echt super 
einfach.

Auf dem in Frage kommenden System ist der Parallel Port übrigens 
vorhanden.

Schöne Grüße,
Marcus

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sabine,

danke für den Link, darüber bin ich auch schon gestolpert. Einen eigenen 
Treiber entwickeln ist zwar mehr als ich mir antun wollte, aber mit 
diesem Tool könnte es vielleicht gehen. Ich werde es mir noch mal 
genauer ansehen.

Schöne Grüße,
Marcus

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternative: Microcontroller => Seriell/USB => PC

Autor: max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
externer 10kHz takt und ein eingangsregister dass die daten im takt 
übernimmt? dann wär die abtastung dazwischen recht timing-unkritisch..

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Nullahn,

auch Dir vielen Dank für Deine Antwort. Wenn ich externe Interrupts 
verwende, zu welchem Zeitpunkt werden dann die Daten übernommen? Erst 
wenn der Interrupt behandelt wird, oder bereits bei der Flanke?

Schöne Grüße,
Marcus

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das macht ohne Puffer alles keinen Sinn, weil Windows kein Echtzeit-OS 
ist, und eine beliebig lange Zeit vergehen kann, bis der wieder mal den 
Parallel-Port abfragt. Konstante Abtastung erfordert mit Windows und 
Linux ohne Echtzeit-Erweiterungen eine externe Hardware mit Puffer. Da 
kommt man nicht dran vorbei.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

der Parallel Port hat im ECP Modus eine FIFO mit 16 Bytes. Bei einem 
Takt von 10kHz muss dieser Puffer also nur alle 1.6ms ausgelesen werden. 
Darüber hinaus hat der Parallel Port aber auch einen DMA Kanal. Das 
heißt, die CPU muss eigentlich überhaupt keine Bytes auslesen.

Vielleicht verstehe ich da auch was falsch. In meinem System wird die 
Parallele Schnittstelle von einem Winbond W83627HG implementiert. Im 
Prinzip ist das doch wie eine externe Hardware, nur dass sie nicht 
extern ist. Der FTDI FT2232 macht ja im Prinzip auch nichts anderes, nur 
dass er sich bereits selbst einen Takt liefern kann.

Schöne Grüße,
Marcus

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar kannst du das im DMA versuchen, aber es kann trotzdem passieren, 
dass du was verlierst, weil ja der DMA Transfer auch immer erst mal 
angestoßen werden muss, und es nur einen einzigen Arbeitsspeicher gibt, 
den Bus dahin müssen sich ja alle DMA TRansfers und sonstigen 
Speicherzugriffe teilen. Wir haben PCI-Messkarten, die per DMA ihre 
Daten in den RAM schaufeln können, selbst die kann Windows sekundenlang 
lahmlegen, wenn es gerade denkt, mal irgendwas anderes zu tun zu haben. 
Wenn dann müsstest du schon einen Burst-Read DMA Transfer machen, aber 
eine garantierte kontinuierliche Abtastung alle 1.6ms wird so gut wie 
unmöglich im Windows. Aus dem Userspace sowieso.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

vielen Dank für Deine Antwort! Ok, ich glaube, ich sehe jetzt, wo ich 
meinen Denkfehler gemacht habe: Ich habe mir das ECP Handshake 
angeschaut und nur gesehen, dass bei positiver Flanke die Daten 
übernommen werden. Was ich aber übersehen habe ist, dass ohne einem 
nReverseRequest gar nichts läuft. Ich dachte, der Port ist bis 2.5MHz 
spezifiziert, da sind 10kHz ja völlig unkritisch. Aber wenn der DMA 
Transfer hängt, kommt das nReverseRequest natürlich gar nie und dann 
wird auch nichts eingelesen. Mit anderen Worten: Es wird zwar oft 
funktionieren, aber ich habe keine Garantie, dass es immer funktioniert.

Wie läuft denn das mit der USB Schnittstelle? Wenn ich den Vorschlag von 
Mars umsetze und den FTDI FT2232 verwende, der hat ja auch keinen Puffer 
drin. Er schickt die Daten ja über die USB-Schnittstelle zum Rechner. 
Wie ist denn da sichergestellt, dass nichts verloren geht?

Schöne Grüße,
Marcus

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, der FTDI hat schon einen 128 Byte großen FIFO drin, das würde 
schon helfen, muss man halt dann immer sehen. Aber garantieren kann 
man es unter Windows/Linux nie, es sei denn, man baut eine 
Echtzeiterweiterung ein, was aber recht aufwendig ist, da die für harte 
Echtzeit im Kernel sitzen muss. Mit dem normalen Windows/Linux kannst du 
nicht mal eine Antwortzeit von 4 Wochen garantieren um es mal 
überspitzt auszudrücken.
Mit einem ausreichend großen Puffer und kontrollierten Randbedingungen 
klappts aber in den meisten Fällen. Es sollten nur keine kritischen 
Prozesse davon abhängen....

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Naja, der FTDI hat schon einen 128 Byte großen FIFO drin, das würde
>schon helfen, muss man halt dann immer sehen. Aber garantieren kann
>man es unter Windows/Linux nie
Erzähl doch keinen Blödsinn. Ein 10 khz Signal kann von jedem 
Multitaskingbetriebsystem problemlos verarbeitet werden, wenn eine 
externe Fifo die Signalkette puffert.

@Marcus
Du brauchst bloss eine externe Fifo mit 2 Stufen Tiefe, dann kannst du 
das Signal ohne Komplikationen vom Lpt-Port runterlesen. Auch ohne den 
Hardware-Handshake (ECP) beträgt die Samplingrate noch zwischen 
70-300khz. (i.d.R. sind es um die 200khz)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf wrote:
>>Naja, der FTDI hat schon einen 128 Byte großen FIFO drin, das würde
>>schon helfen, muss man halt dann immer sehen. Aber garantieren kann
>>man es unter Windows/Linux nie
> Erzähl doch keinen Blödsinn. Ein 10 khz Signal kann von jedem
> Multitaskingbetriebsystem problemlos verarbeitet werden, wenn eine
> externe Fifo die Signalkette puffert.

Soso, du scheinst dich ja gut auszukennen, was mit 
nicht-echtzeit-fähigen Betriebssystemen möglich ist. Wir haben hier ein 
Messgerät mit USB HighSpeed und externem FIFO mit 128 kByte und trotzdem 
hat man immer mal Lücken in der Übertragung, weil Windows gerade 
irgendwas anderes macht, als Daten vom USB abzuholen. Das kannst du mit 
jeder Schnittstelle provozieren.

Ich sagte ja, mit externem Puffer ist das möglich, aber garantieren 
kannst du es trotzdem nicht. Deswegen nicht für kritische Sachen 
geeignet.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine schriftliche Garantie mit Brief, Siegel und von Ballmer eigenhändig 
unterschriebenem unbegrenztem Haftungsversprechen kriegst du bei 
Microsoft wahrscheinlich nicht einmal dafür dass es überhaupt was tut 
ausser Geld kosten. Hängt ein bischen davon ab, was man hier unter 
"garantieren" versteht, denn mit Priorisierung lässt sich schon was 
machen.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>weil Windows gerade
>irgendwas anderes macht, als Daten vom USB abzuholen. Das kannst du mit
>jeder Schnittstelle provozieren.

Wenn es sauber entwickelt ist, darf es nicht reproduzierbar sein. 
Überhaupt gibt es bei USB unterschiedliche Protokollanforderungen. Wenn 
du Aussetzer hast, ist entweder dein Puffer zu klein, das Protokoll 
schlecht (z.B kein Bulk/Iso) oder die Priorität des USB-Devices wird von 
Windows als zu niedrig eingeschätzt. (Dann ist es vom Hersteller falsch 
konfiguriert worden.)

>Ich sagte ja, mit externem Puffer ist das möglich, aber garantieren
>kannst du es trotzdem nicht. Deswegen nicht für kritische Sachen
>geeignet.

So wie du argumentierst müsste es häufiger zu Aussetzern bei Sound, 
Video und überhaupt jedweder Peripherie kommen. Das ist aber nicht der 
Fall. (Wäre auch schlecht wenn, denn es wäre Datenverlust.) Ein 
Betriebsystem wie Winodws arbeitet alle Threads in einem Bruchteil von 1 
ms ab.
Das Problem von Aussetzern ist vorallem schlechte Treiber- bzw. 
Hardwareinteraktion. Z.b. wenn eine Karte mehr Buszeit für sich 
verwendet als ihr das Betriebssystem zugesteht, denn dann kann der Rest, 
der am Bus mit dranhängt, nicht mehr reagieren. (Ein Beispiel unter 
Vielen)

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf wrote:
>>weil Windows gerade
>>irgendwas anderes macht, als Daten vom USB abzuholen. Das kannst du mit
>>jeder Schnittstelle provozieren.
>
> Wenn es sauber entwickelt ist, darf es nicht reproduzierbar sein.
> Überhaupt gibt es bei USB unterschiedliche Protokollanforderungen. Wenn
> du Aussetzer hast, ist entweder dein Puffer zu klein, das Protokoll
> schlecht (z.B kein Bulk/Iso) oder die Priorität des USB-Devices wird von
> Windows als zu niedrig eingeschätzt. (Dann ist es vom Hersteller falsch
> konfiguriert worden.)

Ist ein FX2 USB HighSpeed Controller von Cypress, mit 128kByte FIFO 
zusätzlich davor. Es liegt aber nicht an der Hardware, auch kann man da 
keine Prioritäten vergeben. BULK Transfer wird vom OS halt abgehandelt, 
wenn sonst nix auf dem Bus los ist, deshalb kann eine bestimmte 
Übertragungsgeschwindigkeit nicht garantiert werden, wie etwa bei ISO. 
Dafür gibts aber das Handshake und die Aussetzer stören durch den großen 
Puffer nicht. Im Mittel erreiche ich 40MByte/s, aber eben mit Lücken. 
Ist ja kein Daternverlust, sondern nur eine Übertragungslücke.


> So wie du argumentierst müsste es häufiger zu Aussetzern bei Sound,
> Video und überhaupt jedweder Peripherie kommen. Das ist aber nicht der
> Fall. (Wäre auch schlecht wenn, denn es wäre Datenverlust.)

Soso, dann schau dir mal die Statistik bei einem Direct-Show-Filter oder 
WebCam oder so an, da wirst du sehen, dass da immer mal einige Frames 
verloren gehen, siehst du ja aber nicht. Alles was Iso-Streaming macht, 
kann zwar eine konstante Bandbreite garantieren, dafür aber keine 
Datensicherheit...was weg ist, ist weg. Lass mal irgendwelche Software 
laufen, die den Prozessor extrem belastet und schau dann mal, ob den 
Video noch ruckelfrei läuft.

Wo es auf Integrität der Daten ankommt, gibts Handshake, dann aber 
wieder mit der Möglichkeit der Pausierung.

> Das Problem von Aussetzern ist vorallem schlechte Treiber- bzw.
> Hardwareinteraktion. Z.b. wenn eine Karte mehr Buszeit für sich
> verwendet als ihr das Betriebssystem zugesteht, denn dann kann der Rest,
> der am Bus mit dranhängt, nicht mehr reagieren. (Ein Beispiel unter
> Vielen)

Standard-Windows und Standard-Linux sind nun mal nicht echtzeitfähig, 
dafür gibts eine klare Definition. Wenn man Randbedingungen einhält und 
den PC wenig belastet, kann man sicherlich 10kHz an der 
LPT-Schnittstelle einlesen, aber z.B. eine Maschinensteuerung, bei der 
kritische Prozesse passieren können, wenn der Datenstrom abreißt, dürfte 
man damit nicht bauen. Wenn das so schön wäre, bräuchte man ja keine 
teuren und komplizierten Echtzeit-Erweiterungen für Windows.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte nicht gleich alles in einen Topf werfen. In der Frage und dem 
letzten Beitrag haben sich insgesamt 3 recht unterschiedliche Fälle 
angesammelt, wurden aber kollektiv alle verdammt:

1: Alle 100µs ein Byte von der parallelen Schnittstelle (die 10KHz). 
Wenn man das per DMA hinkriegt hat man Chancen das zuverlässig 
hinzubekommen, sonst sind die Echtzeitanforderungen etwas hart.

2: 40MB/s via USB. Da befindet man sich an der Grenze von USB. Dass dies 
ab und zu mal einbricht finde ich wenig erstaunlich. Hatte Intel beim 
Design nicht so im Auge gehabt, zumal Intel gern mal Dinge in den 
Prozessor verlagert, die man auch autark machen könnte. Immerhin leben 
die davon.

3: 10KB/s via USB. Ein winziger Bruchteil des eben genannten. Da sehe 
ich in normalem Windows recht gute Chancen, das unterbrechungsfrei 
hinzubekommen. Man sollte vielleicht darauf verzichten, über den 
gleichen USB-Komplex nebenbei eine Festplatte oder ähnlich schnellen 
Kram zu betreiben.

Echtzeit ist nicht gleich Echtzeit. Es hängt von den Forderungen ab. 
Linux und Windows sind für Reaktionszeiten im Mikrosekundenbereich 
ungeeignet. Aber bei 10KB/s und 100 Bytes Puffer passiert nur noch alle 
10ms was, und auch das nur im USB-Treiber, nicht im Anwendungsprozess. 
Im diesem Zeitbereich sieht das weit besser aus. Nicht nur wenn 
isochron, aber dann ziemlich sicher, denn sonst wäre jeder 
USB-Lautsprecher unmöglich.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich möchte mich bei allen, die sich an der Diskussion beteiligt haben, 
bedanken. Alle Beiträge haben mich weitergebracht und ich habe viel 
gelernt. Ich denke, ich weiß jetzt, wie ich weitermachen muss.

Schöne Grüße,
Marcus

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.