GPIO Input-Interrupts

t0mM3k Gast #2464907
Lesenswert?
• ▲
▼ 
Hallo @all,
ich nutze die GPIO-Pins an meinem EmbeddedLinux-System um damit Ein-und 
Ausgänge zu realisieren. Alles über sysfs.
Allerdings taucht in meinem entsprechenden gpioXX Verzeichnis neben 
"direction" und "value" kein "edge" auf. Somit kann ich die Flanken für 
Interrupts nicht festlegen, und muss mein Inputs mit busy-polling 
abfragen (Was ja Gift für die Stimmung ist).
Kernelversion ist 2.6.31.
Gibt es eine Möglichkeit die GPIO-Input-Interrupts auch ohne die "edge" 
Dateien zu Triggern? (Also die edge Dateien irgendwie umgehen, oder im 
nachhinein erzeugen?!)

Vielen Dank schonmal für jeden hilfreichen Hinweis :)
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Werner B. #2465149
Lesenswert?
• ▲
▼ 
Sieht nicht gut für dich aus.

kernel/Documentation/gpio.txt (Based on kernel version 3.1.)

...
 /sys/class/gpio/gpioN/
...
"edge" ... reads as either "none", "rising", "falling", or
"both". Write these strings to select the signal edge(s)
that will make poll(2) on the "value" file return.
* This file exists only if the pin can be configured as an
  interrupt generating input pin.
...

Entweder kann der Pin keinen Interrupt erzeugen oder das Board Support 
Package implementiert es nicht.
Was es genau ist ... da hilft nur ein Blick ins Datenblatt des uC.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
t0mM3k Gast #2465953
Lesenswert?
• ▲
▼ 
ja die Dokumentation habe ich schon gelesen. Darum ja mein Ärgerniss, 
dass die "edge" Datei nicht existiert. Meine irgendwo gelesen zu haben, 
dass das erst ab Kernelver. 2.6.33+ geht. Für das Board gibt es aber 
kein aktuelleres Kernelupdate als 2.6.31.
Ist ein PortuxG20 von Taskit mit nem AT91SAM9G20 drauf.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Werner B. #2466049
Lesenswert?
• ▲
▼ 
Dann könntest du versuchen die Kernelquellen zuerst schrittweise von 
2.6.31.x auf 2.6.31 zurückzuführen (wobei dann x implizit 0 ist), und 
dann über 2.6.32 auf 2.6.33 hochziehen.
Das ist aber (wie die Amis so schön sagen) "a pain in the a..".
Ich habe erst letztes Wochenende auf diesem Weg ein AT91SAM9261 Board 
von 2.6.31.6 auf 2.6.32.50 hochgezogen (wegen "long term kernel"). 
Dutzende .rej Files weil sich die Board-Patches und die Kernel-Patches 
teilweise überschneiden. Da muss man die Konflikte dann manuell 
auflösen.
Auch ein Problem ist, an die Patches der 2.6.31-er Reihe zu kommen. Auf 
kernel.org ist nicht mehr alles zu finden seit diese gehackt worden ist. 
Da muss man Suchmaschinen bemühen und auf Spiegelserver zurückgreifen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
t0mM3k Gast #2466070
Lesenswert?
• ▲
▼ 
iehgittigitt :(
das klingt ja brutal ;)
hatte gehofft, dass das auch irgendwie anders geht. Ich meine selbst 
wenn ich mir die ganze Arbeit mache, dann bin ich mir immer noch nicht 
sicher, ob das auch zielführend ist. Habe leider von Kernelfriemelei so 
ziemlich gar keine Ahnung. Hab vllt mal n Modul geändert oder so, aber 
das wars auch schon ^^.

Danke trotzdem erstmal für den Tipp.
Ich hab jetzt einfach mal die Herstellerfirma angeschrieben, mal schauen 
was die zu dem Problem sagt.
Wenn noch andere Ideen aufkommen wie ich meine Inputs ohne busy-polling 
abfragen kann bin ich sehr dankbar.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren