Ob die Einstellungen für den Cache sofort greifen oder ein Neustart fällig ist, kann ich Dir nicht sagen. Ich war auch erst am Wochenende darüber gestolpert und habe das nicht auf Herz und Nieren geprüft.
Selbst wenn die Einstellungen eigentlich gleich wirksam werden, könnte es sein, dass der noch laufenden Prozess nicht davon profitiert.
Ich nutze es selbst nicht in dieser Konstellation, aber bei mehreren Clienten könnte sich auf Dauer auch das Einrichten einer zentralen DB (MariaDB) lohnen. Dann könntest Du den vermeintlich schnellsten KODI-Clienten (PC ??) zum Scrapen verwenden und die anderen Clienten profitieren davon.
Beiträge von HarryH
-
-
Die Hinweise von buers sind auch deshalb wichtig, da die Einstellungen für den Cache mittlerweile unter Einstellungen -> Dienste -> Caching zu finden sind, zumindest in Omega. Deine bisherigen Einstellungen dafür in advancedsettings.xml werden ignoriert.
Mit Mode 1 wurden vorher alle Zugriffe gechached. Bitte stelle das im Menü analog dazu ein- „Alle Dateisysteme puffern, inklusive lokale Dateien“
- „Speichergröße 256MB“ o. „Speichergröße 384MB“
- „Lesefaktor 15“
und schau mal ob sich was ändert.
-
Hallo Robert,
Danke für die Rückmeldung, da bin ich schon mal beruhigt.ZitatDas wäre dann eine zukunftssichere Version oder?
Bei der Angelegenheit habe ich derzeit noch Zweifel. Auf der einen Seite habe ich in den verlinkten Quellen gelesen, dass sysfs-gpio als veraltet gilt (deprecated). Ehrlich gesagt, sieht es mir fast so aus, dass pinctrl die selbe Schnittstelle verwendet. Bin mir da aber nicht sicher. Auf der anderen Seite ist pinctrl als Debug-Werkzeug vorgesehen. Wenn sie das absägen und keine sinnvolle Alternative anbieten, wäre das schon eine starke Nummer.
Hintergrund wird sein, der Kernel soll als Einziger die Oberhand haben. Die verschiedenen Anwendungen, Treiber usw. sollen sich nicht mehr in die Quere kommen und sich gegenseitig die Pins umkonfigurieren/stehlen können. Dafür wurden Bibliotheken als Abstraktionsschicht(en) geschaffen um das zu koordinieren, wovon in LibreELEC 12 aber nur ein spezielle Auswahl vorhanden ist. Um diese Bibliotheken sinnvoll anzusprechen, wäre abseits von pinctrl das Umsetzen in python3 oder eventuell als binary in C notwendig.
Die jetzige Skript-Variante könnte u.U. also nur eine Zwischenlösung darstellen, wer weiß das schon genau? Allerdings hat die Version mit pinctrl den Vorteil, sowohl in alten als auch aktuellen LibreELEC Version zu funktionieren - zumindest glaube ich dort auch schon pintctrl gesehen zu haben. Als Bonus ist die Option für den RPi5 mit rausgesprungen, ohne die neuen Pin-Nummer vorher herausfinden zu müssen. -
RobertMV,
wenn Du mal Langeweile haben solltest, kannst Du bitte die auf pinctrl umgestellte Version auf Funktion prüfen? Die sollte dann auch auf einem RPi5 funktionieren. Außer ich habe noch einen Bug versenkt.Bash: irswitch.sh
Alles anzeigen#!/bin/bash # Created on: 2024-04-15 20:00 # Changed on: 2024-04-17 13:30 # Version: 1.2.0 # # Changelog: # 1.2.0 2024-04-17 # - version information added # - migrated from deprecated usleep to sleep command # 1.1.0 2024-04-16 # - restricted the pinctrl usage to the 40-pin header # - use a more specific pin naming to prevent usage of the wrong pin # 1.0.1 2024-04-15 # - pull-up/down setting added # 1.0.0 2024-04-15 # - migrated to pinctrl # - code comments added PINCTRL_BIN="/usr/bin/pinctrl -p" # this is the GPIO pin receiving the shut-down signal GPIOpin1=GPIO14 # set GPIO14 to input $PINCTRL_BIN set $GPIOpin1 ip pd while true; do sleep 1 # check if GPIO14 is going to high power=$($PINCTRL_BIN get $GPIOpin1 | awk '{ print $5 }') if [ "$power" = "hi" ]; then # change GPIO14 to output and set it to high level $PINCTRL_BIN set $GPIOpin1 op dh pn sleep 3 poweroff fi done
Bash: shutdown.sh
Alles anzeigen#!/bin/bash # Created on: 2024-04-15 20:00 # Changed on: 2024-04-17 13:30 # Version: 1.2.0 # # Changelog: # 1.2.0 2024-04-17 # - version information added # - migrated from deprecated usleep to sleep command # 1.1.0 2024-04-16 # - restricted the pinctrl usage to the 40-pin header # - use a more specific pin naming to prevent usage of the wrong pin # 1.0.1 2024-04-15 # - pull-up/down setting added # 1.0.0 2024-04-15 # - migrated to pinctrl # - code comments added PINCTRL_BIN="/usr/bin/pinctrl -p" if [ "$1" != "reboot" ]; then GPIOpin=GPIO15 GPIOpin1=GPIO14 # execute shutdown sequence on pin # set GPIO15 to output and high level for 125ms $PINCTRL_BIN set $GPIOpin op dh pn sleep 0.125 # change the output to low level for 200ms $PINCTRL_BIN set $GPIOpin dl sleep 0.2 # change the output to high level for 400ms $PINCTRL_BIN set $GPIOpin dh sleep 0.4 # change the output to low level $PINCTRL_BIN set $GPIOpin dl # set GPIO 14 high to feedback shutdown to RemotePi Board # because the irswitch.sh has already been terminated $PINCTRL_BIN set $GPIOpin1 op dh pn sleep 4 fi
-
Ja, es kann passieren, dass CEC komisches Verhalten hervorruft. Allerdings ist dabei nicht immer die Komponente die vermeintlich herumzickt auch der Auslöser ! Die Geräte kommunizieren untereinander, ein Art "Netzwerk". Das Bildausgabegerät Fernseher bildet da die Spitze der Hierachie. Die Daten dafür werden auf den HDMI-Kabeln mit übertragen. Ist z.B. die Software im Fernseher fehlerhaft, kann es zu Problemen kommen, genauso wenn sehr hohe Auflösungen (4K) gefahren werden und die HDMI-Kabel nur minderwertig sind. Ab und zu "verschluckt" sich das Konstrukt auch mal. Wenn gar nichts anderes mehr zu helfen scheint, alle beteiligten Geräte mal komplett vom Strom nehmen.
Wie sieht denn Deine Verkabelung derzeit aus?- RPi4 (HDMI) -> AVR (HDMI) -> TV (HDMI)
- RPi4 (HDMI) -> TV (HDMI)
- RPI4 (HDMI) -> TV (HDMI) -> AVR (HDMI)
-
Zitat
deine letzte Codierung hat es gebracht: ich konnte endlich die Hifiberry in den Audio-settings auswählen und die Musik läuft jetzt wie gewollt analog an den AVR.
Damit auch andere ggf. den gleichen Lösungsweg benutzen. Du hast die 2 Zeilen an den Anfang der config.txt eingefügt?
Kannst Du bitte etwas genauer angeben welche +/- Tasten Du genau meinst? Auf einer angeschlossenen Tastatur, an einem Gehäuse oder einer Fernbedienung? Wenn es die vom TV war/ist, könnte z.B. CEC vorher aktiv gewesen sein, denn da kann man festlegen die Lautstärke des AVR zu steuern. Gibt aber auch noch genügend andere Varianten. -
Hi,
ein paar Sachen die beim Probieren mit den Hifiberry-Treibern zu beachten sind. Ich habe zwar selbst keinen solchen HAT, aber aus anderen Gründen die letzten Tage quergelesen.
Die Overlays hifiberry-dacplus-pro und hifiberry-dacplus-std, hängen vom verwendete HAT ab
Configuring Linux 4.x or higher | HiFiBerry
und sind noch nicht im LibreELEC 11 vorhanden. Diese Overlays wurden primär zur besseren Unterstützung des Pi5 geschaffen und bedingen einen brandneuen Kernel.
Ab LibreELEC 12 beta 2 scheinen die neuen Overlays dabei. Welche Overlays vorhanden sind, kann recht einfach mit ls /flash/overlays/hifi* geprüft werden.Vermutlich muss die Zeile bei Dir deshalb immernoch so lauten:
dtoverlay=hifiberry-dacplus
Die Zeile force_eeprom_read=0 soll verhindern, dass von dem angeschlossenen HAT (Dein Hifiberry Modul) aus dessen EEPROM das Overlay geladen wird (ja, sowas geht). Es könnte sein, diese Zeile muss unbedingt vor dem „dtoverlay=hifiberry…“ Aufruf gesetzt sein -> Reihenfolge beachten!
Außerdem ist diese Vorgehensweise deprecated und es wird empfohlen stattdessen diese beiden Zeilen ganz an den Anfang der config.txt zu rücken.
Wobei diesmal die leere Zeile das Nachladen aus dem EEPROM verhindern soll.
Was das Aussetzen des Tons betrifft, würde ich auch mal getedid create in Betracht ziehen, da KODI/LibreELEC in den neuen Ausprägungen die Information aus den EDID Daten verwendet um die Audiokanäle zu bestimmen. In dem Moment wo Du den Fernseher Aus/Ein schaltest könnte zusätzlich zu CEC auch dort Bewegung drauf sein. -
Zitat
Interessant ist, das jetzt der 5.1 Ton tatsächlich auch über den digital out vom TV kommt.
Wenn Du das vorher ausschließlich mit LE 11 probiert hast, ist das für mich nachvollziehbar. Wie schon erwähnt, hatte sich da ein hässlicher Bug eingeschlichen. Der Bestand darin, dass die Kanäle vertauscht wurden. Der Datenstrom mit AC3 5.1 sollte ja auf den Kanälen unterwegs sein, die sonst für PCM 2.0 Links/Rechts zuständig sind. Wenn diese allerdings mit Hinten o. dem Center/SubWoofer vertauscht waren, kam da nichts Brauchbares am TV an, um es am Digital Out auszugeben.
-
CEC hab ich jetzt aus, war an. Vielen Dank. Beim Fernseher muss ich mal suchen ob ich dort was finde. Probiere jetzt erstmal neues Libreelec. Dachte eigentlich, das ließe sich einfach so updaten.
Kannst Du auch, die Image Datei in den .update Ordner kopieren und LibreELEC neu starten. Nur der Weg zurück ist Dir dann verbaut bzw. schwieriger.
-
Wenn Dein Panasonic sowohl die eingehenden Kanäle als auch die auszugebenden Kanäle getrennt anzeigt, ist das für die Diagnose sehr hilfreich. Wenn Du da bisher schon penibel darauf geachtet hast, ist ja alles gut.
Älteren oder einfacher gestalteten Geräten fehlt oft die Anzeige für das eingehende Signal. An dieser Stelle wird die Unterscheidung zwischen einem PCM 2.0 / AC3 2.0 Signal zu AC3 5.1 Signal schwierig. Der AVR gibt alle 3 Varianten als 5.1 auf die Lautsprecher aus, sofern er nicht explizit auf Stereo steht. Letzteres (AC3 5.1) möglichst ohne weitere akustische Eingriffe, da das Signal ja schon getrennt nach einzelnen Kanäle vorliegt.
Mit diesem Satz irritierst Du mich etwas:Zitatder stellt auch automatisch auf Dolby ProLogic II um, wenn er das passende Signal bekommt. Bekommt er aber vom Raspi nicht.
Die AVRs die ich bisher vor der Nase hatte, stehen per Standard auf Dolby ProLogic II oder DTS Neo:6 (beide entsprechen einem Stereo Upmix) und schalten erst davon weg wenn ein Tonformat > 2.0 am Signaleingang anliegt z.B. AC3 5.1 oder DTS (bei HDMI natürlich noch mehr).
Die einzige technische Erklärung für mich wäre noch, der AVR fällt ganz auf den analogen Eingang zurück und verwendet dort separate Einstellungen für die Surround Programme. Wenn dort noch Stereo eingestellt ist, kann das natürlich sein. Im Umkehrschluss sollte bei Filmwiedergabe mit AC3 5.1 per Toslink bzw. S/PDIF allerdings Dolby Digital 5.1 oder was ähnliches im Display stehen, zumindest nicht mehr Dolby ProLogic II (PCM 2.0 / AC3 2.0). -
Die CEC-Einstellungen verstecken sich im Menü: Einstellungen -> System -> Eingabe -> Peripheriegeräte (Edit: Karsten war schneller. Ein Bild sagt manchmal mehr als tausend Worte )
Für CEC benötigst Du rein von der Verkabelung her nur HDMI. Nix weiter. Natürlich sollte das Kabel auch nicht unbedingt vom Wühltisch stammen und der TV als auch das beteiligte Gerät sollten es unterstützen. Der verwendete Softwarestand spielt da unter Umständen auch mit rein.
Die eine Buchse (sofern Digital) würde vollkommen reichen. Allerdings gibt es verschiedene Fernseherhersteller die selbst bei aktuellen Geräten dort noch Bugs versenkt haben oder absichtlich nur 2.0 Ton ausgeben - obwohl wenigstens 5.1 möglich wäre. Siehe oben Punkt Nr. 2.
Wenn der Fernseher es doch kann (was es sehr wohl gibt), muss man es meist in Untiefen des Fernseher aktivieren. Manche TV-Nutzer wissen nix davon, weil es so gut versteckt oder nicht dokumentiert ist und geben deshalb auf. -
@maranzon ,
ich glaube bei Deinem Ziel hilft nur ganz ruhiges und koordiniertes Vorgehen. Die verschiedenen Vorschläge die ich hier gelesen habe sind alle gut gemeint und haben auch schon paar mehr Details hervorgebracht. Manche Zielen aber in unterschiedliche Richtungen, wenn Du diese zur selben Zeit ausprobierst wird das nicht zum Ziel führen.
Bestandsaufnahme:
Raspberry Pi5 mit LE 11.0.6
AV-Receiver Panasonic SA-XR55 hat kein HDMI nur 2x Toslink u. 2x S/PDIF coaxial
Fernseher: Philips 37PFL7605h
Punkt Nr. 1: Die Unterstützung des RPi5 ist in LE 11 nur rudimentär. Außerdem gab es nach 11.0.1 einen Bug bzgl. Bitstream und HDMI. Auf beides bist Du angewiesen. Ich empfehle Dir daher LE 12 beta oder ein aktuelles nightly zu verwenden. Wenn Du eine freie SD-Karte haben solltest, musst Du dafür die bisherige Konfiguration nicht zwingend opfern.
Punkt Nr. 2: Toslink bzw. S/PDIF coaxial begrenzen die Optionen an Tonformaten die Du darüber leiten kannst. Dolby Digital (AC3), DTS (nur 5.1) als Bitstream, Stereo bzw. PCM 2.0 (PCM Multichannel ist was anderes -> dafür brauchst Du HDMI oder ein anderes proprietäres Interface) sollten möglich sein. Sonderformate True HD, DTS-HD und wie sie alle heißen sind im Regelfall tabu. Manchmal gibt es aber auch schon bei DTS Probleme. Von dieser Kombination ist abhängig, wie Du die Schalter für Passthrough im KODI als auch an Deinem Splitter setzen musst.
Punkt Nr. 3: den Upmix von Stereo-Signalen empfehle ich Dir an allen externen Zuspielern in Deiner Verkabelung auszulassen. Wenn wirklich nötig, lass dies lieber Deinen Panasonic (Verstärker/AVR) übernehmen. Der sollte das beherrschen sobald Du Dolby ProLogic II eingestellt hast. Das stellt gleichzeitig auch sicher, dass die Dialoge weiterhin primär vom Center-Lautsprecher kommen. Für reine Musik-Wiedergabe ist es Deinem persönlichen Geschmack geschuldet, ob Du dafür temporär am AVR auf Stereo stellst oder nicht.
Punkt Nr. 4: Der Einwand von Karsten (Bobbi2021) ist nicht verkehrt, sollte in Deinem Fall aber hoffentlich nur den Fernseher betreffen. Für CEC wird eine reine HDMI-Verbindung benötigt. Sprich nur die Strecke RPi5 -> Splitter -> TV. Toslink bzw. S/PDIF gibt sowas nicht weiter.
Was man solchen Zusatzgeräten (Splitter usw.) leider nie ausschließen kann, dass diese den Standard verletzen und Störungen bzgl. CEC verursachen oder selbst damit nicht klarkommen. Ich habe noch nicht recherchiert, theoretisch bräuchtest Du den Splitter gar nicht, wenn der Philips auch einen digitalen Tonausgang hat. Sollte der Fernseher allerdings Fehler in der Software/Hardware haben, ist der Splitter natürlich die bessere Alternative, ohne ein ordentliches Audiointerface am RPi5 nachzurüsten. Mal abgesehen von der möglichen exotischen Kombination HDMI0 zum Fernseher, HDMI1 am Splitter zum AVR....
Punkt Nr. 5:
Was versuchst Du denn aktuell am RPi5 für Daten wiederzugeben? Wenn es z.B. MKV sind, ist die Wahrscheinlichkeit hoch, dort Tonformate wie DTS-HD oder True HD vorzufinden. (siehe Einschränkungen Punkt Nr. 2). An dieser Stelle macht es Sinn die Passthrough Schalter nur bei AC3 auf "An" zu setzen, die anderen "Aus".
Punkt Nr. 6:
Die Einstellung Audiokanäle 2.0 dürfte in Deinem konkreten Fall sogar genau richtig sein, damit KODI weiß wie groß/breit der Bitsream maximal werden darf (siehe Punkt Nr. 2) den es am HDMI ausleitet. Es kann sein, Dein Splitter kann das in Grenzen auch und macht das wenn dieser auf 5.1 steht. Da kenn ich aber die Doku noch nicht.
Dass bei Anschluss Deines Sat Receiver, der Splitter per Toslink ein Signal ausgibt ist ein gutes Zeichen für die grundlegende Funktion des Splitters. Was damit leider noch nicht belegt ist, ob dabei ein AC3 5.1 Signal übertragen wurde oder nicht. Ich habe da leider schon die "wildesten" Konfigurationen am Sat-Receiver erlebt. -
-
Ja, ich habe es lokal bei mir mit LE12 ausprobiert, per echo die GPIO Pins umzustellen. Mit den richtigen Ziffern, kam keine Fehlermeldung mehr zurück und das GPIO Pin wurde exportiert. Es war allerdings nur eine Trockenübung, da ich diese Platine selbst nicht einsetze.
Auch hatte ich bedenken bei den Infos die ich gefunden habe, ob ich mich ggf. um 1 verzählt habe. Wenn man die Ausgabe von gpioinfo (System-Tools Addon muss installiert sein) benutzt zum Vergleich, passt aber alles zusammen: 58 Pins + Nummerierung ab 0, wobei GPIO14 = 14 ist.
Edit:
erfolgreicher Probelauf auf GPIO24:
Zustand vorher:Code: console
Alles anzeigen~ # gpioinfo gpiochip0 - 58 lines: line 0: "ID_SDA" input line 1: "ID_SCL" input line 2: "GPIO2" input line 3: "GPIO3" input line 4: "GPIO4" input bias=pull-down edges=rising consumer="lg" line 5: "GPIO5" input line 6: "GPIO6" input line 7: "GPIO7" input line 8: "GPIO8" input line 9: "GPIO9" input line 10: "GPIO10" input line 11: "GPIO11" input line 12: "GPIO12" input line 13: "GPIO13" input line 14: "GPIO14" input line 15: "GPIO15" input line 16: "GPIO16" input line 17: "GPIO17" input line 18: "GPIO18" input line 19: "GPIO19" input line 20: "GPIO20" input line 21: "GPIO21" input line 22: "GPIO22" input line 23: "GPIO23" input active-low consumer="ir-receiver@17" line 24: "GPIO24" input line 25: "GPIO25" input line 26: "GPIO26" input line 27: "GPIO27" input line 28: "RGMII_MDIO" input line 29: "RGMIO_MDC" input line 30: "CTS0" input line 31: "RTS0" input line 32: "TXD0" input line 33: "RXD0" input line 34: "SD1_CLK" input line 35: "SD1_CMD" input line 36: "SD1_DATA0" input line 37: "SD1_DATA1" input line 38: "SD1_DATA2" input line 39: "SD1_DATA3" input line 40: "PWM0_MISO" input line 41: "PWM1_MOSI" input line 42: "STATUS_LED_G_CLK" output consumer="ACT" line 43: "SPIFLASH_CE_N" input line 44: "SDA0" input line 45: "SCL0" input line 46: "RGMII_RXCLK" input line 47: "RGMII_RXCTL" input line 48: "RGMII_RXD0" input line 49: "RGMII_RXD1" input line 50: "RGMII_RXD2" input line 51: "RGMII_RXD3" input line 52: "RGMII_TXCLK" input line 53: "RGMII_TXCTL" input line 54: "RGMII_TXD0" input line 55: "RGMII_TXD1" input line 56: "RGMII_TXD2" input line 57: "RGMII_TXD3" input gpiochip1 - 8 lines: line 0: "BT_ON" output line 1: "WL_ON" output line 2: "PWR_LED_OFF" output active-low consumer="PWR" line 3: "GLOBAL_RESET" output line 4: "VDD_SD_IO_SEL" output consumer="vdd-sd-io" line 5: "CAM_GPIO" output consumer="cam1_regulator" line 6: "SD_PWR_ON" output consumer="regulator-sd-vcc" line 7: "SD_OC_N" input
GPIO24 zu Ausgang umkonfigurieren:
GPIO24 ist jetzt auf Ausgang umkonfiguriert:
Code: console
Alles anzeigen~ # gpioinfo gpiochip0 - 58 lines: line 0: "ID_SDA" input line 1: "ID_SCL" input line 2: "GPIO2" input line 3: "GPIO3" input line 4: "GPIO4" input bias=pull-down edges=rising consumer="lg" line 5: "GPIO5" input line 6: "GPIO6" input line 7: "GPIO7" input line 8: "GPIO8" input line 9: "GPIO9" input line 10: "GPIO10" input line 11: "GPIO11" input line 12: "GPIO12" input line 13: "GPIO13" input line 14: "GPIO14" input line 15: "GPIO15" input line 16: "GPIO16" input line 17: "GPIO17" input line 18: "GPIO18" input line 19: "GPIO19" input line 20: "GPIO20" input line 21: "GPIO21" input line 22: "GPIO22" input line 23: "GPIO23" input active-low consumer="ir-receiver@17" line 24: "GPIO24" output consumer="sysfs" line 25: "GPIO25" input line 26: "GPIO26" input line 27: "GPIO27" input line 28: "RGMII_MDIO" input line 29: "RGMIO_MDC" input line 30: "CTS0" input line 31: "RTS0" input line 32: "TXD0" input line 33: "RXD0" input line 34: "SD1_CLK" input line 35: "SD1_CMD" input line 36: "SD1_DATA0" input line 37: "SD1_DATA1" input line 38: "SD1_DATA2" input line 39: "SD1_DATA3" input line 40: "PWM0_MISO" input line 41: "PWM1_MOSI" input line 42: "STATUS_LED_G_CLK" output consumer="ACT" line 43: "SPIFLASH_CE_N" input line 44: "SDA0" input line 45: "SCL0" input line 46: "RGMII_RXCLK" input line 47: "RGMII_RXCTL" input line 48: "RGMII_RXD0" input line 49: "RGMII_RXD1" input line 50: "RGMII_RXD2" input line 51: "RGMII_RXD3" input line 52: "RGMII_TXCLK" input line 53: "RGMII_TXCTL" input line 54: "RGMII_TXD0" input line 55: "RGMII_TXD1" input line 56: "RGMII_TXD2" input line 57: "RGMII_TXD3" input gpiochip1 - 8 lines: line 0: "BT_ON" output line 1: "WL_ON" output line 2: "PWR_LED_OFF" output active-low consumer="PWR" line 3: "GLOBAL_RESET" output line 4: "VDD_SD_IO_SEL" output consumer="vdd-sd-io" line 5: "CAM_GPIO" output consumer="cam1_regulator" line 6: "SD_PWR_ON" output consumer="regulator-sd-vcc" line 7: "SD_OC_N" input
GPIO24 Pin zurück auf Input stellen und wieder freigeben:
Bitte beachten:
Es ist vermutlich nur eine Frage der Zeit wann diese Möglichkeit die Pins zu konfigurieren aus dem Kernel endgültig rausgeschmissen wird. In Zukunft könnte die Umstellung auf "pinctrl" notwendig sein oder eine Migration zu Python3 die einzig verbleibende Variante für LE12 werden. Aktuell ist nur noch lgpio und gpiozero in den RPi-Tools enthalten. gpiozero setzt auf lgpio auf und macht es unter Umständen einfacher, aber auch langsamer. Zu allem Überfluss ist lgpio auch mit ein paar fiesen Bugs gespickt...
PS: Von einem Nutzer im LibreELEC Forum kam gerade die Rückmeldung, dass es bei ihm nach den von mir vorgeschlagenen Änderungen wieder funktioniert.
Quellen:wiringPi broken since kernel 6.5.7 · Issue #5668 · raspberrypi/linuxDescribe the bug Starting with kernel 6.5.7 applications which uses gpios are broken. Steps to reproduce the behaviour e.g. the start of an application which…github.comTrying to write to /sys/class/gpio/export – write error: Invalid argumentI have an Intel aaeon upboard and I want to use its GPIO pins. To do that I'm trying the below code: echo 17 > /sys/class/gpio/export But when I run it,…superuser.comControlling GPIO from Linux User Space
The Pins They Are A-Changin’ -
RobertMV,
besteht das Problem noch?
Wenn ja, probiere mal die Zeilen 3/4 passend zu ändern.
GPIOpin=527
GPIOpin1=526
Hintergrund: Die verwendete Schnittstelle sysfs-gpio gilt schon lange als veraltet und wurde im Kernel größer 6.5 geändert. Bisher wurde ein gpiochip0 instanziert. Wobei die 0 den Index im Speicher angibt. Bei neueren Kerneln werden diese GPIOchips dynamisch erzeugt. Vermutlich ist dies auch zwingend notwendig um z.B. den RP1 des Pi5 adressieren zu können. Hier ein Beispiel von meinem RPi4 mit LE12 beta 1.Code: console# ls -la /sys/class/gpio/ total 0 drwxr-xr-x 2 root root 0 Feb 27 18:26 . drwxr-xr-x 50 root root 0 Jan 1 1970 .. --w------- 1 root root 4096 Apr 9 18:16 export lrwxrwxrwx 1 root root 0 Feb 27 18:26 gpiochip512 -> ../../devices/platform/soc/fe200000.gpio/gpio/gpiochip512 lrwxrwxrwx 1 root root 0 Feb 27 18:26 gpiochip570 -> ../../devices/platform/soc/soc:firmware/soc:firmware:gpio/gpio/gpiochip570 --w------- 1 root root 4096 Apr 9 18:17 unexport
Der gpiochip512 ist der mit den 58 adressierbaren GPIO Pins und entspricht dem bisherigen gpiochip0. Damit man keinen "I/O error" oder "Invalid argument" bekommt, muss man diese Zählweise verwenden: Chipnummer + GPIO Nummer
Alt: 0 + GPIO14 = 14
Neu: 512 + GPIO14 = 526
Da ich nicht sicher bin, ob bei Raspberry Pis kleiner als dem RPi5 immer gpiochip512 angelegt wird, sollte man sicherheitshalber mit ls -la /sys/class/gpio/ nachschauen und ggf. neu berechnen.
Mit cat /sys/class/gpio/gpiochip512/ngpio (Rückgabewert: 58)bzw. cat /sys/class/gpio/gpiochip512/label (Rückgabewert: pinctrl-bcm2711) lässt sich prüfen ob man den Richtigen versucht zu benutzen.
Auf der Basis dieser Infos könnte man die Bash Skripte vermutlich auch automatisiert suchen lassen.
Wenn bei Dir auch der gpiochip512 angelegt wurde, sollten Deine beiden Skripte so angepasst wieder funktionieren: