1Hz Signal über GPIO Pin

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    Ich brauche für einen externen Watchdog ein 1 Hz Signal auf einem GPIO Pin. dafür habe ich ein Shellscript mit einer Endlosschleife geschrieben - funktioniert soweit. Ich kann das Script auch per Service beim Booten starten (ARCH. Linux) aber nach ein paar Minuten bekomme ich einen Timeoutfehler. Kann ich das Script irgendwie im Hintergrund starten? Gibt's einen anderen Weg den Ausgang jede Sekunde zu togglen?

    Danke für Eure Hilfe


  • Hallo,

    Ich brauche für einen externen Watchdog ein 1 Hz Signal auf einem GPIO Pin. dafür habe ich ein Shellscript mit einer Endlosschleife geschrieben - funktioniert soweit. Ich kann das Script auch per Service beim Booten starten (ARCH. Linux) aber nach ein paar Minuten bekomme ich einen Timeoutfehler. Kann ich das Script irgendwie im Hintergrund starten? Gibt's einen anderen Weg den Ausgang jede Sekunde zu togglen?

    Danke für Eure Hilfe

    Moin,

    es wäre schön, wenn Du das ein wenig genauer erklären könntest. Ich kann mir nämlich nicht vorstellen wie ein script, das einen Pin der GPIOs mit 1 Hz ansteuert, einen Timeout bekommen soll ...
    ciao,
    -ds-

  • Hab den Code grad nicht da (bin am iPad). Das setzen / rücksetzen des GPIO erfolgt per endlos while -Schleife. Wenn das Script als Service gestartet wird dann würgt der RPi die Ausführung nach einer Weile ab. In systemctl erscheint dann ein Fehler bei dem Service.

    Einmal editiert, zuletzt von mittererr (11. Juli 2013 um 19:55)


  • Hab den Code grad nicht da (bin am iPad). Das setzen / rücksetzen des GPIO erfolgt per endlos while -Schleife. Wenn das Script als Service gestartet wird dann würgt der RPi die Ausführung nach einer Weile ab. In systemctl erscheint dann ein Fehler bei dem Service.

    Dann sei so gut und schick uns mal, wie und wo der Aufruf beim booten erfolgt (/etc/rc.local ?).
    Und dann müsste das - wie Björn meinte - mit nohup und & zu beheben sein ...

    cu,
    -ds-


  • Wenn das Script als Service gestartet wird dann würgt der RPi die Ausführung nach einer Weile ab. In systemctl erscheint dann ein Fehler bei dem Service.

    Du verwendest (wie ich) vermutlich Archlinux als Betriebssystem und hast einen Service dafür eingerichtet.

    Meine Vermutung ist, daß der timeout von systemd ausgelöst wird. Hast Du die Endlosschleife innerhalb des Servicefiles deklariert?
    Ich würde es lieber als Shellscript auslagern und im Servicefile eine Startanweisung dafür geben. Daß Script muß aber als eigenständiger Prozess laufen, damit die systemd Startanweisung sauber beendet werden kann.

    Gruß, mmi

    P.S.: Dir ist aber klar, daß das 1Hz Signal so sehr ungenau erzeugt wird und grosse Toleranzen auftreten. Falls Du mehr Genauigkeit brauchst, muß es systemnäher programmiert werden (z.B. über den DMA-Takt). Dafür gibt es dann auch fertige Libraries.

  • Moin,

    ja genau, ich verwende Arch Linux. Ich bin euch noch den Code von meinem Script schuldig:

    Shellscript:

    Service:

    Der Service wird beim Booten gestartet - nach einiger Zeit kommt allerdings der Timeout. Unter systemctl sehe ich dann in rot meinen Service mit LOAD: loaded, ACTIVE:failed, SUB:failed und systemctl status zeigt mir den Timout.

    Vielleicht nochmal genau zum Hintergrund: Ich möchte mir ein Erweiterungsboard mit einem Watchdog bauen. Der wird per GPIO mit einem "Heartbeat" versorgt. Friert der Raspberry Pi ein (und damit auch dar Heartbeat) löse ich nach 120 Sekunden einen Reset aus.
    Ich habe auch von dem Watchdog gelesen, den der Raspberry standardmäßig mitbringt. Nur wie zuverlässig ist der? Kann man sich darauf verlassen?

    Der Ansatz mit dem DMA Takt klingt sehr interessant - hast Du diesbezüglich nährere Infos? Ist dieser Takt für mein Vorhaben geeignet. Sonderlich genau muss der Takt nicht sein. Der Watchdog Baustein den ich verwende erwartet alle 1.6 Sekunden ein Lebenszeichen vom RPi.

    Danke
    Gruß mittererr

  • Laß das script doch als eigenständigen Prozess laufen, "&" sollte bereits reichen:

    Code
    ...
    ExecStart=/etc/system-heartbeat.sh &
    ...


    "Type=forking" ist meines Wissens für Dämon-Prozesse gedacht, die sich ja selbst passend einrichten. Ich denke, daß so dann ein "type=oneshot" besser passt.

    Der BCM watchdog arbeitet aber auch sehr zuverlässig, habe ihn grundsätzlich zur Überwachung von WLAN in Betrieb! Fällt das aus, erfolgt nicht einfach ein reset, sondern erst ein ordentlicher shutdown - so soll es sein. ;)

    Für Deinen Fall ist die Genauigkeit so ausreichend. DMA ist erst für hohe Anforderungen an Toleranz bzw. Taktung interessant (z.B. für PWM). Die weitverbreitete "wiringpi" lib sollte entsprechende Funktionen beinhalten, ich selbst verwende "pigpio" (look and search in "raspberrypi.org" forum).

  • Moin,

    hey Danke - das "&" hat's gebracht. Jetzt taktet der RPi gemütlich vor sich hin.

    Den BCM Watchdog hab ich probiert. Mit der ForkBomb (: (){ :|:& };:) konnte ich Ihn aber nicht zum auslösen bringen? Das System friert zwar ein aber der WD löst nicht aus. Mein 1Hz Signal friert mit der Fork Bomb jedoch ein und mein externer Watchdog löst aus.

    Von dem harten Reset bin ich auch nicht unbedingt begeistert aber was besseres ist mir noch nicht eingefallen.

    Gibt's zu dem BCM Wachtdoch ne Doku?

    Danke und Schöne Grüße
    mittererr


  • Moin,

    ...
    Den BCM Watchdog hab ich probiert. Mit der ForkBomb (: (){ :|:& };:) konnte ich Ihn aber nicht zum auslösen bringen? Das System friert zwar ein aber der WD löst nicht aus. Mein 1Hz Signal friert mit der Fork Bomb jedoch ein und mein externer Watchdog löst aus.
    ...
    Gibt's zu dem BCM Wachtdoch ne Doku?

    Danke und Schöne Grüße
    mittererr


    Moin, der Herr,

    ob es ne Doku gibt, weiss ich jedtzt nicht, aber vermutlich hast du denselben Fehler gemacht, wie ich anfangs.
    Damit der watchdog funktioniert, musst Du ihm sagen, was er überwachen soll.
    Dazu gibt es die "/etc/watchdog.conf".
    Am einfachsten ist ein ping auf Deinen Router ( steht gleich am Anfang).
    Solange Du da nicht konkret was einträgst, terminiert der watchdog gleich beim Start.

    cu,
    -ds-

  • Ahh - jetzt dämmerts ...

    meine watchdog.conf sieht (noch) so aus:

    Angenommen ich würde jetzt "max-temperature" auf 50 setzen dann löst der Watchdog aus sobald der Core 50°C überschreitet? Mit den "max-load-x" Parametern könnte ich dann auf einfrieren checken oder?

    Mit dem ping schickt er ständig Ping an meinen router. Friert der RPi ein werden auch keine Pings mehr verschickt und der RPi rebootet.

    Hab ich das so richtig verstanden?

  • Genau so isses :) ...

    Ich bin da auch nur aus Zufall drauf gekommen :blush: ...

    Hab mich immer gewundert, warum der Pi nicht rebootet wenn das WLAN weg ist und mir einen entsprechenden shell-script gebastetelt, der den reboot übernahm.

    Wie gesagt - ob es da weiterführende Infos dazu gibt, weiss ich nicht.
    Aber ich bin zufrieden ...

    cheers,
    -ds-

  • "man watchdog" und "man watchdog.conf" beschreiben es recht ausführlich. Kann mir gar nicht vorstellen, daß das bei Debian nicht so ist.

    VG, mmi


  • "man watchdog" und "man watchdog.conf" beschreiben es recht ausführlich. Kann mir gar nicht vorstellen, daß das bei Debian nicht so ist.

    VG, mmi

    Hi mmi,

    ach ne, oder ... :blush:

    grumpf ... da wär ich im Leben nicht drauf gekommen

    ich glaub, ich werd' alt,

    -ds-

  • ach ne, oder ... :blush:
    grumpf ... da wär ich im Leben nicht drauf gekommen
    ich glaub, ich werd' alt,
    -ds-


    Hmm, soll ich das jetzt in Anbetracht des vorausgegangenen Dialogs ernst nehmen oder nicht ? Wohl lieber erstmal nicht.;)

Jetzt mitmachen!

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