GPIO14 (Tx, Pin8) normal nutzbar?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Ich zeichne aktuell an einem Schaltplan für eine RTC (DS3231) für den RasPi. Die Besonderheit wird sein, dass die Spannungsversorgung des RasPi nach dem Shutdown komplett abgeschaltet wird, wodurch er sehr stromsparend betrieben werden kann. Über die RTC können bis zu zwei Weckzeiten programmiert werden. Wird eine Weckzeit ausgelöst, aktiviert die RTC einen Timer, der beispielsweise eine Minute läuft. Während dieser Zeit wird der RasPi mit 5V versorgt und kann starten.

    Mein Problem ist, dass ich dafür zwei GPIO benötige. Für die Spannungsversorgung und die Kommunikation per I²C benötige ich die Pins1-6. Nahe liegend wäre jetzt, die Pins 7 und 8 für das Projekt zu nutzen. Bei Pin7 (GPIO04) habe ich wenig Bedenken. Bei Pin8 (GPIO14) sieht es anders aus.

    Ich benötige einen GPIO als Eingang. Er wird über einen hochohmigen Pullup auf HIGH gehalten. Fällt die Spannung der Pufferbatterie (Knopfzelle) unter einen Schwellwert, wird der GPIO dauerhaft auf LOW gezogen. Das Verhalten ist nicht zeitkritisch. Es soll lediglich signalisiert werden, dass die Knopfzelle in naher Zukunft getauscht werden sollte.

    Der zweite benötigte GPIO dient als Ausgang. Er soll nach dem Bootvorgang dauerhaft auf HIGH gestellt werden, wodurch er die Spannungsversorgung (parallel zum Ausgang des Timers) des RasPi eingeschaltet hält . Wird der RasPi herunter gefahren, muss dieser GPIO auf HIGH bleiben, weil er sonst die Versorgungsspannung des RasPi abstellen würde.

    Nun ist die Frage zum einen, ob GPIO14 (Tx) geeignet für diese Aufgabe ist und zum anderen ist die Frage, ob er wirklich "bis zum Schluss" auf HIGH bleibt und erst auf LOW geht, wenn der RasPi komplett herunter gefahren ist.

    Sollte das nicht der Fall sein, müsste ich einen weiteren GPIO anzapfen, der über einen Impuls den Timer startet, so dass der RasPi in Ruhe herunterfahren kann.

  • Hallo Neueinsteiger,

    die Verwendung von GPIO14 (TXD) für diesen speziellen Zweck halte ich persönlich für keine gute Idee.

    Bei den meisten Nutzern, die keine weitere Änderungen vorgenommen haben, dient dieser Pin als serieller Ausgang, um die Bootmeldungen verfügbar zu machen. Dies ist meines Wissenes die einzige Möglichkeit, herauszufinden, was beim Booten vor sich geht, wenn man keinen Bildschirm angeschlossen hat.

    Wenn Du mit Deiner Schaltung diesen Pin zweckentfremdest, beraubst Du andere dieser Debugging-Möglichkeit.

    Was mich aber noch bedenklicher stimmt, ist: Du musst die vollständige TXD-Funktionalität abschalten. Denn TXD pustet bei der Normaleinstellung über rund 20 Sekunden einige kB über die serielle Schnittstelle nach draußen. Das sind so etliche Pegelwechsel, die irgendwo ankommen und ihre Wirkung hinterlassen dürften.

    Ich würde für solche Erweiterung grundsätzlich die Pin 29 bis 40 (sofern mit GPIO-Funktion versehen) dafür einsetzen. Diese Pins werden von keinen 2,x, oder 3,x-Zoll-Bildschirmchen genutzt, es gibt keine Überschneidung der von den RPis A und B genutzten Erweiterungen.

    Der GPIO 14 dient beim Booten also als serieller Ausgang. Nach dem Booten dient er als normaler GPIO. Er kann als Eingang oder Ausgang geschaltet werden, der Pull-Up- oder Pull-Down-Widerstand kann ein- oder ausgeschaltet werden. Die Alternativ-Funktionalitäten können gesetzt werden.

    Nach dem Herunterfahren erhält dieser GPIO14 noch eine weitere Funktion. Bei Anschluss eines bestimmten Widerstandes (müsste ich selber noch mal nachschauen) glimmt eine angeschlossene LED ganz schwach. Heller als bei Schaltung als Output und Setzen auf LOW (logisch, dann leuchtet da gar nichts) - aber wesentlich dunkler als beim Schalten auf Output und Setzen auf HIGH.

    Für mich ist dieser GPIO14 eine sehr wichtige Informationsquelle über den Einschalt-Status des Raspberry Pi:
    - Angeschlossene LED ist aus: RPi ohne Anschluss an die Betriebsspannung
    - LED blinkt: RPi bootet
    - LED leuchtet: RPi ist hochgefahren (Ausnahme: Eine Anwendung nutzt diesen GPIO14 als Eingang oder Ausgang LOW)
    - LED glimmt: RPi ist heruntergefahren, aber hängt noch an der Betriebsspannung und kann jederzeit (z.B. durch Kurzschließen der RUN-Pins) wieder hochgefahren werden

    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 (8. Oktober 2016 um 10:50)

  • Der Pin bleibt zudem nicht bis zum wirklichen runterfahren auf high. Die Variante an einem GPIO den Zustand abzulesen ist sehr vage. Eine Lösung über den Stromverbrauch oder ganz simple mit einer ausreichenden Verzögerung wäre nach meiner Meinung besser.

  • Servus,
    das einzig verlässliche, was mir zum Thema heruntergefahren einfällt, ist die grüne LED, die zyklisch 4mal - so in etwa 0.5 Sek. Takt - blinkt, wenn der Raspi heruntergefahren ist.

    Das mit den UART I/Os finde ich auch eher suboptimal, weil ich gerne die serielle Konsole dort aktiviert lasse um im Falle eines Falles noch ZUgriff auf den Raspi zu haben.

    Aber vielleicht fällt mir noch was ein ...

    cu,
    -ds-

  • Vielen Dank für die Infos und Ideen. Ich werde dann die Finger von Rx und Tx lassen. Da ich den Stecker aber so kompakt wie möglich gestalten möchte, werde ich die nächsten beiden möglichen GPIO nehmen. Das sind GPIO17 und GPIO18 (Pin11 Pin12). Um eine möglichst große Flexibilität zu ermöglichen, wird die Verbindung erst über einen Lötjumper aktiv. Vor dem Lötjumper wird ein Lötauge vorgesehen, über das mit einem kleinen Kabel theoretisch auch jeder andere GPIO statt GPIO17/18 angeschlossen werden könnte.

  • Hallo Neueinsteiger,


    Vielen Dank für die Infos und Ideen. Ich werde dann die Finger von Rx und Tx lassen.


    :thumbs1:


    Da ich den Stecker aber so kompakt wie möglich gestalten möchte, werde ich die nächsten beiden möglichen GPIO nehmen. Das sind GPIO17 und GPIO18 (Pin11 Pin12).


    Da habe ich auch einen Einwand, wenn auch nichts so stark wie bei RX & TX.

    GPIO18 muss öfters mal als PWM herhalten. Und GPIO17 kann als Handshake (RTS) der seriellen Schnittstellen dienen.



    Um eine möglichst große Flexibilität zu ermöglichen, wird die Verbindung erst über einen Lötjumper aktiv. Vor dem Lötjumper wird ein Lötauge vorgesehen, über das mit einem kleinen Kabel theoretisch auch jeder andere GPIO statt GPIO17/18 angeschlossen werden könnte.

    TOP!

    Meiner Meinung nach sind die GPIO27, 22 und 23 am unverfänglichsten.

    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 (8. Oktober 2016 um 12:31)

  • Hallo zusammen,

    meine Frage wäre ähnlich aber dazu hab ich leider bisher nichts eindeutigen gefunden
    und deshalb hier gefragt und nicht als neues Thema.

    Ich möchte die GPIO14/15 Pins als Eingänge nutzen da ich die UART nicht benötige.

    Beim Initialisieren der Pins per GPIO.setup(8, GPIO.IN, pull_up_down = GPIO.PUD_DOWN) erhalte ich eine Warning das
    der Pin bereits in Verwendung sei. Ich möchte es jedoch nicht einfach Testen und 3.3V auf den Pin legen.

    Kann ich UART nicht einfach deaktivieren und die Pins normal als GPIO verwenden?
    Wenn Ja wie deaktiviert man URAT das die Pins frei sind?

    Grüße coprea

  • Hi,

    ok den UART möchte ich nicht nutzen da es für das Projekt nicht erforderlich ist.
    Danke für den Link.

    Ich werde es testen :)

    Grüße und einen schönen Sonntag noch!


  • ok den UART möchte ich nicht nutzen da es für das Projekt nicht erforderlich ist.

    Hallo coprea,

    wenn Du ein unverändertes Betriebssystem (Beipiel Raspbian) verwendest, dann fungiert der GPIO 14 als TX der seriellen Schnittstelle /dev/ttyACM0 - das heißt er sendet die Meldungen, die beim Booten abgesetzt werden. Der GPIO15 fungiert als RX - ist also bereit sals Eingang geschaltet.

    Beim Booten befinden sich diese beiden GPIOs in der Alternativfunktionaölität Alt0.

    Erst nach dem vollständigen Hochfahren werden diese beiden Pins in die GPIO-Funktionalität versetzt. Erst dann kannst Du sie als Eingänge schalten.

    Deswegen musst Du die Alt0-Funktionalität ausschalten. Eine Suche

    Code
    Raspberry Pi serielle Schnittstelle deaktivieren
    Raspberry Pi how to deactivate the serial device


    wird Dich zu Lösungsansätzen führen.

    Wenn Du keinen Bildschirm angeschlossen hast, beraubst Du Dich allerdings der dann einzigen Diagnosemöglichkeit, wenn Du die serielle Schnittstelle dauerhaft deaktivierst.

    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 (30. Oktober 2016 um 12:17)

Jetzt mitmachen!

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