[PATCH] 51_RPI_GPIO WiringPI export flackern

Begonnen von blecher-at, 18 November 2017, 12:03:09

Vorheriges Thema - Nächstes Thema

blecher-at

Problemstellung:
Eine an einem gpio hängende LED wird im FHEM eingebunden. Beim restart von FHEM wird diese mittels WiringPI als output exportiert. Dabei flackert die LED kurz. (bei einer led weniger schlimm aber wenn das z.b. ein Garagentor ist ...)

Ursache: FHEM exportiert den PIN als output ohne gleichzeitig den status zu setzen (auf high in diesem fall)
Analyse: alte versionen von WiringPI haben export und status setzen in einem befehl nicht unterstützt, seit 2.24 (Feb. 2015) geht dies aber.
Workaround: Pin per script exportieren bevor fhem startet, aber das muss extern gewartet werden und die einstellungen des pin sind egal.

Der angehängte Patch behebt das Problem indem der korrekte initial-level (high oder low) an WiringPI geschickt wird. Alte Versionen des Tools werden unterstützt indem der fehler erkannt wird und dann das alte verhalten (gpio export <pin> out) ausgeführt wird.

Damit das ganze auch mit ACTIVE_LOW funktioniert, muss auch WiringPI gepatcht werden.
Raspberry PI: https://github.com/WiringPi/WiringPi/pull/55
Orange PI Zero: https://github.com/xpertsavenue/WiringOP-Zero/pull/15

blecher-at

Fortsetzung von anderem Thread:
Zitat von: klausw am 08 Dezember 2017, 00:54:25
Von welchen Verrenkungen sprichst du?
Den User fhem in die Gruppe gpio aufzunehmen ist meiner Meinung nach die einfachste Lösung.

Nochmal auf meinen Pi3s (Arch Linux), meinen Orange-PI Zeros (armbian) und einem Raspberry Pi Zero (Resin.io) gecheckt. auf keinem existiert überhaupt eine gruppe "gpio".
Der Grund ist hier zu finden: https://stackoverflow.com/questions/30938991/access-gpio-sys-class-gpio-as-non-root
Nicht jeder verwendet Raspian :) und diese udev-regeln selbst zu pflegen meinte ich mit verrenkungen.

Mit dem GPIO-Fhem Modul und einem installierten WiringPI braucht es keine zusätzliche Software oder Config auf Systemebene. Nachdem viele Nutzer Interrupts nutzen werden, wird das Tool ohnehin benötigt. Finde es aber gut dass das Modul auch die sysfs-variante unterstützt.

Das einzige Problem das ich mit dem wiringpi gefunden habe, ist im ersten posting beschrieben und wäre durch die patches gelöst. Verstehe aber deine Ablehnung ggü WiringPI langsam, denn gewartet scheint die Software nicht mehr zu werden.

klausw

Zitat von: blecher-at am 08 Dezember 2017, 15:07:40
Fortsetzung von anderem Thread:
Nochmal auf meinen Pi3s (Arch Linux), meinen Orange-PI Zeros (armbian) und einem Raspberry Pi Zero (Resin.io) gecheckt. auf keinem existiert überhaupt eine gruppe "gpio".
Der Grund ist hier zu finden: https://stackoverflow.com/questions/30938991/access-gpio-sys-class-gpio-as-non-root
Nicht jeder verwendet Raspian :) und diese udev-regeln selbst zu pflegen meinte ich mit verrenkungen.

Mit dem GPIO-Fhem Modul und einem installierten WiringPI braucht es keine zusätzliche Software oder Config auf Systemebene. Nachdem viele Nutzer Interrupts nutzen werden, wird das Tool ohnehin benötigt. Finde es aber gut dass das Modul auch die sysfs-variante unterstützt.

Das einzige Problem das ich mit dem wiringpi gefunden habe, ist im ersten posting beschrieben und wäre durch die patches gelöst. Verstehe aber deine Ablehnung ggü WiringPI langsam, denn gewartet scheint die Software nicht mehr zu werden.

Den Thread habe ich jetzt eher durch Zufall entdeckt.
Bitte das nächste mal ne PN mit Link. Ich versuche regelmäßig reinzuschauen, aber es kann durchaus passieren das ich was übersehe.

