SCC Busware 1101 unter Buster lite nicht mehr zu öffnen

Otto123 · 22 Dezember 2019, 20:44:59

Hallo Szlachta,

danke für die Rückmeldung

Wahrscheinlich kann man die Zeile enable_uart=1 auch noch weglassen, die wird vom System intern richtig gesetzt.

Es ist keine leichte Kost, aber zum nachlesen mal noch die offizielle Doku dazu
https://www.raspberrypi.org/documentation/configuration/uart.md

Edit: Allerdings ist es nach meinen Tests falsch die Zeile core_freq=250 wegzulassen. Dann ist die core Frequenz nicht mehr stabil und die miniuart läuft mit wechselnder Frequenz! Das ist, nach allem was ich gelesen habe, falsch!

Man kann das mit drei Zeilen Code und zwei Terminalfenstern einfach nachstellen. Man muss sysbench vorher installieren! In einem Fenster zeigt man die cpu Frequenz an und im anderen startet man den sysbench.

Code Auswählen

sysbench --test=cpu --num-threads=4 --cpu-max-prime=20000 run

vcgencmd measure_clock arm

vcgencmd measure_clock core

Frohe Weihnachten
Otto

isy · 23 Dezember 2019, 13:56:33

Hallo Otto,
ich habe alles nochmals aufgesetzt.

Es bleibt bei der FM im Syslog, FHEM läuft und der SCC auch:

Code Auswählen

Dec 23 13:47:49 fhem bash[516]: /opt/fhem/EnableSCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Dec 23 13:47:49 fhem bash[516]: /opt/fhem/EnableSCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 23 13:47:49 fhem systemd[1]: Failed to start FHEM Home Automation.
Dec 23 13:47:49 fhem systemd[1]: Started OpenBSD Secure Shell server.
Dec 23 13:47:49 fhem systemd[1]: Reached target Multi-User System.
Dec 23 13:47:49 fhem systemd[1]: Reached target Graphical Interface.
Dec 23 13:47:49 fhem systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Dec 23 13:47:49 fhem systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Dec 23 13:47:49 fhem systemd[1]: Stopped FHEM Home Automation.
Dec 23 13:47:49 fhem systemd[1]: Starting FHEM Home Automation...
Dec 23 13:47:49 fhem systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.

@Szlachta
Könntest du bitte mal die Syslog Ausgabe hier posten?

Code Auswählen

nano /var/log/syslog

Da der SCC funktioniert könnte es sein, dass bei dir auch eine FM im Syslog steht. Die fällt aber nicht auf.

Gruß Helmut

Szlachta · 23 Dezember 2019, 15:33:08

Hallo,

syslog sieht bei mir wie folgt aus und bringt ebenfalls einen Fehler, SCCs funktionieren...

Code Auswählen

Dec 23 15:23:54 RPi-FHEM4 bash[606]: /opt/fhem/EnableSCC.sh: Zeile 2: /sys/class/gpio/gpio17/direction: Keine Berechtigung
Dec 23 15:23:54 RPi-FHEM4 bash[606]: /opt/fhem/EnableSCC.sh: Zeile 3: /sys/class/gpio/gpio17/value: Keine Berechtigung
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Control process exited, code=exited, status=1/FAILURE
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Failed to start FHEM Home Automation.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Started OpenBSD Secure Shell server.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Stopped FHEM Home Automation.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Starting FHEM Home Automation...
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Started Samba NMB Daemon.
Dec 23 15:23:54 RPi-FHEM4 systemd[1]: Starting Samba SMB Daemon...
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Started Samba SMB Daemon.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Started FHEM Home Automation.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Reached target Multi-User System.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Reached target Graphical Interface.
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: Starting Update UTMP about System Runlevel Changes...
Dec 23 15:23:55 RPi-FHEM4 systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.

Szlachta · 23 Dezember 2019, 15:50:11

@Otto

Ohne die core-Zeile in der config.txt und bei laufendem Sysbench sehen die core Werte stabil aus (1. und letzter Wert jeweils vor/nach sysbench):

Code Auswählen

pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock core
frequency(1)=500000992
pi@RPi-FHEM4:~ $

Die arm Frequenz ändert sich im Wesentlichen durch das Starten/Beenden von sysbench (1. und letzter Wert sind jeweils vor bzw. nach sysbench-Lauf)

Code Auswählen

pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=600117184
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500398464
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=1500345728
pi@RPi-FHEM4:~ $ sudo vcgencmd measure_clock arm
frequency(48)=600169920
pi@RPi-FHEM4:~ $

sysbench:

Code Auswählen

pi@RPi-FHEM4:/boot $ sudo sysbench --test=cpu --num-threads=4 --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 4

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          63.3065s
    total number of events:              10000
    total time taken by event execution: 253.1727
    per-request statistics:
         min:                                 24.40ms
         avg:                                 25.32ms
         max:                                 76.00ms
         approx.  95 percentile:              25.95ms

Threads fairness:
    events (avg/stddev):           2500.0000/25.23
    execution time (avg/stddev):   63.2932/0.00

Otto123 · 23 Dezember 2019, 17:53:51

