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
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.
Für genaues Timing kannst du Windows normalerweise vergessen.
Aber die Druckerschnittstelle kann auch externen Interrupt.
Besser mit uC Messen und dann reinholen.
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
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
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
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.
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
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.
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
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....
>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)
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.
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.
>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)
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.
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.
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
