OS Aufbau

keine Angst die Notaus-Funktion wird über Interrupt und direkte Trennung 
der Versorgungsspannung für die Antriebe realisiert!!!
ich werde keinen Gefährden... Aber ich wollte nur mal ein Beispiel 
nehmen was verdeutlichen kann was Realtime bedeutet!!

Interessant könnte auch dies sein:
http://picoos.sourceforge.net/

Realtime bedeutet doch nur, dass das OS innerhalb einer garantierten 
Zeit reagiert. Wie groß diese Zeit ist, um noch als RealTime 
durchzugehen, hängt immer von den Anforderungen des Projektes ab.
Ob die Abschaltung eines Motors nun 30us oder 100us dauert ist doch 
ziemlich egal, wenn man die Nachlaufzeit des Motors da ins Verhältnis 
setzt.

@Andre:
das war mir schon klar wie RealTime definiert ist, aber ich suche halt 
ein Beispiel wie Ihr sowas aufbauen würdet...
Wenn ich die Definition Notaus habe, dann sollten die Antriebe nicht 
nachlaufen sondern sofort stehen. Dafür gibt es verschiedene 
Möglichkeiten bei Antrieben... Kurzschlißen der Wicklungen, 
Gleichstrombremsen oder mechanische Bremsen... usw.. Auf dem Gebiet kann 
man so viel machen.

@All:
Ich würde lieber wissen wie Ihr Euren Quellcode aufbauen würdet um dies 
zu realisieren. Also ich meine, würdet Ihr ähnlich einer Schrittkette 
die Funktionen nacheinander aufrufen und bearbeiten lassen und die 
Interrupts nur nutzen um z.B. die Endlagen, Notaus usw. zu erkennen. 
Oder würdet Ihr zb. einen Timer in genau definierten Abständen einen 
Interrupt auslösen lassen (zb. 100us) und mit dem Interrupt einen Zähler 
hochzählen lassen. Der ausserhalb der Interruptroutine mit Konstanten 
verglichen wird, die ein Auslösen einer gewissen Funktion 
zusammenhängen...

Beispiel "main":

if (ucCounter < 256) {  //Taster, Endlagenabfrage
   ...      //Frage die Taster alle 100us ab
}
if (ucCounter == 10) { //Wenn kein Taster gedrückt
   ...      //Gebe jede 1ms einen Tackt aus
}

usw.

oder wie würdet ihr das machen?

Gruß
Benjamin

Die Frage ist doch, ob du tatsächlich ein "vollwertiges" OS brauchst.
Wenn ich dich richtig verstehe, hast du eine kritische Anforderung: den 
Notaus. Dieser soll innerhalb kürzester Zeit bearbeitet werden. Ich 
würde den dann also in eine Interrupt-Routine packen.
Die restlichen Funktionen deiner Anwendung sollen in einer bestimmten 
Reihenfolge durchlaufen werden.
Selbst die Endschalter musst du nicht unbedingt mit einem Interrupt 
abarbeiten, wenn du die Funktion, die den Endschalter überwacht, nur 
häufig genug aufrufst. Vielleicht würde das sogar für den Notaus 
funktionieren.
Es kommt ganz darauf an, welche Laufzeit deine einzelnen Funktionen 
haben, welche Vorschubgeschwindigkeit du hast und ob dir die 
resultierende Abfragehäufigkeit ausreicht.
Beispiel:

1

while (1)

2

{

3

    endschalter();

4

    funktion1();

5

    endschalter();

6

    funktion2();

7

    endschalter();

8

    funktion3();

9

}

Wenn du mit einem Timer arbeiten möchtest, dann musst du spätestens in 
der Auswertefunktion deine (ganzen) Register sichern und wieder 
herstellen. Denn du weißt nicht, in welcher Funktion du gerade den 
Prozessor unterbrichst und welche Register belegt sind.
Ich weiß von einem sicherheitsrelevanten Steuergerät (Bremsassistent), 
da ist das "OS" ähnlich implementiert, da werden keinerlei Interrupts 
verwendet, alles über Polling, sogar der Datentransfer auf dem 
Systembus.

@Stefan

Danke für den Kommentar:
"Ich würde es so machen, wie es in bewährten OSen gemacht wird."

Ich würde nicht danach fragen, wenn ich wüßte wie die "bekannten" OS 
aufgebaut sind!!!

@Andre
Danke für die Info!! Aber meinst du die Bearbeitung ist wirklich schnell 
genug?? Dann werde ich das wohl so aufbauen. Aber ich denke um den 
Regelprozess für die Motoren nicht zu stören, sollte ich das Display an 
der Controllereinheit vielleicht über einen seperaten Controller 
ansteuern... Sonst bremst das LCD alles aus, oder was denkst Du?

Danke noch mal!!!

Gruß

Mit dem Display wird die Sache schon etwas komplizierter, was das Timing 
angeht. Die Frage dabei ist, wie oft und wann die Anzeige aufgefrischt 
wird, wieviele Daten dann an das Display gesendet werden, wie schnell 
die Schnittstelle zum Display ist, welche Wartezeiten durch das Display 
entstehen.
- Wird das Display nur beim Einschalten initialisiert und dann nur
  gelegentlich 2..3 Zahlen aufgefrischt? Dann könnte es mit dem obigen
  Ansatz klappen pro Schleifendurchlauf einmal das Display
  aufzufrischen.
- Gibt das Display nur Statusmeldungen aus? zB "Betriebsbereit",
  "In Arbeit", "Fertig". Dann muss das Display nicht in der Schleife
  aufgefrischt werden, hat also da keinen Einfluss auf die Steuerung.


Gerade wenn ein Display ins Spiel kommt, kann es tatsächlich nützlich 
sein auf ein RTOS zu setzen. Dann wird die Ansteuerung für das Display 
als Task mit niedriger Priorität implementiert. Alle anderen Tasks 
erhalten eine höhere Priorität. Dann wird unter Umständen das Display 
verzögert aufgefrischt, aber die anderen Tasks werden mit garantierten 
Zeiten bearbeitet. (Das stimmt aber auch nur bedingt. Es kann dann zB zu 
Problemen mit Prioritäts-Inversion[1] kommen.) Grundsätzlich behält aber 
immer der Task mit der höchsten Priorität die Kontrolle über die CPU.
Du musst dabei aber immer im Kopf behalten, dass ein RTOS dir 
zusätzlichen Overhead verursacht(Zeit- und Speicherverbrauch), und du 
musst dich in das RTOS einarbeiten.



[1] http://netrino.com/Publications/Glossary/PriorityInversion.html

@stefan:
ich finde es nett das du mich auf ein fertiges RTOS hinweist..., aber 
ich wollte mich nicht erst in die strukturen eines ARM und dem 
hinterlegten RTOS einarbeiten...

Wenn dies jetzt für einen AVR vorhanden gewesen wäre, hätte ich damit 
keine probleme gehabt... aber ich bin ein newbie im gegensatz zu manch 
anderem hier!! ich bin froh das ich meinen displaytreiber und 
verschiedene andere sachen zusammen bekomme. darum verweigere ich mich 
in eine RTOS für ein anderes system einzuarbeiten!! ich möchte erst 
einmal eines verstehen!!!!

@TheMason:
vielen dank für die detailierten informationen. das hat mir schon ein 
wenig weitergeholfen... ich glaube ich sollte noch ein 
informatik-studium hinterherschieben... dann komme ich vielleicht besser 
in die struktruen hinein!!

Gruß
Benjamin