Hallo Zusammen, ich bastel gerade ein bisschen mit einem Orange PI Zero herum und habe mich gefragt ob es dafür eingentlich auch die möglichkeit gibt Echtzeit-Anwendungen drauf laufen zu lassen? Ich benutze auf dem Orange PI Zero als OS aktuell armbian. Grüße Patrick
Moin, was bedeutet bei dir Echtzeit? Wie zeitnah muss etwas ausgeführt werden? Oftmals ist Echtzeit nicht notwendig. Mit Armbian wird das nichts. Lieber ein rtos nehmen.
Der OPi Zero verwendet einen Chip von Allwinner, damit wird es schwierig, ein RTOS daran laufen zu lassen. Zu den Chips gibt es nämlich nur sehr wenig Dokumentation. Das heißt, etwas echtzeitfähiges würde einen mit SPI o.ä. angeschlossen MC erfordern.
Ich wuerd meinen Echtzeit ist immer noetig. Nur : Echtzeit bedeutet innerhalb verlangter Zeit auf ein Ereignis antworten. Gilt auch fuer ein GUI mit einem komplexen OS. Wenn der Mousecursor oder die Tastatur eine Sekunde nachhaengt ist es nicht brauchbar. Normalerweise, in industriellen, physikalischen oder sonstwelchen Prozessen muss es schneller sein. Aber nicht beliebig schnell. Wie schnell ist durch das System bestimmt. Das kann zB eine Millisekunde sein.
>Nur : Echtzeit bedeutet innerhalb verlangter Zeit auf ein Ereignis >antworten. Das bedeutet es nicht. Es bedeutet genau zu einem bestimmten Zeitpunkt etwas zu tun und NICHT "irgendwann" von "jetzt" bis spätestens "dann". Sonst funktioniert kein Regelalgorithmus, weil die einem die Zeitbasis wegwandert. Echtzeit bedeutet eben nicht einfach "so schnell wie möglich"
> Gilt auch fuer ein GUI mit einem komplexen OS. Wenn der Mousecursor oder > die Tastatur eine Sekunde nachhaengt ist es nicht brauchbar. Das hab ich ja auch immer gedacht, aber trotzdem kauf die ganze Welt Microsoftprodukte. :) Olaf
Mr. Mephistopheles schrieb: > nicht. Es bedeutet genau zu einem bestimmten Zeitpunkt > etwas zu tun und NICHT "irgendwann" von "jetzt" bis spätestens "dann". falsch. Kein Computer kann nicht etwas exakt zu einer zeit machen. Es wird immer ein Zeitfester geben. Wiki: die bestimmte Ergebnisse zuverlässig innerhalb einer vorbestimmten Zeitspanne, zum Beispiel in einem festen Zeitraster, liefern können.
Olaf schrieb: > aber trotzdem kauf die ganze Welt > Microsoftprodukte. :) Die sind leiderprobt und nehmen es als Standard hin.
Sicher kann ein Computer etwas auch nicht zu einem bestimmten Zeitpunkt tun - selbst wenn nur ein Programm läuft und die Garbagecollection aktiv wrird. https://de.wikipedia.org/wiki/Echtzeit >die bestimmte Ergebnisse zuverlässig innerhalb einer vorbestimmten >Zeitspanne davor steht noch >>harakterisiert den Betrieb informationstechnischer Systeme, Das "informationstechnischer" klingt für mich nach Dingen wie z.B. Streaming und da reicht es, wenn der nächste Soundschnippsel beliebig schnell gezogen wird, solange er passend abgespielt wird. Weiter unten im Artikel steht das, was ich sagte: >Zur Beschreibung einer Steuerungs- und Regelungsaufgabe reicht es aber >nicht aus, eine Echtzeit über die Reaktionszeit zu definieren Da geht der Ball also zurück an den TE. Willst du was regeln oder geht es um Dinge, die sich eher in "Verfügbarkeit" (also maximale Reaktionszeit) verkaufen müssen?
Mr. Mephistopheles schrieb: > Das "informationstechnischer" klingt für mich nach Dingen wie z.B. > Streaming und da reicht es, wenn der nächste Soundschnippsel beliebig > schnell gezogen wird, solange er passend abgespielt wird. Die informationstechnische Echtzeit ist älter als Streaming. Es geht um Echtzeit bei Computer-Systemen. Ganz allgemein. Mr. Mephistopheles schrieb: > Weiter unten im Artikel steht das, was ich sagte: >>Zur Beschreibung einer Steuerungs- und Regelungsaufgabe reicht es aber >nicht >> aus, eine Echtzeit über die Reaktionszeit zu definieren Und? Hat ja auch keiner behauptet, dass das ausreicht. Wie groß die Zeitspanne ist, in der die Aufgabe erledigt werden muss, gibt die Aufgabe vor, nicht die Definition für "Echtzeit". Das kann auch deutlich mehr als Sekunden sein.
>>Nur : Echtzeit bedeutet innerhalb verlangter Zeit auf ein Ereignis >>antworten. > >Das bedeutet es nicht. Doch bedeutet es. Denn Regelungsaufgaben laufen equidistant, mit einem Timer. Und das ganze System muss eben so schnell wie der Timer sein. Sensoren, Aktoren, Rechner, zusammen muessen mitmoegen.
Ich möchte an dem Orange Pi Zero ein paar TLC5940 (12x) hängen und diese über das TPM2 Protokoll steuern. Der Orange Pi hängt dann über WLAN im Netzwerk. Ziehl ist damit einen LED-Tisch zu bauen. Ich hätte als Anforderung, dass vom Senden des Befehls über TPM2 bis er an dem entsprechenden TLC5940 ankommt nicht mehr als 200ms vergehen. Denkt ihr das ist realistisch? Außerdem wäre es schön wenn die Verzögerung immer ungefähr gleich wäre, damit es beim abspielen von Sequenzen nicht zu "rucklern" kommt.
Ja, das sollte machbar sein. Ist auch eine ziemlich "weiche" Echtzeit
Patrick L. schrieb: > mit einem Orange PI Zero herum und habe > mich gefragt ob es dafür eingentlich auch die möglichkeit gibt > Echtzeit-Anwendungen drauf laufen zu lassen? Ich benutze auf dem Orange > PI Zero als OS aktuell armbian. Grundsätzlich kann jeder Thread im Userland zu einem beliebigen Zeitpunkt und beliebig lange unterbrochen werden. Auf einem Mehrkernsystem kann man allerdings seine Chancen "verbessern" wenn man den Prozess auf einen gesonderten Kern (nicht den der die Interrupts bearbeitet) und mit Echtzeitpriorität laufen lässt. Patrick L. schrieb: > Ich hätte als Anforderung, dass vom Senden des Befehls über TPM2 bis er > an dem entsprechenden TLC5940 ankommt nicht mehr als 200ms vergehen. Also alle 200ms? Das könnte ohne Verrenkungen klappen. Ansonsten kann man grundsätzlich auch versuchen direkt auf die Peripherie zuzugreifen und eine DMA Loop bauen (das geht zumindest auf dem Raspberry).
Mikro 7. schrieb: > Grundsätzlich kann jeder Thread im Userland zu einem beliebigen > Zeitpunkt und beliebig lange unterbrochen werden. Ja, richtig. Deswegen hatte ich überlegt ob es da nicht irgendeine möglichkeit gibt das zu verhindern^^ Mikro 7. schrieb: > Also alle 200ms? Das könnte ohne Verrenkungen klappen. Ansonsten kann > man grundsätzlich auch versuchen direkt auf die Peripherie zuzugreifen > und eine DMA Loop bauen (das geht zumindest auf dem Raspberry). Ja, dann müsste ich vermutlich einen Kernel-Triber schreiben. Weil ja der direkt Zugriff auf die Periphere nicht möglich ist. Kann man des den bewerkstelligen das wenn es zu einer Verzögerung kommt diese zumindest immer gleich ist? Gibt es eig. eine SPI-Lib für den Orange Pi Zero?
Patrick L. schrieb: > Ja, richtig. Deswegen hatte ich überlegt ob es da nicht irgendeine > möglichkeit gibt das zu verhindern^^ Eine Zange ist nur selten das richtige Werkzeug, um einen Nagel reinzuschlagen. Aber ein bisschen geht es.
Patrick L. schrieb: > Ja, richtig. Deswegen hatte ich überlegt ob es da nicht irgendeine > möglichkeit gibt das zu verhindern^^ Echtzeitpriorität einstellen. Linux kann Echtzeit, wenn man dem Kernel das beigebracht hat. Allerdings nicht unbegrenzt hart (d.h. nicht bis an die Lastgrenze des Systems). Deine 200ms weicher Echtzeit (= "mal ein Ereignis verpasst") sollte das System auch so schaffen.
Sonst ev. in Richtung RealTime (RT) Kernel Erweiterungen schauen. z.B https://forum.armbian.com/topic/4130-rt-preempt-error-in-orange-pi-zero/ Scheint zwar noch Probleme zu geben, aber ev. sind die ja jetzt gefixt.
Ist dieses TPM2 Protokoll so Overheadbehaftet? Denn ganz ehrlich, ich krieg problemlos smoothe Lichtefekte über ein PWM Board, angeschlossen an einem Raspberry Pi (standard Raspian) per i2C und kontroliert über Java(!) hin! Wertänderung rund 60 mal pro Sekunde angestrebt. Hab bislang nur 4 Kanäle getestet (da die Lichtefekte EL Wire sind), aber die Prozessauslastung ist niedrig. Denke 200ms pro Befehl reicht locker, selbst wenn irgendein OS Thread zwischenschiessen sollte. Der Orange PI Zero hat genau für den Zweck ja eine Multicore CPU.
:
Bearbeitet durch User
Patrick L. schrieb: > Mikro 7. schrieb: >> Also alle 200ms? Das könnte ohne Verrenkungen klappen. Ansonsten kann >> man grundsätzlich auch versuchen direkt auf die Peripherie zuzugreifen >> und eine DMA Loop bauen (das geht zumindest auf dem Raspberry). > > Ja, dann müsste ich vermutlich einen Kernel-Triber schreiben. Weil ja > der direkt Zugriff auf die Periphere nicht möglich ist. Doch, über /dev/mem. (Edit: Wenn es ähnlich zum Rpi gelöst ist). Bei den angestrebten 200ms wird das aber wohl nicht notwendig sein.
:
Bearbeitet durch User
Alles klar. Dann probiere ich das erstmal ohne Echtzeit-Erweiterung aus.
Patrick L. schrieb: > Ja, dann müsste ich vermutlich einen Kernel-Triber schreiben. Weil ja > der direkt Zugriff auf die Periphere nicht möglich ist. Schaue dir mal das UIO-Subsystem (Userspace I/O) des Kernels an. Um das zu benutzen, trägst du in den Devicetree den Adressraum ein und kannst dann über /dev/uioX darauf zugreifen. Das ist wesentlich sauberer, als direkt mit /dev/mem zu arbeiten und es kann mit Interrupts umgehen. Allerdings kann ich mir nicht vorstellen, dass es für RPi-interne Hardware (wie die DMA-Engine) keinen Treiber gibt. Es gibt ein vollwertiges DMA-Subsystem im Kernel, das sollte man dafür auch benutzen können.
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.