Verständnisfrage - GPIO als Datei ansprechen?

  • Wenn ich es richtig verstanden habe, werden die GPIO prinzipiell über eine Datei angesprochen? Ich hab das heute mal ausprobiert, Rechte geändert, Pin definiert, als Ausgang gesetzt und geschaltet => hat funktioniert.


    Nach dem Neustart sind der Pin und die Änderungen an den export und unexport-Dateien wieder weg. Sehe ich das richtig, daß das keine Datei auf der SD-Karte, sondern eine "virtuelle" Datei ist? Die beim Start des Raspi angelegt wird?


    Wäre ja auch blöd, wenn jeder Pinchange einen Schreibvorgang auf der SD-Karte auslösen würde. Aber wie wird das realisiert? Ist das eine Ramdisk? Und was ist alles virtuell, das ganze Verzeichnis /sys, oder die Unterverzeichnisse, oder nur die Dateien? Und welche Funktionen (i2c, bluetooth...) die im Verzeichnis /sys/class liegen werden noch so behandelt?

  • Hallo.


    Wenn ich es richtig verstanden habe, werden die GPIO prinzipiell über eine Datei angesprochen? Ich hab das heute mal ausprobiert, Rechte geändert, Pin definiert, als Ausgang gesetzt und geschaltet => hat funktioniert.


    Nach dem Neustart sind der Pin und die Änderungen an den export und unexport-Dateien wieder weg. Sehe ich das richtig, daß das keine Datei auf der SD-Karte, sondern eine "virtuelle" Datei ist? Die beim Start des Raspi angelegt wird?


    Wäre ja auch blöd, wenn jeder Pinchange einen Schreibvorgang auf der SD-Karte auslösen würde. Aber wie wird das realisiert? Ist das eine Ramdisk? Und was ist alles virtuell, das ganze Verzeichnis /sys, oder die Unterverzeichnisse, oder nur die Dateien? Und welche Funktionen (i2c, bluetooth...) die im Verzeichnis /sys/class liegen werden noch so behandelt?


    Ich sag's mal vorsichtig so.
    Linux kennt keine "Geräte", sondern ist ein File-System.
    Der Linux-Geräte-Treiber kommuniziert mit dir über ein File über dieses Gerät.Du machst also einen Request über das File des Gerätes das Linux anlegt, und erhälst Antwort in diesem File.
    Meist ist es so (Beispiel 1wire Geräte).Du versucht das Gerät/File zu öffnen... ist es nicht vorhanden, wird kein File existieren, wenn jan, kannst es öffnen und lesen.
    Zum groben Verständnis.


    gruß root

  • Linux kennt keine "Geräte", sondern ist ein File-System.
    Der Linux-Geräte-Treiber kommuniziert mit dir über ein File über dieses Gerät.Du machst also einen Request über das File des Gerätes das Linux anlegt, und erhälst Antwort in diesem File.


    Ok, aber das "File" ist kein reales File als Daten auf der SD-Karte, sondern ein virtuelles File in einer Art Ramdisk, oder? Kommt mir irgendwie noch vom Amiga bekannt vor...

  • Realisiert wird das durch den Kernel. root sagt ja schon ganz richtig - die Abstraktion unter UNIX ist die, dass nahezu alles eine Datei ist, ueber die man einen Strom von Daten bekommt/wegschreibt.


    Eine Kamera? Nichts anderes als einen Datei, aus der man Bilder Frame fuer Frame liest. Audioausgabegeraet? Eine Datei, in die man Buffer fuer Buffer Samples schreibt. Usw.


    Der Vorteil ist, dass du nur sehr wenig API zum Kernel brauchst. Weil aber viele der Geraete eben doch spezielle Schnittstellen benoetigen - zb setzen von Bildraten, Aufloesungen, Farbtiefen, Sampleraten, usw., gibt es noch den sehr wichtigen Aufruf "ioctl". Der ist sehr generisch, und da kann/muss man dann fuer konkrete Geraeteklassen oder sogar einzelne Geraete selbst nachschauen, was die da koennen/brauchen.


    Und zu der Frage, was alles "virtualisiert" ist - /sys in jedem Fall, im Zweifelsfall auch /dev. Ob die beiden als Verzeichnisse existieren muessen weiss ich im Moment nicht so genau, aber die Dateien und Unterverzeichnisse darin definitiv nicht.


    Eine RAM-Disk in dem Sinne ist das natuerlich nicht. Der Kernel bekommt ja mit, wenn du zb ein Verzeichnis auflisten moechtest. Damit kann er dann innerhalb seiner selbst verzweigen, und statt sich durch Code fuer ein Filesystem zu hangeln, die Liste der angeschlossenen Geraete zurueckliefern.
    Automatisch zusammengefügt:[hr]
    TimM: der AMIGA hatte starke anleihen bei UNIX-Systemen - daher das Dejavu.

  • Google Suche nach: gpio sysfs


    Du kannst allerdings nicht alle Funktionen über die sysfs Dateien umsetzen, zB PWM geht damit nicht. GPIO via sysfs ist zudem langsamer als via zB Register.




    PS: Doch es ist wie eine RAM-Disk, es liegt nicht physikalisch auf dem Datenträger also wo sonst?

  • meigrafd: jup, alle Dinge sind ja irgendwie Dinge die Dinge tun. Hatten wir ja schon, oder?

  • Das es gute Gruende gibt, verschiedene Konzepte nicht zu vermischen, und Aussagen beliebig werden, wenn man es trotzdem tut. Wenn man dich darauf anspricht, dann kommt immer "ja, du fokussierst dich jetzt darauf, was ichi als ganzes gesagt habe, aber du musst doch diverse Worte weglassen, und dann stimmt's". Das ist aber nicht, wie sinnvolle Kommunikation funktionieren kann.


    Eine RAM-Disk impliziert das *speichern* von Daten, wenn auch fluechtig. Aber ein virtualisiertes FS wie /sys oder /dev speichert nichts. Es stellt lediglich eine Sicht auf Dinge dar.

  • So ein Quatsch... Du lässt Worte unaufgefordert weg und hängst dich daran dann auf - wie jetzt auch wieder: Ich hab geschrieben WIE eine RAM-Disk. Das ist ein Vergleich keine Festlegung. Also bitte unterschlage nicht schon wieder Worte obwohl sie da geschrieben stehen.

  • Also... ich bin absolut nicht der Linux-Guru... aber



    PS: Doch es ist wie eine RAM-Disk, es liegt nicht physikalisch auf dem Datenträger also wo sonst?


    und


    Ich hab geschrieben WIE eine RAM-Disk. Das ist ein Vergleich keine Festlegung.


    :huh: ja wat denn nu :huh:


    ...oder missverstehe ich da was ???


    zum weiter oben angesprochem 1-wire gilt


    ...das File existiert also sehr wohl real.


    richtig ist dass das bei GPIO read/write und PWM anders aussieht.


    Wenn ich also z.B. ein bestimmtes Bitmuster an best. GPIO's legen will gibt's ne elegante Lösung wie:


    Code
    int gpioWrite_Bits_0_31_Set(uint32_t bits)
    Sets GPIO 0-31 if the corresponding bit in bits is set. 
    bits: a bit mask of GPIO to set
    Returns 0 if OK.


    oder löschen

    Code
    int gpioWrite_Bits_0_31_Clear(uint32_t bits)
    Clears GPIO 0-31 if the corresponding bit in bits is set. 
    bits: a bit mask of GPIO to clear
    Returns 0 if OK. 
    
    
    Example
    // To clear (set to 0) GPIO 4, 7, and 15
    gpioWrite_Bits_0_31_Clear( (1<<4) | (1<<7) | (1<<15) );


    basierend auf:


  • Was ist daran denn nicht zu verstehen?


    Timm Thaler fragte ob jeder Pinchange einen Schreibvorgang auf der SD-Karte auslösen würde. Und: sondern ein virtuelles File in einer Art Ramdisk
    Daraufhin schrieb deets: Eine RAM-Disk in dem Sinne ist das natuerlich nicht.


    Ich schrieb nicht "es ist eine RAM-Disk" sondern "es ist wie eine RAM-Disk"... Das eine Wort welches deets unterschlägt macht einen wichtigen Unterschied.
    WIE eine RAM-Disk, bedeutet das es so ähnlich ist wie eine RAM-Disk, denn es finden keine Schreibvorgänge auf dem Datenträger statt, also kann das ja nur noch im RAM stattfinden!?

  • Ja, ok, ich habs auch kapiert.


    Was mich jetzt noch interessiert: Wenn die Einstellung der IOs flüchtig ist, wo wird die dann nach einem Reset festgelegt? Ich nehme an, dann stehen die erstmal alle auf Eingang.


    Reicht es dann aus, wenn ich die Richtung in meinem Programm festlege? Dann muß die Peripherie damit klarkommen, daß Pins auch mal hochohmig sein können. Aber daß muß sie ja für den Fall des Reset sowieso.


    Und muß man Programm als SU laufen, damit es Scheibrechte auf die GPIOs hat? Oder macht man das anders?

  • Das haengt ein bisschen davon ab. Fuer den hier skizzierten Fall - Kernel-IO via /sys/ - sollte die Mitgliedschaft in der Gruppe gpio reichen. Wenn das System entsprechend aufgesetzt ist - bei raspibian sollte dem so sein.


    Allerdings ist das nicht unbedingt die beste Art, mit den GPIOs umzugehen. Da gibt's leider konzeptionelle Schwaechen. Weswegen kluge Menschen die Bibliothek pipgio erfunden haben, welche die IO-Register des BCM direkt ausliest, mittels DMA, aus dem Speicher. Und dafuer eine eigene API anbietet.


    Das klappt dann nur als root, weil man nur als solcher beliebige Speicherseiten und DMA-Kanaele nutzen kann. Da kaeme es jetzt etwas auf deinen Anwendungszweck an.


  • Das haengt ein bisschen davon ab. Fuer den hier skizzierten Fall - Kernel-IO via /sys/ - sollte die Mitgliedschaft in der Gruppe gpio reichen. Wenn das System entsprechend aufgesetzt ist - bei raspibian sollte dem so sein.


    Bei Einführung des Kernels 4.1.6 gab es damit Probleme die mittlerweile aber behoben sind.


    Damals und davor wurde das über die Datei /etc/udev/rules.d/80-gpio-noroot.rules des Dienstes udev, aktuell (mit Jessie) wird das über die Datei /etc/udev/rules.d/99-com.rules geregelt. In dieser Datei steht:


    Code
    SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"
    SUBSYSTEM=="input", GROUP="input", MODE="0660"
    SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
    SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
    SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"


    Bei dem Programm hat deets leider einen kleinen Schreibfehler, es heißt nicht pipgio sondern pigpio
    Da gibt es auch ein Daemon pigpiod welcher als root im Hintergrund läuft und als ganz normaler Benutzer angesprochen werden kann - sogar übers Netzwerk via Socket. Siehe dazu FAQ --> Nützliche Links / Linksammlung --> GPIO ohne root-Rechte oder über Netzwerk