Autor Thema: Parallelport mit DMA hereinlesen  (Gelesen 9385 mal)

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« am: 06. November 2018, 14:17 »
Hallo,

ist es möglich die Inhalte der Parallelport-Register (Statusbyte/Steuerbyte) direkt über DMA einzulesen, oder geht das grundsätzlich nur über die Portadressen?

THX

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 25. December 2018, 17:05 »
Meines Wissens geht das nur über die Ports, nicht mit DMA.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 02. January 2019, 22:38 »
Zumindest für ECP-fähige Parallelports sollte es gehen:
Zitat von: Wikipedia:en/Parallel_port
The Extended Capability Port (ECP) is essentially an entirely new port in the same physical housing that also adds direct memory access based on ISA and run-length encoding to compress the data, which is especially useful when transferring simple images like faxes or black-and-white scanned images. ECP offers performance up to 2.5 MByte/s in both directions.

In halbwegs modernen PCI-Chipsätzen könnten die Register auch ein MMIO-Mapping haben. Das sollte dann im Datenblatt der Southbridge stehen (vielleicht steht das auch in den ACPI-Tabellen, aber das weiß ich nicht). Aber dann sind die Ports vermutlich auch ECP.

Klassische Parallelports (SPP) haben kein MMIO-Mapping und damit für den DMA-Controller nicht ansprechbar.

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 31. January 2019, 09:19 »
Hi,

danke erstmal für die Antworten.  :-)
Eigentlich geht es mir nicht direkt um den Parallelport. Es ist nur so dass digital i/o-Karten oft genau diesen Baustein benutzen. Aber es scheint so dass dieses Problem eher nicht zu existieren, da
diese Karten ein MMIO nicht unterstützen. Oder taeusche ich mich da.?
Wenn man sehr schnell viele Ports lesen muss, schafft kann halt kaum hohe Abtastfrequenzen.

Thx TomCat

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 31. January 2019, 09:30 »
Es ist nur so dass digital i/o-Karten oft genau diesen Baustein benutzen. Aber es scheint so dass dieses Problem eher nicht zu existieren, da diese Karten ein MMIO nicht unterstützen.
Das hängt schlicht davon ab, wie die Karten verdrahtet sind. Für MMIO muss der Karte ein Speicherbereich zugeordnet sein.

Bei ISA-Karten kann man das meist direkt sehen (oder anhand der Jumper erraten), bei PCI(e)-Karten kann man einfach nachschauen:
$ lspci -v
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
        Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Flags: bus master, fast devsel, latency 0, IRQ 16
        I/O ports at d000 [size=256]
        Memory at ef404000 (64-bit, non-prefetchable) [size=4K]
        Memory at ef400000 (64-bit, non-prefetchable) [size=16K]

        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169


Wobei das für MMIO nur notwendig ist, aber nicht hinreichend.

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 31. January 2019, 11:27 »
Danke,

ich habe grad eben mal eine PCI-Parallelportkarte eingebaut, und mir über PCIVIEW.EXE angeschaut.
Da bekomme ich folgende Daten:

Device Code          :   Parallel Controller
ID                        :   Vendor = 1415H    Device = 8403H
Resources             :  [I/O]  [Memory]

   I/O Address       :   0000DC00H  0000D880H   0000D800H
 Memory Address  :   F7FFF000H
   Interrupt           :   IRQ10             

Wenn jetzt die Adress 0000DC00H nehme kann ich auf die 3 Register(DatenByte, Druckerbyte, Steuerbyte)
zugreifen. Also mit in /out Assembler-Befehlen.
Das geht halt relativ langsam.

Was hat es mit dieser Memory Address auf sich?

Ich möchte noch dazusagen, dass ich im UNREAL-Mode bin, d.h. auch auf den 32-Bitadress-Raum zugreifen kann.

THX
TomCat
« Letzte Änderung: 31. January 2019, 11:32 von TomCat »

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 31. January 2019, 19:52 »
Was hat es mit dieser Memory Address auf sich?
Mit ein bisschen Glück hast du dort die gleichen Register memory-mapped nochmal. :-)

Die Karte scheint ECP-fähig zu sein und wird von Linux direkt unterstützt. Ich habe dort mal kurz in den Code reingeschaut, und das parport_pc-Modul kann auch DMA, wenn der Port dazu fähig ist.

