Hallo zusammen.
Ich habe bereits einige kleine Projekt mit AVR-Controllern gemacht.
Da ich nun auch im Besitz eines Raspberry Pi (Model B) bin, möchte ich
damit hochpriorisierte Prozesse ausführen, um beispielsweise Spindeln
einer Drehbank (CNC) mittels Schrittmotoren zu steuern.
Da ich in Linux bisher nur den Befehl "nice" kenne, um Prozesse zu
priorisieren, habe ich nun eine gewaltige Lücke in meiner Vorstellung:
- in wie weit ist "nice" "echtzeitfähig"?
- wann brauche ich ein Echtzeit-OS (RTOS)?
Stelle ich es mir zu leicht vor, den Raspberry dazuzubringen, ein
Rechtecksignal mit z.B. 100 Hz über die GPIOs an eine Treiberstufe für
die Schrittmotoren zu schicken?
Vielen Dank euch!
Raspler schrieb:> - wann brauche ich ein Echtzeit-OS (RTOS)?
Kennst du überhaupt den Unterschied zwischen einem, Realtime-OS und
einem non Realtime-OS?
>Kennst du überhaupt den Unterschied zwischen einem, Realtime-OS und>einem non Realtime-OS?
...dass man ein vorhersehbares Zeitverhalten vom System erhält.
Vielleicht sollte ich die Frage umformulieren:
Wann brauche ich in der Praxis ein RTOS?
Würde eine normale Linux-Distri für meine Zwecke mit entsprechender
Prozess-Priorisierung ebenfalls den beschriebenen Zweck erfüllen?
Gruß
>ohne OS.
Gibt es denn nix fertiges? :-)
Schließlich sind doch die meisten ziemlich "steuerungsgeil".
Schließlich hat man auch schon Heizungssteuerungen etc. mit dem
Raspberry realisiert.
Aber dafür scheint es noch keine RTOS-Distri zugeben, die man mal eben
auf die SD-Karte imaged.
es gibt die PREEMPT_RT Patches für den Linux Kernel bei den wird
versucht
Linux "echtzeitfähig" zu bekommen.
https://rt.wiki.kernel.org/index.php/Main_Page
ob das wer für den PI bsi zu ende duch getestet hat weiss ich nicht
aber,
wenn du nicht bare Metall auf den PI arbeiten willst könnte das ggf. was
sein.
Raspler schrieb:> Stelle ich es mir zu leicht vor, den Raspberry dazuzubringen, ein> Rechtecksignal mit z.B. 100 Hz über die GPIOs an eine Treiberstufe für> die Schrittmotoren zu schicken?
Folgender Link könnte für dich interessant sein, allerdings geht es da
um RC-PWM und GPIOs
https://github.com/richardghirst/PiBits/tree/master/ServoBlaster
Probier es mal mit
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=56&t=49373
Das ist ein Port von Xenomai für den Raspberry Pi. Bei Linux-basierten
Realtime-Lösungen sollte man allerdings grundsätzliche keine allzu hohe
Erwartungshaltung haben. Zu oft machen nicht echtzeitfähige Treiber u.ä.
einiges kaputt.
Hi,
Raspler schrieb:> Würde eine normale Linux-Distri für meine Zwecke mit entsprechender> Prozess-Priorisierung ebenfalls den beschriebenen Zweck erfüllen?
Mit einem ungepatchten Linux wirst Du keine harte Echtzeit hinbekommen.
Aber es gibt Patchsets dafür, etwa RTLinux/GPL und RTAI.
Ein anderer Trick könnte sein, an den RasPi einen uC anzuflanschen, der
sich dann um den Echtzeitkram kümmert.
HTH,
Karl
> Ein anderer Trick könnte sein, an den RasPi einen uC anzuflanschen, der> sich dann um den Echtzeitkram kümmert.
... oder gleich ein BeagleBone Black nehmen. Der hat zwei zusätzliche
(abgespeckte) CPUs (PRU oder PRUSS genannt), die für
Echtzeitanforderungen wie geschaffen sind. Hier mal ein Link zum
Einstieg:
https://github.com/modmaker/BeBoPr/wiki/BeBoPr-for-CNC
Es gibt aber auch ein paar andere Beispiele:
http://hipstercircuits.com/
Exaktes Timing über Pru:
http://www.youtube.com/watch?v=YlDHBbKrRtU
Karl Käfer schrieb:> Mit einem ungepatchten Linux wirst Du keine harte Echtzeit hinbekommen.> Aber es gibt Patchsets dafür, etwa RTLinux/GPL und RTAI.
Und PREEMT-RT. Siehe
https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html
Bei Xenomai ist die Treibersituation etwas schwierig, da man für alle
Hardware, auf die man aus dem Realtime-Mode heraus zugreifen will, einen
extra Xenomai-Treiber braucht und es nur wenig Hardware gibt, für die
ein solcher existiert.
Hab mal irgendwo gelesen, dass sich RiscOS für Echtzeit mit dem
raspberry pi eignet. Weil es kooperatives Multitasking macht, kann sich
ein Userspace-Programm alle Rechenzeit nehmen.
Raspler schrieb:> Stelle ich es mir zu leicht vor, den Raspberry dazuzubringen, ein> Rechtecksignal mit z.B. 100 Hz über die GPIOs an eine Treiberstufe für> die Schrittmotoren zu schicken?
Schau mal hier, dass könnte vielleicht eine Alternative zum Raspi sein:
http://www.adwin.de/de/produkte/goldII.html
Ist zwar nicht ganz billig, aber ein gut durchdachtes Echtzeitsystem -
vorallem - relativ ausfallsicher und zuverlässig.
hexe schrieb:> Da kann man die wirklich harten Echtzeianforderungen auf den FPGA per> grafische Programmierung auslagern...
bist Du Dir sicher, dass der Raspi auch einen FGPA verbaut hat?
>Bei Linux-basierten>Realtime-Lösungen sollte man allerdings grundsätzliche keine allzu hohe>Erwartungshaltung haben.
würde mal sagen, bei Linux (wie ähnl Windows) gibt es kein wirkliches
Realtime.
Für ein Echtzeitsystem (Schrittmotoren) funktioniert der Tick Interrupt
mit
max 1Mhz Frequenz recht gut, die Rampensteuerung, Planung usw muss aber
im
User Code gemacht werden, und es braucht eine relativ lange Fifo damit
es
reibungslos funktioniert.
MCUA schrieb:> würde mal sagen, bei Linux (wie ähnl Windows) gibt es kein wirkliches> Realtime.
Sagst du das aus Erfahrung oder einfach nur so, weil du denkst, das
müsse so sein?
Raspier schrieb:> bist Du Dir sicher, dass der Raspi auch einen FGPA verbaut hat?
Bist du dir denn sicher, dass das da wirklich ein Raspi ist?
hexe schrieb:> http://sine.ni.com/nips/cds/view/p/lang/en/nid/211737
MCUA schrieb:>>Bei Linux-basierten>>Realtime-Lösungen sollte man allerdings grundsätzliche keine allzu hohe>>Erwartungshaltung haben.> würde mal sagen, bei Linux (wie ähnl Windows) gibt es kein wirkliches> Realtime.
in der "standardausführung" meines wissens nicht, da die scheduler nicht
für "hartes" RT ausgelegt sind.
z.b. bei RTLinux (zumindest die Version mit der ich vor ein paar jahren
an der uni mal zu tun hatte) wird das system mit einem gepatchten kernel
gestartet. wenn man dann den rt-modus gestartet hat und z.b. der
rt-thread zu schnell hintereinander aufgerufen wurde oder irgendwo ein
"strategisch ungünstiger" fehler lag, dann konnte man das system nur
mehr über die stromversorgung (oder den ein-/ausschalter sofern
vorhanden) "herunterfahren", da der rt-scheduler das "normale" system
nicht mehr bedient hat
Hallo,
folgende Distribution bringt bereits einen realtime kernel mit:
http://mubox.voyage.hk/rpi
root@voyage-mubox:~# uname -a
Linux voyage-mubox 4.1.12-v7+ #824 SMP PREEMPT Wed Oct 28 16:46:35 GMT
2015 armv7l GNU/Linux
Gruss
Steph
so, aber das hier ist RT:
http://docs.emlid.com/Downloads/Real-time-Linux-RPi2/
root@navio-rpi:~# uname -a
Linux navio-rpi 3.18.9-rt5-v7+ #1 SMP PREEMPT RT Thu Mar 26 10:31:34 UTC
2015 armv7l GNU/Linux
Gruss
Stepha
Über eine Suche bin ich auf diese Seite gestoßen und fand die Hinweise
zu Linux etwas unbefriedigend. Daher habe ich heute das Thema weiter
recherchiert und möchte hier meine bisherigen Erkenntnisse
zusammenfassen.
Die Frage, ob ein System echtzeitfähig ist, kann nicht mit ja oder nein
beantwortet werden. Um das zu verstehen ist es wichtig zu wissen, was
Echtzeitfähigkeit bedeutet. Typischerweise meint man mit
Echtzeitfähigkeit genau das, was der TO eingangs geschrieben hat. Er
wollte eine Funktion mit 100 Hz also einer vorgegebenen Frequenz
ausführen. Die Echtzeitfähigkeit wird also nicht mit ja oder nein
sondern über die Frequenz qualifiziert, mit der man etwas ausführen
will.
Der Linux-Kernel wie quasi jedes Multitasking-System hat einen sog.
Scheduler, der darüber bestimmt, welcher Prozess zu welchem Zeitpunkt
und für wie lange ausgeführt wird. Die zur Verfügung stehende Rechenzeit
wird in Zeitscheiben eingeteilt und jeder Prozess erhält einen gerechten
Anteil. Wenn wenig zu tun ist, ist jeder Prozess schnell dran, wird also
mit einer hohen Frequenz ausgeführt. Wenn viel zu tun ist, ist jeder
Prozess nur selten dran, wird also mit einer langsamen Frequenz
ausgeführt.
Wenn man etwas mit einer konstanten Frequenz ausführen will, kann also
nicht gleichzeitig gerecht bei der Vergabe der Zeitscheiben sein. Man
muss ungerecht sein, und dem Prozess, der mit einer konstanten Frequenz
laufen will, im Falle einer hohen Last mehr Rechenleistung einräumen.
Und das geht auch mit Linux indem man den normalen gerechten
Scheduler-Algorithmus durch einen ungerechten ersetzt. Das geht mit der
Funktion
1
sched_setscheduler(0,SCHED_FIFO,params)
Der Fifo-Scheduler ist ein ungerechte Scheduler, der es ermöglicht, dass
ein Prozess bei Bedarf mehr Rechenzeit bekommt als andere Prozesse.
Um also eine Funktion garantiert mit 100 Hz ausführen zu können, muss
man sich mit
1
clock_getres(CLOCK_MONOTONIC_RAW,res)
die maximale Auflösung der System-Uhr holen.
Linux hat diverse Uhren, die laufen entweder streng monoton, nur monoton
oder nicht monoton. Das bedeutet, die Zeit kann bei einer Zeitumstellung
ggf. rückwärts laufen oder sie kann gedehnt oder gestaucht werden. Wenn
man nur an einer Frequenz aber nicht an der tatsächlichen Uhrzeit
interessiert ist, ist CLOCK_MONOTONIC_RAW die beste Wahl.
Nichts desto trotz benötigt man die Uhrzeit, da man nicht vorher sagen
kann, wie viel Zeit die Funktion, die man mit 100 Hz ausführen will,
selber benötigt. Deswegen sieht der Timer-Algorithmus typischerweise so
aus:
1
for(;;){
2
clock_gettime(CLOCK_MONOTONIC_RAW,t0);// Zeit t0 vor Ausführung holen.
clock_gettime(CLOCK_MONOTONIC_RAW,t1);// Zeit t1 nach Ausführung holen.
5
nanosleep(1/frequenz-(t1-t0));// Intervall-Zeit abzüglich der bereits verbrauchten Zeit warten.
6
}
Der Aufruf von nanosleep ist nur Pseudo-Code, da t0 und t1 structs sind.
1/frequenz ist die maximale Länge des Zeit-Intervalls, das durch die
Ausführungsfrequenz vorgegeben ist und (t1 - t0) ist die Zeit, die die
auszuführende Funktion benötigt hat.
Ich denke es ist selbsterklärend, dass man in der Funktion, die mit 100
Hz ausgeführt wird, nicht auf die Idee kommen darf, irgendwelche
HTTP-Requests abzusetzen oder sonst irgendeinen Kram zu machen, der
länger dauert als die vorgegebene Frequenz zulässt.
Ich habe es nicht ausprobiert aber ich vermute, dass eine Frequenz von
100 Hz zum Schreiben von ein paar IO-Ports für einen Prozessor, der mit
700 MHz getaktet ist, durchaus machbar sein sollte. Und das bedeutet,
dass unter den vom TO geschilderten Anforderungen der Linux-Kernel für
seine Belange voll echtzeitfähig wäre. Schwierig wird es erst, wenn die
Frequenz weiter gesteigert werden soll. Wo genau die Grenze ist und ob
man sie durch übertakten der CPU noch etwas nach oben schieben kann,
müsste man im Detail mal ausprobieren.
S. Z. schrieb:> Deswegen sieht der Timer-Algorithmus typischerweise so> aus:
gibt es keine passende Timer direkt in der Hardware? Bei deinen Beispiel
wird nur sinnlos rechenzeit verbraten. Ein RPi hat auch PWM einheiten,
würde mich wundern wenn er keine Timer hat die einen Interrupt auslösen
können. Damit sollte eine etwas sauber Lösung möglich sein. Dafür müsste
man sich mal mit dem Datenblatt beschäftigen.
