GPIO Write ohne Pause

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

    in diesem Tutorial
    Bitschiebereien Teil 1: 74HC595 mit 8 LEDs am Raspi

    wurde folgende Code programmiert.


    gpioWrite(clockPin, PI_HIGH);
    gpioWrite(clockPin, PI_LOW);

    Ich stelle aml die Frage: Ist das korrekt? Ist dem Programmierer klar das wir uns hier im 10 MHz Bereich bewegen.
    Wie ist das bei der nächsten Raspberry Pi die noch schnellere IOs hat (Pi2, Pi3)

    Müsste es nicht heißen


    gpioWrite(clockPin, PI_HIGH);
    usleep(1)
    gpioWrite(clockPin, PI_LOW);


    Habe hier im Forum mal einen Code gefunden der nicht funktioniert hat in C aber in Python.
    Ein paar usleeps rein und schon lief er wie gedacht.
    LED 4 Segment I2C Display

    Einmal editiert, zuletzt von evil (2. Februar 2017 um 14:53)

  • Aus dem Kontext gerissen magst du Recht haben - aber dreamshader schreib da drüber: Software-Beispiel.
    Daher würde ich das erst mal nur als Anschauungsbeispiel betrachten, nicht zwangsläufig als 1:1 Kopie eines lauffähigen Programms. Allerdings könnte man auch die Funktionsbeschreibung beachten und könnte daraus den Schluss ziehen dass das schon so funktioniert und auch beabsichtigt ist

    Ich frage mich allerdings was Du mit deinem Thread nun möchtest?
    Was möchtest du wissen?

  • Servus,
    ich hatte mich auch gefragt, ob irgendein delay() nötig ist.
    Im Datenblatt wird die max. Frequenz von STCP/SHCP mit 52 MHz angegeben, die Mindest-Pulsweite mit 5 ns ...
    Ich hab' mir dann keinen Kopf mehr drum gemacht, weil man beim Raspi Pulse mit 5 ns imho nicht mehr handeln kann ...

    Aber: guter Hinweis ... den nehm' ich mal auf, wenn es Probleme geben sollte.

    meigrafd: passt schon ... ist vielleicht tatsächlich einen Hinweis wert ;)

    cu,
    -ds-

  • Hallo evil,

    warum sollte es nicht korrekt sein?

    Es wird ein "Clock-Pin" angestoßen. Da bedarf es nicht unbedingt einer Pause zwischen HIGH und LOW. Kann man machen, muss man nicht. Ansonsten gilt, was der Baustein im Datenblatt erwartet.
    Es gibt z.B. SPI-fähige Chips, die einen Pegel von mindestens 85 µs erwarten, damit die ihre Betriebsart umschalten. Da ist eine leichte Verzögerung sinnvoll - auch wenn man feststellt, dass es auch ohne geht.


    Wenn eine LED angesteuert werden soll, klar, die sollte länger als ein paar ms leuchten, damit man eine Änderung wahrnehmen kann.

    Aber gut aufgepasst!

    EDIT: Dreamshader hat schon aufgeklärt... Bei 5 ns würde ich mir auf dem RPi auch keine Gedanken zu machen. Da reicht ein HIGH-LOW ohne Verzögerung.


    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 (2. Februar 2017 um 15:04)

  • Ne ... is schon ok ... nobody is perfect und da bin ich mit Sicherheit keine Ausnahme ;)

    Meine Denke war halt, dass es vermutlich schon mehr als 5 ns dauert, bis der 2te gpioWrite() ausgeführt wird.
    Im Zweifelsfall hätte man mal ausrechnen müssen, wie lange so ein gpioWrite() dauert.

    Bei SPI/I2C sieht das anders aus, keine Frage ... da spielt oft das Timing eine wichtige Rolle.

    Jedenfalls danke, dass Du meiner Bitte nach einem eigenen Thread gefolgt bist.

    cu,
    -ds-


  • Bei der Pi3 sind wir da bei 0,07 µs (wiringPi GPIO speed).

    wiringPi ist langsam :fies:
    Google mal nach: raspberry gpio benchmark
    wiringPi bewegt sich laut dieser Messung beim Pi2 bei umdie 9 MHz, "Native Library" aber bei umdie 40 MHz - alles C versteht sich. Folgendes ist auch sehr interessant: https://github.com/hzeller/rpi-gpio-dma-demo

  • Ich setzte auf eine kompatible Library und nicht auf eine schnelle. Orange Pi Banana Pi und Raspberry Pi Support bei WiringPi vorhanden.
    Aber vielleicht hab ich mal Zeit das bei anderen Librarys auszumessen. Gut zu wissen das da noch was geht.
    Automatisch zusammengefügt:
    http://codeandlife.com/2015/03/25/ras…gpio-benchmark/

    pigpio fehlt leider, Python ist richtig übel fast faktor 100

    Einmal editiert, zuletzt von evil (2. Februar 2017 um 15:41)

  • Ja, das ist wohl wahr, dass wiringPi eher langsam ist.
    Ich verwende u.a. deshalb die pigpio Lib.
    Der Hinweis von evil war jedenfalls gar nicht sooo weit hergeholt. Bei zweimaligem Setzen hintereinander direkt über die Register in Assembler könnte man den 5 ns vermutlich schon sehr nahe kommen ...

    cu,
    -ds-

  • Da könnte _deets_ Näheres zu sagen. Ich glaube, der hatte die wiringPi mal (teilweise?) zerpflückt und kam zu dem Schluß, dass sie ziemlich ungünstig implementiert ist. Aber frag' mich jetzt nicht, ob er das hier irgendwo veröffentlicht hat.
    Fakt ist, dass ich vor einiger Zeit massive Probleme mit zwei Servos hatte. Damals wies sogar der Autor von wiringPi auf seiner Website drauf hin, dass PWM auf mehr als einem GPIO Probleme machen würde. Den Link habe ich aber nicht mehr gefunden ... k.A. warum ...

    cu,
    -ds-

  • Hi Dreamshader,


    Der Hinweis von evil war jedenfalls gar nicht sooo weit hergeholt. Bei zweimaligem Setzen hintereinander direkt über die Register in Assembler könnte man den 5 ns vermutlich schon sehr nahe kommen ...

    Wenn Du in Assembler einmalig die gemappten virtuellen Adressen eines bestimmten Pins ermittelt hast und einen Aufruf hast, der Dir nur die Bits in den drei erforderlichen Registern schubst, dann kommst Du irgendwo in den Bereich von 15 bis 20 ns (ich bin da gerade noch dran, zu optimieren - bin aber jetzt schon total begeistert!).

    Plausibilität: 700 MHz => 1 Takt entspricht 1,4 ns
    Die meisten ARM-Befehle brauchen 3 bis 5 Taktzyklen
    Eine handvoll Bitschubser sind für's Setzen eines GPIO-Pins erforderlich. 5 Bitschubser * 3 Taktzyklen / Bitschubser * 1,4 ns / Taktzyklus = 21 ns.

    Das Ganze wäre allerdings Augenwischerei, denn dies bedeutet, dass man z.B. für den GPIO17 die Adresse im virtuellen Speicher kennt (gespeichert hat), um den Pin auf 0 oder 1 zu setzen oder auszulesen (sind 3 verschiedene Adressen, die in 3 Speicherzellen hinterlegt werden. Dann schubse ich die Bits rein und raus, lasse einen Zähler zählen, damit ich weiß, wie viele Ereignisse pro Sekunde zusammen kommen. Vielleicht zähle ich auch nicht, sondern setze das Ergebnis in einen Puffer. Die Größe des Puffers bzw. Abstand zwischen Beginn und aktuellem Index entspricht der Anzahl der Vorgänge. Oder ich messe die Zeit, um einen definierten Puffer mit GPIO-Ereignissen voll zu schreiben. Oder ...

    D.h., allein der Messvorgang, um die Geschwindigkeit bestimmen zu wollen, verdopelt die dafür erforderliche Zeit. Da liegen wir bei 40 bis 50 ns wohl eher richtig.


    Da dies nicht die Denke von allgemein einsetzbaren Libraries ist, kann eine "normale" Library da auch nicht annähernd mithalten. Die ermittelt jedes Mal aufs Neue die virtuelle Adresse.


    Was die Sachen mit der nativen Library noch interessanter macht, dass man bis zu 31 GPIO-Pins gleichzeitig auslesen bzw. setzen kann. Und der Vorgang dauert genau so lange wie mit einem Pin.


    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 (2. Februar 2017 um 16:19)

  • naja ... lass' das im Kernelspace ohne mapping direkt in Assembler laufen, dann kommen wir da schon ziemlich nahe dran ...
    Aber das ist jetzt alles absolute Labor-Theorie.
    Im echten Leben läuft das im Userspace, unterliegt dem Scheduling, ...

    Trotzdem ... den Hinweis find ich gut und hab' ihn auch gleich in das Tut eingebaut. Ich kann mir ausserdem gut vorstellen, dass die hier gesammelten Infos auch für andere Bereiche ziemlich interessant sein könnten.

    cu,
    -ds-

  • Servus evil,


    ... Werd dem mal nachgehen sollte in ein paar Minuten erledigt sein (GPIO).

    bist Du mit Deinen Recherchen schon weitergekommen?

    So wie es aussieht, muss ich meine Aussage bezüglich "langsam" revidieren ...
    Ich hatte das angenommen, u.a. weil eben max. ein Software-PWM Signal möglich war und pigpio auch zwei problemlos schafft (u.a. wohl weil sie den DMA Takt nutzt).
    _deets_ hatte ja "nur" die Implementierung als nicht unbedingt optimal eingestuft.
    Das lässt aber zunächst mal keinen Rückschluß auf die Performance zu.
    Kann also leicht sein, dass ich mit meiner Annahme da falsch liege ...


    cu,
    -ds-

Jetzt mitmachen!

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