RPi.GPIO vs. gpiozero - Latenz beim Aufruf

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

    vor einiger Zeit hatte ich mit meiner Schloss-Steuerung von RPi.GPIO nach gpiozero gewechselt. (Link zum Thema)

    Warum? Naja, weil einem jeder erzählt RPi.GPIO ist veraltet, das neue gpiozero ist besser, schöner, einfacher...

    Seit diesem Wechsel reagiert meine Steuerung erst nach einer Verzögerung von fast 1 Sekunde.

    Ich hab das mal mit 2 einfachen Scripten nachgestellt und meine Vermutung, dass das tatsächlich an gpiozero liegt, hat sich bestätigt.

    Bei diesem Script startet der Motor quasi sofort:

    Und bei diesem erst mit ca. einer halben Sekunde Verzögerung :sleepy: :

    In einem anderen Beitrag las ich, dass gpiozero sowieso auf RPi.GPIO aufsetzt, dann kann letzteres ja eigentlich auch nicht veraltet sein (Beitrag #7). Denke mal das ist auch der Grund für die Verzögerung.

    Meine Frage: Kann man diese Verzögerung irgendwie wegbekommen/verkürzen oder hilft da nur wieder RPi.GPIO direkt zu verwenden?

    • Offizieller Beitrag

    Deshalb schrieb ich

    Im Hauptskript, in dem Du auch den anderen Kram regelst (RFID-Karten usw.) würde ich when_pressed verwenden und das obige Skript-Beispiel wirklich nur für SSH-Button nutzen. Der Punkt ist die etwas längere Dauer der Initialisierung bei gpiozero.

    Das Schalten per SSH-Button ist ja, wenn ich das richtig in Erinnerung habe, eh eher selten und da würde mich persönlich eine Verzögerung nicht stören. Darum geht es Dir aber oder?

  • Das Schalten per SSH-Button ist ja, wenn ich das richtig in Erinnerung habe, eh eher selten und da würde mich persönlich eine Verzögerung nicht stören. Darum geht es Dir aber oder?

    Hi Hyle, nein, darum geht es nicht. Deshalb habe ich auch diese beiden einfachen Scripte oben erstellt, dass da keine anderen Faktoren mit reinspielen wie von dir angesprochen. Nur Motor an Motor aus Script Ende.

    Ich starte beide in der Konsole mit ./name.py und dann geht beim ersten Script der Motor direkt los, und beim zweiten dauert es etwas.

    Hängt jetzt auch nicht am Motor, den gleichen Effekt stelle ich fest wenn ich eine LED an und ausschalte. Mit gpiozero dauert es einen Moment bis die LED leuchtet. Wenn ich das über RPi.GPIO mache reagiert die LED sofort. Probier es mal selber aus. Achja, ich mache das ganze auf einem Pi Zero, ist der vielleicht zu schwach für gpiozero?

    • Offizieller Beitrag

    Probier es mal selber aus.

    Ich hatte schon verstanden was Du meinst und kenne diesen Effekt. (Siehe zweiten Satz in meinem Zitat oben! ;))

    Wenn das Skript aber erstmal läuft und ein Motor oder eine LED z.B. per Taster o.ä. gesteuert werden soll, dann gibt es keine Verzögerungen.

    Achja, ich mache das ganze auf einem Pi Zero, ist der vielleicht zu schwach für gpiozero?

    Bei mir macht das keinen so großen Unterschied, aber auf meinem Test-Zero ist nur ein Raspberry Pi OS Lite und faulenzt vor sich hin.

  • ch hatte schon verstanden was Du meinst und kenne diesen Effekt. (Siehe zweiten Satz in meinem Zitat oben! ;) )

    Wenn das Skript aber erstmal läuft und ein Motor oder eine LED z.B. per Taster o.ä. gesteuert werden soll, dann gibt es keine Verzögerungen.

    Sorry, ich hatte meine Antwort auf das SSH bezogen.

    Aber jetzt verstehe ich was du mit diesem Satz gemeint hattest. Genau diese Initialisierung, kann man die beschleunigen?

    Bei mir macht das keinen so großen Unterschied, aber auf meinem Test-Zero ist nur ein Raspberry Pi OS Lite und faulenzt vor sich hin.

    Bei mir ist auch nicht mehr drauf.

    Bei einer früheren Version von gpiozero gab es ja wohl schon mal so ein Problem (Link nach draußen), dass dann mit einem Upgrade behoben wurde. Ich hatte die Frage hier gestellt, in der Hoffnung, dass es ich bei meiner Verzögerung wieder um so etwas handelt und behoben werden kann.

  • Mach mal ein:

    Code
    print(motor.forward_device.pin_factory)

    Es ist ein wenig komisch, da ich selbst mit dem Package arbeite und recht gute Reaktionszeiten erziele (Seriell 9600 Baut + gpiozero).

    Die Klasse Motor nutzt DigitalOutputDevice, um die Ausgänge ohne PWM zu schalten.

    Die Klasse LED auch.

    Dann probier mal folgendes:

    Python
    import time
    from gpiozero import LED
    
    motor_a = LED(14)
    motor_a.on()
    time.sleep(1)
    motor_a.off()
  • Hallo,

    bei mir auf dem Pi Zero braucht gpiozero auch spürbar lange, um importiert zu werden. Meine _Vermutung_ ist, dass gpiozero wesentlich mehr beim importieren instanziert / initialisiert.

    Stören tut's mich nicht, weil a) der Pi Zero so oder so "lahm" ist und b) wenn gpiozero einmal importiert ist alles "normal" schnell läuft.

    Wenn du wissen willst, was beim Importieren von gpiozero abläuft -> Quellcode lesen. Oder einen Profiler laufen lassen:

    Python
    >>> import cProfile
    >>> cProfile.run('import gpiozero')

    Gruß, noisefloor

  • Mach mal ein:



    Code print(motor.forward_device.pin_factory)

    <gpiozero.pins.rpigpio.RPiGPIOFactory object at 0xb6418ef0>

    Dein Beispielcode lässt den Motor zwar laufen aber leider nicht mehr ausgehen. Warum auch immer. Das motor_a.off() greift nicht.


    Ist es überhaupt sinnvoll auf Python zu setzen, wenn es nur um die Geschwindigkeit geht ?

    Da sollte irgendwas mit C doch schneller sein.

    Es geht mir nicht mal um die Geschwindigkeit an sich, eine Sekunde, damit kann ich bei der Anwendung schon noch leben, es irritiert mich lediglich, dass wenn ich einen Schalter umlege und dann erst eine ganze Maschinerie anläuft nur um ein simples "an" zu schalten.

  • Ist es überhaupt sinnvoll auf Python zu setzen, wenn es nur um die Geschwindigkeit geht ?

    Da von einer halben Sekunde die Rede ist, nein.

    Außerdem bleibt so ein Motor nicht sofort stehen, es seiden man schließt ihn Kurz (H-Brücke)

    EDIT:

    Da haben sich unsere Antworten überschnitten.

    Dass du ihn nicht mehr ausschalten kannst, ist schon mehr als komisch.

    Jedenfalls nutzt dein gpiozero aktuell RPi.GPIO als Backend. Ich hatte vermutet, dass gpiozero ein andere kaputtes Backend verwendet.

    Ist aber nicht der Fall.

  • Wenn du wissen willst, was beim Importieren von gpiozero abläuft -> Quellcode lesen. Oder einen Profiler laufen lassen:



    Python >>> import cProfile >>> cProfile.run('import gpiozero')

    Das gibt bei mir eine Fehlermeldung:

    Code
    Traceback (most recent call last):
      File "./profile.py", line 5, in <module>
        import cProfile
      File "/usr/lib/python3.7/cProfile.py", line 10, in <module>
        import profile as _pyprofile
      File "/home/pi/Motor/profile.py", line 6, in <module>
        cProfile.run("import gpiozero")
    AttributeError: module 'cProfile' has no attribute 'run'

    Was macht denn dieses cProfile?


    Da haben sich unsere Antworten überschnitten.

    Dass du ihn nicht mehr ausschalten kannst, ist schon mehr als komisch.


    Jedenfalls nutzt dein gpiozero aktuell RPi.GPIO als Backend. Ich hatte vermutet, dass gpiozero ein andere kaputtes Backend verwendet.

    Ist aber nicht der Fall.

    Hab den Code mit anderen Pins an einer LED probiert, die geht an und aus.

    Jetzt noch mal die Motorpins auf die von der LED gesteckt, den gleichen Code gestartet, Motor geht an und nicht mehr aus.

  • Nachtrag: habe es gerade auf meinem Pi Zero ausprobiert, funktioniert. Python Version ist 3.7.3:

    Die komplette Ausgabe kann ich leider nicht posten, weil die Länge eines Forenposts wohl auf 50.000 Zeichen begrenzt ist - die Ausgabe ist aber länger.

    Gruß, noisefloor

  • Ist es überhaupt sinnvoll auf Python zu setzen, wenn es nur um die Geschwindigkeit geht ?

    Da sollte irgendwas mit C doch schneller sein.

    Hallo Fred0815,

    genau aus diesem Grund habe ich mal eine GPIO-Library in Assembler programmiert.

    Schneller geht's nimmer. Da kann selbst C-Compilat nicht mehr mithalten, da hier selbst bei diversen Optimierungen immer noch Objektcode erzeugt wird, der überflüssig ist bzw. nichts außer Verlangsamung beiträgt.

    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.

  • Ja, gibt es hier. Erwartungsgemäß schneidet RPi.GPIO ziemlich gut ab.

    Mit C ist das natürlich nicht vergleichbar.

Jetzt mitmachen!

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