hi, ich entwickle einen Treiber unter Linux (Kernel Version 3.0.x), der auf den Interrupt 7 am Parallelport (0x378) hören soll. unter /proc/ioports & /proc/interrupts scheint alles korrekt eingetragen zu sein. allerdings krieg ich keinen interrupt am pin 10 (ACK) am parallelport ausgelöst. hat jemand eine idee, was ich noch prüfen könnte? grüße jihm
verwendest du das parport framework, oder versuchst du dich daran vorbeizumogeln? Steigen die IRQ-Counter in /proc/interrupts wenn du am Port "wackelst"?
ich entferne lp, parport, parport_pc, ppdev. und leider geht der counter nicht.
ji hm schrieb: > und leider geht der counter nicht. *hoch
1) Schlechte Idee. Das Parport-Framework existiert nicht nur zum Spass, sondern um dir und anderen Treiber-Entwicklern das Leben einfacher zu machen. 2) Vermutlich fehlt dir noch ein pci_enable_device() oder request_irq() 3) geht denn der Counter hoch, wenn du nur die normalen parport-Module drinnen hast, aber nicht deinen Code? Nur um ein Hardware-Problem auszuschliessen? (evtl. /dev/parport0 während des Tests offenhalten)
Wenn der Interrupt irgendwann man kommen sollte, dann denk dran, dass nicht jeder Interrupt 7 vom Parallelport kommen muss. Auf dem 7er landen u.U. auch andere Interrupts, wenn deren Anforderung zwischendurch wieder verschwunden ist (spurious interrupts).
Εrnst B✶ schrieb: > 1) Schlechte Idee. Das Parport-Framework existiert nicht nur zum Spass, > sondern um dir und anderen Treiber-Entwicklern das Leben einfacher zu > machen. glaub ich, allerdings ist das teil der aufgabe, die kommunikation so lowlevel wie möglich zu gestalten > 2) Vermutlich fehlt dir noch ein pci_enable_device() oder request_irq() wird probiert > 3) geht denn der Counter hoch, wenn du nur die normalen parport-Module > drinnen hast, aber nicht deinen Code? Nur um ein Hardware-Problem > auszuschliessen? wird auch probiert A. K. schrieb: > Wenn der Interrupt irgendwann man kommen sollte, dann denk dran, dass > nicht jeder Interrupt 7 vom Parallelport kommen muss. Auf dem 7er landen > u.U. auch andere Interrupts, wenn deren Anforderung zwischendurch wieder > verschwunden ist (spurious interrupts). werd ich beachten ich werds alles probieren, und melde mich dann. vielen dank soweit.
ji hm schrieb: >> 1) Schlechte Idee. Das Parport-Framework existiert nicht nur zum Spass, >> sondern um dir und anderen Treiber-Entwicklern das Leben einfacher zu >> machen. > glaub ich, allerdings ist das teil der aufgabe, die kommunikation so > lowlevel wie möglich zu gestalten ich habe mir doch gleich gedacht "das problem kommt mir bekannt vor" - ich hatte mal die gleiche aufgabe (finde aber den code im moment nicht, muss mal meinen alten computer checken...)