C/C++ GPIO lib: pigpio oder WiringPi?


  • Habe jetzt in der WiringPi lib auch eine Funktion entdeckt für Pinchange-IRQs auf ARM-Prozessor-Ebene (!).

    Achtung, das suggeriert nur, ein Interrupt zu sein. Tatsächlich handelt es sich um eine vom Broadcom gelatchte Flankenänderung, die per Thread gepollt wird. Mit echtem Interruptverhalten hat das nix zu tun. Ähnliches bietet der MCP23017 auch an. Damit wirst Du so jitterhaft benachrichtigt, wie eben Threads jittern. Und der Thread setzt auch nur seinen nice level höher. Ein RT Thread ist es auch nicht, der da pollt.

  • uuups, da kann man mal sehen... :(

    Es zeigt sich also tatsächlich, dass ein Raspi mit Raspbian nicht für zeitkritische Dinge geeignet ist, und wegen seiner sehr sparsamen Schnittstellen (nur je 1 UART und nur 1 I2C, nur 1 Hardware-PWM, und überhaupt keine ADC - CMIIW !) auch kaum zur Robotersteuerung geeignet ist, zumindest verglichen mit Arduino Mega (AVR) und Due (ARM).
    Für 4 Motoren bräuchte ich ja 8 pins mit den PC-IRQs aber auch zusätzlich noch 4 pins mit Hardware-PWM /enable (plus unabhängig davon aber auch 8 einfache pins für dir) !!
    Das muss man also offenbar alles "outsourcen". :(
    Immerhin ist dann aber wiringPi zumindest kein Nachteil gegenüber pigpio, soweit ich erkennen kann.

    Einmal editiert, zuletzt von HaWe (18. Oktober 2015 um 12:01)


  • Es zeigt sich also tatsächlich, dass ein Raspi mit Raspbian nicht für zeitkritische Dinge geeignet ist, und wegen seiner sehr sparsamen Schnittstellen (nur je 1 UART und nur 1 I2C, nur 1 Hardware-PWM, und überhaupt keine ADC - CMIIW !) auch kaum zur Robotersteuerung geeignet ist, zumindest verglichen mit Arduino Mega (AVR) und Due (ARM).
    Für 4 Motoren bräuchte ich ja 8 pins mit den PC-IRQs aber auch zusätzlich noch 4 pins mit Hardware-PWM /enable (plus unabhängig davon aber auch 8 einfache pins für dir) !!

    Das ist relativ. Es gibt ja durchaus eine Anzahl Roboter, die nur PI-basiert rumfahren. Aber du hast Recht: ein uebliches Design fuer Roboter ist einen uC fuer die harte IO zu verwenden, und den PI die uebergeordneten Planungsaufgaben machen zu lassen.

    Ich verwende dazu zB das PropellerHAT Shield von Pimoroni.

    Denn auf deinem Arduino wirst du mit der Verarbeitung von Laserscanner Daten etc. nicht wirklich gluecklich. Der wuppt das einfach nicht.

    Und du wiederholst, dass der PI ja nur einen I2C Bus hat. Das mag gelegentlich stoeren, aber der I2C heisst ja nicht umsonst "BUS" - da kannst du auch ein dutzend Slaves dranhaengen. Das mag nicht immer gut sein, aber fuer sehr viele Anwendungen sehr wohl.

  • HaWe: Deine erste generelle Aussage zu Schnittstellen und Echtzeitverhalten würde ich mal tendenziell mit "Ja" beantworten, wenngleich der Begriff der Echtzeitfähigkeit immer unter dem Aspekt der Anwendung zu beurteilen ist.

    Ob wiringPi besser oder schlechter als pigpio ist, vermag ich nicht zu beurteilen - ich hab' mir pigpio nicht angesehen, geschweige denn Messungen mit ihr angestellt. Allenfalls kann ich noch den Vergleich zu bcm2835 ziehen. Diese Lib implementiert z.B. keinen Thread, der Dir die gelatchten "Interrupt"-Stati als Callback herausreicht. Damit fehlt auf der einen Seite Komfort, auf der anderen Seite ist man aber auch nicht auf die Threadimplementierung der wiringPi Lib festgenagelt, sondern kann sich sein eigenes Verhalten (u.U. sogar unter der Berücksichtigung der Semantik der eigenen Applikation) implementieren.

    Gut oder schlecht definiert sich damit immer unter dem Blickwinkel der eigenen Anwendung und kann nicht pauschalisiert werden.
    Automatisch zusammengefügt:
    Da hat mit __deets__ die Worte förmlich wenige Minuten vorher aus dem Mund genommen... :)

  • die ursprüngliche Frage lautete ja: pigpio oder wiringPi, die direkten GPIO- libs waren mir ja nicht nur nicht bekannt sondern dann auch viel zu kryptisch. Im Zweifel müsste man dann erst wieder selber Libs mit entsprechenden simple-syntax-wraps drumrum etablieren.


    Aber machen wirs mal schnell komplett OT:

    [OT]
    ebenfalls OT, aber: PropellerHAT ... ok, sehr interessant, aber hat das C/C++-Libs? Die HAT-Dinger bieten doch meist nur Python-libs, oder? Falls keine C-Libs: dann wird das aber auch schon wieder schnell superkompliziert bis OT... :-/

    i2c als Bus: naklar, aber was, wenn ich 1 in Master- und 1 in Slave-Modus brauche? Beim Arduino geht das (er hat ja 2 davon, und das nutze ich auch), und je mehr Geräte dran hängen, desto langsamer wird die Sache ja auch wieder, insbesondere wenn es - wie für mich wichtig ist - um schnellen Datenverkehr im ms- oder sogar im µs-Bereich handelt (z.B. möglichst per highspeed i2c, 400kHz, was die Arduinos immerhin beherrschen). Wenn ich also an i2c statt an UART den Arduino als Muxer für schnelle digitale und langsamere ADC-Daten sowie weitere langsamere in 4-byte-IEEE-754 Codierung dranhänge, die dauernd hin- und hergeschaufelt werden müssen (i2c ist ja nur halb-duplex!) ist der "Bus" damit voll ausgelastet. Dann noch ein paar PCFs oder MCPs oder MAXs - dann haben wir aber ganz schnell Stau auf dem Datenhighway.

    ok, wieder Topic-Mode
    [/OT]

    Insgesamt kommen also laut TOP-Fragestellung nur pigpio oder wiringPi als libs in Frage, und alles andere was es sonst gibt, muss einfache C-API-libs haben, egal aus welcher Applikations- oder Hardware-Richtung.

    Einmal editiert, zuletzt von HaWe (18. Oktober 2015 um 17:42)

  • Um auch mal neinen Kringel Senf dazuzugeben... Ich bevorzuge die pigpio, einfach wegen des Funktionsumfangs. Da ich in C# code, brauche ich für jede Lib einen Wrapper, und dessen API designe ich einfach so, wie ich sie gerne hätte.

    Und jetzt noch zum leidigen Thema "Echtzeit". Eigentlich wurde das Wesentliche ja schon gesagt (nur halt noch nicht von jedem ^^). Was hindert dich eigentlich dran, HaWe, deine Echtzeitanforderungen in Hardware auszulagern? Einen Arduino Nano kannst du beim Chinesen deines Vertrauens für ~ € 6,- samt Shipping schießen, die anderen Modelle sind auch keine Mordsinvestitionen. Oder du designst dir dein eigenes Board und hockst einen ATmega oder einen PIC drauf. Dem bringst du dann die Betriebsmodi, die du brauchst für deine Motoren, bei (Beschleunigen, Drehzahl halten, Bremsen, Schnellbremsung, Last bei Stillstand halten oder 0-Referenzpunkt anfahren, d Meter mit v m/s fahren oder was immer du halt benötigst), und der RPi sagt dem Slave einfach, was er machen soll, und der Slave meldet sich beim RPi, wenn es erledigt ist.

    "Mein" RPi daheim ist meine Licht- und Steckdosensteuerung, meine Alarmanlage, er steuert meinen Fernseher und treibt sonstige Spielereien, die zwar kein Mensch braucht, aber einfach Spaß machen. Solche Sachen wie die Fernseher-Steuerung habe ich dann aber wegen der Timing-Geschichten an einen "echten" uC delegiert. Ob das Programm nach 200 us wechselt oder nach 200 ms ist ja ziemlich egal, den Unterschied merke ich nicht. Aber die IR-LED muss genau in der richtigen Frequenz mit der richten Pulsweite "flackern", damit der Empfänger im Fernseher die Befehle versteht. Das ist mit Boardmitteln mit dem RPi unter *bian halt nicht zu machen.

    Und wieso es die pigpio bei mir ist, ist recht einfach erklärt. Da ich mit dem RPi 2 ins Thema eingestiegen bin, wollte ich eine Lib, die möglichst viel mit dem "großen" GPIO anfangen kann, und die pigpio war die erste, die ich gefunden habe, die das 2. SPI ansteuern kann. So einfach ist das manchmal ^^

    LG
    Carsten

    "Wer nur Nägel kennt, hält jedes Stück Materie für einen Hammer."
    (einschließlich mir)

    Einmal editiert, zuletzt von R2Pi (15. November 2015 um 20:14)

Jetzt mitmachen!

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