Preempt-RT Patch ? Schon wer probiert?

  • Hallo,

    hat diesen Patch schon jemand probiert? Wie sind eure Erfahrungen damit?

    Ich habe immer weider mal Probleme mit DS18B20-Sensoren (geht verloren) und fehlerhafte Auslesevorgänge vom HX711 und ich vermute mehr "Echtzeitfähigkeit" würde dem Pi gut tun.

    Meine Vermutung, das Bus-timing kann nicht exakt eingehalten werden und kommt unregelmäßig außer Takt.

    Ich verwende seit heute die Kernel Version 4.19.29+ auf meinem Pi Zero-W, vielleicht hilft die auch schon ein wenig. Der Patch würde mich aber sehr interessieren.

    Was meint ihr?

    sG

    Martin

    http://www.frank-durr.de/?p=203

    https://lemariva.com/blog/2018/07/r…r-kernel-4-14-y

    Einmal editiert, zuletzt von zmaier (21. März 2019 um 12:29)

  • Kannst Du Deine Vermutung mit Fakten untermauern? Hast Du die Timings nachgemessen?

    Mit rpi-update holst Du Dir zwar „das neueste“ auf Deinen RPi, es handelt sich aber um Kernel, an denen gerade gebaut wird. Wenn Du nicht ganz genau weißt, warum Du genau diese oder jene Version einsetzen musst, handelst Du Dir u.U. Probleme an unerwarteten Stellen ein. Die Verwendung ist im Alltag absolut unnötig.

  • Wie kommst du jetzt auf rpi-update? Hier gehts doch um den "Echtzeitkernel".

    Ach! (Loriot)

    seit heute die Kernel Version 4.19.29+ auf meinem Pi Zero-W, vielleicht hilft die

    aktuell: Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l

    Was steht denn in der Doku des Patches bzw. den Release Notes des unstable Kernels der noch nicht freigegebenen und u.U. fehlerhaften Treiber und des neuesten Kernels zur Verbesserung der Stabilität von one wire?

  • aktuell: Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l

    Deswegen wird der Kernel ja selbst kompiliert und mit dem Patch versehen. Das hat erst mal nichts mit dem rpi-update zu tun. Ich will nicht drauf rumhacken, aber selbst beim rpi-update wird ein stabiler Kernel verwendet. Also der, der als letzter Kernel bei kernel.org als stabil markiert ist. Problem ist bei Raspbian nur das drumherum. Der derzeitige stabile Kernel ist übrigens 5.0.4. Wenn man wollte, könnte man den auch schon kompilieren und der wäre stabil, allerdings müssen dann auch die Treiberquellen passen. Bitte jetzt aber nicht wieder auf das Thema rpi-update aufsatteln, mit rpi-update wird zwar auch ein Kernel mitgegeben, hauptsächlich aber hängt es da trotz des stabilen Kernels an den Treibern, die im Gegensatz zum offiziellen Raspbian Image nicht zu 100% geprüft sind.

  • Ich hatte vor einigen Jahren ein wenig mit dem damaligen RT-Patch herumprobiert, aber nie wirklich eingesetzt.

    Einen weiteren Einstieg zum selber patchen findest Du >>> hier <<<. Die Scripte zum Bauen des Kernels liegen >>> hier<<<. Erfreulicherweise liegt die Konfiguration komplett bei. Probiert habe ich den Patch allerdings nicht.

    Ich bin mir aber auch überhaupt nicht sicher, ob der Einsatz eines RT-gepatchten Kernels wirklich Dein Problem löst. Es gibt genügend andere (Hardware-) Ursachen, die da reinspielen. Die erscheinen mir plausibler.

  • Hallo,

    danke für die Info.

    Hardwareprobleme schließe ich aus.

    Stabiles Labornetzteil

    4 Pi-Zeros und ein Pi3

    Mehrere verschiedene Chargen von DS18B20 (inkl. Kabellängen), jedoch alle von Ali, aber von unterschiedlichen Händlern

    Versorgung der Sensoren mit 3.3V oder 5V

    Widerstandswerte von 800 Ohm bis 5k alles durchprobiert.

    Ein Sensor alleine oder mehre Sensoren (2 und 5 Stück).

    Alles nicht stabil, Aussetzer die sich mit Reboot nicht lösen lassen. Manchmal funktioniert die Spannungsversorgung der Sensoren zu kappen, aber auch nicht immer. Dann hilft nur die Spannungsversorgung vom PI weg und ein hard-reset.

    Meine bescheidene Meinung, irgenwie muss der PI Probleme mit dem Bus haben. Der hängt sich sowas von auf, das nur mehr ein Hard-Reset hilft.

    Was ich auch komisch finde, warum gibt es keinen "Reset-Befehl" für den Bus - oder gibt's den und kenne ihn nicht?

    Weiters liest man ja öfters von Problemen mit den 1-Wire Sensoren ich bin ja nicht der Einzige der Probleme damit hat.

    https://community.hiveeyes.org/t/use-realtime…-sensors/1646/7

    Ich fürchte ich muss auf einen RTOS System (Arduino etc...) wechseln. Mit allen Nachteilen (Remote-Zugriff,...) :(

    sG

    Martin

  • irgenwie muss der PI Probleme mit dem Bus haben

    Problemen mit den 1-Wire Sensoren

    Ja, das scheint richtig. Allerdings habe ich seit wilden ISDN "Installationen" (Stern mit wahllos verstreuten Terminatoren...) selten so viele falsch bzw. mit ungeeigneten Mitteln angeschlossene Devices gesehen wie bei 1-wire. Da kommt dann eins zum anderen und am Ende geht nüscht mehr. Oder holprig.

    Ich fürchte ich muss auf einen RTOS System (Arduino etc...) wechseln. Mit allen Nachteilen (Remote-Zugriff,...)

    Wieso wechseln? Wenn Du es besser funktionierend hinbekommst, dann lass den Arduino/ESPxxx die Sensoren auslesen, da "pfuscht" Dir kein OS dazwischen. Den Rest machen dann RPi und Co.

  • Der Raspi besitzt keinen 1wire Controller. Er bitbangt einen GPIO. D.h. der Scheduler pfuscht Dir in's Protokoll hinein (siehe STF's Anmerkung oben). Das macht er bei dem "normalen" Kernel ebenso wie bei einem RTOS-Kernel. Im Gegenteil. Wenn Du Pech hast, dann funktioniert der momentan leidlich bitbangende Teil im RTOS-Patch noch schlechter, weil ihn die Threads jetzt wesentlich häufiger unterbrechen. Könnte also ein Schuß nach hinten werden.

    Ein echter 1wire Controller oder ein dafür abgestellter Arduino ist definitiv die bessere Lösung.

    Du könntest noch ausprobieren, ob sich Deine jetzigen Probleme einzelnen Sensoren zuordnen lassen. D.h. Sensoren handverlesen... Ist aber auch nur eine "faule Krücke".

  • Hi,

    Danke für die Infos.

    Mein Gedanke mit dem RTOS-Patch war eher so. Vielleicht (reine Vermutung) wird dadurch dem "1-Wire-GPIO-BitBanging" Threads mehr Priorität gegeben, als z.B. anderen Prozessen die nicht sooo zeitkritisch sind.

    Ich werde mir den Arduino ansehen.

    Danke,

    sG

    Martin

  • Der Patch ändert zunächst nix an der Vergabe von Prioritäten. Das ist die Sache eines jeden Programmierers. Er ändert das Verhalten des Schedulers (und wahrscheinlich auch der Synchronisationsobjekte - denn die sind eng mit dem Scheduler verwandt). Damit kann der Patch aber in beide Richtungen ausschlagen - in die gewünschte oder aber auch in's Gegenteil.

  • Hallo Schnasseldag,

    bleibt wie immer nur noch der Hinweis auf Bare Metal und darin das Bitbanging abzubilden. Wie es geht, verrät das Datenblatt.

    Und durch Bare Metal gibt's keine Einmischung des OS.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Servus Andreas,

    schön, daß Du mal wieder vorbeischaust!

    Klar, Bare Metal wäre auch eine technische Option. Allerdings hat ein Betriebssystem mit Filesystem und anderen "Kleinigkeiten" auch so seine Annehmlichkeiten ;), die man mit der Zeit zu lieben gelernt hat... Sieht man es von der Kostenseite, dann wären ein 1wire-Controller oder ein bitbangender Arduino/µC aber vermutlich attraktiver. Und wenn man nicht den Lerneffekt, sondern den "wie bekomme ich's schnell hin Effekt" in den Vordergrund stellt, dann ist's vermutlich der Arduino. Einen Sketch geklaut, und die Werte über die serielle Schnittstelle ausgegeben - fertig. Bleibt nur noch die verflixte 85.0. Mit der habe ich mich nie richtig anfreunden können. Was dem "Hitcher" die 42, daß dem 1wire-Temperatureinleser seine "85.0" ;)

    Schöne Grüße in's Ländle!

    schnasseldag

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!