Aha, ok dann macht der PI4 dort etwas anderes als der PI3+. Oder ich habe was falsch gemacht?
Na ich werde nochmal probieren.
Der Text in der PI Dokumentation klingt ja eigentlich so als ob die Firmware selbsttätig alles richtig machen sollte.

Aber ich hatte früher andere Informationen und Erkenntnisse

Das Mit der Fehlermeldung beim Start prüfe ich auch noch mal. Ich meine wenn alles geht, sind ja zwei Meldungen "akademisch"

Schöne Weihnachten 🎅
Otto

isy · 23 Dezember 2019, 19:47:21

Hallo Otto,
alles prima!
Vielen, vielen Dank und ein schönes Weihnachtsfest!

Helmut

Otto123 · 29 Dezember 2019, 00:09:11

Hi,

Mein Testergebnis:
mit dem overlay miniuart-bt wird die miniuart aktiviert und auf die BT Schnittstelle geschaltet.
Wenn man beim Pi3 nicht die core_freq auf 250 festzurrt, funktioniert die BT Schnittstelle nicht, weil der Takt für die miniUart aus der core_freq abgeleitet wird.
Nachzulesen hier https://www.raspberrypi.org/documentation/configuration/uart.md

Zum Pi4 ist in der oben verlinkten Doku nichts geschrieben. Ich kann es auch nicht evaluieren.

Gruß Otto

isy · 29 Dezember 2019, 18:22:45

Moin,

ich habe mir mal ein FHEM Testsystem aufgebaut

Also:
PI4, Buster, core-freq auskommentiert:

Code Auswählen

# core_freq=250

Zumindest der lepresenced Daemon funktioniert einwandfrei.
Weitere Bluetooth Tests habe ich nicht unternommen

Gruß Helmut

Otto123 · 29 Dezember 2019, 18:26:44

Hallo Helmut,

naja in #75 sah es ja auch so aus, als ob die core_freq beim 4er auf 500 festgezurrt ist von Hause aus.

Bei meinem Test mit dem Pi3 und Pi3+ ging schon der Befehl hcitool dev nicht mehr

Reagiert er überhaupt auf den core_freq=250? Hast Du mal gemessen wie in #75 ?

Code Auswählen

vcgencmd measure_clock core

Gruß Otto

isy · 29 Dezember 2019, 18:44:52

Hallo Otto,

Mit

Code Auswählen

core_freq=250

Code Auswählen

vcgencmd measure_clock core
frequency(1)=250000496

Ohne

Code Auswählen

# core_freq=250

Code Auswählen

vcgencmd measure_clock core
frequency(1)=500000992

Der PI4 reagiert, aber auf lepresencede hat das wohl erst mal keinen Einfluss.
Der RSSI Wert liegt bei mir bei -67dB, egal ob mit 250 oder 500 MHz, ich dachte zuerst, die Empfindlichkeit sei reduziert bei 500 MHz.

Ich habe bei meinem Prod-System die core_freq auskommentiert.
Danach hat das System kurz gelaufen - Crash! Ethernet SST.
Bin wieder auf 250 MHz zurück.

Otto123 · 29 Dezember 2019, 18:56:23

Ok

Bei deinem Testsystem, also bei deinem Test mit Bluetooth, hattest Du das dtoverlay=miniuart-bt aktiv oder nicht? Nur dann spielt das mit der corefreq ja eine Rolle.

Ich muss nochmal schauen ob ich eine exakte Doku zur miniUART beim Pi4 finde ...

isy · 29 Dezember 2019, 19:19:29

Ja, war gesetzt:
dtoverlay=pi3-miniuart-bt

Habe beim Prod System wieder auf 500 MHz umgestellt.

Ich befürchte ein Spannungsproblem, welches durch die höhere Frequenz eher noch verstärkt wird.
Ich setze das Original 3A PI-Netzteil ein und habe den Eindruck, die Stromversorgung ist schwächer als beim PI2.
Warum?
Mein alte SSD (mit IDE-USB-2 Interface) wird erst gar nicht erkannt, die neue USB-3 SSD läuft nur, wenn der zusätzliche 5V Anschluss am HUB steckt.

Otto123 · 29 Dezember 2019, 19:36:06

der Pi liefert am USB nicht unbedingt freiwillig vollen Strom! config.txt

Code Auswählen

max_usb_current=1
Leider ist der Link in der config.txt gerade offline? http://rpf.io/configtxt
ich finde dazu aber widersprüchliche Behauptungen - also vielleicht ist das Halbwissen was ich hier erzähle

isy · 29 Dezember 2019, 19:49:58

Der Parameter ist neu für mich.
Habe ich am PI2 nicht gebraucht.

Danke für den Tipp, werde ich testen,

Otto123 · 29 Dezember 2019, 20:03:06

~~naja Vorsicht! Ich finde den in der Original Doku nicht mehr.~~ Kann sein das es jetzt per default so ist! Dann ist der Parameter nicht funktional.

ich habe die offizielle Doku gefunden: https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md
Dieser Eintrag in der config.txt ist für den Pi 4 obsolet - sorry für die Verwirrung!