Raspi real time pin toggle

[Christoph M. (mchris)]

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?

// filename: fastPinToggle.c
//
// Test the real time capabilities of a Raspberry Pi
//
// Toogle an GPIO pin fast, use an oscilloscope to check the speed
//
// 2024-06-16 ch
//
// https://github.com/WiringPi/WiringPi
// gcc -o fastPinToggle fastPinToggle.c -l wiringPi 

#include <stdio.h>
#include <wiringPi.h>
#include <stdbool.h>
#include <stdint.h>

// LED Pin - wiringPi pin 0 is BCM_GPIO 17.

#define LED 0

#define DELAY_US 100

void togglePin()
{
  static bool flag=false;
  if(flag)digitalWrite (LED, HIGH) ;
  else digitalWrite (LED, LOW) ;
  flag=!flag;
}

void setup()
{
  printf ("fastPinToggle\n") ;
  wiringPiSetup ();
  pinMode (LED, OUTPUT) ;
}

uint32_t currentTime = 0;
uint32_t startTime = 1;

void loop()
{
  togglePin();
  do
  {
      currentTime = micros();
  } while ((uint32_t)(currentTime - startTime) <= DELAY_US);
  startTime = currentTime;
}

int main (void)
{
  setup();
  while(1) loop();
  return 0 ;
}

[Rainer W. (rawi)]

Christoph M. schrieb:
> 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.

[Sebastian W. (wangnick)]

Christoph M. schrieb:
> Gibt es eine Möglichkeit, den Rechteckgenerator auf einen eigenen Core
> auszulagern?

Was du suchst nennt sich process cpu affinity und wird über das Programm 
taskset und die Bibliotheksfunktion sched_setaffinity gesteuert.

LG, Sebastian

[Thomas W. (dbstw)]

Christoph M. schrieb:
> 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.

[Monk (roehrmond)]

Wobei die Aktivitäten eines Kerns durchaus den anderen ausbremsen 
können, weil sie sich jede Menge Hardwarekomponenten teilen.

[Christoph M. (mchris)]

>Das Zauberwort fuer die Suche ist "linux core affinity".

Danke für den Hinweis.
Hier habe ich ein Codebeispiel modifiziert:

// filename: coretest.c
//
// run a c-program on a specific core
//
// https://github.com/WiringPi/WiringPi
// gcc -o coretest coretest.c -l wiringPi 
#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    cpu_set_t cpuset;
    //int core_id = 1;  // Change this to the core you want to run on (0-indexed)
    int core_id = 0;  // Change this to the core you want to run on (0-indexed)
        
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);
    
    pid_t pid = getpid(); // Get the PID of the current process

    if (sched_setaffinity(pid, sizeof(cpu_set_t), &cpuset) == -1) {
        perror("sched_setaffinity");
        exit(EXIT_FAILURE);
    }

    // Your program logic here
    while (1) {
        printf("Running on core %d\n", core_id);
        sleep(1);
    }

    return 0;
}

Hier stellen sich mir zwei Fragen: Das Beispiel wird jetzt für Core0 
compiliert. Würde taskset das dann auf einen anderen Core verschieben?

>Wobei die Aktivitäten eines Kerns durchaus den anderen ausbremsen
>können, weil sie sich jede Menge Hardwarekomponenten teilen.

Würde das auch gelten, wenn das Programm einen bestimmten GPIO 
verwendet? Andere Programme verwenden dan ja dann ganz sicher nicht.

[Dergute W. (derguteweka)]

Moin,

Christoph M. schrieb:
> Hier stellen sich mir zwei Fragen:

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...?

Gruss
WK

[Mikro 7. (mikro77)]

Christoph M. schrieb:
> 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).

Habe ich selbst nie gemacht. Erster gefundener Link dazu wäre das hier:
https://forums.raspberrypi.com/viewtopic.php?t=228727

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).

[Frank K. (fchk)]

Christoph M. schrieb:

> 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?

Nein. Falsche Hardware. Schau Dir das hier an:

https://www.beagleboard.org/boards/beaglebone-ai-64

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.

