Ein GPIO als Eingang via Interrupt erzeugt auf meinem Raspi eine dauerhaft hohe CPU-Auslastung. Es sieht so aus, als würde intern doch irgendwo ein Polling stattfinden, was die CPU belastet.
Ist dieses Verhalten as designed?
Internals:
CHANGED
DEF 23
EXCEPT_FD 14
GPIO_Basedir /sys/class/gpio
NAME Pin16
NR 20
RPI_pin 23
STATE off
TYPE RPI_GPIO
WiringPi_gpio /usr/local/bin/gpio
lasttrg 1470501618.9572
Readings:
2016-08-06 14:52:44 Counter 2
2016-08-06 16:48:06 Dblclick off
2016-08-06 16:48:06 Longpress off
2016-08-06 16:48:06 Pinlevel low
2016-08-06 16:48:06 state off
Fhem:
interfaces switch
Attributes:
debounce_in_ms 250
direction input
event-on-change-reading state,Pinlevel,Longpress,Dblclick
interrupt both
restoreOnStartup off
Im Bild ist die CPU-Auslastung von 30% zu sehen. Beende ich FHEM, ist sie wieder normal.
lg
aeronaut
Ich habe zwei Pins als Interrupt definiert (RPI1), und kworker verursacht zwischen 0,3 und 0,7% CPU Last.
An die Pins sind aber zwei Reed-Schalter angeschlossen, die nur selten auslösen.
Wie häufig werden die Interrupts denn bei dir ausgelöst?
Hm ja, anscheinend wird der ständig ausgelöst.
Ich sollte nochmal meine Schaltung überdenken. Gar nicht so einfach als E-Technik-Noob ::)
Zitat von: aeronaut am 06 August 2016, 19:04:37
Ein GPIO als Eingang via Interrupt erzeugt auf meinem Raspi eine dauerhaft hohe CPU-Auslastung. Es sieht so aus, als würde intern doch irgendwo ein Polling stattfinden, was die CPU belastet.
Ist dieses Verhalten as designed?
nee, isses nicht
Die Vervendung des Interrupts soll ja gerade das polling vermeiden.
Was ist an dem GPIO denn angeschlossen?
Wenigstens ein Pullup/down Widerstand sollte dran sein, da sonst der GPIO floatet. Ein angeschlossenes (offenes) Kabel wirkt dann wie eine Antenne und den Pin schaltet ständig. (allerdings wundert mich die 2 beim Counter. Die sollte in solch einem Fall recht schnell größer werden)
debounce_in_ms würde ich so klein wie möglich machen.
Während dieser Entprellzeit ist FHEM komplett blockiert.
[/quote]