Ich versuche gerade die Echtzeitfähigkeit eines Raspberry Pi auszutesten.
Raspberry Pi OS Lite
Release date: March 15th 2024
System: 32-bit
Kernel version: 6.6
Was zu erwarten war, gibt es relativ selten eine sehr kurze Unterbrechung des Rechtecksignals. Gibt es eine Möglichkeit, den Rechteckgenerator auf einen eigenen Core auszulagern?
1
// filename: fastPinToggle.c
2
//
3
// Test the real time capabilities of a Raspberry Pi
4
//
5
// Toogle an GPIO pin fast, use an oscilloscope to check the speed
Gibt es eine Möglichkeit, den Rechteckgenerator auf einen eigenen Core
auszulagern?
Welchen sinnvollen Grund gibt es, ein Rechtecksignal per Software unter einem nicht echtzeitfähigen OS zu erzeugen und dann ein jitterfreies Signal zu erwarten. Selbst kleine Mikrocontroller erzeugen solche Signale aus gutem Grund mit einem (Hardware-)Timer.
Ich versuche gerade die Echtzeitfähigkeit eines Raspberry Pi
auszutesten.
Raspberry Pi OS Lite
Release date: March 15th 2024
System: 32-bit
Kernel version: 6.6
Was zu erwarten war, gibt es relativ selten eine sehr kurze
Unterbrechung des Rechtecksignals. Gibt es eine Möglichkeit, den
Rechteckgenerator auf einen eigenen Core auszulagern?
Das Zauberwort fuer die Suche ist "linux core affinity". Ich weiss ja nicht, was fuer einen RaspberryPi hast (es gibt ja einige Hardware-Versionen, die genau einen Kern haben und dann bist Du sehr schnell "out of Cores").
Falls Dein Betriebssystem "taskset" unterstuetzt koennte das Dir helfen.
Mir auch:
Wie stellst du sicher, dass es keine Cache Misses gibt? Denn wenn der code irgendwann mal aus dem Cache fliegen sollte, bzw. garnicht ganz reinpasst (Keine Ahnung, wie gross Cache auf dem Prozessor ist), muss der ja erst aus dem DRAM neu geladen werden. Da dann gleich die naechste Frage: Wenn's DRAM grad "klemmt", weil wegen Refresh oder weil irgendein gepanzerter Penner grad einen DMA macht, wie lange kann das dann dauern...?
Ich versuche gerade die Echtzeitfähigkeit eines Raspberry Pi
auszutesten.
Das Vanilla Linux ist nicht "echtzeitfähig". Abhängig von der Anwendung kann man aber "nahe" dran kommen.
Wenn möglich direkt die Hardware nutzen (SPI, I2C, PWM). Queues über DMA. (Geht alles aus dem User Space). Dann kommt man auf zuverlässige Timings im 1us Bereich. Bei manuellen Füllen der Queues ist es Glückssache (klappt aber meist.)
Bit Banging ist dagegen "herausfordernd".
Der ganze Kram ist schlecht dokumentiert. Man weis nicht wirklich was BCM da macht (udn wird es wohl auch nie). Ich hatte bspw sporadisch 12us Aussetzer. (Waren aber keine Intr, zumindest wenn man den Linux Countern vertraut.)
Mit einem dedizierten Core kann man unerwünschte Unterbrechungen (Interrupts, Scheduling) reduzieren (also dein Ansatz hier); da der Bus aber geshared ist, nicht ausschließen (single Cache Miss liegt bspw. bei ca. 200ns auf dem Pi Zero).
Wenn Wiederhoung eine Option ist, dann kann man auch auf einen Single Core Bitbanging im us Bereich hin bekommen (1wire, 2812, etc.) Man muss dann vor und nach jeder Flanke die Zeit speichern (ns bus/timer; bus freq. voher auf const umstellen, glaube 250 MHz waren das) und nach Abschluss der Sequenz die Timings prüfen (ggf Reset/Wiederholen der Sequenz).
Was zu erwarten war, gibt es relativ selten eine sehr kurze
Unterbrechung des Rechtecksignals. Gibt es eine Möglichkeit, den
Rechteckgenerator auf einen eigenen Core auszulagern?
Der hat viele verschiedene CPU-Kerne für unterschiedliche Aufgaben: Zwei ARM64-Kerne für Linux, DSP-Kerne für Signalverarbeitung und ARM R5F-Kerne für Realtime-Tasks. Jeder Kern bzw. jede Gruppe von Kernen hat eigenen Speicher. Der Prozessor hat spezielle Hardware, mit denen die einzelnen Kerne schnell und effizient Informationen austauschen können.
Dein Rechteckgenerator würde da idealerweise auf einem der R5F-Kerne laufen.
Ich versuche gerade die Echtzeitfähigkeit eines Raspberry Pi
auszutesten.
Das ist wohl eher die Echtzeitfähigkeit des verwendeten Linux-Systems, der Raspi ist zwei Größenordnungen schneller als Linux.
Was zu erwarten war, gibt es relativ selten eine sehr kurze
Unterbrechung des Rechtecksignals.
Wäre es Dir möglich, das Wort "kurz" etwas zu präzisieren? Die Verteilung der Ausreißer könnte z.B. auf einen typischen Grund hinweisen.
Gibt es eine Möglichkeit, den
Rechteckgenerator auf einen eigenen Core auszulagern?
Erwarten würde ich, daß sich dadurch nur wenig ändert, da auch der zweite Core von Linux verwaltet wird und dessen Schedulingalgorithmen unterliegt. Das würde m.E. nur dann viel ändern, wenn man den 2.Core ganz aus der Linuxverwaltung herausnimmt. Aber das ist natürlich Spekulation, bin gespannt auf das Ergebis,
Die bisherigen Studien, die ich zu dem Thema gelesen habe (PC und Beaglebone), kamen alle auf eine Grenze so irgendwo zwischen 10 und 50 Mikrosekunden Jitter.
Würde mich interessieren, wie es auf dem Raspi aussieht.
Wäre es Dir möglich, das Wort "kurz" etwas zu präzisieren? Die
Verteilung der Ausreißer könnte z.B. auf einen typischen Grund
hinweisen.
Ich versuche, die Untergrenze heraus zu finden. Das können zur Not auch 10kHz oder 20kHz sein.
Gibt es eine Möglichkeit, den
Rechteckgenerator auf einen eigenen Core auszulagern?
Erwarten würde ich, daß sich dadurch nur wenig ändert, da auch der
zweite Core von Linux verwaltet wird und dessen Schedulingalgorithmen
unterliegt. Das würde m.E. nur dann viel ändern, wenn man den 2.Core
ganz aus der Linuxverwaltung herausnimmt. Aber das ist natürlich
Spekulation, bin gespannt auf das Ergebis,
Das scheint tatsächlich ein Problem. Es wäre super, wenn man den Core für Linux sperren könnte. Das ist möglicherweise aber gar nicht vorgesehen.
Irgendwo habe ich was von einer Untergrenze von 5ms gelesen (200Hz), was mir aber definitiv zu langsam wäre.
Um noch mal auf die Pin-Toggle Geschwindigkeit zu kommen:
Hier gibt es eine Bare-Metal-Implementierung von HZeller. Der Raspi 3B+, den ich gerade verwende wird dort bei der Software-Loop mit 65MHz angeben.
Ich habe das Beispiel mal kompiliert, der Pin toggled aber nicht..
Die Untersuchung ist aber ziemlich ausführlich und gibt für die verschieden Raspi Typen und verschiedenen Verfahren wie DMA Benutzung ein Tabelle mit der Übersicht.
So, ich bin wieder ein Stück weiter gekommen.
Die Anzahl der "Cöre" die beim Raspi verwendet werden, lassen sich durch einen Eintrag in cmdline.txt bestimmen.
isolcpus=3
Scheinbar wichtig: Der Eintrag von "isolcpus=3" hat bei mir nur funktioniert, wenn er ganz hinten stand.
Wie man im Bild von htop sieht, ist der Core3 jetzt voll ausgelastet.
Es gibt zwar sehr selten kurze Verlängerungen des 10kHz Signals, das könnte für meine Anwendung akzeptabel sein.
Das kommt mir hier ein bisschen so vor, wie wenn man mit Gewalt mit einem Buegeleisen sich eine Scheibe Leberkäs' braten will. Klar, geht schon irgendwie - aber es gibt dafuer viel besser geeignete Haushaltsutensilien...
Das kommt mir hier ein bisschen so vor, wie wenn man mit Gewalt mit
einem Buegeleisen sich eine Scheibe Leberkäs' braten will.
Warum?
Der Sinn dieser Aktion hier ist natürlich auszutesten, wie schnell ein Echtzeitzyklus auf einem Raspberry Pi sein kann. Das Pin-Toogling wird hier nur als Messmethode benutzt.
Ein Raspberry Pi hat gegenüber anderen Mikrocontrollern enorme Vorteile:
hoher Verbreitungsgrad, viel Dokumentation
sehr günstig
viele unterstütze Varianten
mit Linux ein riesiger Softwarepool.
Im Grunde genommen ist Linux ein "Echtzeitbetriebssystem", sonst könnte man nicht stundenlang unterbrechungsfrei Musik hören oder Videospiele spielen. Insbesondere bei Videospielen muss die Reaktionszeit ja bei unterhalb von zehntel Sekunden liegen. Ich vermute, das 20ms garantiert sind. Diese Thread behandelt die Frage, wie schnell die Echtzeitloop wirklich ohne Störungen sein kann.
Im letzten von mir geposteten Beispiel bei dem ein Core speziell für das Pin-Toogling reserviert wird, kann man 1kHz Softwarepintoogling erreichen.
Für die Library "Pigpio" gibt es ein Beispiel für mehrere PWM-Ausgaben gleichzeitig, mit derselben PWM-Frequenz in Stufen von 1µs:
https://abyz.me.uk/rpi/pigpio/examples.html
-> "Wave PWM 2"
Nö. Linux ist ein Betriebssystem, kein RTOS.
Da ist nichts garantiert.
Der Scheduler ist einfach nur besser als der von MS Windows.
Deine Beispiele sind etwas an den Haaren herbeigezogen:
Musik wird gepuffert - lass dein Raspberry Pi mal richtig was rechnen, dann stockt auch irgendwann die Musik.
Deine Beispiele sind etwas an den Haaren herbeigezogen:
Wieso? Haben die Videospiele Aussetzer?
Vielleicht, vielleicht auch nicht. Videospiele erfordern keine Echtzeitfähigkeiten. Wenns mal laggt, ärgert sich der Spieler und das wars.
Linux ist out of the box nicht echtzeitfähig. Preempt-rt ist seit gefühlten 15 Jahren immer ganz kurz davor, vollständig in den mainline-kernel integriert zu werden.
Erwarten würde ich, daß sich dadurch nur wenig ändert, da auch der
zweite Core von Linux verwaltet wird und dessen Schedulingalgorithmen
unterliegt. Das würde m.E. nur dann viel ändern, wenn man den 2.Core
ganz aus der Linuxverwaltung herausnimmt. Aber das ist natürlich
Spekulation, bin gespannt auf das Ergebis,
Das scheint tatsächlich ein Problem. Es wäre super, wenn man den Core
für Linux sperren könnte. Das ist möglicherweise aber gar nicht
vorgesehen.
Aber ja doch, dafür gibt es den Bootparameter "isolcpus".
Linux ist out of the box nicht echtzeitfähig. Preempt-rt ist seit
gefühlten 15 Jahren immer ganz kurz davor, vollständig in den
mainline-kernel integriert zu werden.
Im Grunde genommen ist Linux ein "Echtzeitbetriebssystem", sonst könnte
man nicht stundenlang unterbrechungsfrei Musik hören oder Videospiele
spielen. Insbesondere bei Videospielen muss die Reaktionszeit ja bei
unterhalb von zehntel Sekunden liegen. Ich vermute, das 20ms garantiert
sind. Diese Thread behandelt die Frage, wie schnell die Echtzeitloop
wirklich ohne Störungen sein kann.
Linux kann nur weiche Echtzeit. Wenn Video oder Audio mal etwas stottern, ist das nicht weiter schlimm. Wenn aber ein 3t-Kran irgendwo gegen fährt, weil eine Deadline nicht eingehalten wird, dann ist das was anderes. Das ist harte Echtzeit. Harte Echtzeit heißt, dass Reaktionszeiten unter allen denkbaren Umständen garantiert eingehalten werden. Dafür wurde Linux nicht gemacht, und dafür ist es auch nicht geeignet. Wirklich Garantiert ist da überhaupt nichts. Das muss Dir klar sein.
Genau dafür gibts dann z.B. die Prozessoren, die auf dem Beaglebone AI-64 drauf sind. Die haben für so etwas extra Kerne, die unabhängig vom Linux laufen. Da kann man dann auch zwei Kerne zusammenschalten, so dass sie im Lockstep laufen und sich gegenseitig überwachen. Wenn sich der Zustand der beiden Kerne voneinander unterschiedet, gibts eine Exception, und das gesamte System geht in einem Not-Aus. Natürlich ist auch der Speicher per ECC gesichert, um Bitfehler zu erkennen und ggf zu korrigieren. Das ist einfach eine ganz andere Nummer. Der Broadcom-Prozessor auf dem Pi ist ursprünglich nur für digitale Bilderrahmen und so entwickelt worden.
Ja, der Pi ist güntig (wobei der Pi 5 auch schon nicht mehr ganz so günstig ist und in die Preisregionen kleiner x86-System kommt), und ja, er ist weit verbreitet. Aber das ist noch kein Grund dafür, jedes Problem damit lösen zu wollen. Wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus.
Christoph db1uq K. (christoph_kessler)
17.06.2024 08:50
Für die Library "Pigpio" gibt es ein Beispiel für mehrere PWM-Ausgaben
gleichzeitig, mit derselben PWM-Frequenz in Stufen von 1µs:
https://abyz.me.uk/rpi/pigpio/examples.html
Gilt das auch für die Herausnahme des Cores aus der Linux-Verwaltung in
meinem Beispiel oben?
Echtzeit ist nicht nur vom Kern abhängig, das drumherum ist auch wichtig.
Ein fetter I7 kann schlechter RT fähig sein, als ein 8bit AVR.
Wie soll man von Pin Togglen, einfach so schnell wie möglich rechteck ausgeben, auf die Echtzeitfähigkeit schliessen können?
Eine Aussage
"Es gibt zwar sehr selten kurze Verlängerungen des 10kHz Signals, das
könnte für meine Anwendung akzeptabel sein."
sagt nur aus, daß Du eine Idee aber keine wirkliche Vorstellung deiner eigenen Anforderungen hast.
Bei Echtzeit, nur harte zählt hier, gibt es kein "könnte". Entweder es wird eingehalten oder nicht und bei letzterem ist es keine.
Du kannst ja mal deine theoretische Anforderung angeben.
Vermutlich ist es einfacher einen uC zu nehmen.
Ja. Überlege mal, was mit den Interrupts pasiert. Zumindest bei den
älteren Pis sind die immer auf Kern 1 aufgeschlagen.
Ich nutze Core3. Welche Interrupts können diesen Core stören und wie
lange?
Das könnte Dir sicher nur Broadcom sagen, und die werden nicht mit Dir reden. Ein PI ist halt keine Open Hardware, da ist vieles von Broadcom einfach nicht dokumentiert und hinter Binärblobs versteckt. Dazu gehört beispielsweise auch der Videocore, der sich die internen Resourcen mit den ARM-Kernen teilt und der wesentlich mehr macht als nur Video.
Bei dem TI-Prozessor des Beaglebones bekommst Du wenigstens Datenblätter, Referenzmanuals und Referenzdesigns - da kannst Du wesentlich tiefer reinschauen. Und Du kannst TI fragen, und die antworten tatsächlich auch. Ich habs ausprobiert.
Wie gesagt, es ist schon ein Unterschied zwischen "funktioniert zufällig" und "ist per Design garantiert".
Genau das meine ich mit "falsche Hardware gewählt".
Du kannst ja mal deine theoretische Anforderung angeben.
Vermutlich ist es einfacher einen uC zu nehmen.
Vermutlich hast du den Thread nicht gelesen. Es geht darum, die Untergrenze der Zykluszeit herauszufinden.
Nach einigen Experimenten läuft das System sehr stabil mit 500us. Das bedeutet, mit der obigen Loop-Synchronisierung kann man ein System mit 1000us Zykluszeit bauen. Die Hälfte davon kann in der Loop für Rechnungen verbraucht werden, der Rest wird für das Housekeeping von Linux verbraucht.
Im RPI 3 B+ ist ein
Broadcom BCM2837B0 quad-core A53 (ARMv8) 64-bit @ 1.4GHz
Damit bleiben in der 1kHz loop 50% der Rechenleistung für Double-Precision Rechnungen übrig.
Entspricht also einem 700MHz 64 Bit Prozessor, wenn man nur einen Core für die "Echtzeit" nutzt.
Bei Echtzeit, nur harte zählt hier, gibt es kein "könnte". Entweder es
wird eingehalten oder nicht und bei letzterem ist es keine.
Echtzeit bedeutet auch nicht notwendigerweise schnell, Echtzeit bedeutet nur "RECHTZEITIG", auch eine garantierte Reaktionszeit von 1 Sekunde kann Echtzeit bedeuten; 1.001 s ist dann nicht mehr zu tolerieren.
Bei Echtzeit, nur harte zählt hier, gibt es kein "könnte". Entweder es
wird eingehalten oder nicht und bei letzterem ist es keine.
Echtzeit bedeutet auch nicht notwendigerweise schnell, Echtzeit
bedeutet nur "RECHTZEITIG", auch eine garantierte Reaktionszeit von 1
Sekunde kann Echtzeit bedeuten; 1.001 s ist dann nicht mehr zu
tolerieren.
Hab ich das irgendwo behauptet, falls es so rüberkam, dann ist das blöd.
Klar, Harte echtzeit kann auch bedeuten, daß die Reaktion auf das ereignis innerhalb 1,5Jahre+-3h sein kann.
Auf ein Ereignis muss innerhalb eines festgelegten Zeitfensters die Reaktion erfolgen, nicht vorher und nicht später.
Deswegen ist das ganze Sinnfrei ohne die Anforderung anzugeben.
Du kannst ja mal deine theoretische Anforderung angeben.
Vermutlich ist es einfacher einen uC zu nehmen.
Vermutlich hast du den Thread nicht gelesen. Es geht darum, die
Untergrenze der Zykluszeit herauszufinden.
Du hattes von RT fähigkeit geschrieben, und jetzt geht es um irgendeine untergrenze irgendeiner Zykluszeit.
Was genau wird denn in dem Zyklus abgearbeitet?
PS: in Sachen Zykluszeit ist wago da genial drin.
Wago + Dali, System, läuft, aber nach einigen Woschen auf einmal Zykluszeit von 30 Sekunden. Die von Wago haben selbst keinen Fehler finden können.
Du hattes von RT fähigkeit geschrieben, und jetzt geht es um irgendeine
untergrenze irgendeiner Zykluszeit.
Die Frage ist ganz einfach: Wie schnell kann ein Raspi auf eine wechselnde Eingangsinformation antworten. Im Moment lautet meine Antwort aus dem praktischen Experiment am Raspi 3B + mit reserviertem 3.ten Core: Innerhalb einer Millisekunde.
Bei Echtzeitsystemen werden bevorzugt mit konstanter Abtastrate verwendet. Die Abtastrate z.B. 1ms nennt man auch Zykluszeit.
Wie schnell kann ein Raspi auf eine
wechselnde Eingangsinformation antworten. Im Moment lautet meine Antwort
aus dem praktischen Experiment am Raspi 3B + mit reserviertem 3.ten
Core: Innerhalb einer Millisekunde.
Immer? Das bedeutet, es dauert niemals länger als eine Millisekunde? Unter keinen Umständen? Kannst Du das verifizieren?
Nein, es ist kein Beweis, die Sache einen Tag lang laufen zu lassen und die Verteilung der Zykluszeiten, Streuung und Min-Max-Werte zu dokumentieren. Und ich rede erst gar nicht von Watchdog, Redundanz etc.
Immer? Das bedeutet, es dauert niemals länger als eine Millisekunde?
Wenn er ein Echtzeitbetriebssystem verwendet, dann schon. Aber AFAIK macht er das ja gar nicht.
Die eine Millisekunde ist übrigens nur ein Beispielwert. Ein Echtzeitbetriebssystem kann auch eine Reaktionszeit von einem Monat haben. Nur muß sie eben garantiert sein. Unser Prof pflegte zu sagen: "Echtzeitig ist rechtzeitig."
Es gibt auch so ein RISV-V low cost Board, Milk-V für 5 $ (real eher 10 €).
Das hat zwei Kerne, Linux kann nur auf einem laufen, auf dem anderen z.B. FreeRTOS, so ist das wohl in einem Image schon drin das man laden kann.
Ich habe das hier liegen aber noch nichts damit gemacht, so plug 'n play wie ein Raspberry Pi ist es nicht.
Vielleicht ist das ja eine Alternative, hat das hier jemand schon mal eingesetzt?
Es gibt auch so ein RISV-V low cost Board, Milk-V für 5 $ (real eher
10 €). Das hat zwei Kerne, [...]
Sogar 4, einen RISV-V mit 1GHz, einen RISC-V mit 700MHz, einen Cortex-A53 mit 1GHz und einen 8051 mit 300MHz, mit der Einschränkung, dass nur einer der 1GHz-Cores benutzt werden darf. Dazu noch eine 0.5/1.0TOP NPU. Ein echter Frankenstein-Proz - weiß noch nicht, was ich davon halten soll. Hab den Eindruck, da konnte sich einer nicht entscheiden ...
Mit etwas Glück könnte der 8051 Core deterministische Laufzeiten haben.
Immer?
Ein kleiner Hinweis: nichts ist für immer. Auch nicht bei einem
Echtzeitbetriebssystem. Es ist alles eine Frage der Wahrscheinlichkeit.
Doch, wenn nicht dann ist es nicht Echtzeit oder ein Fehler im Programm.
Externe Einflüsse, wie z.B. ein um die Ecke hochgehendes AKW zählt nicht dazu.
Das ist ja der Sinn von Echtzeit, sonst bräuchte man das nicht.
PS: Kannst ja mal schauen ob WinCE drauf läuft. Das ist Echtzeitfähig und war wohl auch garnichtmal so schlecht.
Bei Echtzeitsystemen werden bevorzugt mit konstanter Abtastrate
verwendet. Die Abtastrate z.B. 1ms nennt man auch Zykluszeit.
Was wird da abgetastet?
Ob es so ist, das hängt von der Anforderung ab, das kann man gar nicht verallgemeinern.
Und da ist der Begriff "Zykluszeit" auch Sinnfrei.
Weil es nicht darum geht wann das Ereignis auftritt und wielange es bis zur Detektierung dauert, sondern es geht einzig darum, daß innerhalb des festgelegten Zeitfensters auf die Aktion die Reaktion erfolgt.
Ein kleiner Hinweis: nichts ist für immer. Auch nicht bei einem
Echtzeitbetriebssystem. Es ist alles eine Frage der Wahrscheinlichkeit.
Jens B. (dasjens)
Doch, wenn nicht dann ist es nicht Echtzeit oder ein Fehler im Programm.
Externe Einflüsse, wie z.B. ein um die Ecke hochgehendes AKW zählt nicht
dazu.
Das entscheidende Wörtchen "wenn" ist was die Realität von der Wunschvorstellung unterscheidet. Die Idealvorstellung ist ein System mit "harter Echtzeit" zu bauen. Das ist aber nur eine mathematische Idealvorstellung, die es real nicht gibt, da ein System immer ausfallen oder gestört werden kann. Das einzige was es gibt, ist diese Wahrscheinlichkeit zu minimieren. Wenn diese Wahrscheinlichkeit klein genug ist, wird das System akzeptiert. Selbst bei der Bitweisen Datenübertragung auf einer digitalen Leitung zwischen zwei Geräten geht man von einer "Bit Error Rate" von ca. 10e-12 aus.
Ein gestörtes Echtzeitsystem hat eine Antwortzeit unbekannter Dauer und es stellt sich die Frage nach der Wahrscheinlichkeit einer der Dauer einer ungestörten Antwortzeit. Bei einem sicherheitskritischen Echtszeitsystem mag das je nach SIL- oder ASIL Klasse bei 10e-9 liegen.
Bei einem Videospiel auf einem Linux Computer oder dem Musikhören oder Videoschauen mag das Akzeptanzkriterium bei einem Hänger in 8 Stunden liegen. Dort ist die Anforderung an die Ausfallwahrscheinlichkeit niedriger.
Da es diese Anwendungen millionenfach gibt, funktionieren sie wohl in akzeptabler Weise.
Die Idealvorstellung ist ein System mit "harter Echtzeit" zu bauen. Das
ist aber nur eine mathematische Idealvorstellung, die es real nicht
gibt, da ein System immer ausfallen oder gestört werden kann.
Du hast es nicht verstanden.
Echtzeitfähigkeit im OS-Kontext bedeutet, innerhalb einer definierten Zeit garantiert, d.h. mathematisch nachweisbar, reagieren zu können.
Äußere Störungen zählen nicht.
Der Begriff "Echtzeit" macht ohne Angabe von garantierten
Redaktionszeiten keinen Sinn.
Doch, macht er. Es beschreibt schlicht die Tatsache, dass es
garantierte Redaktionszeiten
überhaupt gibt.
Oder, wie Wikipedia schreibt:
"Entscheidend ist hier nicht die Länge der Frist, sondern dass es überhaupt eine Frist gibt, deren Einhaltung zugesichert werden kann."
...womit Echtzeitbetriebssystem dann wieder von so ziemlich jedem OS erfüllt wird. Garantierte Reaktionszeit von einer Minute sollte mit Hardwaretimern und Interrupts ja realisierbar sein.
Es sollte also schon als Kriterium hinzugefügt werden, was genau in welcher Zeit und auch wie oft garantiert wird.
Es sollte also schon als Kriterium hinzugefügt werden,
Wenn du halt unbedingt deine eigene, private Definition eines RT-OS haben willst, es hindert dich niemand.
Ob du dann vom Rest der Welt verstanden wirst steht auf einem anderen Blatt.
Ein kleiner Hinweis: nichts ist für immer. Auch nicht bei einem
Echtzeitbetriebssystem. Es ist alles eine Frage der Wahrscheinlichkeit.
Jens B. (dasjens)
Doch, wenn nicht dann ist es nicht Echtzeit oder ein Fehler im Programm.
Externe Einflüsse, wie z.B. ein um die Ecke hochgehendes AKW zählt nicht
dazu.
Das entscheidende Wörtchen "wenn" ist was die Realität von der
Wunschvorstellung unterscheidet. Die Idealvorstellung ist ein System mit
"harter Echtzeit" zu bauen. Das ist aber nur eine mathematische
Idealvorstellung, die es real nicht gibt, da ein System immer ausfallen
oder gestört werden kann. Das einzige was es gibt, ist diese
Wahrscheinlichkeit zu minimieren. Wenn diese Wahrscheinlichkeit klein
genug ist, wird das System akzeptiert. Selbst bei der Bitweisen
Datenübertragung auf einer digitalen Leitung zwischen zwei Geräten geht
man von einer "Bit Error Rate" von ca. 10e-12 aus.
Was hat das mit Echtzeit zu tun?
Zeig dochmal bitte wo die definition von RT Störung steht. Aber bitte seriöse Quellen, nicht sowas wie wikipedia.
Bei einem Videospiel auf einem Linux Computer oder dem Musikhören oder
Videoschauen mag das Akzeptanzkriterium bei einem Hänger in 8 Stunden
liegen. Dort ist die Anforderung an die Ausfallwahrscheinlichkeit
niedriger.
Ja, da läuft CodeSys drauf.
Aber es steht nirgends dass da harte Echtzeit am laufen ist.
Und wie gesagt, bei Wago gabs auch schon mal einfach so 30Zykluszeit, da läuft auch Codesys.
Die Zykluszeit hat zwar nichts mit RT zu tun, aber wenn solche Fehler auftreten können, dann ist das gesamtsystem auch nichts zuzutrauen.
...womit Echtzeitbetriebssystem dann wieder von so ziemlich jedem
OS
erfüllt wird. Garantierte Reaktionszeit von einer Minute sollte mit
Hardwaretimern und Interrupts ja realisierbar sein.
Dazu muss der Interrupt auch aktiv sein. Was wenn der gerade gesperrt wurde?
Und hardwaretimer haben auch nicht mit RT direkt zu tun.
Es sollte also schon als Kriterium hinzugefügt werden, was genau in
welcher Zeit und auch wie oft garantiert wird.
Wie soll das gehen?
Alle möglichen Kombinationen angeben?
Die OS Hersteller wissen doch garnicht was Du machen willst und welche Hardware eingesetzt wird.
DopplershiftberechnungAuswertung bei 1m/d oder Lichtgeschwindgkeit?
Genau dafür gibts dann z.B. die Prozessoren, die auf dem Beaglebone
AI-64 drauf sind. Die haben für so etwas extra Kerne, die unabhängig vom
Linux laufen.
...isolcpus, um definierte Prozessorkerne aus dem Task Scheduling des Kernels herauszunehmen, und taskset(1), um einen Prozeß an diese Prozessorkerne zu binden. Hier gibt es ein paar ausführlichere Informationen zum Thema:
Genau dafür gibts dann z.B. die Prozessoren, die auf dem Beaglebone
AI-64 drauf sind. Die haben für so etwas extra Kerne, die unabhängig vom
Linux laufen.
Ein T. (ein_typ)
18.06.2024 19:46
...isolcpus, um definierte Prozessorkerne aus dem Task Scheduling des
Kernels herauszunehmen, und taskset(1), um einen Prozeß an diese
Prozessorkerne zu binden.
So ist es. Allerdings habe ich das schon relativ früh im Thread als ziemlich einfaches Demo implementiert
Wer also gewollt hätte, hätte es schon praktisch probieren können. Die
Bindung ist im Demo aber nicht über taskset sondern im Code realisiert.
Das hast Du gut gemacht. Dein Link ist leider etwas veraltet und lückenhaft. Deswegen habe ich ein wenig Dokumentationen für jene verlinkt, die nicht nur unverstandenen Code kopieren, sondern wirklich wissen wollen, wie die Sache funktioniert und wie man sie richtig macht.
Das könnte Dir sicher nur Broadcom sagen, und die werden nicht mit Dir
reden. Ein PI ist halt keine Open Hardware, da ist vieles von Broadcom
einfach nicht dokumentiert und hinter Binärblobs versteckt. Dazu gehört
beispielsweise auch der Videocore, der sich die internen Resourcen mit
den ARM-Kernen teilt und der wesentlich mehr macht als nur Video.
Bei dem TI-Prozessor des Beaglebones bekommst Du wenigstens
Datenblätter, Referenzmanuals und Referenzdesigns - da kannst Du
wesentlich tiefer reinschauen. Und Du kannst TI fragen, und die
antworten tatsächlich auch. Ich habs ausprobiert.
Genau das meine ich mit "falsche Hardware gewählt".
ist auch mein Eindruck nach ein paar Tagen mit meinem neuen
RP5. Mit der PRU des BeagleBoneBlack konnte ich 2 Flanken erzeugen
mit 5 ns Abstand, und das waren immer 5 ns Abstand. Bit-Banging
von einem C-Programm aus.
Beim RP5 habe ich in den paar Tagen noch nicht rauskriegen können,
wie groß ein Datenfeld beim SPI sein darf, wie schnell das
gesendet werden kann oder wie lange das von C aus dauert und
wo man das einstellt.
Bevor ich überhaupt um ein Datenblatt betteln kann, werde ich
erst mal gründlich ausgequetscht, bis hin zur Körbchengröße der
Freundin. Na ja, fast. Hier sammelt sich Unmut an.
Meine Begeisterung für Pis hält sich auch in Grenzen. Und dann ist da noch die Zielgruppe. Wer wirklich harte Echtzeit braucht, der sucht sich auch die optimale Hardware dafür aus, was auch immer das sein mag. Da haben Firmen wie TI und Renesas einen deutlichen Vorsprung. Da weiß man auch, dass die Hardware nur zu einem Teil zu den tatsächlichen Systemkosten beiträgt.
Die Leute, die sich mit Pis beschäftigen, machen das oftmals wegen der Anschaffungskosten der Hardware und der Community, deren Hilfe sie brauchen. Und die meisten davon brauchen keine harte Echtzeit. Und solche Dinge wie Yocto sind in Bastlerkreisen eher wenig bekannt.
Bevor ich überhaupt um ein Datenblatt betteln kann, werde ich
erst mal gründlich ausgequetscht, bis hin zur Körbchengröße der
Freundin. Na ja, fast. Hier sammelt sich Unmut an.
Gruß, Gerhard
Manchmal hilft auch im Kernel zu suchen.
Das hilft aber auch nicht gegen verzweifeln, ganz im Gegenteil.
Alleine beim Parport Treiber. Jeder Hersteller macht es anders und niemand sagt einem wie.
Genau das meine ich mit "falsche Hardware gewählt".
Gerhard H. (ghf)
ist auch mein Eindruck nach ein paar Tagen mit meinem neuen
RP5. Mit der PRU des BeagleBoneBlack konnte ich 2 Flanken erzeugen
mit 5 ns Abstand, und das waren immer 5 ns Abstand. Bit-Banging
von einem C-Programm aus.
Es ist mir schon klar, dass ein Raspi nicht die optimale Platform für Echtzeitanwendungen ist. Ich verwende sehr viel lieber Mikrocontroller ohne Betriebssystem. Und wer sich wirklich in der Tiefe auskennt hier mal eine für das MC-Netz schwer zu verdauende These: der einzig wirklich echtzeitfähige Controller, den ich kenne (es mag weitere mit dieser Struktur geben) heißt "Parallax Propeller". Der Grund: die 8 Kerne laufen parallel ohne Störungen durch Interrupts bei denen nicht Zyklengenau bekannt ist, wann diese abgearbeitet werden und keine Memories mit nachzuladenden Cashes und unbekannten Delays, weil es keine gibt. Das stellt man aber nur fest, wenn man mit solchen Controller gearbeitet hat.
Der ein- oder andere wird einwenden: Ich habe Applikationen, bei denen die Signale auf 5ns genau wiederholbar sind. Das sind aber die Peripherieeinheiten wie Zähler, PWM-Einheiten oder ähnliches und nicht die vom Programmkern erzeugten Signale. Zwischen Programmkern und Ansprechen dieser Peripherieieinheiten ist immer mit einem Zeitdelay verbunden. Oder kurz: Ein System, das auf 5ns Sekunden genau Signale ausgibt ist kein System, das einen in Software implementierten PID-Regler verwendet, dessen Realtimeantwort bei 5ns liegt.
Die Frage, ob ein Raspi für Echtzeitaufgaben verwendet werden kann (die man ohnehin nur mit Gesamtsystembetrachtungen über die geforderte Zuverlässigkeit beantworten kann, wie ich oben ausgeführt habe), stellt sich insbesondere für die Verwendung von ROS2. Denn immerhin würde man erwarten, dass so ein Roboter seine Bewegungen für eine gewisse Zeit im Griff hat.
der einzig wirklich
echtzeitfähige Controller, den ich kenne (es mag weitere mit dieser
Struktur geben) heißt "Parallax Propeller". Der Grund: die 8 Kerne
laufen parallel ohne Störungen durch Interrupts bei denen nicht
Zyklengenau bekannt ist, wann diese abgearbeitet werden und keine
Memories mit nachzuladenden Cashes und unbekannten Delays, weil es keine
gibt. Das stellt man aber nur fest, wenn man mit solchen Controller
gearbeitet hat.
Häh? Was ist daran Echtzeitfähig?
Man sieht, Du hast NULL Ahnung vom Thema.
ist auch mein Eindruck nach ein paar Tagen mit meinem neuen
RP5. Mit der PRU des BeagleBoneBlack konnte ich 2 Flanken erzeugen
mit 5 ns Abstand, und das waren immer 5 ns Abstand. Bit-Banging
von einem C-Programm aus.
Es ist mir schon klar, dass ein Raspi nicht die optimale Platform für
Echtzeitanwendungen ist. Ich verwende sehr viel lieber Mikrocontroller
ohne Betriebssystem. Und wer sich wirklich in der Tiefe auskennt hier
mal eine für das MC-Netz schwer zu verdauende These: der einzig wirklich
echtzeitfähige Controller, den ich kenne (es mag weitere mit dieser
Struktur geben) heißt "Parallax Propeller". Der Grund: die 8 Kerne
laufen parallel ohne Störungen durch Interrupts bei denen nicht
Die PRUs beim BBB SIND 200 MHz-Mikrocontroller ohne Betriebsystem
und ohne Interrupts. Sie reden mit dem Hauptprocessor (1GHz ARM)
nur über Dual Port Rams und haben direkten Zugriff auf IO-Pins.
Mit etwas Hilfe eines Coolrunners kann man damit z.B. richtig
schnelle ADCs auslesen ohne dass die Zeitreihen verschweinert werden.
Es gibt eine bombensichere Art, den Pi echtzeitfaehig zu machen: bare metal, ohne Betriebssystem. Eben so wie man es mit einem ARM Mikrocontroller macht. Beispiele:
Dieses Projekt nutzt Circle als Unterbau. Bei den anderen beiden konnte ich in der Kürze nicht erkennen, ob sie vollständig selbstgemacht oder auch ein Framework benutzten.
Das Pistorm Projekt benötigt ein CPLD oder FPGA, dort weiß ich nicht, wie stark das zur Synchronisation beiträgt.
ist auch mein Eindruck nach ein paar Tagen mit meinem neuen
RP5. Mit der PRU des BeagleBoneBlack konnte ich 2 Flanken erzeugen
mit 5 ns Abstand, und das waren immer 5 ns Abstand. Bit-Banging
von einem C-Programm aus.
Und wie?
Weiter unten steht etwas von 200MHz bei der PRU.
Das würde bedeuten, daß Du in C schneller bist als die CPU, oder aber es einen Befehl gibt, der im Systemtakt den Pin togglet.
Raspberry Pi und Echtzeitfähigkeit hatte ich mal 2014 im Ramen einer Seminararbeit untersucht.
Damals™ auf einem Raspberry Pi B Rev.2
Verglichen habe ich das Raspbian und ein Raspbian mit Realtime-Preempt-Patch. Der Patch verändert das Scheduling.
Darüber hinaus hatte ich per WiringPi eine PWM ausgegeben und den Jitter aufgenommen. Das c-Programm hatte dafür eine erhöhte Priorität mit "piHiPri(95);" im Programmcode.
Im Ramen einer darauf aufbauenden Abschlussarbit hatte ich auch noch die Performance der WiringPi Bibliothek hinsichtlich SPI untersucht. Am Ende war WiringPi zu langsam (unnötig lange Pausen im SPI Protokoll) und ich hatte diese hier verwendet: https://www.airspayce.com/mikem/bcm2835/.
Es lohnt sich also mal nach Alternativen zu suchen, wenn es auf spezielle Anforderungen ankommt.
Im Ramen einer darauf aufbauenden Abschlussarbit hatte ich auch noch die
Performance der WiringPi Bibliothek hinsichtlich SPI untersucht. Am Ende
war WiringPi zu langsam (unnötig lange Pausen im SPI Protokoll)
ist auch mein Eindruck nach ein paar Tagen mit meinem neuen
RP5. Mit der PRU des BeagleBoneBlack konnte ich 2 Flanken erzeugen
mit 5 ns Abstand, und das waren immer 5 ns Abstand. Bit-Banging
von einem C-Programm aus.
Und wie?
Weiter unten steht etwas von 200MHz bei der PRU.
Das würde bedeuten, daß Du in C schneller bist als die CPU, oder aber es
einen Befehl gibt, der im Systemtakt den Pin togglet.
Eine Instruktion dauert 5 ns. Kein Cache etc. Zu etwa 2 Dutzend
I/O-Pins hat die PRU Direktzugang über ein Register.
Simple Zuweisungen, toggles oder reads gehen mit 1 Instruktion.
Eine PRU kommt aber auch an die anderen Resourcen des Systems.
Dann konkurriert sie eben über den Systembus mit dem ARM, den
DMA-Kanälen, refresh etc. Wenn man das Timing vorhersagbar haben
will, muss man sich da zurückhalten.
Programm- & Datenspeicher sind jeweils ein paar KB Dual port ram.
Der C-Compiler für die PRU ist inclusive im Linux des ARM.
RaspiRealTimePinToggle100us.png
(26 KB)
