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