Ab wann RTOS

Also ab wann sich ein RTOS lohnt, kann man kaum sicher beantworten. Es 
ist eher eine Philosophiefrage. Da gibt es immer wieder Diskussionen :-)

Mir scheint es eher, dass du bei deiner Aufgabe keins brauchst. Der 
Arbeitsaufwand, dass zu implementieren wird höher sein, als den Nutzen, 
den du daraus ziehst. Erweiterungen sind ja noch nicht geplant?

Es scheint mir aber, dass du das gerne lernen möchtest, sonst würdest du 
wohl kaum drüber nachdenken. Dann mach es. Deine Aufgabe scheint 
"simple" und da kannst du dann "klein anfangen" mit dem RTOS.

just my 2 cents

Hi 900ss,

Erweiterungen sind möglich aber nicht geplant, die Busse sind auf dem 
PCB frei zugänglich für Erweiterungen, aber im Moment ist die 
Grundfunktion entscheident.

Ich denke auch das ich es versuchen werde, weil es interessant ist, und 
es anscheinend keine gravierenden Nachteile für die Funktion entstehen.


Danke

Ein RealTimeOperatinfSystem wird interessant je mehr der folgenden 
Punkte du gegeben sind:

1) wenn du bestimmte Zeitanforderungen garantieren must. ( Sende 
Messwert aber nicht wenn Ereigniss A vorliegt, dann sende Fehlermeldung 
innerhalb von 5 ms).

2) mehrere Programmierer am Project arbeiten. (Jeder hat seine/n eigenen 
Task und darf auch "Warten".)

3) Mehrere lange Sequenzen abarbeiten must. Es wird sehr unübersichtlich 
diese in State-Mashine zu packen.

