Bei meinen bisherigen onboard-Parallelports und Parallelports auf ISA- oder PCI-Karten hatte ich bisher keine Problem und konnte die traditionell verwenden, wie z. B. unter https://web.archive.org/web/20121225013454/http://et.nmsu.edu/~etti/fall96/computer/printer/printer.html beschrieben. Es funktionerte auch über BIT5 vom Kontrollregister im bidirektionalen Modus die Datenpins mal als Eingänge und mal als Ausgänge zu verwenden, wobei sich natürlich TTL-Implementierungen (ISA) elektrisch etwas anders verhalten als CMOS-Implementierungen (PCI(e)). Aber mit PCIe-Karten funktioniert das nicht mehr, z. B. bei der Delock 89219 und auch der Conrad 1 Port Parallel PCI-Express-Karte, Artikel-Nr. 972542. Ebenso ist es bei dem onboard-Parallelport vom Esprimo E9900. Deshalb habe ich nach Fehlerursachen gesucht und gefunden das man im ECP's Extended Control Register (ECR) den Modus einstellen sollte ( http://retired.beyondlogic.org/spp/parallel.htm#11 ). Aber das Register liegt 0x400 über der Basisadresse, wo sich sowohl laut /proc/ioports als auch nach lspci -vvv nichts befindet. Sollte man trotzdem auf den Port Base +0x402 schreiben?
Gast
#4352855
Erwin M. schrieb: > Sollte man trotzdem Versuch macht klug. Man sollte sich erinnern, daß füher ein simpler PIO das Interface bedient hat und heute über PCI sich manches entwickelt hat.
Nicht ohne grund Missbraucht niemand mehr die Datenpins. Bzw wieso überhaupt noch LPT benutzen?
Warum wurschtelst du da überhaupt selbst an irgendwelchen Registern rum? Nimm doch den parport-Treiber.
> Sollte man trotzdem auf den Port Base +0x402 schreiben?
Der ISA Bus hat nur die unteren 10 bit ausdekodiert. Viele Interfaces
haben daher zur Registerdecodierung auch die oberen 6 bit verwendet.
Der Microsoft ECP Standard stammt noch aus ISA Zeiten. PCI decodiert
alles aus. Der einfachste Weg um herauszufinden, wie es funktioniert,
führt über die Datenblätter der verwendeten Chips. Dort wird es mit
Sicherheit drinstehen.
fchk
Rolf M. schrieb: > Warum wurschtelst du da überhaupt selbst an irgendwelchen Registern rum? > Nimm doch den parport-Treiber. Das mache ich doch, um die Basisadresse zu finden. Nur reicht das nicht.
Gast
#4353037
Erwin M. schrieb: > Das mache ich doch, um die Basisadresse zu finden. Die wird ja vom BIOS oder vom Betriebssystem zugewiesen, das ist keineswegs immer die gleiche. Du könntest ja 2 solche Karten reinstecken. Aber u.U. kann man sie im Treiber festlegen. Georg
Erwin M. schrieb: > Rolf M. schrieb: >> Warum wurschtelst du da überhaupt selbst an irgendwelchen Registern rum? >> Nimm doch den parport-Treiber. > > Das mache ich doch, um die Basisadresse zu finden. > Nur reicht das nicht. Wenn du den parport-Treiber nutzen würdest gäbe es für dich gar keine Basisadressen. Siehe z.B. http://mockmoon-cybernetics.ch/computer/linux/programming/parport.html und verwende "Full access via /dev/parportX" statt "Access via raw IO (not recommended)".
Rolf M. schrieb: > Erwin M. schrieb: >> Rolf M. schrieb: >>> Warum wurschtelst du da überhaupt selbst an irgendwelchen Registern rum? >>> Nimm doch den parport-Treiber. >> >> Das mache ich doch, um die Basisadresse zu finden. >> Nur reicht das nicht. > > Wenn du den parport-Treiber nutzen würdest gäbe es für dich gar keine > Basisadressen. > Siehe z.B. > http://mockmoon-cybernetics.ch/computer/linux/programming/parport.html > und verwende "Full access via /dev/parportX" statt "Access via raw IO > (not recommended)". Das hat aber einige Nachteile, neben erhöhter Latenz auch kein Einlesen aller Eingangs-Pins mit einem 16-Bit-Zugriff (inw()) oder Ausgeben mit einem 32-Bit-Zugriff (outl()).
Frank K. schrieb: > Der einfachste Weg um herauszufinden, wie es funktioniert, > führt über die Datenblätter der verwendeten Chips. Seitdem Moschip von Axis gekauft wurde, ist dieser Weg nicht so einfach. Und dort steht dann auch nicht viel drin. Laut dem Linux-Treiber hat der MCS9901 keine "hi"-Ports.
Update: Von Fujitsu kam die Antwort das der Parallelport beim E9900 tot ist; das es dazu eine onboard-Buchse gibt und und BIOS-Einstellungen ist ein Überbleisel ohne Funktion, so wie die Sachen zu Floppy. Immerhin funktionert die onboard-Buchse mit der zweiten seriellen Schnittstelle.
Also ich bin weitergekommen: Im Datenblatt vom OXPCIe952 ist beschrieben ein lower block von 8 Byte und ein upper block von 4 Byte und das der upper block beispielsweise 0x400 höher als der lower block liegt. Und cat /proc/ioports zeigt das beide bei den getesteten Karten null Abstand haben, d. h. der Beginn des upper block liegt 8 Byte, nicht 0x400, oberhalb vom Beginn des lower. Das müsste bei anderen Karten ähnlich sein, also der upper block meist nicht mit Offset 0x400, aber mit der inneren Struktur nach dem Standard.
Gast
#4358382
Erwin M. schrieb: > Also ich bin weitergekommen: Im Datenblatt vom OXPCIe952 ist beschrieben > ein lower block von 8 Byte und ein upper block von 4 Byte und das der > upper block beispielsweise 0x400 höher als der lower block liegt. > Und cat /proc/ioports zeigt das beide bei den getesteten Karten null > Abstand haben, d. h. der Beginn des upper block liegt 8 Byte, nicht > 0x400, oberhalb vom Beginn des lower. > Das müsste bei anderen Karten ähnlich sein, also der upper block meist > nicht mit Offset 0x400, aber mit der inneren Struktur nach dem Standard. Das bestimmt nicht die Karte sondern das BIOS. Es sind 2 getrennte Addressbereiche, die das BIOS beliebig zuweisen kann. Aber der Legacy Support lässt aber inzwischen etwas zu wünschen übrig. Im Gerätemanager von Windows 7 ist es eventuell möglich das von Hand einzustellen.
Lattice User schrieb: > Erwin M. schrieb: >> Das müsste bei anderen Karten ähnlich sein, also der upper block meist >> nicht mit Offset 0x400, aber mit der inneren Struktur nach dem Standard. > > Das bestimmt nicht die Karte sondern das BIOS. Es sind 2 getrennte > Addressbereiche, die das BIOS beliebig zuweisen kann. Aber der Legacy > Support lässt aber inzwischen etwas zu wünschen übrig. Dann ist kaum ein BIOS konform zum ECP-Standard. Aber eigentlich hätte man den Standard flexibler machen können, an die Realität anpassen können.
Gast
#4359280
Erwin M. schrieb: > Lattice User schrieb: >> Erwin M. schrieb: >>> Das müsste bei anderen Karten ähnlich sein, also der upper block meist >>> nicht mit Offset 0x400, aber mit der inneren Struktur nach dem Standard. >> >> Das bestimmt nicht die Karte sondern das BIOS. Es sind 2 getrennte >> Addressbereiche, die das BIOS beliebig zuweisen kann. Aber der Legacy >> Support lässt aber inzwischen etwas zu wünschen übrig. > > Dann ist kaum ein BIOS konform zum ECP-Standard. Aber eigentlich hätte > man den Standard flexibler machen können, an die Realität anpassen > können. Laut dem OXPCIe952 Datasheet ist beim Parallelport Funktion der Classcode = 0x070102. Das ist laut PCI 3.0 Spec ein "ECP 1.X compliant parallel port" . Allerdings kann der Kartenhersteller das per EEProm überschreiben, ist also möglicherweise falsch. Mal im Windowsgerätemanager bei Defaults->Hardware Ids nachschauen. Da müsste ein CC_070102 auftauchen.
Lattice User schrieb: > Allerdings kann der Kartenhersteller das per EEProm überschreiben, ist > also möglicherweise falsch. Mal im Windowsgerätemanager bei > Defaults->Hardware Ids nachschauen. Da müsste ein CC_070102 auftauchen. Ja, aber viele Hersteller verwenden kein EEProm, beispielsweise bei der Delock 89219: http://cdn-reichelt.de/bilder/web/xxl_ws/E600/DELOCK_89219_2.png http://www.kosatec.de/images/xl/620040.jpg Der Platz für das EEPROM, neben dem Controller-Chip, ist unbestückt, so wie auch die Plätze für die beiden Seriellen Schnittstellen. Unter Linux wird die Karte erkannt als Parallel controller, driver parport_pc.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.