Stimmt ich gehe von Raspbian aus  8)
Die Abneigung bezieht sich nicht explizit auf wiringpi  ;), das GPIO Modul basierte anfangs ausschließlich darauf.
Nur kamen dann Nutzer die auch außerhalb von Raspbian die GPIOs nutzen wollten dazu.
Zu diesem Zeitpunkt gab es wiringpi nur für das Pi. Außerdem lassen sich die Interrupts nur über den Userspace nutzen (jedenfalls meines Wissens nach) Wiringpi wird dafür nicht benötigt.
Ich hoffe ich widerspreche nicht meinem Modul, aber wiringpi nutze ich nur für die Pullups und je nach Rechten für den Export.
Es ist drin geblieben, da nach und nach andere Systeme dazu kommen.
Ich bin aber kein Freund von Software die von einer Person entwickelt wird. Da ist der Unsicherheitsfaktor recht hoch das irgendwann mal Schluss ist. Daher fand ich den Zugriff über das Filesystem am besten. Das ist meines Wissens bei allen Linux Systemen gleich (mit Ausnahme der Nutzerrechte)

Die udev Sache ist wirklich umständlich, ebenso die rclocals Lösung.

Deinen Patch finde ich gut. Schließlich musste ich extra für die fehlende "high/low" output Geschichte einen Workaround reinbasteln.
Aber wenn er nicht eingepflegt wird dann macht es leider wenig Sinn ihn einzubauen.
Wenn ich das richtig gesehen habe hast Du Deinen Patch in einem Fork von WiringPi. Würde der denn (vorrausgesetzt dein Patch wird angenommen) über die üblichen Installationsquellen verfügbar sein?

RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

blecher-at

Die Changes die ich für fhem gemacht hab funktionieren auch mit der ungepatchten sowie auch der uralten version (2015) von wiringpi.

Der Patch am Wiringpi ist nur für das exportieren von active_low notwendig.
Bzgl. Software von einer Person gewartet stimme ich dir zu, hab den "gordon" mittlerweile direkt kontaktiert, mal sehen. aber ich bin auch wie du gemerkt hast nich gut im leute nachrennen ;) Alternative/Ohnehin sinnvoll wäre, im Wiki/Commandref eine liste an gewarteten forks für die unterschiedlichen SBCs zu pflegen.

klausw

Den Patch baue ich ein, dauert aber noch nen Moment, ich möchte auch noch die Fehlermeldungen verbessern.
Die irritieren mich dummerweise selbst schon.
Du meinst wiringpi Forks?
Das sehe ich eher im Wiki. Die commandref möchte ich so kurz wie möglich halten.
Wenn du magst könntest du gern eine Liste im Wiki beginnen.
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

blecher-at

Wird gemacht. Ich hab mal Wiki-Zugriff beantragt  :-X

blecher-at

Wiki ist upgedated. Wie geht es dir mit dem patch?

klausw

Ist nicht vergessen, die Feiertage sind nur voll durchgeplant  ::)
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

Beetle2003

Guten Morgen,

ich teste derzeit ein wenig mit den GPIOs meines BananaPI. Ich erhalte immer wieder die Meldung:

GPIO18: WiringPi alte version erkannt. '/usr/local/bin/gpio export 18 low' export: Invalid mode: low. Should be in or out

Bei der Suche nach einer Lösung bin ich hier gelandet. Ich habe den Patch, welcher hier hinterlegt ist herunter geladen, doch habe ich keine Ahnung was ich damit machen muss.

Würde mir jemand etwas Licht reichen?

Danke

blecher-at


Beetle2003

Zitat von: blecher-at am 16 Januar 2019, 10:36:51
Ich habe keinen bananapi/pro. Habe allerdings die WiringPI libary dennoch mit den notwendigen changes verpasst:
https://github.com/blecher-at/WiringOP/tree/bananapro
https://github.com/blecher-at/WiringOP/tree/bananapi
Hallo,

Danke für den Support.
Was ich noch nicht verstanden habe, wie installiere ich den Patch. Reicht es ihn in das Thema Verzeichnis zu kopieren?

Vielen Dank