fchk

[Klaus S. (kseege)]

Christoph M. schrieb:
> 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.

Gruß Klaus (der soundsovielte)

[Christoph M. (mchris)]

>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.

[Klaus (feelfree)]

Christoph M. schrieb:
> Es wäre super, wenn man den Core
> für Linux sperren könnte

Doch das geht schon.
Random Link, nicht im Detail verifiziert: 
http://telmomoya.blogspot.com/2016/10/asymmetric-multi-processing-amp-with.html

[Christoph M. (mchris)]

Bevor es weiter geht: Ich habe mal das delay aus dem ersten Post raus 
genommen, um zu sehen wie schnell der WiringPi den Pin toogeln kann.

void loop()
{
  togglePin();
/*  do
  {
      currentTime = micros();
  } while ((uint32_t)(currentTime - startTime) <= DELAY_US);
  startTime = currentTime;
  */
}

Ergebnis ~3.6MHz

[Christoph M. (mchris)]

>Random Link, nicht im Detail verifiziert:
>http://telmomoya.blogspot.com/2016/10/asymmetric-multi-processing-amp-with.html

Der Link erwähnt "Open Amp", der weiterführende Link ist aber tot.

[Klaus (feelfree)]

Christoph M. schrieb:
> Der Link erwähnt "Open Amp", der weiterführende Link ist aber tot.

Ich google das gerne für dich: https://www.openampproject.org/

[Christoph M. (mchris)]

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..

https://github.com/hzeller/rpi-gpio-dma-demo/tree/master

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.

[Christoph M. (mchris)]

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

Beschreibung hier:
https://forums.raspberrypi.com/viewtopic.php?t=228727

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.

[Dergute W. (derguteweka)]

Moin,

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...

scnr,
WK

[Christoph M. (mchris)]

>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.

[Christoph db1uq K. (christoph_kessler)]

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"

   1      +------------+             +------------+
          |    GPIO    |             |    GPIO    |
          |<--- on --->|             |<--- on --->|
          |    time    |             |    time    |
   0 -----+            +-------------+            +---------
        on^         off^           on^         off^
     +--------------------------+--------------------------+
     ^                          ^                          ^
     |<------ cycle time ------>|<------ cycle time ------>|
   cycle                      cycle                      cycle
   start                      start                      start

Da übernimmt wohl der PWM-Timer das genaue Timing.

[Rahul D. (rahul)]

Christoph M. schrieb:
> Ich vermute, das 20ms garantiert sind.

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.

Es gibt Linux-Derivate, die echtzeitfähig sind.

[Christoph M. (mchris)]

>Deine Beispiele sind etwas an den Haaren herbeigezogen:

Wieso? Haben die Videospiele Aussetzer?

[Klaus (feelfree)]

Christoph M. schrieb:
>>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.

[Ein T. (ein_typ)]

Christoph M. schrieb:
> Klaus S. schrieb:
>> 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".

PS: Quoting korrigiert.

[Christoph M. (mchris)]

>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.

Deshalb habe ich ja in meinem Beispiel
Beitrag "Re: Raspi real time pin toggle"
den 3.ten Core des RPI 3B+ aus der Linux Verwaltung heraus genommen.

[Frank K. (fchk)]

Christoph M. schrieb:

> 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.

fchk

[Christoph M. (mchris)]

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

Eine sehr schöne Library. Danke :-)

[Christoph M. (mchris)]

Frank K. (fchk)
17.06.2024 09:19
>Linux kann nur weiche Echtzeit.

Gilt das auch für die Herausnahme des Cores aus der Linux-Verwaltung in 
meinem Beispiel oben?

[Frank K. (fchk)]

Christoph M. schrieb:
> Frank K. (fchk)
> 17.06.2024 09:19
>>Linux kann nur weiche Echtzeit.
>
> Gilt das auch für die Herausnahme des Cores aus der Linux-Verwaltung in
> meinem Beispiel oben?

Ja. Überlege mal, was mit den Interrupts pasiert. Zumindest bei den 
älteren Pis sind die immer auf Kern 1 aufgeschlagen.