Nachteile: erhöte Administration. (Festlegen von Prioritäten, Vewrwalten 
der Recourcen. etc.

Der Perfomence verlust dürfte bei deinem Prozessor nicht ins Gewicht 
fallen.

Als Zwischending ist auch ein Realtime Kernel denkbar. Zum Vergleich :

Nackte Maschine - die Applikation ist ein Binary das fest geladen 
(geflasht) wird und das wars. Die Funktionalitaet wird auf eine oder 
mehrere Statusmaschinen runtergebrochen. Die werden ab einer gewissen 
Komplexitaet muehsam.

Realtime Kernel - Die Applikation wird zusammen der realtime kernel 
library kompiliert, geladen (geflasht) und das wars. Der Realtime Kernel 
stellt Semaphoren, mailboxen, queues, threads, Scheduler zur Verfuegung. 
Und die einzelmen Threads sind im Wesentlichen unabhaengige Prozeduren 
die je einen eigenen Stack haben.

Realtime OS - Das OS beinhaltet einen Lader, dh es existiert eine Welt 
ausserhalb der Applikation. Das OS beinhaltet die Mechanismen, dass 
mehrere Threads oder mehrere Applikationen gleichzeitig laufen koennen 
und kommunizieren koennen. Also Semaphoren, Mailboxen, Queues. Der 
Scheduler ist Teil des Betriebssystems.

Oberhalb einer gewissen Komplexitaet moechte man erweiterte Debug 
features haben, die ein OS bieten kann, und die anderen eben nicht.

Hä-jetzt Noch schrieb:

> Als Zwischending ist auch ein Realtime Kernel denkbar. Zum Vergleich :

Das ist hier ja auch gemeint. FreeRTOS ist ebendies. Im Kontext von 
vollintegrierten Microcontrollern wird unter dem Begriff "RTOS" i.d.R. 
ein Realtime Kernel verstanden, kein echtzeitfähiges Linux oder so.

Zwölflieter schrieb:

> Ein RTOS benötigt viel Einarbeitungszeit. Es lohnt sich deshalb nur,
> wenn das RTOS vorprogrammierte Funktionen mitbringt, die man für das
> Projekt braucht und die die Programmierzeit drastisch verkürzen.

Oder wenn man anhand dieses einen Projektes sich mit der Denkweise und 
Programmiertechnik vertraut machen will. Wenn man das mal drauf hat, 
dann sind diese verschiedenen Kernels sich alle ziemlich ähnlich.

Eine nette Eigenheit vom FreeRTOS ist: Man kann bereits auf dem PC üben.

Zwölflieter schrieb:
> Ein RTOS benötigt viel Einarbeitungszeit.
Wenn man Zeit hat und sich einarbeiten möchte, spart das die 
erforderliche Einarbeitungszeit, wenn man mal wirklich auf ein RTOS 
angewiesen ist.
Es kann natürlich sein, dass du mitten in der Einarbeitungszeit alles 
vor Wut in die Ecke wirfst und doch auf die nackte Maschine zurück 
gehst.

Hallo Zusammen,

A.K. hat mich richtig verstanden, ein Echtzeit Linux, Win CE oder so 
will ich nicht einsetzen, ich dachte von vornherrein an z.b. Free RTOS, 
da bin ich als erstes drauf gestoßen.

\quote
Ein RTOS benötigt viel Einarbeitungszeit. Es lohnt sich deshalb nur,
wenn das RTOS vorprogrammierte Funktionen mitbringt, die man für das
Projekt braucht und die die Programmierzeit drastisch verkürzen.
\!quote

Welcher Echtzeit Kernel fwürde z.b. SPI, USB, Dateisysteme ala FAT16/32 
auf uSD unterstützen? das sich die Einarbeitung auch lohnt.

Es handelt sich hier um ein Privates Projekt, Programmiert wird zu 2.

Vorallem ist mir wichtig das die ZustandsRegelung sicher mit 1ms 
garantiert antwortet. Das System soll die Übergeördnete Regelung eines 
UAV übernehmen.
Die Zustandsregelung usw. Steht schon Platine auch.

Bei uns kam durch lesen im hier im Forum nur die Frage auf ob uns ein 
echtzeit system/kernel hilft, da es vllt auch für andere Projekte in der 
Größenordnung interessant ist.

Wir kamen eben Wegen der Kombination aus Regelung und 
Datenverarbeitung(SD Karte, Übergeordnete Kommunikation, später 
Kollektive KI)

Am SPI hängen alle Aktoren und Sensoren, was eine hohen Datenaufwand 
bedeut, wenn uns jetzt ein Kernel die Verwaltung abnimmt/vereinfacht, 
z.b. SPI in einem Task welches Informationen für das Regelungs Task 
bereitstellt.

Das sind alles nur grobe Vorüberlegungen um nicht doppelte Arbeit zu 
machen.

Habt ihr Vllt eine empfehlung für ein Echtzeit kernel der SPI und 
Ähnliche Funktionalitäen implementiert?

Tec Nologic schrieb:

> Welcher Echtzeit Kernel fwürde z.b. SPI, USB, Dateisysteme ala FAT16/32
> auf uSD unterstützen? das sich die Einarbeitung auch lohnt.

FreeRTOS ist leidlich verbreitet und schon deshalb sinnvoll auch wenn 
für meinen Geschmack manche Dinge zu aufwendig realisiert sind. Wie ich 
oben schon schrieb: kennst du einen kennst du alle, vereinfacht gesagt. 
Es gibt natürlich Unterschiede, aber die Prinzipien sind weitgehend 
gleich.

> Habt ihr Vllt eine empfehlung für ein Echtzeit kernel der SPI und
> Ähnliche Funktionalitäen implementiert?

Der Echtzeit-Kernel hat einen bestimmten Aufgabenbereich. Abdeckung von 
Periphieriemodulen wie SPI, CAN, RS485, I2C, ... gehört nicht dazu. 
Einzig UART ist recht verbreitet, weil für Debugging nützlich. Andere 
Module werden zwar im Laufe der Zeit hinzugefügt, sind aber kein 
Bestandteil eines Kernels, sondern Zusatzkomponenten auf Basis dieses 
Kernels.

Ich würde auch nicht empfehlen, sowas strategisch zu verwenden, weil du 
dich damit zu sehr an eine Variante bindest. Insbesondere wenn es auch 
um den Lerneffekt geht. Andererseits ist es nicht allzu schwierig, ein 
Peripherie-Treiber für I2C selbst so zu schreiben, dass er ohne grossen 
Aufwand sowohl mit FreeRTOS als auch mit AvrX zusammen arbeitet.

Hi A. K.

Ok das heißt für mich, ich setz als Bsp: FreeRTOS auf, mit dem mache ich 
dann lediglich die Recourcenverteilung und Rechenzeitzuteilung der 
verschiedenen Tasks, den Rest muss ich wie bei der leeren Maschine 
selbst wie gewohnt implementieren.

Das alle RTOS mehr oder minder auf dem gleichen Prinzip beruhen dachte 
ich mir schon, ist wie bei Programmiersprachen, kennt man eine kennt man 
alle (mal abgesehen von OOP und nicht OOP aber egal)

Ich denke die Einarbeitung, wird auf lange Sicht Lohnenswert sein. Wenn 
irgend wann Mal mehere dieser Systeme unter einander im Netzwerk 
kommunizieren.

Wie sieht das mit dem Debugging aus da habe ich recht viel gelesen das 
sich so ein system einfacher  debuggen lassen sollte bzw, 
übersichtlicher sei wie kann ich das verstehen? wird Task für Task 
debugt? oder wie unter Win mit "Debug Prints"?

Danke schon Mal

Tec Nologic schrieb:

> Ok das heißt für mich, ich setz als Bsp: FreeRTOS auf, mit dem mache ich
> dann lediglich die Recourcenverteilung und Rechenzeitzuteilung der
> verschiedenen Tasks, den Rest muss ich wie bei der leeren Maschine
> selbst wie gewohnt implementieren.

Würde ich schon des Lerneffekts wegen so empfehlen.

> Wie sieht das mit dem Debugging aus da habe ich recht viel gelesen das
> sich so ein system einfacher  debuggen lassen sollte bzw,
> übersichtlicher sei wie kann ich das verstehen? wird Task für Task
> debugt? oder wie unter Win mit "Debug Prints"?

Reichlich Debug-Ausgaben mit Zeilenpufferung(!) einbauen, um den Ablauf 
sichtbar zu machen.

Manchmal praktisch: Ein Monitor, der über UART einen Taskzustand 
anzeigen kann. Nicht selten schon dabei.

Mit den üblichen JTAG-Debuggern wird man nicht wirklich glücklich, denn 
da verwirrt die automatische Taskumschaltung doch ziemlich.

Übersichtlicher wird der Quellcode, weil sich Abläufe sequentiell 
darstellen und nicht als Statemaschines häppchenweise zerhackt werden. 
Dass der Ablauf trotzdem häppchenweise stattfindet muss man dann 
allerdings im Kopf haben und berücksichtigen.

Hi A.K.

Danke, das hat mir sehr geholfen, ich werde mich mal auf der seite von 
Free RTOS weiter einlesen, und erst mal auf einem Dev Board etwas 
Probieren, um mich damit anzufreunden.

Das mit der Taskumschaltung, war auch mein Problem was ich beim 
Debugging gesehen habe, aber die Variante alles über ein Uart auf einen 
Monitor(bei mir wohl Laptop mit Terminal) raus zu jagen ist natürlich 
super simpel und Effektiv, Breakpoints verdummen etwas :) Früher habe 
ich das nur so gemacht, als ich keinen onChip-Debugger hatte.

