GPIO Status bei Stromausfall beibehalten

  • Ich suche nach einer Möglichkeit um elektronisch den Status eines GPIO Pins an einem Micro-Controller über einen Stromausfall hinweg zu erhalten um diesen nach einem Neustart softwaremässig wieder einzulesen um mit dem Status vor dem Stromausfall fortzufahren.

    Es geht also darum softwaremässig beispielsweise den Zustand einer LED an einem andern Pin in den Zustand vor dem Stromausfall zu setzen. Eine Möglichkeit bestünde darin den Status über ein bi-stabiles Relais zu setzen und diesen beim Programmstart abzufragen.

    Da ich gerade kein passendes Relais zur Verfügung habe stellt sich folgende Frage:

    Gibt es noch andere Möglichkeiten, die möglichst wenig Platz benötigen und einfach zu beschaffen/bauen sind (z.B. einfache Schaltung mit Kondensator)?

    Voraussetzungen:

    • eine Statusänderung darf maximal 1.2 Sekunden dauern
    • der Status muss bei Stromausfall mindestens 24 Stunden (besser 72 Stunden) garantiert erhalten bleiben
    • es darf auch mehr als ein GPIO Pin verwendet werden, falls dies etwas bringt
    • es muss mit bis zu ca. 6'000 Statusänderungen pro Tag gerechnet werden
    • die Schaltung muss insgesamt mindestens 500'000 Statusänderungen aushalten (12 Wochen)


    Ist das überhaupt machbar?

  • Hallo pgloor,

    ich würde das softwaretechnisch lösen, indem bei jedem Wechsel eines GPIO-Status (egal ob als Ausgang oder Eingang gesetzt) der aktuelle Status gespeichert wird.

    Ich will jetzt keine Werbung für meine GPIO-Library machen. Aber da wäre es ganz einfach, weil man da nur die Variable GPIO_TABLE zu speichern braucht. Diese wird bei jedem Umschalten von und zu Eingang / Ausgang aktualisiert, ebenso auch bei Änderung der Pegel.

    Und das Speichern würden diese Zeilen erledigen:

    Code
    procedure save_GPIOstatus(filename)
       if fh := open(filename, "w") then
       {   every x := key(GPIO_TABLE) do
           {   write(fh, x,":", GPIO_TABLE[x].pin, ",", GPIO_TABLE[x].direction, ",", GPIO_TABLE[x].value)
               # Kurzform: every write(fh, !GPIO_TABLE[x])
           }
           close(fh)
       }
    end

    Bei einem Neustart müsste Deine Anwendung dann nur diese Datei einlesen und die Einstellungen in GPIO_TABLE übertragen.


    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 (20. Oktober 2016 um 21:45)

  • ich würde das in Hardware lösen, hinter jedem GPIO ein RS-Flipflop mit Enable, das Enable aus einem Schieberegister, ohne das es geladen wird kann kein Signal die GPIO ändern.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Es geht beim Projekt um eine Art programmierbarer Timer zur synchronisierten Steuerung mehrerer Projektoren in einer Ausstellung. Wichtig ist dabei, dass die Show nach einem Stromausfall genau dort weitergeht, wo sie beendet wurde.

    Inzwischen habe ich die genauen Daten und Öffnungszeiten zur Ausstellung erhalten, womit sich die Bedingungen drastisch verbessert haben. Wenn der Strom ausserhalb der Öffnungszeiten, z.B. über eine Schaltuhr gesteuert, strikt ausgeschaltet wird, komme ich auf weit unter 100'000 Statusänderungen über den Zeitraum der Ausstellung hinweg und kann somit das EEPROM des Micro-Controllers nutzen.

    Zentris: Es handelt sich um einen Helvetino (minimalistischer Arduino zum selber löten) mit einen Atmega 328P-PU mit Arduino Bootloader. Das Problem ist, dass das EEPROM nur für 100'000 Write/Erase Vorgänge ausgelegt ist und der Flash-Speicher sogar nur für 10'000. Bei der gestern noch erwarteten Anforderung von rund 500'000 Statusänderungen war das keine Option.

    jar: An sowas hatte ich auch gedacht. Wenn ich das, was ich über RS-Flip-Flops gelesen habe, richtig verstanden habe, funktionieren die aber auch nur bei permanenter Stromversorgung. Obwohl sich das Problem für mich jetzt erledigt hat, interessiert mich das Thema Hardware-Lösung immer noch.

    Andreas und meigrafd: wie erwähnt, handelt es sich um einen Microcontroller und nicht um den Raspberry Pi, deshalb kann ich die Daten auch nicht auf der SD-Karte speichern. Ich hatte das Projekt zwar ursprünglich für einen Raspberry Pi Zero vorgesehen, konnte damals aber keinen bekommen und bin dabei bei meinen Recherchen auf den Arduino, bzw. den ATmega 328 gestossen. 100'000 Schreib-/Löschvorgänge waren für mich eine grosse Zahl und ich hätte nie gedacht, dass das zum Problem werden könnte. Erst bei der Ausprogrammierung der letzten Details wurde ich mir bewusst, wie viel da theoretisch zusammenkommen kann.

  • auch RS FlipFlops kann man mit Batterie puffern, aber es gibt auch SRAM mit Batterie oder man baut es, ist eigentlich egal. Dann gibt es noch FRAM welches ohne Batterie auskommt oder man baut ein (micro)SD Shield an aber dann hat man wieder flash mit begrenzter Scheibzahl, wobei die CT ja feststellte das es normalerweise nicht kaputtzuschreiben geht und man kann ja die Daten auch mehrfach verteilt schreiben.

    Wenn es nur um GPIO Zustände geht sind das ja nur wenige Bits, das kann ich 100 oder 1000 mal auf eine SD schreiben und wenn einige Blöcke Fehler bekommen dann eine Meldung ausgeben das die SD getauscht werden muss!
    Dito bei USB am PI

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Auch mit einem Arduino kannst du Daten auf eine SD via Shield speichern, ansonsten schließt du halt einen separaten EEPROM an der dann auch mehr Kapazität hätte als der interne Siehe dazu zum Beispiel "EEPROM Shield With 256K AT24C256" bzw https://github.com/cbxbiker61/XilkaEEPROM

    Alternativ baust du dir halt eine art USV dran, die bei Verlust der Hauptstromversorgung dein Steuergerät noch eine gewisse Zeit mit Strom versorgt und zugleich einen I/O auf LOW schaltet woraufhin dein Steuergerät erst dann die letzten Schaltzustände sicher speichert - dadurch reduzierst du die Schreibvorgänge drastisch da nicht _jedesmal_ beim schalten der Zustand auch noch gespeichert werden müsste.

  • pgloor:
    Das mit dem "erase" hab ich nicht verstanden: Ändert sich die Anzahl der GPIOs denn ständig?

    Noch ein paar Realisierungsideen (ohne das Projekt detailierter zu kennen... könnte daneben liegen :) :(
    Um die Schreib/Löschrate gering zu halten , könnte man den Status (ein/aus ?) als Bit speichern. Pro Byte lassen sich somit 8 Zustände ablegen.

    Ok, der Codier/Decodieraufwand des Backups steigt etwas, aber das ist letztlich vermutlich egal, das macht man einmal...
    Für den EEPROM muss man sich 'eh eine eigene Struktur ausdenken. Da könnte man (Vorsicht: weiter steigender Aufwand) sogar ein "rolling write" durch den Speicher bauen, um die Zellen gleichmäßiger auszulasten.

    Andererseits: Ändert sich denn der Zustand so oft? Also wirkliches Ändern!
    Sonst schreibt man (nach vorherigem lesen) nur, wenn sich der Zustand wirklich verändert hat, das sollte die Schreiblast der Zellen weiter verringern.

    Interessante Aufgabenstellung! :thumbs1:

    Grüße, das Zen

  • Ich führe mal Meigrafd's Idee der USV fort...

    Wenn da schon ein Arduino vorhanden ist, wieso dann nicht die Speisespannung des Arduino in einem Kondensator puffern und über 3 Shottkydioden sicherstellen, daß die Stromrichtung paßt. Zusätzlich noch eine Spannungsüberwachung per Analogeingang des Arduino, damit er merkt, wenn der Saft aus dem Netzteil zusammenbricht. Braucht in der Summe:

    • 1 Widerstand zur Strombegrenzung beim Laden des Kondensators
    • 1 Kondensator
    • 2 Widerstände als Spannungsteiler zur Analogmessung
    • 3 Schottkydioden, damit der Saft in die richtige Richtung gezwungen wird
    • 1 Stück Universalleiterplatte.


    Dann erkennst Du zyklisch den Stromausfall und speicherst Deine Werte in das Eeprom. Macht einen Schreibzugriff pro Stromausfall. Die Kosten für obige BOM sollten gerade noch verschmerzbar sein :)

  • schnasseldag: genau wonach ich gesucht habe. Ich werde das demnächst mal realisieren und testen.

    N.B. Dank diesem Forum und eurer Hilfe ist mein erstes Projekt jetzt fertig und braucht nur noch ein paar kleine Anpassungen an der Software. Vom 9V Eingang über den Atmega 328 bis zu den DIN Steckern, inklusive Relais Modulen, Potis und Kontroll-LED's alles selber zusammengebaut und gelötet, das hätte ich mir vor 2 - 3 Monaten nie zugetraut.

  • Schön, wenn Du Freude und Erfolg dabei hast!
    Noch ein kleiner Nachtrag. Im Prinzip brauchst Du keine Schottkydioden verwenden. "Normale" reichen auch, dann ist der Spannungsabfall lediglich ein wenig höher, was sich aber durch eine etwas größere Dimensionierung des Netzteils kompensieren läßt (so das überhaupt notwendig ist).

Jetzt mitmachen!

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