Das heißt, dass du sowohl MMIO als auch DMA mit diesem Port machen können solltest.

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 01. February 2019, 09:43 »
Zitat
Mit ein bisschen Glück hast du dort die gleichen Register memory-mapped nochmal. :-)

Ich habe im Moment nur 2GB im PC. Die Adress-Angabe ist aber mit F7FFF000H sehr hoch.
d.h. hier ist physikalisch gar kein Speicher mehr vorhanden.
Wie ist das dann zu verstehen?


Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 02. February 2019, 00:59 »
Gegenfrage: Was ist MMIO eigentlich?

Antwort: Das ist am Speicherbus angeschlossene Hardware. Die Verhält sich ungefähr so wie RAM (aber mit anderem Timing), aber ist kein RAM.

Logischerweise können MMIO-Geräte nicht die gleichen Adressen benutzen wie der verbaute RAM, denn sonst würden bei einem Zugriff mehrere Chips gleichzeitig aktiv sein und sich gegenseitig stören. Der PCI-Hostcontroller mappt die Geräte also irgendwo in den Adressraum, wo kein RAM ist. Für die Software ist das aber dasselbe.

Port I/O ist eine Spezialität von x86 (und den Vorgängern und Kompatiblen) - die meisten Architekturen kennen sowas überhaupt nicht. Dort nutzt grundsätzlich sämtliche Hardware MMIO, erscheint also der Software gegenüber wie Speicher.

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 02. February 2019, 12:23 »
Mit diesem Port i/o war ich nie gluecklich. Beim 286 er mag das wohl schnell gewesen sein. Aber bei den heutigen Prozessoren hat man das Gefuehl, es haette jemand die Bremse reingehauen. Was anderes noch : Meine Grafikkarte wird auch im hohen 32 bit Speicherbereich eingemappt. Etwa so ab adresse 4 Mrd. Was ist, wenn ich im unrealmode 4GB physikalischen Speicher zur Verfuegung habe.  Wie geht das dann, ich meine, es waere ja dann keine Adressen mehr fuer das Mapping vorhanden??

Thx TomCat

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 03. February 2019, 19:18 »
Beim 286 er mag das wohl schnell gewesen sein. Aber bei den heutigen Prozessoren hat man das Gefuehl, es haette jemand die Bremse reingehauen.
Port I/O hat keine Caches, keine Cache-Invalidierungsstrategien, kein Access Reordering, kein Coalescing etc, dafür ist es synchron. Logisch ist es aus heutiger Sicht langsam, aber dafür ist es eine Legacy-Schnittstelle und interessiert niemanden mehr.

Was ist, wenn ich im unrealmode 4GB physikalischen Speicher zur Verfuegung habe.  Wie geht das dann, ich meine, es waere ja dann keine Adressen mehr fuer das Mapping vorhanden??
Stichwort "Memory Hole". Eine 8 Bit ISA-Karte kann 1 MB adressieren (darum gibt es zwischen 640 KB und 1 MB ein Loch); eine 16 Bit ISA-Karte kann 16 MB adressieren (darum hat man bei alten BIOSen zwischen 15 MB und 16 MB ein Loch); eine PCI-Karte kann nur 4 GB adressieren, also macht man da das gleiche.

Wenn du 8 GB RAM hast, dann wirst du nur 3 GB oder 3.5 GB nutzen können, dann kommen die Speicherbereiche der PCI-Karten, und erst dann kommt der restliche Speicher. Das siehst du, wenn du ein 32 Bit-Windows auf einem System mit 4 GB RAM oder mehr installierst.

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 04. February 2019, 10:59 »
Danke für die Antwort,


Device Code          :   Parallel Controller
ID                        :   Vendor = 1415H    Device = 8403H
Resources             :  [I/O]  [Memory]

   I/O Address       :   0000DC00H  0000D880H   0000D800H
 Memory Address  :   F7FFF000H
   Interrupt           :   IRQ10           