Wenn sich noch weitere Fragen ergeben werde ich wohl mal wieder hier 
schreiben.

Danke,

Achja gibt es irgend wo Howtos oder so für die implementierung von 
Perepherietreibern? Steht das bei Free RTOS auf der Seite?

Danke

Stefan Kunz schrieb:
> Wie du am Anfang erwähntest willst du zyklisch jede ms eine
> Reglerfunktion aufrufen. Da wüde ich sagen, dass du kein RTOS nehmen
> solltest, da diese meistens einen Systemtick haben der in dieser
> Größenordnung liegt. Gut bei Fee-RTOS bin ich mir nicht ganz sicher.
> Man kann zwar den Systemtick herabsetzen aber verursacht man dadurch ein
> nicht unerheblichen overhead beim Sheduler.
>
> mfg
> Stefan

Hi Stefan,

Das klingt gar nicht gut, die 1ms steht fest die, ist für die Regelung 
unter den gegebenen Anforderungen erforderlich.

Da werde ich auf jeden fall mal bei Free RTOS nach suchen was die dort 
angeben.

Danke

HI

Auf der Seite von FreeRTOS steht leider nichts zum Timing, weiß das 
jemand, ob ein SystemTick von 10kHz oder höher möglich ist? oder Ob ich 
einen SystemTick von 1ms nehmen kann in mit Höchster Prio die Regelung 
berechne, der Rest ist vom Timing her fast egal.

