www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ab wann RTOS


Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen Zusammen,

Ich würde gerne eine Einschätzung von euch haben mit Vor und Nachteilen 
eines RTOS. Ab was für einer Programmkomplexität lohnt es sich, was 
erleichtert mir der Scheduler usw.

Meine Hauptanwendung ist eine Zustandsregelung mit 1ms Zykluszeit. Der 
Prozessor soll dabei  Führungsgrößen usw. über SPI verteilen, Daten auf 
einer uSD Karte speichern und auslesen und nach außen über RS485 oder 
Zigbeemodule Istwerte senden und Sollwerte empfangen.

als Cpu steht zur Zeit ein 32Bit Prozessor ohne MMU mit unter 100MHz 
Arbeitstakt im Raum (Cortex-M3 oder PIC32)

als RTOs dachte ich an "Free RTOS".

Normal würde ich dieses Problem folgender maßen angehen.
-Regeleung in festem Zyklus über Timer
den Rest würde ich frei im main laufen lassen.

Würde mir hier für ein RTOS arbeit abnehmen oder eher nur Resourcen 
verbraten?

ich selbst habe keine erfahrung mit RTOS auf uC, nur auf x86 
Prozessoren.

Aber mit Digitaler Regelung auf uC's und C Programmierung bin ich 
bewandert.

vor der Einarbeitung in RTOS scheue ich mich nicht.
Die Frage ist Lohnt es sich, oder will ich zu viel?

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> RealTimeOperatingSystem
Echzeitbetriebssystem lohnt sich nur bei zeitkritischen Prozessen wie 
z.B. Werkzeugmaschinensteuerungen. Wenn der Fräser z.B. mit XP gesteuert 
würde, wäre das Material schon komplett weggefräst, weil z.B. der der 
neue Virenscanner "etwas länger" gebraucht hätte bis der nächste Befehl 
für den Fräser kommt...
RTOS erfordert etwas mehr Erfahrung.

Autor: Zwölflieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Projekt ist bestimmt auch noch ohne RTOS lösbar, handkerum ist so 
ein überschaubares Projekt gut geeignet um sich in ein RTOS 
einzuarbeiten.

Wenn das Programm mal mit RTOS steht, ist es viel pflegeleichter bzw. 
einfacher es später zu erweitern, selbst wenn es mal eine sehr komplexe 
Applikation wird.

Das gewonne KnowHow ist zudem auch für spätere Projekte sehr nützlich 
und wertvoll.

Viele komplexere Dinge (zB TCP/IP, HTTP-WebBrowser) lassen sich ohnehin 
nur mit einem Betriebsystem vernüftig realisieren.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? 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.

Ich würde nicht sagen, dass man einen 10 kHz-Systemtick braucht für eine 
1 kHz-Regelung.

Du müsstest für die Regelung eine hoch priorisierte RTOS-Task nehmen und 
diese mit 1 ms Zykluszeit laufen lassen (FreeRTOS kann das). Die 
restlichen Tasks (SPI, SD-Karte, ...) haben tiefere Prioritäten, das 
heißt, sie kriegen die Reste, die der Regler übriglässt. Achte drauf, 
dass das genug ist, damit die noch fertig werden können mit ihren 
Aufgaben.

Und noch was ist wichtig: Egal wie hoch die Task-Priorität des Reglers 
ist, Interruptroutinen sind immer noch höher priorisiert. Wenn du also 
für SPI, SD usw. Interrupts verwendest, dann behalte im Hinterkopf, dass 
diese den Regler verdrängen können (-> Jitter im Reglertakt).

Falls das ein Problem ist für das Flugmodell, dann verzichte auf weitere 
Interrupts.

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.

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tec Nologic schrieb:
> 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.

Ja. FreeRTOS bietet dir den Scheduler und die API, um Tasks, Queues, 
Semaphoren und ähnliche typische Multithreading-Elemente zu verwalten 
und nicht mehr.

> Das alle RTOS mehr oder minder auf dem gleichen Prinzip beruhen dachte
> ich mir schon,

Letztendlich ist das Prinzip auch nicht so viel anders, als bei einer 
Threading-Bibliothek auf dem PC. Man muß sich halt etwas mehr Gedanken 
darüber machen, wann welcher Thread genau drankommt und die Prioritäten 
mit Bedacht vergeben.

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? 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.

Ja, bei 1 ms System-Tick kannst du deinen Regler auch im 
Millisekunden-Task laufen lassen.

Tec Nologic schrieb:
> 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.

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.

Autor: Kalli L. (knl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bei einem UAV scheint mir 1 ms auch schon...
Was ist eine UAV?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tec Nologic 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.

Das würde ich nicht so spontan entscheiden, sondern lieber drüber 
nachdenken oder ausprobieren. Definiertes Zeitverhalten kannst du auch 
haben, wenn du es anders machst (also Regler als Task).

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.

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tec Nologic (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tec Nologic schrieb:
>> 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.

Lohnt sich das denn? Also gerade der Motor ist doch eh viel träger. Hast 
du schlechte Erfahrungen gemacht bei größeren Zykluszeiten oder hast du 
die nur vorsichtshalber so kurz gewählt? Mich interessiert das, weil ich 
auch in diesem Bereich experimentieren will. Bei mir ist es zwar kein 
UAV, aber es geht auch in die Richtung.

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

Wer ist Holger?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.