fchk

[Christoph M. (mchris)]

>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?

[Jens B. (dasjens)]

Christoph M. schrieb:
> Frank K. (fchk)
> 17.06.2024 09:19
>>Linux kann nur weiche Echtzeit.
>
> 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.

[Frank K. (fchk)]

Christoph M. schrieb:
>>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".

fchk

[Christoph M. (mchris)]

>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.

[Klaus (feelfree)]

Christoph M. schrieb:
> Vermutlich hast du den Thread nicht gelesen.

Oder du die Probleme bei der Auswahl des gewählten SoC nicht verstanden.

[Martin H. (horo)]

Jens B. schrieb:
> 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.

[Jens B. (dasjens)]

Martin H. schrieb:
> Jens B. schrieb:
>> 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.

Christoph M. schrieb:
>>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.

[Christoph M. (mchris)]

Jens B. (dasjens)
>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.

[Martin H. (horo)]

Christoph M. schrieb:
> 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.

[Frank K. (fchk)]

Martin H. schrieb:

> Immer? Das bedeutet, es dauert niemals länger als eine Millisekunde?
> Unter keinen Umständen? Kannst Du das verifizieren?

Mein Reden. Das ist so wie bei Loriot und dem weichen Ei.

https://www.youtube.com/watch?v=90-3Vv5OMsY

Er wird sich erst dann vernünftig verhalten, wenn alle anderen 
Möglichkeiten ausgeschöpft sind.

fchk

[Axel S. (a-za-z0-9)]

Martin H. schrieb:
>
> 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."

[Christoph M. (mchris)]

Martin H. (horo)
17.06.2024 13:23
>Immer?
Ein kleiner Hinweis: nichts ist für immer. Auch nicht bei einem 
Echtzeitbetriebssystem. Es ist alles eine Frage der Wahrscheinlichkeit.

[J. S. (jojos)]

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?

[Foobar (asdfasd)]

jojos schrieb:
> 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.

[Jens B. (dasjens)]

Christoph M. schrieb:
> Martin H. (horo)
> 17.06.2024 13:23
>>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.

Christoph M. schrieb:

> 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.

[Christoph M. (mchris)]

Christoph M. schrieb:
>> 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.

Es gibt aber auch Ansätze, Raspian mit Echtzeierweiterungen zu versehen.
Die Firma Kunbus fertigt SPS-Steuerungen auf Basis des Raspberry Pi:
https://www.directindustry.de/prod/kunbus-gmbh/product-103365-2387814.html

[Klaus (feelfree)]

Christoph M. schrieb:
> 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.

[Christoph M. (mchris)]

Es gibt schon seit längerem Realtime-Patches für den Raspberry-Pi:

https://www.get-edi.io/Real-Time-Linux-on-the-Raspberry-Pi/

Es basiert wohl auf "PREEMPT_RT"
https://wiki.linuxfoundation.org/realtime/start

Hat das schon mal jemand ausprobiert?

[Rainer W. (rawi)]

Christoph M. schrieb:
> Im Grunde genommen ist Linux ein "Echtzeitbetriebssystem",

Der Begriff "Echtzeit" macht ohne Angabe von garantierten 
Redaktionszeiten keinen Sinn.

[Klaus (feelfree)]

Rainer W. schrieb:
> 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."

[Schwierig (ruelps)]

...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.

[Klaus (feelfree)]

Schwierig schrieb:
> 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.

[Klaus (feelfree)]

Schwierig schrieb:
> Garantierte Reaktionszeit von einer Minute sollte mit Hardwaretimern und
> Interrupts ja realisierbar sein.

Ist es aber nicht. Wenn Windows was auf Platte schreiben will und die 
SSD grad wie wild am Platz schaffen ist, steht die Kiste halt.

[Jens B. (dasjens)]

Christoph M. schrieb:
> Christoph M. schrieb:
>>> 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.

Das hat auch nichts mit Echtzeit zu tun.

