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
externer 10kHz takt und ein eingangsregister dass die daten im takt übernimmt? dann wär die abtastung dazwischen recht timing-unkritisch..
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
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.