1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Windows on Devices…

real time aufgaben?

  1. Thema

Neues Thema Ansicht wechseln


  1. real time aufgaben?

    Autor: Pwnie2012 27.08.14 - 12:20

    Das ist schon das Problem vom raspi. Gbts für sowas nicht irgend wo nen dedizierten chip!

  2. Re: real time aufgaben?

    Autor: am (golem.de) 27.08.14 - 12:26

    FPGA-Shield:
    [www.kickstarter.com]

    Grüße,
    Alexander Merz (golem.de)



    1 mal bearbeitet, zuletzt am 27.08.14 12:26 durch am (golem.de).

  3. Re: real time aufgaben?

    Autor: 486dx4-160 27.08.14 - 12:56

    Echtzeitfähigkeit ist eine Fähigkeit des Betriebssystems, keine des SOCs.
    Wenn du statt des normalen Linux-Kernels RTLinux nimmst müssts gehen. Ob QNX auch auf dem Raspi läuft weiß ich nicht.

  4. Re: real time aufgaben?

    Autor: \pub\bash0r 27.08.14 - 13:13

    Oder, so verrückt das vielleicht klingt, FreeDOS. Das ist ja tatsächlich einer der wenigen Vorteile dieses Uralt-Systems. Da es von Haus aus kein Multitasking unterstützt, hat ein Prozess (fast) 100% der Ressourcen exklusiv.

  5. Re: real time aufgaben?

    Autor: schuhumi 27.08.14 - 13:17

    Üblicherweise pollt man auch nicht um ein Signal abzuwarten (verschwendung vom CPU Zeit), sondern man richtet einen Interrupt ein, der anspringt wenn sich der Pegel an diesem Pin ändert.

  6. Re: real time aufgaben?

    Autor: kazhar 27.08.14 - 13:25

    schuhumi schrieb:
    --------------------------------------------------------------------------------
    > Üblicherweise pollt man auch nicht um ein Signal abzuwarten (verschwendung
    > vom CPU Zeit), sondern man richtet einen Interrupt ein, der anspringt wenn
    > sich der Pegel an diesem Pin ändert.

    Gratulation, du hast gerade eines der Dinge gefunden, die Echtzeitfähigkeit verhindern: Interrupts :D

  7. Re: real time aufgaben?

    Autor: h1j4ck3r 27.08.14 - 13:55

    kazhar schrieb:
    --------------------------------------------------------------------------------
    > schuhumi schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Üblicherweise pollt man auch nicht um ein Signal abzuwarten
    > (verschwendung
    > > vom CPU Zeit), sondern man richtet einen Interrupt ein, der anspringt
    > wenn
    > > sich der Pegel an diesem Pin ändert.
    >
    > Gratulation, du hast gerade eines der Dinge gefunden, die Echtzeitfähigkeit
    > verhindern: Interrupts :D

    und wie nennst du die unterbrechung von jobs durch höherpriore jobs?

  8. Re: real time aufgaben?

    Autor: schuhumi 27.08.14 - 14:11

    kazhar schrieb:
    --------------------------------------------------------------------------------
    > schuhumi schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Üblicherweise pollt man auch nicht um ein Signal abzuwarten
    > (verschwendung
    > > vom CPU Zeit), sondern man richtet einen Interrupt ein, der anspringt
    > wenn
    > > sich der Pegel an diesem Pin ändert.
    >
    > Gratulation, du hast gerade eines der Dinge gefunden, die Echtzeitfähigkeit
    > verhindern: Interrupts :D

    Ich weis ja nicht ob du schon mal mit Interrupts gearbeitet hast, aber das funktioniert so dass man die zeitkritischen Dinge in Interrupts packt, damit sie Zeitnah abgearbeitet werden. Dafür wird dann unkritisches wie nebenherberechnung von Daten unterbrochen. Wenn man z.B. ein zeitlich kritisches Signal ausgeben muss, das wichtiger als die eingehenden Signale ist, so deaktiviert man derweil die Interrupts. Danach aktiviert ma sie wieder und es wird sofort die Interruptroutine angesprungen.

    Je nach komplexität des Systems kann man den Interrupts auch Prioritäten geben, damit die Signale in der Reihenfolge ihrer wichtigkeit abgearbeitet werden können.



    1 mal bearbeitet, zuletzt am 27.08.14 14:13 durch schuhumi.

  9. Re: real time aufgaben?

    Autor: kazhar 27.08.14 - 14:12

    h1j4ck3r schrieb:
    --------------------------------------------------------------------------------
    > kazhar schrieb:
    > ---------------------------------------------------------------------------
    > Gratulation, du hast gerade eines der Dinge gefunden, die
    > Echtzeitfähigkeit verhindern: Interrupts :D
    >
    > und wie nennst du die unterbrechung von jobs durch höherpriore jobs?

    Wie man das nennt ist egal. Aber Interrupts mit Eingängen zu verknüppeln geht garnicht.
    Schon mal probiert, was passiert wenn ein ein Signal mit einer Frequenz von nur ein paar hundert Kiloherz auf einer Interruptleitung anliegt?
    Da passiert gar nichts mehr...



    1 mal bearbeitet, zuletzt am 27.08.14 14:13 durch kazhar.

  10. Re: real time aufgaben?

    Autor: schuhumi 27.08.14 - 14:16

    kazhar schrieb:
    --------------------------------------------------------------------------------
    > h1j4ck3r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > kazhar schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > Gratulation, du hast gerade eines der Dinge gefunden, die
    > > Echtzeitfähigkeit verhindern: Interrupts :D
    > >
    > > und wie nennst du die unterbrechung von jobs durch höherpriore jobs?
    >
    > Wie man das nennt ist egal. Aber Interrupts mit Eingängen zu verknüppeln
    > geht garnicht.
    > Schon mal probiert, was passiert wenn ein ein Signal mit einer Frequenz von
    > nur ein paar hundert Kiloherz auf einer Interruptleitung anliegt?
    > Da passiert gar nichts mehr...
    Dann hast du falsch programmiert. Eine Interruptroutine soll nur abarbeiten was sofort getan werden muss. Für alles andere wird ein Flag gesetzt, um beim nächsten Durchlauf der Hauptschleife die noch ausstehenden, wenig kritischen und möglicherweise länger dauernden Aufgaben zu bewältigen.

    Wenn das System es dann auch nicht schafft, ist es hardwareseitig zu langsam um die paar hundert Kiloherz abzuarbeiten. Ohne Interruptprogrammierung ist es noch viel langsamer

  11. Re: real time aufgaben?

    Autor: h1j4ck3r 27.08.14 - 14:28

    kazhar schrieb:
    --------------------------------------------------------------------------------
    > h1j4ck3r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > kazhar schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > Gratulation, du hast gerade eines der Dinge gefunden, die
    > > Echtzeitfähigkeit verhindern: Interrupts :D
    > >
    > > und wie nennst du die unterbrechung von jobs durch höherpriore jobs?
    >
    > Wie man das nennt ist egal. Aber Interrupts mit Eingängen zu verknüppeln
    > geht garnicht.
    > Schon mal probiert, was passiert wenn ein ein Signal mit einer Frequenz von
    > nur ein paar hundert Kiloherz auf einer Interruptleitung anliegt?
    > Da passiert gar nichts mehr...

    Abgesehen von der hardwarerealisierung beeinträchtigen Interrupts nicht die Echtzeitfähigkeit eines Betriebssystems.

    Wie schuhumi schrieb
    >Wenn das System es dann auch nicht schafft, ist es hardwareseitig zu langsam
    >um die paar hundert Kiloherz abzuarbeiten

    Wenn die Hardware nicht hinterherkommt ist sie evtl. nicht für die Anforderungen des Systems geeignet.
    https://de.wikipedia.org/wiki/Earliest_Deadline_First

    https://de.wikipedia.org/wiki/Rate_Monotonic_Scheduling

    gibt es beides als präemptive(unterbrechbare) Varianten.

  12. Re: real time aufgaben?

    Autor: kazhar 27.08.14 - 14:33

    Was soll daran langsam sein, die Eingänge alle 50ms abzutasten, wenn man (max) 10 Pulse pro Sekunde erwartet bzw erfassen will?

    Realtimeanforderung bedeutet: ich will, dass das System auf einen Signalwechsel in genau (hardrealtime) bzw maximal (softrealtime) Zeit "X" reagiert hat. Interrupts spucken mir da mit einer zusätzlichen - und noch dazu unbekannten - Latenz rein.

    Also vermeidet man Interrupts wo man kann oder verwendet sie nur da, wo man sie genau einplanen kann; z.B. taskswitch alle x ms.

    btw: das mit dem paar hundert Kilohertz auf den Eingang ist kein Witz, sondern ein Standardtest.

  13. Re: real time aufgaben?

    Autor: schuhumi 27.08.14 - 15:08

    kazhar schrieb:
    --------------------------------------------------------------------------------
    > Was soll daran langsam sein, die Eingänge alle 50ms abzutasten, wenn man
    > (max) 10 Pulse pro Sekunde erwartet bzw erfassen will?
    Dass der letzte Puls schon vor 49.9ms passiert sein kann (Und das ist ganz und garnicht Realtime, 49.9ms ist ne halbe Ewigkeit!). Wenn die Impulse kleiner als 50ms sein können gehen sie verlohren wenn die Abtastung nicht zufällig zum richtigen Zeitpunkt stattfindet.

    > Realtimeanforderung bedeutet: ich will, dass das System auf einen
    > Signalwechsel in genau (hardrealtime) bzw maximal (softrealtime) Zeit "X"
    > reagiert hat. Interrupts spucken mir da mit einer zusätzlichen - und noch
    > dazu unbekannten - Latenz rein.
    Deine Definition für Realtimeanforderung stimmt. Mit deiner jetzigen Lösung erfüllst du die auch nicht, denn du hast bis zu 49.9ms Verzögerung. Die Behauptung dass Interrupts Latenzen erzeugen stimmt überhaupt- und garnicht. In die Interruptroutine schreibst du wie das System reagieren soll. Kommt der Signalwechsel beim System an wird sofort deine Code zum reagieren ausgeführt, somit gibt es deine Latenz nicht (außer den Sprung in die Interruptroutine (sprich ein paar Register sichern und program pointer setzen (einige Nanosekunden)), und unberechenbar ist sie schon garnicht.

    > btw: das mit dem paar hundert Kilohertz auf den Eingang ist kein Witz,
    > sondern ein Standardtest.
    Deine polling-variante übersteht den Test nur, weil sie Pulse einfach fallen lässt (Bei z.B. 500KHz gehen dir ca. 25000 Impulse durch die Lappen). Eine anständige Interruptlösung versucht jeden Impuls abzuarbeiten (das ist was du dem System aufgetragen hast). Wenn du das nicht willst: Angenommen dass du in der Anwendung höchstens alle 100ms einen Puls hast, dann sperre den interrupt wenn er auslöst (am Anfang der Interruptroutine) und gib ihn erst 90ms nach dem sperren wieder frei (idealerweise durch Timerinterrupt).

    > Also vermeidet man Interrupts wo man kann oder verwendet sie nur da, wo man
    > sie genau einplanen kann; z.B. taskswitch alle x ms.
    Nein, man benutzt Interrupts so viel man kann. Und bevor man sich online blamiert weil Interrupts ja blöd wären liest man sich ein wie Interrupts überhaupt funktionieren.

  14. Re: real time aufgaben?

    Autor: gadthrawn 27.08.14 - 16:21

    schuhumi schrieb:
    --------------------------------------------------------------------------------
    > kazhar schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was soll daran langsam sein, die Eingänge alle 50ms abzutasten, wenn man
    > > (max) 10 Pulse pro Sekunde erwartet bzw erfassen will?
    > Dass der letzte Puls schon vor 49.9ms passiert sein kann (Und das ist ganz
    > und garnicht Realtime, 49.9ms ist ne halbe Ewigkeit!).

    Wie lange das dauert ist dem RealTime-Begriff egal, er definiert nur eine fixe Antwortzeit. Die könnte auch Jahre betragen.

    > > Realtimeanforderung bedeutet: ich will, dass das System auf einen
    > > Signalwechsel in genau (hardrealtime) bzw maximal (softrealtime) Zeit
    > "X"
    > > reagiert hat. Interrupts spucken mir da mit einer zusätzlichen - und
    > noch
    > > dazu unbekannten - Latenz rein.
    > Deine Definition für Realtimeanforderung stimmt. Mit deiner jetzigen Lösung
    > erfüllst du die auch nicht, denn du hast bis zu 49.9ms Verzögerung. Die
    > Behauptung dass Interrupts Latenzen erzeugen stimmt überhaupt- und
    > garnicht. In die Interruptroutine schreibst du wie das System reagieren
    > soll. Kommt der Signalwechsel beim System an wird sofort deine Code zum
    > reagieren ausgeführt, somit gibt es deine Latenz nicht (außer den Sprung in
    > die Interruptroutine (sprich ein paar Register sichern und program pointer
    > setzen (einige Nanosekunden)), und unberechenbar ist sie schon garnicht.

    Hier würde ich einhaken.

    Ein Interrupt wird vom Prozessor empfangen und in einer Lookuptable gesucht, welches Programm das abzuarbeiten hat. Je nach OS kann nun eine ganze Menge passieren. Erst mal das aktuelle Programm anhalten, sichern, Wechsel in einen Kernelmode, ...

    Das ist nicht unbedingt etwas langes - aber verzögert zu einem unbekannten Zeitpunkt.

    Stell dir vor du hast einen Prozess der fix auf Ereignisse in x ns reagieren soll. Z.B. einen Airbag in x ns auslösen. Dein Interrupt kommt bei x - 1 ns und hindert erst mal das aktuelle Programm am weiterlaufen. Du brauchst mindestens n-ns für den Prozesswechsel, sagen wir eine blöde ns. Prozesswechel,minimale Abarbeitung, erneuter Prozesswechsel - und deine Echtzeitanforderung ist Geschichte.

    Insofern kann ein Interrupt eine Echtzeitanforderung durchaus stören.

    Du kannst mal in die RTAI Sachen zu Interrupthandling schauen...

  15. Nanosekunden?

    Autor: barforbarfoo 27.08.14 - 17:01

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > Stell dir vor du hast einen Prozess der fix auf Ereignisse in x ns
    > reagieren soll. Z.B. einen Airbag in x ns auslösen. Dein Interrupt kommt
    > bei x - 1 ns und hindert erst mal das aktuelle Programm am weiterlaufen. Du
    > brauchst mindestens n-ns für den Prozesswechsel, sagen wir eine blöde ns.
    > Prozesswechel,minimale Abarbeitung, erneuter Prozesswechsel - und deine
    > Echtzeitanforderung ist Geschichte.

    Im zweistelligen Nanosekundenbereich liegt die Latenz von RAM. Ich würde ein paar Zehnerpotenzen drauflegen um in sinnvolle Größenordnungen zu kommen.



    1 mal bearbeitet, zuletzt am 27.08.14 17:05 durch barforbarfoo.

  16. Re: Nanosekunden?

    Autor: MisterProll 27.08.14 - 20:02

    barforbarfoo schrieb:
    --------------------------------------------------------------------------------
    > gadthrawn schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Stell dir vor du hast einen Prozess der fix auf Ereignisse in x ns
    > > reagieren soll. Z.B. einen Airbag in x ns auslösen. Dein Interrupt kommt
    > > bei x - 1 ns und hindert erst mal das aktuelle Programm am weiterlaufen.
    > Du
    > > brauchst mindestens n-ns für den Prozesswechsel, sagen wir eine blöde
    > ns.
    > > Prozesswechel,minimale Abarbeitung, erneuter Prozesswechsel - und deine
    > > Echtzeitanforderung ist Geschichte.
    >
    > Im zweistelligen Nanosekundenbereich liegt die Latenz von RAM. Ich würde
    > ein paar Zehnerpotenzen drauflegen um in sinnvolle Größenordnungen zu
    > kommen.

    Vor einigen Jahren waren 11ms sehr gutes MIttelfeld und besser. Auch Win CE war dasrunter, wohl das beste win was es gibt :P.

    Harte Echtzeit bedeudet nichts anderes, daß auf eine Aktion innerhalb einer definierten Zeit ndie Reaktion kommt. Dass kann auch bedeuten nicht frueher als 10ms und nicht später als 11ms. Und wenn man auf dem System mehrere solcher Programme am laufen hat, kanns u.U. das System nicht mehr einhalten, und dann braucht man andere Hardware die das kann.

    Und btw. zuviele Interrupts(war in einem anderen Beitrag) haben auch Probleme bei der Mondlandung verursacht, die kamen schneller als bei Tests auf der Erde und haben das System blockiert und somit musste per Hand gelandet werden, oder zumindest ein Teil davon.

  17. Re: real time aufgaben?

    Autor: 486dx4-160 28.08.14 - 18:40

    schuhumi schrieb:
    --------------------------------------------------------------------------------
    > Ich weis ja nicht ob du schon mal mit Interrupts gearbeitet hast, aber das
    > funktioniert so dass man die zeitkritischen Dinge in Interrupts packt,
    > damit sie Zeitnah abgearbeitet werden. Dafür wird dann unkritisches wie
    > nebenherberechnung von Daten unterbrochen. Wenn man z.B. ein zeitlich
    > kritisches Signal ausgeben muss, das wichtiger als die eingehenden Signale
    > ist, so deaktiviert man derweil die Interrupts. Danach aktiviert ma sie
    > wieder und es wird sofort die Interruptroutine angesprungen.
    >
    > Je nach komplexität des Systems kann man den Interrupts auch Prioritäten
    > geben, damit die Signale in der Reihenfolge ihrer wichtigkeit abgearbeitet
    > werden können.

    Und genau das macht die Echtzeitfähigkeit kaputt: Du kannst nicht wissen wie lange die Abarbeitung von irgendwas braucht wenn dauernd Interrupts dazwischenfunken können.

  18. Re: real time aufgaben?

    Autor: derdiedas 31.08.14 - 12:35

    Für x86 Systemen gibt es tonnenweise RT OS... für die PI ist es etwas mühselig...

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Landkreis Stade, Stade
  2. Sky Deutschland GmbH, Unterföhring bei München
  3. Tecan Software Competence Center GmbH, Mainz-Kastel
  4. über duerenhoff GmbH, Walluf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 12,99€
  2. (-10%) 8,99€
  3. (-10%) 17,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Leistungsschutzrecht: Drei Wörter sollen ...
Leistungsschutzrecht
Drei Wörter sollen ...

Der Vorschlag der Bundesregierung für das neue Leistungsschutzrecht stößt auf Widerstand bei den Verlegerverbänden. Überschriften mit mehr als drei Wörtern und Vorschaubilder sollen lizenzpfichtig sein. Dabei wenden die Verlage einen sehr auffälligen Argumentationstrick an.
Eine Analyse von Friedhelm Greis

  1. Leistungsschutzrecht Memes sollen nur noch 128 mal 128 Pixel groß sein
  2. Leistungsschutzrecht Französische Verlage reichen Beschwerde gegen Google ein
  3. Leistungsschutzrecht Französische Medien beschweren sich über Google

Energiegewinnung: Zu wenig Magma-Nachschub für die Geothermie
Energiegewinnung
Zu wenig Magma-Nachschub für die Geothermie

Bei Diskussionen über Geothermie klingt es oft so, als könnten vulkanisch aktive Gegenden wie Island den Rest der Welt mit Energie versorgen. Aber ein Blick auf die Zahlen zeigt, dass dieser Eindruck täuscht.
Von Frank Wunderlich-Pfeiffer

  1. E-Truck Nikola Tre wird in Ulm gebaut
  2. Wasserstoff Thyssen-Krupp will Stahlproduktion klimaneutral machen
  3. Energiewende Sonnen vermietet Solaranlagen und Elektroautos

Frauen in der Technik: Von wegen keine Vorbilder!
Frauen in der Technik
Von wegen keine Vorbilder!

Technik, also auch Computertechnik, war schon immer ein männlich dominiertes Feld. Das heißt aber nicht, dass es in der Geschichte keine bedeutenden Programmiererinnen gab. Besonders das Militär zeigte reges Interesse an den Fähigkeiten von Frauen.
Von Valerie Lux

  1. Arbeit Warum anderswo mehr Frauen IT-Berufe ergreifen
  2. Arbeit Was IT-Recruiting von der Bundesliga lernen kann
  3. Arbeit Wer ein Helfersyndrom hat, ist im IT-Support richtig

  1. Elektromobilität: Umweltbonus gilt auch für Jahreswagen
    Elektromobilität
    Umweltbonus gilt auch für Jahreswagen

    Vom neuen Umweltbonus für Elektroautos können künftig Käufer von Gebrauchtwagen profitieren. Neben einem zeitlichen Limit hat die Bundesregierung eine Obergrenze für die Kilometerzahl und den anrechenbaren Wertverlust festgelegt.

  2. Ausdiskutiert: Sony schließt das Playstation-Forum
    Ausdiskutiert
    Sony schließt das Playstation-Forum

    Falls es technische Probleme mit der Playstation 5 geben sollte, wird man an einer Stelle keine Hilfe finden: im offiziellen Playstation-Forum. Sony will den schon länger nur noch schwach frequentierten Treff schließen.

  3. Alphabet: Google strukturiert Cloud-Business um
    Alphabet
    Google strukturiert Cloud-Business um

    Um Nummer eins im Cloud-Business zu werden, strukturiert Google derzeit um. Auch einige Mitarbeiter müssen gehen. Man wolle sich dabei auf fünf Kernmärkte konzentrieren.


  1. 18:22

  2. 18:00

  3. 17:45

  4. 17:30

  5. 17:15

  6. 16:39

  7. 16:20

  8. 16:04