G fand zu Free RTOS systemtick nur http://www.coocox.org/CoOS.htm ein 
anderes Derivat für M3, dort steht aber auch nur, wie lange ein 
Taskwechsel usw. dauert aber nicht, wie schnell der grund Zyklus läuft.

Danke

OT:
Tec Nologic schrieb:
> \quote
> ....
> \!quote
Du kannst hier im Forum mit >>> zitieren.
> Ebene 1
>> Ebene 2
>>> Ebene 3
>>>> usw...

Tec Nologic schrieb:

> Auf der Seite von FreeRTOS steht leider nichts zum Timing, weiß das
> jemand, ob ein SystemTick von 10kHz oder höher möglich ist?

Das gehört da auch nicht rein, sondern ist Sache des Programmierers. Das 
RTOS stellt eine Funktion zur Verfügung, die regelmässig von einem 
Timer-Interrupt aufgerufen werden sollte. Wie kurz oder lang das ist 
darf man selbst entscheiden. Einen 16Mhz AVR habe ich beim 
zugegebenermassen sparsamen AvrX mit 10KHz Tick gefahren. Das gab zwar 
so um die 10% Grundlast, aber dafür liessen sich bereits manche 1-Wire 
Delays darüber abwickeln.

Ein 10KHz Takt auf einem 50-100MHz Cortex-M3 sollte jedenfalls keinerlei 
Problem darstellen - wenn man nicht darauf besteht, in jedem Tick ein 
printf() auszugeben ;-).

> G fand zu Free RTOS systemtick nur http://www.coocox.org/CoOS.htm ein
> anderes Derivat für M3, dort steht aber auch nur, wie lange ein
> Taskwechsel usw. dauert aber nicht, wie schnell der grund Zyklus läuft.

Was für ein Grundzyklus? Ausser dem Timer-Tick gibt es keine Grundlast 
und keinen Grundzyklus. Den ungefähren Aufwand des Timer-Ticks kann man 
ggf. durch kurzen Blick in den Quellcode ermitteln.

In das Coocox habe ich mal reingesehen. Ich bin der Ansicht, dass die 
Mädels dort ein bischen sehr auf bestimmte Compilereigenschaften 
vertrauen. Ein RTOS ohne ein einziges "volatile" darin macht mich 
unweigerlich etwas misstrauisch. Entsprechende Kommunikation mit deren 
Mailadresse verlief unergiebig (sinngemäss: "passt schon, vertrau uns") 
- und für meinen Geschmack zu anonym.

HI

Ok ich denke mal ich werde mich in Free RTOS einarbeiten, dann kann ich 
denke ich auch besser einschätzen, wie das System sich verhält zur Zeit, 
ist das noch nicht ganz klar.

Aber danke an alle für die guten Antworten!

Stefan Kunz schrieb:

> Man kann zwar den Systemtick herabsetzen aber verursacht man dadurch ein
> nicht unerheblichen overhead beim Sheduler.

Üblicherweise wird der Scheduler nur aktiv, wenn sich am Zustand was 
rührt, d.h. wenn eine bisher schlafende Task ausführbar wird. Wenn sich 
nichts rührt, dann kehrt der Tick-Interrupt ohne Zusatzaufwand wieder 
zurück. Ein "leerer" Timer-Tick hat also nur geringen Aufwand zur Folge.

An dieser Stelle kommt auf den Cortex-M3 eine speziell dafür entwickelte 
Besonderheit des Interrupt-Controllers zum Tragen. Der PendingSVC (oder 
so ähnlich) Interrupt, der Interrupt-Routinen ganz normal ohne den bei 
RTOS sonst üblichen Overhead gestalten lässt. Wenn sich im Scheduling 
was ändert wird dieses Bit gesetzt und am Ende des letzten Interrupts in 
der Verschachtelung, also direkt vor Rückkehr zum laufenden Programm, 
wird per Hardware automatisch dieser Handler aufgerufen, der dann den 
etwas teureren Taskswitch ausführt.

Ergebnis: Ein Interrupt ohne ausgelöstem Taskswitch ist kaum teurer als 
einer ohne RTOS.

Hi