ich habe mal versucht einfach das Status/Steuerbyte über die Memory Address zu lesen. Also einfach
F7FFF000h + 1 für das Statusbyte.
Das funktioniert gar nicht. :-(

Wie kommt man denn mit Memoryzugriff statt Port-IO auf die Inputs?

Thx
TomCat         
« Letzte Änderung: 04. February 2019, 13:16 von TomCat »

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 04. February 2019, 23:23 »
Wie kommt man denn mit Memoryzugriff statt Port-IO auf die Inputs
Ich habe keine Ahnung. :-D

Vielleicht sind die Register mit einem Offset gemappt, vielleicht sind die Register nur mit der passenden Zugriffsbreite (8/16/32 Bit) zugreifbar, vielleicht geht es auch überhaupt nicht. Keine Ahnung. Kurzes Googeln fördert auch keine "üblichen" MMIO-Zugriffsmuster für den Parallelport zutage.

Längliches Googeln findet Dokumentation zu den EPP/ECP-Modi. Das läuft alles darauf hinaus, dass der Parallelport das Handshaking selbst macht und damit deutlich schneller betrieben werden kann als mit dem klassischen "Daten schreiben, Strobe aktivieren, Warten, Strobe deaktivieren"-Zyklus. Es geht also nicht darum, einen Logikanalysator damit zu bauen. DMA-Zugriffe auf die klassischen Register sind scheinbar nicht vorgesehen, sondern man nutzt für DMA die ECP-Register (Offset 0x400), wo ein FIFO dahinter steht. Angeblich bekommt man dadurch starken Jitter (unregelmäßiges Timing). Nur ECP-Ports sind DMA-fähig. Ferner scheint ISA-DMA immer auf 4.77 MHz festgenagelt zu sein, weswegen man z.B. IDE nicht mit ISA-DMA benutzt, sondern entweder mit PIO-Zugriffen oder Busmaster-DMA.

Ich weiß ja nicht, was du genau vorhast... aber vermutlich kommst du weiter, wenn du einen Mikrocontroller mit dem Auslesen eines GPIO-Ports beauftragst und ihn dann über eine andere Schnittstelle rausschicken lässt. Ein Atmega32U4 kann USB Full-Speed und harte Echtzeit. Ein STM32 oder anderer ARM ist zwar nur eingeschränkt 5V-kompatibel, hat aber mehr RAM.

Viel mehr dürfte es dazu nicht zu sagen geben, glaube ich. :-)
« Letzte Änderung: 04. February 2019, 23:26 von Svenska »

TomCat

  • Beiträge: 35
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 07. February 2019, 09:58 »
Hi,

danke für die Antworten.  :-)

Mein eigentliches Problem ist, dass ich in auf einem PC (IA32) ohne Betriebssystem !, keine Lösung habe wie ich schnell Daten von externen Geräten einlesen kann.
Ausser diese langsame Port IO.  Ich bin so zwar extrem schnel was interne Kalkulationen anbelangt, aber wie bekomme ich schnell Daten in den PC??

Gibt es da andere Möglichkeiten?

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 07. February 2019, 22:22 »
Ausser diese langsame Port IO.
Das Port I/O ist vermutlich nicht deine Bremse, sondern die daran angeschlossene Hardware (d.h. der Parallelport selbst).

Gibt es da andere Möglichkeiten?
Es gibt drei klassische PC-Schnittstellen: Parallelport (maximal 2.5 MB/s mit abgestimmter Hardware), serielle Schnittstelle (maximal 115.200 Bit/s entsprechend 11.52 KB/s) und Gameport (vier digitale Eingänge, so schnell wie der Parallelport; vier 8~10 Bit-Analogeingänge, sehr umständlich). Dazu kommen noch die Floppy-Schnittstelle (500 KBit/s für HD-fähige Controller) und die IDE-Schnittstelle (maximal 8~16 MB/s). Der ISA-Bus, über den sämtliche Geräte mit der CPU kommunizieren, schafft maximal 16 MB/s - für das gesamte System zusammen.

Die PC-Plattform ist trotz ihrer Erweiterungen bis vor ein paar Jahren ziemlich kompatibel zum PC/AT geblieben - also grob dem Stand von ungefähr 1985. Seitdem haben sich Betriebssysteme durchgesetzt, die Hardware halbwegs sinnvoll abstrahieren können und daher keine Kompatiblität auf unterster Ebene mehr brauchen.

Heißt konkret: Wenn du schnellere Schnittstellen benutzen möchtest (z.B. Ethernet, USB, Firewire oder SCSI), dann musst du dir die Treiber dafür selbst schreiben. Diese Treiber sind abhängig von der konkreten Hardware, die du in deinem PC stecken hast (Netzwerkchip, USB-Controller, etc.). Dafür bekommst du ordentliches Busmaster-DMA (wenn die Hardware das kann) und höheren Datendurchsatz.

 

Einloggen