Treiber für schnelle Parallele Schnittstellen

[Mario (Gast)]

Wie implementiert man einen IRQ fähigen Treiber für schnelle parallele 
Schnittstellen. z.B für LCD Displays mit Hitachi Ctrl, für die Centronix 
- Schnittstelle etc.

Mir fällt nur ein
 - mit dem Ack Signal einen IRQ auslösen: ggf hohe IRQ Last
 - alle 1-x ms IRQ Auslösen und hoffen daß die Gegenseite READY ist
   wenn nein in 1-x ms nochmal fragen

Gibt es besseres? Wie war das etwa bei MS, bei LINUX implementiert, als 
eben noch die parallele Schnittstelle (Centronix) gab ?

Mario

[Martin B. (martin_b35)]

Ich würd sagen..

Zieh dir den Kernelsource von kernel.org, also z.B. 
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.tar.bz2

Dadrin findest du auch den Code vom parport-Treiber.

Gruß,
    Martin

[Rufus Τ. F. (rufus)]

Die parallele Schnittstelle ("Centronics" mit "cs", nicht mit "x") 
kannte in ihren letzten Zuckungen auch Hardwareunterstützung für 
schnellere Datenübertragung, das wurde mit den erweiterten Betriebsarten 
ECP und EEP eingeführt.

Überblick & Links auf mehr: 
http://en.wikipedia.org/wiki/IEEE_1284#Specifications


Wenn Du schon mit dieser toten Leiche herumspielen möchtest, dann 
solltest Du Dich an diesen Möglichkeiten orientieren.

[Kilgore, Bill (Gast)]

>Mir fällt nur ein
> - mit dem Ack Signal einen IRQ auslösen: ggf hohe IRQ Last
> - alle 1-x ms IRQ Auslösen und hoffen daß die Gegenseite READY ist
>   wenn nein in 1-x ms nochmal fragen

>Gibt es besseres? Wie war das etwa bei MS, bei LINUX implementiert, als
>eben noch die parallele Schnittstelle (Centronix) gab ?

Wenn du das Irq-Signal auslöst, dann findet "sofort" ein Kontextswitch 
statt und es wird in den Kernelhandler gesprungen. Der Handler ist nicht 
unterbrechbar, also zumindest nicht für die abarbeitende CPU. (Du kannst 
ihn aber unterbrechbar machen.) Das heisst, du solltest die Abarbeitung 
schnell erledigen. Für hohes Datenvolumen ist dies keine geignete 
Massnahme. Für "schnelle" Reaktionszeit schon.