besucher schrieb:
> Oder bau auch den Regler als Interruptroutine, lass die von einem
> weiteren Timer antreten (parallel zu FreeRTOS) und gib ihr die höchste
> Priorität. Du musst dir dann nur überlegen, wie du den Regler in
> atomaren Aktionen mit neuen Sollwerten versorgst.

ich denke ich werde das in dieser Weise Realisieren weil ich so für den 
Regler ein definiertes Zeitverhalten habe. den rest werde ich dann vom 
OS verwalten lassen. ich bin mal gespannt wie das läuft.

Ich werde mir in den nächsten Tagen auf jeden Fall mal eine 
Experimentier Plattform dafür zusammen suchen, n STM32 oder n Pic32 
sollten hier noch irgend wo rumliegen samt Board. und dann heißts LED's 
Blinken :) oder was die bei Free RTOS so für demos haben. Ich muss mir 
das ganze erst mal  in ruhe selbst angucken selbst angucken. Aber das 
schein ja keine all zu große Schnappsidee( das Problem mit einem RTOS 
zulösen) zu sein.

Danke

> Bei einem UAV scheint mir 1 ms auch schon...
Was ist eine UAV?

Hi Rolf,

Rolf Magnus schrieb:
> Die Frage ist, welche Interrupt-Routinen überhaupt dazwischenfunken
> können und wie lange die brauchen. Und natürlich wie genau dein Regler
> überhaupt sein muß. Bei einem UAV scheint mir 1 ms auch schon recht kurz
> zu sein, wenn man bedenkt, daß die normalen Servos und Motorsteller
> üblicherweise nur alle 20 ms einen neuen Sollwert bekommen.

Deswegen werden bei diesem Gerät die Motorsteller usw. über SPI mit 
16bit Sollwerten versorgt. Das  und die Zustandsregelung des 
Gesamtsystems sorgt für eine sehr weiche Regelung. Mit einem dsPic als 
HauptProzessor läuft das schon ganz gut, aber nicht automom deswegen die 
Erweiterung auf 32Bit und eben die Frage Rtos oder nicht.

Zur info ich verwende keine Standardregler, ala Holger-Regler oder so, 
die sind selbst entwickelt.

Ziel des ganzen ist später mehere UAV's  "zusammen" arbeiten zulassen. 
Da gibt es interessante Projekte ich glaube an der University of 
Stanford einfach mal bei Youtube gucken. Oder bei Hackaday mal schauen.

Hi Besucher,

besucher schrieb:
> Wenn man schon ein RTOS hat, sollte man dessen Dienste auch benutzen,
> die können einem viel helfen. Und je mehr man in Interruptroutinen
> erledigt, desto mehr Einschränkungen unterliegt man. Manche Dienste des
> RTOS sind im Interrupt nicht nutzbar.

wie ich schon geschrieben habe werde ich mir erst mal ein Testsystem 
aufbauen und ein mal eine Demo von free RTOS fashen und damit etwas rum 
Probieren und testen, weil ich zur Zeit noch kein Gefühl dafür habe, was 
mir so ein System bietet und nicht bietet, dann werde ich sicherlich 
auch  entscheiden können, wie ich jetzt was Priorisieren kann und wie 
ich es Löse, aber ohne je so ein RTOS am amlaufen gehabt zu haben ist 
das schlecht zusagen.

Aber danke, ich werde das Alles mal Prüfen.

Erst mal LED's Blinken und dann anfangen die ganze Perepherie 
einzurichten, und Timing Tests machen, wenn die zufriedenstellend, durch 
sind dann würde ich das ganze erst auf das UAV drauf lassen, Um da mal 
eben was zu testen steckt da doch zu viel Arbeit drin.

Aber danke

hi

oszi40 schrieb:
> Tec Nologic schrieb:
>> mehere UAV's  "zusammen" arbeiten zulassen
>
> Wenn Deine "UFOs" per Funk zusammen arbeiten sollen, wird Dein
> Echtzeitsystem noch das kleinere Übel sein. Echtzeitsystem und STABILE
> Funkverbindung und Sicherheit sind 3 Unbekannte auf einem Haufen.

Ja das weiß ich, da kommt noch so einiges, aber ich gehe auch nicht 
davon aus das das ganze System innerhalb von einem Jahr läuft. Das ist 
mehr so als ewige Hobby-Baustelle gedacht.