Piface Digital 2 nachdem das System Stromlos war: Auslesen&Schalten ohne Wirkung

Begonnen von Patrik.S, 03 Januar 2019, 23:57:07

Vorheriges Thema - Nächstes Thema

Patrik.S

Mutige Mittester gesucht, die im Kernel 4.14 unterwegs sind und auch mal eine Datei patchen können.

Der RaspberryPi Kernel hat mindestens seit der Version 4.9.51 ca. im August 2017 eine deutlich höhere SPI clock speed von 125 Mhz anstatt der bisherigen 500kHz, siehe https://github.com/raspberrypi/linux/issues/2165
Ich habe über Monate fleißig meine System Updates gemacht und einige reboots durchgeführt und auch wegen des wiringPi Tools das FHEM Modul 55_PIFACE im Oktober 2018 angepasst, siehe https://forum.fhem.de/index.php/topic,13236.msg844138.html#msg844138
Zu dieser Zeit war ich schon lange im 4.14.x Kernel und hatte nie Probleme die Ausgänge zu schalten oder die Eingänge auszulesen.

Dann kam der Tag, der mich verzweifeln lässt, ich habe den RaspberryPi nicht nur rebooted sondern vom Strom genommen!
Danach kommt aber bei mir die Piface Digital 2 Erweiterung nicht mehr klar. Der PiFace2 oder der MCP23S17 Chip darauf muss sowas wie einen flüchtigen Speicher haben und sich darüber die Einstellungen merken. Ich kann es mir nicht erklären......

Ich hatte zuerst einfach einen Hardware Defekt der Piface Digital 2 Erweiterung vermutet und eine 2. Platine bestellt, die nun als Ersatz Sinnlos rumliegt.
Ich kann das Verhalten zu 100% mit wiringPi reproduzieren und auch immer zu 100% mit dem SpiDev Python Binding und dem pifacedigitalio Paket "heilen", ohne den Grund gefunden zu haben.

Schritte:

shutdown -h now


RaspberryPi kurz vom Strom nehmen!!!

Nach dem Booten diesen Befehl probieren, um das erste Relais einzuschalten:

gpio -x mcp23s17:200:0:0 write 200 1
gpio -x mcp23s17:200:0:0 readall


Das Ergebnis ist, dass das Relais 1 nicht eingeschaltet ist und das readall zeigt weiterhin eine Null (0) für alle Ausgänge


Jetzt kommt der Verrückte Teil. Dazu die Python Tools zum Ansprechen des PiFace2 installieren und das Blink Beispiel starten:

$ sudo apt-get install python{,3}-pifacedigitalio

$ python3 /usr/share/doc/python3-pifacedigitalio/examples/blink.py


Es kommt nun der Fehler:

            No PiFace Control and Display board detected....


Grund ist, das der SPI Bus den MCP23S17 Chip nicht mit 125MHz ansprechen kann, weil der das nicht verkraftet.
Man muss die Datei /usr/lib/python3/dist-packages/pifacecommon/spi.py editieren und dem spi_ioc_transfer() Block die neue Zeile speed_hz=ctypes.c_uint32(100000) mitgeben, damit der SPI Bus mit 100KHz läuft.
In der vormals letzten Zeile  len=ctypes.sizeof(wbuffer) muss noch ein Komma hinzu, weil es nicht mehr die letzte Zeile ist!

        # create the spi transfer struct
        transfer = spi_ioc_transfer(
            tx_buf=ctypes.addressof(wbuffer),
            rx_buf=ctypes.addressof(rbuffer),
            len=ctypes.sizeof(wbuffer),
            speed_hz=ctypes.c_uint32(100000)
        )


Ein offizieller Fix ist zwar schon in den Sourcen vorhanden, wird aber im apt-get upgrade nicht verteilt, weil es seit über 2 Jahren keine neues Releases gibt, siehe https://github.com/piface/pifacecommon/issues/27

Nach der Änderung wieder das Blink Beispiel starten und siehe da, der Ausgang out7 blinkt nun munter (mit CTRL+C abbrechen)

$ python3 /usr/share/doc/python3-pifacedigitalio/examples/blink.py


Jetzt kommt das verrückte, was ich nicht eingrenzen konnte. Denn ab jetzt kann ich mit dem wiringPi Tool auch wieder meine Relais oder überhaupt alle Ausgänge schalten und alles wie gewöhnt auslesen:

gpio -x mcp23s17:200:0:0 write 200 1
gpio -x mcp23s17:200:0:0 readall


mache ich nun nur einen Reboot, kann ich danach auch sofort ohne Probleme wieder mit wiringPi arbeiten.
Nehme ich den Raspi aber kurz vom Strom, geht das Spiel von vorne los.

Ich habe die Systemcalls von wiringPi und dem Python Skript mit strace -v -tt ...... nachverfolgt, habe einige Debugausgaben eingebaut, habe das setzen des Interupts auf gpio25 als Heilung gesehen, dem war aber nicht so.
Ich habe das wiringPi mit seinen SPI_IOC_MESSAGE calls an die Python Variante angepasst und auch dort das speed_hz angepasst (war vorher auf 500KHz).
Ich habe echt viel versucht.......

