GPIO Start-Zustand

  • Hallo Leute,

    Zuallererst hoffe ich dass ich hier im richtigen Thread mit meiner Frage gelandet bin :D

    Undzwar geht es um den Zustand der GPIO's nach dem Start des Raspi's.
    Mein GPIO 14 ist automatisch ein Output und auf High-State sobald der Raspi gestartet wird (die anderen Pins nicht). Dies ist natürlich äußerst problematisch wenn nach einem Absturz z.B. irgend ein Motor (oder sonstiges) automatisch angesteuert wird.

    Kann dieses "Startup - Verhalten" softwaretechnisch geändert werden?

    MfG ToTTy

  • Hallo.


    Mein GPIO 14 ist automatisch ein Output und auf High-State sobald der Raspi gestartet wird (die anderen Pins nicht). Dies ist natürlich äußerst problematisch wenn nach einem Absturz z.B. irgend ein Motor (oder sonstiges) automatisch angesteuert wird.

    Kann dieses "Startup - Verhalten" softwaretechnisch geändert werden?


    ...hab da bisher auch nichts vernünftiges gefunden, das einzige war > das < hier.
    Aber während des eigentlichen Bootvorgangs ist eben nichts definiert.

    Vor dem Problem stand ich auch mal, und hab mit mit ner externen Verriegelung geholfen.
    Sprich:
    1 oder 2 GPIO-Pins hernehmen, nach dem booten auf Ausgang setzten, und den/die Pin's für eine gewisse Zeit auf high setzten.... vorher spricht die externe Schaltung nicht an.(Eine von vielen Möglichkeiten)
    D.h eventuelles "Flacken" der Pin's beim booten werden ignoriert.

    gruß root

    Einmal editiert, zuletzt von root (1. August 2015 um 22:48)

  • Hallo ToTTy,

    die Lösung ist nah, nämlich hier!

    Gutes Gelingen

    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 (14. Oktober 2017 um 13:54)

  • Die von euch erwähnten GPIO#14 (und #15) erfüllen Standardmäßig den Zweck einer Seriellen-Linux-Konsole und das auch schon bei Systemstart, worüber man dann den Bootvorgang betrachten könnte, so als wär ein Monitor angeschlossen. Also Ausgaben die direkt vom Linux-Kernel kommen. In erster Linie dient das dem sog. Debugging.

    Ein spezieller Verbindungsaufbau ( Verbindungsaufnahme ), wie es in dem von Andrea's verlinkten Beitrag vielleicht falsch zu verstehen wäre, muss nicht durchgeführt werden, sondern die Daten der Seriellen Konsole werden zumindest auf TxD immer gesendet, egal ob an den Pin etwas angeschlossen ist (solange die Serielle Konsole aktiviert ist).

  • so, jetzt hab ich es.....


    ich hab eine pyton datei in /home/pi/Desktop angelegt (led.py)

    jetzt noch sudo nano /etc/rc.local öffnen und eintragen


    jetzt noch neu starten

    Raspberry Pi 2 Model B SBC [made in the U.K.] / microSDHC 32GB / Raspberry Pi NoIR Kamera-Modul

  • Hallo.
    Das klingt ja alles gut, aber dann stell ich die Frage:

    Wann wird die rc.local ausgeführt, und was ist mit den Pins bis zu diesem Zeitpunkt ?

    gruß root

    Einmal editiert, zuletzt von root (1. August 2015 um 21:56)

  • Hi.


    Die rc.local wird automatisch beim booten geladen, und somit werden auch die entsprechenden gpio's auf Out oder In gesetzt


    ...das ist mir schon klar, aber da hast meine Frage missverstanden :D ...
    was ist mit den Pins bis zum ausführen von rc.local ...bis dahin vergeht Zeit...und zwar nicht wenig.

    gruß root

    Einmal editiert, zuletzt von root (1. August 2015 um 22:05)

  • Hm, das kann ich dir auch nicht wirklich sagen
    Automatisch zusammengefügt:
    Ich hab jetzt noch einmal im Netz nachgeschaut, dort steht..... Standardmäßig sind sie alle als Eingänge außer GPIO 14 & 15 konfiguriert....

    Das kannst du auch hier nachlesen.

    http://www.raspberrypi-spy.co.uk/2012/06/simple…header-and-pins

    Raspberry Pi 2 Model B SBC [made in the U.K.] / microSDHC 32GB / Raspberry Pi NoIR Kamera-Modul

    Einmal editiert, zuletzt von rubi007 (1. August 2015 um 23:07)

  • /etc/rc.local wird ziemlich spät ausgeführt - quasi kurz bevor der Login-Promt kommt.

    Zu dem Zustand der GPIO's:
    Alle GPIO's sind deaktiviert - mit Ausnahme solcher die durch config.txt bzw cmdline.txt und somit beim laden des Kernels aktiviert werden. Dazu gehören Standardmäßig GPIO#14 & #15 -> Serielle Konsole (UART).


  • Hallo ToTTy,

    die Lösung ist nah, nämlich hier!

    Gutes Gelingen

    Andreas

    Vielen Dank,
    Diese Methode hat zumindest den Verbindungsaufbau ("Flackern") des Ports verhindert, jedoch gibt der Port trotzdem ein High-signal aus, sprich das eigentliche Problem ist immer noch vorhanden..

    MfG ToTTy

Jetzt mitmachen!

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