Beaglebone Black: Status

[HaWe]

Da hab ich gesehen, das einige damit RT Aufgaben auf der PRU machen und den großen Non-RT Krams auf Linux. Da gibt es wohl einen Memory Bridge für den Datenaustausch. Da gibt es auch Tutorials dafür. Auf dem BBB läuft auch ein Preempt RT Kernel. Damit ist dann auch der Linux Part RT tauglich.
Das gefällt mir an dem Board!

es lassen sich auch auf dem Pi RT OS verwenden,
darüberhinaus kann man aber auch auf dem Standard-Raspbian einzelnen threads (pthread oder std::threads, alle preemptiv) höhrere prios zuweisen als die kernel-threads besitzen (z.B. SCHED_RR, prio=80),
und man kann sogar optional bei Pi 2,3,4 (quadcores) per compiler-flags so compilieren, dass das eigene Programm für bestimmte cpu-cores den Zugriff exklusiv erhält, unter Ausschluss des kernels.
Damit hat man auf dem Pi alle RT Fähigkeiten, die man braucht, und der Preis ist ja auch ok (neu oder gebraucht)

[Ceos]

hat da nicht vor kurzem ein Patch die Runde gemacht der so ziemlich jedem Linux ein PreEmpRT ermöglichen soll? Irgendwo auf Heise oder Golem war mir das untergekommen meine ich.

PS: Ich präferiere hier definitv das python wegen der startzeit, der konsole für live tests bzw. debugging und der zahlreichen python scripts im netz für alleerdenklichen bauteile und funktionen

und natürlichn unschlagbar für rapid prototyping ohne compilieren und flashen

[schorsch_76]

hat da nicht vor kurzem ein Patch die Runde gemacht der so ziemlich jedem Linux ein PreEmpRT ermöglichen soll? Irgendwo auf Heise oder Golem war mir das untergekommen meine ich.

PS: Ich präferiere hier definitv das python wegen der startzeit, der konsole für live tests bzw. debugging und der zahlreichen python scripts im netz für alleerdenklichen bauteile und funktionen

und natürlichn unschlagbar für rapid prototyping ohne compilieren und flashen

Meines Wissens nach, ist ein großer Teil des PREEMPT_RT Patches mittlerweile Mainline, aber noch nicht alles. [1]

Die PRU's sind eben wie Microkontroller in der CPU. Hier läuft nichts anderes nur das kleine Miniprogramm. Dadurch kann man (bei entsprechner Programmierung) Latenzen garantieren. Auch unter Linux mit PREEMPT_RT sind die Latenzen nicht so exakt einzuhalten wie auf einer MCU. Beispielsweise QNX oder VxWorks [2][3] sind von Haus aus auf das RT Verhalten ausgelegt (Mikrokernel Architektur). Linux ist hier ganz anderst aufgebaut. Es ist ein Monolith. [4]

Mit Xenomai oder RTAI wird unter "das normale OS" ein Microkernel gepackt der dann die harte Echtzeit garantiert. Un ja, es gibt zwischen PREEMPT_RT und Xenomai/RTAI noch sehr große Unterschiede was das Echtzeitverhalten angeht (auch wenn PREEMPT_RT schon sehr gut ist). [5]


[1] https://www.heise.de/ct/artikel/Die-...g-4470638.html

[2] https://de.wikipedia.org/wiki/QNX
[3] https://de.wikipedia.org/wiki/VxWorks

[4] https://de.wikipedia.org/wiki/Linux

[5] https://www.embedded-software-engine...inux-a-632464/

[HaWe]

ich bin und war eigentlich immer der Meinung, dass pthread eine ANSI C99 Standard-Lib ist, die in jeder Linux- und GCC distri enthalten ist, und es ist grundsätzlich preemptiv.
Nutze ich ständig, sowohl auf Raspberry Pi (Debian) als auch sogar schon seit ca. 10 Jahren auf Lego EV3 (hat eine TI Linux distri).

#include <pthread.h>
compilieren mit GCC flag -lpthread

und fertig!

es ist für gängige Anwendungen absolut RT-fähig (GPIO r/w sicher innerhalb 400ns auf einem alten Pi 2, parallel zu WiFi, geöffnetem Firefox, full-HD HDMI TFT, Soundwiedergabe und wireless BT für Maus und Kbd.)

[schorsch_76]

pthread ist eine Standard Library. Sie garantiert aber kein Echtzeitverhalten.

https://elinux.org/Realtime_Testing_Best_Practices

https://ocw.cs.pub.ro/courses/_media...it_curs_07.pdf

Harte Echtzeit bedeutet: Es ist in JEDEM Fall garantiert, das die Deadline eingehalten wird. Bsp. Steuerung von Raketen, Steuerung von Flugzeugen, Sicherheitskritische Abschaltungen von denen Menschenleben abhängen. Würdest du wirklich garantieren, dass dein pthread unter allen Umständen, in die dein System kommen kann, immer und jederzeit rechtzeitig reagiert? DDOS auf den Netzwerk Port? Ein Amok laufendes Skript?

[HaWe]

ich schrieb "gängige Anwendungen", ich programmiere mobile Robots, die sich mit bis zu 10km/h bewegen, aber keine Raketen.
Für mobile Robots reicht es dicke,
aber Raketen oder wenn Menschenleben davon abhängen, dann würde ich auf multicores einsetzen und den kernel auf einzelne Cores einschränken, dann läuft das eigene Programm vom kernel unbeeinflusst. Plus ein 2. oder 3. redundantes System (für bemannte Marsmissionen ).
Und ja, dann würde ich das auch dafür garantieren.


PS
ich würde dafür aber NIE eine single-core cpu einsetzen.

[Ceos]

ich glaaube wir schweifen ab ^^
eigentlich gings doch um den beaglebone

PS single core ist wunderschön deterministisch und threads streng genommen luxus den man sich durch interlligente statemachines sparen kann, aber da trennt sich eben library basiertes programmieren von echtem bare metal. Mehr kontrolle erfordert auch mehr management, einfach nur eine kosten/nutzen frage und des persönlichen gemacks und darüber lässt sich bekanntlich nicht freundlich streiten