aber ich verstehe nicht, warum es initial das wirnigPi nicht schafft nach einem PowerOff Cycle, das PiFace2 zu "initialisieren" und warum ein Aufruf über das Python zu einer Heilung führt und ich danach mit wirnigPi wie gewohnt zugreifen kann.

Also nächstes würde ich wohl in die Materie der Device Tree Overlays einsteigen und dem Kernel die 125MHz Clock Speed mit einem Overlay und 100KHz oder 500KHz überschreiben. Wenn dann das wiringPi wieder sofort von selbst funktioniert liegt's definitiv an der SPI Geschwindingkeit.
Wenn es jedoch so bleibt, muss wiringPi wohl einen ganz anderen Fehler im Bauch haben, den ich einfach nicht sehe in den strace Ausgaben.
Ich bin auch schon Gedanklich so weit ein Issue beim Raspberyy Kernel Team zu eröffnen mit der Bitte um Mithilfe

Patrik.S

Nach vielen Stunden mit erweiterten Debug Ausgaben und dem Vergleich zwischen wiringPi und der Python pifacecommon Variante, ist der Fehler nicht im "neuen" höheren SPI clock speed zu finden, sondern in der Art wie wiringPi den MCP23S17 Chip auf dem PiFace anspricht und initialisiert.

Bis zur Version 2.44-1 gab es den Schalter -p und der macht intern viel mehr SPI_IOC_MESSAGE Aufrufe als der Aufruf über Schalter -x mcp23s17:200:0:0 ....
Den Schalter -p gibt es aber nicht mehr, siehe https://forum.fhem.de/index.php/topic,87685.0.html
Installier ich also die alte wiringPi Version 2.44-1, kann ich nach einem Power Off Cycle mit gpio -p write 200 1 das Relais 1 sofort ansprechen. Ich muss nicht erst den Umweg über das Python pifacecommon nehmen.

Das Problem ist nicht gelöst in der wiringPi Version 2.46, aber dafür verstanden was da intern passiert. Jetzt kann ich das dem Entwickler mitteilen.

Michael70

Hallo Patrik.S,

konntest Du schon etwas erreichen bzw. hast Du Feedback vom wiringPi Entwickler bekommen ?

Danke für eine Info.


VG, Michael


Raspberry Pi 4 (Raspberry OS Bullseye), FHEM 6.2, 1-Wire USB Busmaster. Anwendung: Kellerlüftung und Heizung Zirkulationspumpe, Balkon PV Überschuss Steuerung

Patrik.S

Hallo Michael,

ich habe nach den Problemen mit wiringPI direkt eine andere Baustelle auf einem anderen System aufgemacht und mich nicht weiter um dieses Problem gekümmert.
Ich hatte noch nicht mal dem Entwickler geschrieben. Das muss ich noch machen, sorry.
Es läuft für mich ja erstmal mit dem Workaround der alten wiringPI oder python pifacedigitalio

Patrik.S

Ich habe heute dem Entwickler endlich mal die E-Mail geschickt, mal gucken was er antwortet.
Seine Antwort vor einem Jahr könnte man beim 2. Satz eher so verstehen, das es keine schöne Lösung geben wird:
Zitat
I was actually thinking about dropping device specific stuff from the gpio command anyway. You can control a piface with the -x mcp23s17 extension if needed, but it might not be quite the same.

Anyway, the smart kids don't use wiringPi anymore - it's all rpi.zero or pigpio or whatever...

Aber warten wir's mal ab...

Prof. Dr. Peter Henning

Mit dem Fix im Clock speed und einem gepatchten 55_PIFACE.pm arbeitet das PiFace2 problemlos. Außerdem werte ich inzwischen die Interrupts aus.

Mehr dazu hier:

https://forum.fhem.de/index.php/topic,101299.msg947413.html#msg947413

LG

pah

Patrik.S

Ich hab bis heute vom wiringpi Entwickler Gordon leider keine Antwort erhalten.
Es sieht also mau aus, dass das Piface Board intern wieder komplett initialisiert wird, damit es nutzbar ist.
Vielleicht sollte das Fhem Modul 55_PIFACE.pm umsteigen auf die Python Implemetierung oder die fehlenden Register Initialisierungen selber durchführen. Alles nicht so doll.

Ich für meinen Teil werde wohl für's erste in das Fhem Startscript einen Python pifacecommon Aufruf einbauen, der das Board initialisiert.

Patrik.S

Ich habe heute den Blog Post vom Entwickler gelesen.  :(
http://wiringpi.com/wiringpi-deprecated/
Ich kann ihn sogar verstehen, das er wiringPi nicht weiterentwickeln will.

Somit ist das Thema hier geerdet und wer sein PiFace weiter betreiben will, sollte auf andere Alternativen umsteigen,  inklusive Umbau der Fhem Module.  ???