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?
Der Raspi selbst ist echtzeitfähig, aber ich denke das Linux da drauf nicht!
>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ß
Gibt Linux Extensions damit kriegt man so ~1ms hin. Wenn dus besser brauchst, den RasPi kannst du auch in Assembler programmieren - ohne OS.
>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.
Alternative: Der beaglebone hat 2 realtime units die mit 200mhz getaktet sind und Zugriff auf eigentlich fast alles auf dem system haben.
Hi, habe vor kurzem an einem realtime preemptive kernel für den Raspberry gewerkelt. Das Ergebnis war ein raspian kernel, gepatcht mit realtime preemption patches von Ingo Molnar für die Wolfson Audio Card für Raspberry Pi http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi Die Quellen und der vorkompilierte Kernel 3.12 incl. Firmware kann hier heruntergeladen werden Blog Georg Mill https://blog.georgmill.de/
Das hier könnte auch was sein: http://sine.ni.com/nips/cds/view/p/lang/en/nid/211737 Da kann man die wirklich harten Echtzeianforderungen auf den FPGA per grafische Programmierung auslagern...
nimm doch einfach deinen altbewährten avr für deine anwendung und stelle die parameter über raspberry mittels uart ^^ easy as that
imonbln schrieb: > ob das wer für den PI bsi zu ende duch getestet hat weiss ich nicht Bei der OSADL kann man sich die Ergebnisse der Testläufe anschauen, z.B. diesen hier: https://www.osadl.org/Profile-of-system-in-rack-b-slot-3.qa-profile-rbs3.0.html In dem Graphen auf https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html kann man sehen, daß die maximale Latenz des Raspi in diesem Test bei 174 µs lag.
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
Steph schrieb: > 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 .. sorry, stimmt nicht, ist nicht realtime
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
Es gibt einen Port von FreeRTOS (http://www.freertos.org/) https://github.com/jameswalmsley/RaspberryPi-FreeRTOS der könnte aber auch schon im Mainline FreeRTOS drinn sein - musst mal schauen
Ü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. |
3 | funktion_die_gpio_ports_setzt(); // Funktion ausführen. |
4 | 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.
Performance der GPIO am Raspberry: https://docs.microsoft.com/de-de/windows/iot-core/develop-your-app/lightningperformance
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.