> Die Firma Kunbus fertigt SPS-Steuerungen auf Basis des Raspberry Pi:
> https://www.directindustry.de/prod/kunbus-gmbh/product-103365-2387814.html

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.

[Jens B. (dasjens)]

Klaus schrieb:
> Schwierig schrieb:
>> Garantierte Reaktionszeit von einer Minute sollte mit Hardwaretimern und
>> Interrupts ja realisierbar sein.
>
> Ist es aber nicht. Wenn Windows was auf Platte schreiben will und die
> SSD grad wie wild am Platz schaffen ist, steht die Kiste halt.

Deshalb läuft Windows bei Echtzeiterweiterungen im idle task. Win hat da 
nix mehr zu melden.

[Jens B. (dasjens)]

Schwierig schrieb:
> ...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?

[Ein T. (ein_typ)]

Frank K. schrieb:
> Linux kann nur weiche Echtzeit.

Deswegen gibt es ja...

> 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:

https://lwn.net/Articles/816298/

https://stackoverflow.com/questions/76460740/how-to-get-rid-of-interrupts-on-isolated-cores-caused-by-simple-go-app-during

https://www.linutronix.de/blog/A-Checklist-for-Real-Time-Applications-in-Linux

https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/isolating_cpus_using_tuned-profiles-realtime

[Christoph M. (mchris)]

>> 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

Beitrag "Re: Raspi real time pin toggle"

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.

[Ein T. (ein_typ)]

Christoph M. schrieb:
> So ist es. Allerdings habe ich das schon relativ früh im Thread als
> ziemlich einfaches Demo implementiert
>
> Beitrag "Re: Raspi real time pin toggle"
>
> 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.

[Gerhard H. (ghf)]

Frank K. schrieb:

> 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.

Gruß, Gerhard

[Frank K. (fchk)]

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.

fchk

[Jens B. (dasjens)]

Gerhard H. schrieb:

> 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.

[Christoph M. (mchris)]

Frank K. (fchk)
>Das hast Du gut gemacht.

Danke :-)

>> 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.

https://docs.ros.org/en/foxy/How-To-Guides/Installing-on-Raspberry-Pi.html

Ich vermute, dass die Frage, ob ein Raspi für ROS2 Echtzeitaufgaben 
verwendet werden kann, von einigen Leuten mit "ja" beantwortet wird.

edit: typo

[Jens B. (dasjens)]

Christoph M. schrieb:
> 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.

[Gerhard H. (ghf)]

Christoph M. schrieb:

> 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

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.

[Christoph M. (mchris)]

Gerhard H. (ghf)
>Die PRUs beim BBB SIND 200 MHz-Mikrocontroller ohne Betriebsystem
>und ohne Interrupts.

Das klingt ein wenig "Propeller-artig". Bei dem sind es aber 8 
gleichwertige Cores.

[Marko ⚠. (mos6502)]

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:

https://github.com/pi1541/Pi1541

https://github.com/captain-amygdala/pistorm

https://github.com/dwhinham/mt32-pi

[Christoph M. (mchris)]

Das könnte eine gute Idee sein, den Raspberry Pi ohne Linux zu nutzen.
Vor einiger Zeit hatte ich mal "Circle" ausprobiert

https://github.com/rsta2/circle

was erstaunlich problemlos zu nutzen war.

>https://github.com/dwhinham/mt32-pi

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.

[Jens B. (dasjens)]

Gerhard H. schrieb:
>
> 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.

[Sebastian E. (s-engel)]

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.

Getestet hatte ich mit "cyclictest". Das ist ein Testprogramm, welches 
ursprünglich für Test des RT-Preempt-Patches entwicklet wurde.
https://manpages.ubuntu.com/manpages/trusty/man8/cyclictest.8.html

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.

[Mikro 7. (mikro77)]

Sebastian E. schrieb:
> 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)

Meinst du das hier:
https://forums.raspberrypi.com/viewtopic.php?t=181154

Das liegt an der fehlenden Dokumentation im data sheet.

[Gerhard H. (ghf)]

Jens B. schrieb:
> Gerhard H. schrieb:
>>
>> 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.