"Ausgeschaltete" GPIO's beim Boot gesucht!

  • Hallo zusammen,
    ich habe ein kleines System, welches 6 GPIO Ports braucht. Aktuell hatte ich im Script folgende verwendet:

    Funktionierte im Betrieb soweit auch, allerdings werden die beim Systemstart durchgetestet und teilweise auf High gesetzt. GPIO 37 aber z.B. bleibt beim Boot aus, 29 und 31 gehen hingegen an. Problematisch ist das ganze, weil dahinter eine Türansteuerung sitzt, das würde heißen, dass die Tür bei Systemstart geöffnet wird.

    Welche GPIOs haben ein anderes Verhalten? Es wäre mir so gerade möglich einen anderen GPIO auf der Platine anzuzapfen, eine andere Schaltung mit Zeitverzögerung oder sonstigem ist nicht mehr realisierbar. (System muss langsam dringend getestet und genutzt werden & die Platine ist voll..)

    Gruß

  • Servus JumpY,
    ich fürchte, da wirst Du Pech haben ... der Status eines I/Os während des Systemstart/Stop ist imho nicht definiert.
    Abhilfe würden da entsprechende pulldowns schaffen.
    Ausserdem fände ich es besser, wenn Du hier von Anfang an klarstellen würdest, dass Du von phsikalischen Pin-Nummern und nicht von GIPO-Nummern redest. Das sorgt sonst nur für Verwirrung ...

    cu,
    -ds-

  • Hallo JumpY,

    das Einzige, was mir einfällt, ist über Konfiguration des DeviceTrees einen DeviceTree-Blob zu compilieren, der vom Kernel beim Booten verwendet wird.

    Stichworte zum Suchen hast Du jetzt.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • ich fürchte, da wirst Du Pech haben ... der Status eines I/Os während des Systemstart/Stop ist imho nicht definiert.
    Abhilfe würden da entsprechende pulldowns schaffen.
    Ausserdem fände ich es besser, wenn Du hier von Anfang an klarstellen würdest, dass Du von phsikalischen Pin-Nummern und nicht von GIPO-Nummern redest. Das sorgt sonst nur für Verwirrung ...

    Oh ja, sorry. Komme mit der Notation der einzelnen GPIO-Teile immer durcheinander.
    Bist du sicher, dass das nicht definiert ist? Ich meine hier irgendwo gelesen zu haben, dass manche auf HIGH und manche auf LOW gezogen werden (allerdings ohne Beschreibung welche das sein sollen..). Kannst du mir kurz sagen, wie du das mit Pulldowns erledigen willst? Vielleicht bekomme ich das noch irgendwo untergebracht...



    das Einzige, was mir einfällt, ist über Konfiguration des DeviceTrees einen DeviceTree-Blob zu compilieren, der vom Kernel beim Booten verwendet wird.

    Stichworte zum Suchen hast Du jetzt.


    Ich meine gelesen zu haben, dass es Softwareseitig nicht funktioniert. Ich werde danach nochmal suchen, aber glaube jetzt schon, dass mich das überfordert :lol:

  • Tja JumpY,


    ... Bist du sicher, dass das nicht definiert ist? Ich meine hier irgendwo gelesen zu haben, dass manche auf HIGH und manche auf LOW gezogen werden ...


    ... nach dem Bootvorgang, wenn alle Treiber und Kernelmodule geladen sind, haben wohl die meisten einen ( reproduzierbaren - ich sag' jetzt absichtlich nicht definierten ) Zustand.
    Die Krux ist halt die Zeit bis zu diesem Status ...

    Pulldown - relativ easy - verbinden die Pins mit einem relativ großen Widerstand ( 10 kOhm ) mit GND und Bingo ...
    Du solltest das allerdings nicht mit den beiden I2C-Leitungen (SDA/SCL) machen, weil die physikalisch fix auf 3V3 gelegt sind. Sonst fallen mir da aber jetzt ad hoc keine Einschränkungen ein.

    cu,
    -ds


  • Pulldown - relativ easy - verbinden die Pins mit einem relativ großen Widerstand ( 10 kOhm ) mit GND und Bingo ...
    Du solltest das allerdings nicht mit den beiden I2C-Leitungen (SDA/SCL) machen, weil die physikalisch fix auf 3V3 gelegt sind. Sonst fallen mir da aber jetzt ad hoc keine Einschränkungen ein.

    Wie du weißt, sind meine Kenntnisse der Elektrotechnik sehr bescheiden. Die Sache mit den Pullup/Pulldown Widerständen habe ich noch nie verstanden..

    Ich verstehe das Prinzip dahinter einfach nicht, hier eine kleine Skizze wie das dann verschaltet wäre.

    unbenanntuqrea.jpg

    Rechte Seite ist dann meine Schaltung. Da wird ein Transistor über den GPIO geschaltet, der die Masse für (hier) meine LED freigibt. Das gleiche passiert aber eben auch mit Summer, Relais, etc.
    Meine Frage: Was soll der Pulldown-Widerstand da jetzt bewirken? Die Verbindung zu meiner Schaltung ist doch immer gegeben, somit wird der Transistor doch trotzdem durchschalten, weil der Port ja auf HIGH steht (das was eigentlich ja auch der Sinn ist, nur halt eben nicht im Boot).

    Habe ich jetzt da einen Denkfehler, oder kann das so garnicht funktionieren? (Oder funktioniert das Teil so, dass es dem GPIO Port durch die "Masseverbindung" vorgibt, Masse anzunehmen, wenn der Port es nicht von intern anders gesagt bekommt?)

  • Hallo JumpY,

    dann schau doch mal hier rein. Da geht es um die Erstellung von Device Trees, deren Syntax und Möglichkeiten, deren Kompilierung und deren Einbindung in den Kernel. Also genau das, was Du erreichen möchtest, damit bestimmte GPIOs einen bestimmten Status haben.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (3. Dezember 2016 um 21:13)

  • Habe gerade auf meiner großen Suche folgendes gefunden: Hier

    Ich hatte mich schon gewundert, dass ich der einzige sein soll, aber mit genauen Suchbegriffen dank deiner Hilfe findet man sowas dann doch. Derjenige hat zumindest das gleiche Problem, er setzt seine GPIOs allerdings damit auf HIGH. Ich werde das später mal versuchen ob ich die damit auf LOW gesetzt bekomme & werde das dann mal prüfen. Wäre jedenfalls Klasse, wenn es entgegen der Meinung von ganz vielen anderen Threads doch einfach Softwareseitig funktioniert. (Das muss dann nur halt schnell sein, da das verdammte Relais nur einen millisekunden-Impuls braucht)

  • Hi,
    das hast Du schon ganz richtig verstanden.
    Vermutlich wirst Du eh "beides" brauchen ... einen pulldown, der Deinen GPIO erst mal auf Masse legt (solange er nicht explizit auf HIGH gesetzt wird sondern sozusagen uninitialisiert da so "rumhängt" oder als Eingang gesetzt ist, und alle möglichen Zustände annehmen kann).
    Und dann halt (D)eine Initialisisierung der I/Os, sobald der Kernel mal gestartet ist. ...
    Da käme dann vllt. diese Overlay-Geschichte von Andreas in Frage ... aber dazu kann ich nix sagen.
    Allerdings würde ich das

    Zitat


    sudo rpi-update


    mit Vorsicht geniessen, und erst mal probieren, ob es mittlerweile auch ohne geht ...

    cu,
    -ds-

  • mit Vorsicht geniessen, und erst mal probieren, ob es mittlerweile auch ohne geht ...

    Das kam etwas zu spät, hat aber nichts zerschossen. Grundsätzlich funktioniert das Softwaremäßig sogar ein bisschen, nach ~1 Sekunde werden die GPIOs so tatsächlich abgeschaltet. Allerdings kann ich im Betrieb jetzt einen nicht mehr richtig verwenden, könnte vielleicht an dem internen Pulldown liegen, muss ich mal prüfen. Aber die eine Sekunde ist eben auch zu lang, deshalb werde ich dann gleich mal Widerstände einbringen und schauen ob es damit besser wird, ansonsten habe ich ein Problem...

  • Na Glück gehabt ...
    Widerstände, wie gesagt, um die 10 kOhm, ist so eine allgemeine Hausnummer ... grösser ist auch ok ...
    Es geht darum, dass möglichst wenig Strom fliesst. Das wären bei 10 kOhm und 3V3 ca. 0,3 mA .... bei 20 kOhm dann die Hälfte ...
    Wenn der zu gross wird, funktioniert das Ganze nicht mehr zuverlässig.
    Notfalls probieren

    //EDIT: wenn Du mal nach downgrade/rollback suchst, findest Du auch eine Anleitung, wie man den rpi-update wieder rückgängig machen kannst ... weiss ich jetzt auswendig nicht mehr. Aber wenn nix kaputt ist ...

    cu,
    -ds-

  • Ein 10kOhm Pulldown scheint die gewünschte Wirkung zu bringen. Habe provisorisch mal einen eingelötet, da bliebt die LED aus beim Bootvorgang und der Rest nachher funktioniert trotzdem. Ob da jetzt einen sehr kurzen Moment (schneller als die LED) ein Strom fließt kann ich natürlich nicht sagen, habe kein Oszilloskop oder so zur Hand. Dann muss ich mal schauen wie ich die irgendwie noch in die Platine gebracht bekomme, dass wird ja ein super Spaß :s

  • Wenn du die Platine sehen würdest, wüsstest du dass SMD da absolut fehl am Platze ist :lol: Wollte die immer Zeichnen und fertigen lassen, aber ich bin einfach nicht dazu gekommen und kann das auch nicht sonderlich. Wenn es jetzt wirklich irgendwann läuft wird das allerhöchste Zeit :)

    Ich werde berichten wie es funktioniert, wenn es dann irgendwann fertig ist :s

  • Sooo,
    es hatte alles soweit funktioniert, aber.. Ich habe den ganzen Testaufbau jetzt auf einer sauberen Raspbian Partition neu aufgebaut und stoße genau hier an Probleme.. Ich habe versucht die Devicetree Regeln wie hier https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=91344 wieder genau so eingestellt wie bei dem "alten" Raspbian, allerdings habe ich beim build der dt-blob.dts jetzt ganz viele Warnings. Die sehen im Prinzip alle gleich aus:

    Pin@P1 has a unit name, but no reg property , etc. Habe jetzt die genaue Fehlermeldung nicht mehr, das ist ein Teil davon. Im Netz finde ich absolut nichts darüber. Habe mir dann von der offiziellen Raspbian Seite aus den Manuals deren dt-blob.dts in Rohform genommen und diese versucht aufzuspielen -> gleiche Fehler. (Auf dem "alten" Raspbian laufen beide Dateien von mir ohne Probleme)

    Kann sich jemand vorstellen was da irgendwo hakt? Fehlt mir irgend ein Paket, fehlen irgendwelche Zuweisungen die damals irgendwie automatisch dabei waren? Im ganzen Netz finde ich absolut nichts zu genau der gleichen Problematik, nur bei irgendwelchen anderen builds die den Bootloader betreffen, aber ohne passende Lösung für mich..

  • So, Fazit:
    Bekomme zum verrecken den Devicetree unter Jessie nicht kompiliert und somit fällt die Softwarelösung raus. Die Herren von Raspbian (IRC) haben keine Idee woran das liegen soll, die Herren von Debian direkt wollen mit PI's nichts am Hut haben :lol:
    Hardwarelösung mit Pulldowns auf Masse (10kOhm) funktioniert einwandfrei. Habe eine Messung mit dem Oszilloskop gemacht, der Transistor hat für ~15ms einen Durchgang. Das kann aber durch ein unsauberes Signal bzw. die Einschaltschwankung? kommen, also im Grundsatz schaltet der GPIO beim booten nicht durch und wird auf LOW gehalten.

    Somit wäre das dann auch geklärt, vielen Dank ;)

Jetzt mitmachen!

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