Zugriff auf die GPIOs per sysfs als Alternative zu den Libraries z.B. pigpio/bcm2835/wiringPi?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Der BCM2835 ist kein µC das stimmt. Er besitzt aber eine "Hardware" zur Verwaltung von Interrupts seiner Komponenten (GPIOs, UARTs SPIs ... ).

    Diese "Hardware" zur Verwaltung der BCM2835-Interrupts ihrerseits ist aber mit dem Interrupt-System des ARM-Prozessors verbunden, und kann dort Hardware_Interrupts auslösen.

    Die Adresse der Interrupt-Service-Routine muss dazu in die IRQ-Vektor-Tabelle des ARMs eingetragen werden.

    Die Tabelle kann man aber wohl nur in einem Mode beschreiben, in welchen der ARM-Prozessor nach seinem Reset arbeitet. Das ist in der Phase, wo der Device-Tree "aufgebaut" wird.

    Zur Unterstützung gibt es Device-Tree-Compiler. Bei Informationen zum Device-Tree-Compiler wird die Luft im Internet dann aber ganz dünn.

    Beispiele für das Beschreiben der Vektor-Tabelle und Beispiele für IRQ-Service-Routinen in Assembler findet man ja wohl zu hauf, aber nicht für Linux.

    "GPIO for Engineers and Makers" scheint ja was ganz Allgemeines für Linux zu sein, gibt es das auch für den Raspberry ?

    Gruß Prittzl

  • Zugriff auf die GPIOs per sysfs als Alternative zu den Libraries z.B. pigpio/bcm2835/wiringPi?? Schau mal ob du hier fündig wirst!

  • Hi Prittzl ,

    "GPIO for Engineers and Makers" scheint ja was ganz Allgemeines für Linux zu sein, gibt es das auch für den Raspberry ?

    hab' speziell für den Pi noch nicht entdeckt. Ich halt' aber mal die Augen offen.

    Danke für die Info ... ich werde zukünftig bei meinem Herumggestöbere im Netz mal besonderes Augenmerk auf device-tree mit speziellem Schwerpunkt Interrupt-Tabellen haben. Vielleicht läuft mir ja mal was Passendes über den Weg.

    Wie gesagt, ich brauch's zwar nicht, es kann aber nicht schaden, da evtl. mehr zu erfahren ...

    Schönes WE noch,

    -ds-

  • Prittzl : -> http://xillybus.com/tutorials/device-tree-zynq-4

    Vielleicht hilft das weiter? Ca. in der Mitte ist was von Interrupts ...

    //EDIT: Ach ja: noch was -> https://www.raspberrypi.org/forums/viewtopic.php?t=38076

    und -> http://www.valvers.com/open-software/…mming-in-c-pt4/

    Aber das kennst Du wahrscheinlich.

    cu,

    -ds-

  • @Ozymandias

    Hast Du denn vielleicht ein Beispiel, wie man an die Interrupt-Vektoren der Prozessoren kommt?

    Den bcm2835 echte Prozessor-Interrupts via Device-Tree erzeugen zu lassen, da bin ich schon lange hinterher.

    Nein, das habe ich nicht. Da wird sich wohl einer durch das Device Tree durchwurschteln müssen und nach dem InterruptController suchen und dann die GPIOs an Interrupt-Quelle definieren...

    Ich habe kurz reingeschaut, aber das ist so ein Haufen Sch**sse, wo ein DTSI auf den anderen DTSI, auf den anderen DTSI und noch einen anderen und den vierten und fünften aufsetzt, dass ich Null Bock habe, mich da durchzuwurschteln.

    In "GPIO und Interrupts" steht sehr oft die Zeichenfolge "POLL", was darauf schließen lässt, das keine echten Prozessor-Interrupts generiert werden.

    Keine Ahnung, das war als ein Beispiel für was anderes gedacht.

    "LKM und GPIO" gibt gesicherte Delays von 25 µs zur Erkennung einer Zustandesänderung an einem GPIO-Pin an.

    Also ich sehe da nichts von "gesicherten" 25 µs, beim besten Willen nicht. Da steht, dass die Zeitspanne zwischen 15 und 25 µs liegt...

    Wie soll man da irgendwas zusichern bitte??? Es ist kein RealTime Kernel! Nur im RT-Kernel hat man irgendwas zugesichert... hier ist einfach nur ein Zufall, dass er zwischen 15 und 25µs gelandet ist, es hätten genau so 10 und 50 sein können und mit der nächsten Kernel-Version liegt man plötzlich bei 30 und 70µs...

    In meinen Routinen habe ich mich so beholfen, dass ich einem Core den Prozesss zum Pollen der GPIOs zuordne, und alle anderen Prozesse auf die anderen Cores verteile. Damit kann ich an den GPOIs Impulse bis über 25 kHz sauber erfassen, das entspricht gesicherten Delays von 20 µs.

    Auch hier gilt: da ist gar nichts zugesichert... Es kann keiner sagen, ob mit der nächsten Kernel-Version es nur noch 20kHz sind.

    Wie sieht es aus, wenn du kein Polling sondern Interrupt verwendest?

    Mit echten Prozessor-Interrupts müsste man doch Delays in ns erreichen ?

    Für solche Geschichten nimmt man entweder einen Mikrocontroller oder einen DSP, aber sicherlich keinen SoC.

  • Bernd666

    Das sieht sehr gut aus, weil die für den BCM2708 (Vorläufer des BCM2835) gilt.

    Das ist aber wohl Unterhaltung für mehr als für einen Abend.

    Da werde ich mich dahinter klemmen.

    @Ozymandias

    Wozu ist denn das Prozessorsystem dafür ausgelegt, dass der SoC echte Harware-Interrupts am Interrupt-System der Cores auslösen kann ?

    dreamshader

    Benötigst Du den Zugriff auf die Register des BCM2835 noch ?

    Wenn ja, kann ich Dir die Routinen gerne zur Verfügung stellen. Ich müsste sie aber noch ein wenig ausführlicher "betexten".

    Die Routinen liefern ein Zeitnormal (ms) und den Zugriff auf die Pins des GPIO.

    Die Zugriffe auf die auf Register der anderen Komponenten könntest Du dann selbst erstellen.

    Der eigentliche Zugriff auf die Register erfolgt dabei nicht über Funktionen, sondern direkt mittels Zeiger via MMU. Schneller geht es nicht.

  • Prittzl: Ich glaube, Du hast den Rest von meinem Beitrag nicht wirklich verstanden... oder erst gar nicht gelesen?

    Du hast einen wahnsinnigen Overhead durch den Kernel. Es bringt gar nichts, wenn die Hardware den Interrupt sofort fängt. Es dauert einfach ewig, bis der Interrupt bis in die Service Routine durchschlägt, das ist einfach Fakt! Ich habe keine Ahnung, was Ihr für Anforderungen habt, ob sie echt sind oder gesponnen. Wenn sie wirklich echt sind, dann habt Ihr Euch für das falsche Werkzeug entschieden...

    Nur weil ein SoC echte Hardware Interrupts hat, heißt es noch lange nicht, dass es sie auch schnell abarbeitet, da ist jeder 8 bitter um die Lichtjahre schneller.

  • Hi Prittzl ,

    Benötigst Du den Zugriff auf die Register des BCM2835 noch ?

    Hm ... nicht wirklich, aber da tritt mal wieder mein Spieltrieb zutage. Schaden kann es nicht ;)

    btw: passt die Richtung mit den Links oder liege ich da total daneben?

    cheers,

    -ds-

  • @dreamsgader

    http://xillybus.com/tutorials/device-tree-zynq-4 ist eine Library, wobei ich nicht weiß, ob es eine Version für den Raspberry gibt.

    http://www.valvers.com/open-so…tal-programming-in-c-pt4 ist bare metal programming.

    Aber trotzdem vielen Dank für Deine Bemühungen.

    @Ozymandias

    Ich habe Deine Beiträge gelesen, verstanden was Du schreibst, und halte Deine Aussagen für nicht richtig.

    Allein in Deinem letzten Beitrag stellst Du Behauptungen auf, welche mich daran zweifeln lassen, ob Du je Interrupt-Routinen geschrieben hast und deren Sinn verstehst.

    Dass z.B. zu jeder Interrupt-Service-Routine auch immer mindestens eine Routine gehört, welche die Resultate der Interrupt-Service-Routine an die Erfordernisse des Kernels mit seinem "wahnsinnigen Overhead" und "Ewigkeiten" anpasst.

  • Prittzl: LOOOOOL, ja, genau... ich programmiere seit 12 Jahren Mikrocontroller und seit ca 2,5 Jahren Treiber, aber passt schon. Du bist mein Held! Lerne erstmal, was passiert, wenn ein Interrupt auftritt und wie er vom Kernel abgearbeitet wird, dann können wir uns nochmal unterhalten. jemand der von "garantierten Latenzen" bei einem non-RT Kernel redet, hat das Thema grundsätzlich nicht verstanden...

    Viel Erfolg euch beiden.

    Einmal editiert, zuletzt von Ozymandias (23. Oktober 2018 um 10:25)

  • Prittzl ,

    naja ... aus dem Link zu xillybus hoffte ich, dass Du da was rauslesen kannst, was den device und Interrupts betrifft.

    Ist zwar ein anderes System, müsste nach meinem Verständnis aber zumindest ähnlich sein ...

    Das war mehr als Quelle für Hintergrund-Informationen gedacht ..

    Wobei ich da Zweifel hab' ob der device tree für Dein Vorhaben nicht auch schon zu spät aktiv wird ...

    Viel Erfolg euch beiden.

    @Ozymandias : ich weiss nicht, was Du meinst ... :conf:

    Ich wollte lediglich die pigpio/wiringPi/bcm2835 weg haben, weil ich eben nur den einen oder anderen Pin schalten will.

    Das Ziel habe ich erreicht ( -> Quick hack: GPIO-Steuerung in C ohne root Rechte und ohne Library ... ). Das ging relativ problemlos und reicht mir erst mal vollkommen aus.

    cu,

    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!