Wiringpi vs pigpio GPIO Speed

  • Hi Leute

    habe die max. GPIO Geschwindkeit mit der writingPi (wiringPiSetupGpio) und pigpio Library verglichen.
    Folgenden Ergebnis mit Raspberry Pi Zero.

    pi@raspberrypi:~/bench $ sudo ./gpio_test
    WiringPi GPIO speed test program
    toggle 100 million times ...
    100000000 toggle took 15.736 s, Time per toggle 0.157 us, Freq 6.355 MHz
    pi@raspberrypi:~/bench $ sudo ./gpio_test_pigpio
    pigpio GPIO speed test program
    toggle 100 million times ...
    100000000 toggle took 23.974 s, Time per toggle 0.240 us, Freq 4.171 MHz
    pi@raspberrypi:~/bench $ sudo ./gpio_test
    WiringPi GPIO speed test program
    toggle 100 million times ...
    100000000 toggle took 15.761 s, Time per toggle 0.158 us, Freq 6.345 MHz
    pi@raspberrypi:~/bench $ sudo ./gpio_test_pigpio
    pigpio GPIO speed test program
    toggle 100 million times ...
    100000000 toggle took 24.005 s, Time per toggle 0.240 us, Freq 4.166 MHz


    also
    WiringPi gewinnt mit 6,3 zu 4,2 MHz .

    Einmal editiert, zuletzt von evil (3. Februar 2017 um 21:55)

  • Im Kern sowas

    printf("toggle %d million times ...\n", ToggleValue/1000000);
    gettimeofday(&t1, NULL);
    for (loop=1; loop<ToggleValue; loop++) {
    digitalWrite(GPIO18, LOW);
    digitalWrite(GPIO18, HIGH);
    }
    gettimeofday(&t2, NULL);
    Automatisch zusammengefügt:


    Das Ergebnis WiringPi passt zu den Werten von der Homepage http://codeandlife.com/2015/03/25/ras…gpio-benchmark/
    ca. 1,4 * Pi 1 (700 MHz)

    Einmal editiert, zuletzt von evil (3. Februar 2017 um 22:15)

  • Einmal editiert, zuletzt von evil (3. Februar 2017 um 22:15)

  • Hallo evil,

    vielen Dank für die Testergebnisse.

    Du bist Dir aber schon im Klaren darüber, das ein solcher Test vergleichsweise wenig aussagt? Denn für keine Anwendung geht es darum, mit welcher Frequenz ein GPIO-Status umgeschaltet werden kann. Die meisten Bauteile erwarten Signale, die eine bestimmte Dauer anliegen, um irgendeinen Einfluss zu nehmen.

    Ein Benchmarkt in der Art, wie viele GPIO-Ereignisse können in einer festgelegten Zeit erfasst werden, halte ich da für wesentlich aufschlussreicher. So gehe ich jedenfalls beim aktuellen Testen von Anpassungen meiner aktuellen GPIO-Library vor. Dieses Mal wird's direkt in Assembler geschrieben ...


    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 (3. Februar 2017 um 22:17)

  • Der Test sagt aus:
    - Das WiringPi weniger Zeit braucht um einen GPIO zu setzen als pigpio.
    - Wielange ein minimaler Puls dauert ( T/2) wenn ohne Pause eine High Low Kombination gesetzt wird.

    das ist was ich wissen wollte.

    Für mich persönlich bedeutet das Ergebnis :
    Mein Programm/Klasse für den TM1637 wird nicht schneller laufen wenn ich es auf pigpio portiere.
    Ich brauche unbedingt einen usleep(1) Befehl für den TM1637 da 1µs für die minimale tWAIT Zeit im Datenblatt steht.
    Darum geht das Programm von sd582 nicht (mehr)
    LED 4 Segment I2C Display

    Einmal editiert, zuletzt von evil (3. Februar 2017 um 22:37)

  • Bei mir kommt da auf einem Pi2 was anderes heraus:

    CPU Auslastung geht dabei auf 100% hoch, aber nur ein Core.


    Und nu?

  • Benchmarks sind wie immer mit Vorsicht zu genießen;)

    Ein Handy welches XY :auslachen: Punkte erreicht muss nicht schneller sein als ein Handy welches nur Ab :baeh2: Punkte erreicht!

    Benchmarks sind meiner Meinung nach nicht immer 100% Aussagekräftig.

    Es sind sehr oft nur synthetische Werte :daumendreh2:

    Was ist denn los mit den Emojis...?

    Wenn's brennt 112 hilft weiter!

    Einmal editiert, zuletzt von raspbastler (3. Februar 2017 um 22:46)


  • Aussagen sind oft nicht zu 100% Aussagekräftig oft nur zu 40-50%.

    Worauf war das jetzt bezogen? Klar ist nicht jede Aussage aussagekräftig. Jedoch ist der allgemeine Hinweis, dass Benchmarks die best mögliche Leistung zeigen! Jedoch in der Praxis ganz von denen abweichen...

    [OT]Bestes Beispiel, SSD im Benchmark 500 MB/s lesen, jedoch friert Windows alle 3 Minuten ein.. und ja Neuinstalliert wurde es auch! [/OT]

    Wenn's brennt 112 hilft weiter!

    Einmal editiert, zuletzt von raspbastler (3. Februar 2017 um 22:56)

  • Servus evil,
    danke für die Info ... :thumbs1:
    Ich hab' mich heute schon mal mit _deets_ über das Thema ausgetauscht und auch -> meine Aussage im anderen Thread <- mal entsprechend korrigiert.
    Wobei ich noch anmerken möchte, dass meine Versuche aus den Anfangszeiten der Libs stammen (2013). Einen Versuch mit z.B. der bcm und der wiringPi habe ich -> hier noch gefunden <- ...
    Zu in etwa dieser Zeit wurde mir auch die pippio empfohlen ... die lag halt damals in meinen Versuchen vorn.
    Natürlich haben sich alle drei weiterentwickelt ... so gesehen sind die Aussagen von früher wohl nicht mehr relevant.

    Wobei sich die Aussagekraft eines Tests, der nur aus simplem HIGH/LOW schalten eines I/Os besteht imho auch in Grenzen hält ;)

    Aber wie gesagt, danke für's probieren ...

    cu,
    -ds-

  • hallo.
    ...das ganze kommt mir vor wie Mäuse melken möchten und nicht können... :D

    Wie Andreas schon bemerkte ist doch in erster Linie die Pheripherie der Flaschenhals, und sch... auf ne µS.
    Ich habe für die pigpio vor paar Jahren nen Tipp von nem User hier bekommen und bin dabei geblieben.

    Nicht aus Bequemlichkeit, sondern weil ihr Funktionsumpfang seinesgleichen sucht.

    gruß root

  • Meine Benchmarking-Ergebnisse sind hier zu sehen: https://github.com/deets/pi-gpio-benchmark

    Der Wert dieser Benchmarks ist aber - wie ja auch schon von anderen bemerkt - gering. In dem Moment, wo man etwas sinnvolles machen will (also nicht einfach hard-kodierte Muster auszugeben), werden die Zahlen eh *massiv* einbrechen. Und die Qualitaet des eigenen Codes dominiert dann die Laufzeit.

    Und pigpio hat eine wave-Funktionalitaet. Dort wird mittels DMA (also praesize getaktet!) eine vordefinierte Bitfolge rausgeschoben. Wenn ich so etwas wie evil zu programimeren haette, waere das eh mein Mittel der Wahl.

  • ... wobei man im Falle von wiringPi und direktem lesen/schreiben auf die IO's noch hinzufügen sollte, daß wiringPi sich nicht um Memorybarriers kümmert. Schreib- und Lesebefehle können somit durchaus mal in der falschen Reihenfolge gesendet/gelesen werden. bcm2835 berücksichtigt diese, pigpio hatte ich mir nicht angeschaut.

  • Guter Hinweis! Ich sehe im pigpio-Code erstmal nix in Bezug darauf. Es findet sich zumindest im gesamten Source kein "__sync_synchronize()".

  • Das kann sich auch in inline Assembler verstecken. Etwa so:

Jetzt mitmachen!

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