Guten Morgen, da der Code meiner Bachelorarbeit mit zunehmender Systemfunktionalität mehr und mehr eine Art Spaghettiarchitektur annahm, frage ich mich ob es an der Zeit ist, das Bare-Metal-Paradigma hinter sich zu lassen und zukünftig FreeRTOS zu verwenden. Da ich viel im Low-Power-Bereich unterwegs bin, frage ich mich aber, ob die Controllerspezifischen extremen Tiefschlaffunktionen z.B. eines MSP432-P4 (kein Takt, nicht aufweckbar, GPIO-Interrupt führt zu Systemreset, dafür nur 22nA Verbrauch) mit FreeRTOS überhaupt nutzbar sind. Hat hierzu jemand Erfahrungen? Kann man allgemein sagen dass es einen Tradeoff zwischen Energieoptimierung und Systemflexibilität gibt? Grüße, Andreas
Andreas F. schrieb: > Kann man allgemein sagen dass es einen > Tradeoff zwischen Energieoptimierung und Systemflexibilität gibt? Ja das kann man schon sagen. Es fängt schon damit an, dass ein aktives Muktitasking beim Task-Wechsel viel mehr CPU Register sichern und wiederherstellen muss, als wenn das die Tasks kooperativ selber tun. Ich denke auch, dass so ein OS nicht automatisch eine bessere Programmstruktur herbei führt. Es hilft dabei villeicht, aber in erster Linie ist hier doch die Arbeit des Programmierers massgeblich.
Andreas F. schrieb: > da der Code meiner Bachelorarbeit mit zunehmender Systemfunktionalität > mehr und mehr eine Art Spaghettiarchitektur annahm, frage ich mich ob es > an der Zeit ist, das Bare-Metal-Paradigma hinter sich zu lassen und > zukünftig FreeRTOS zu verwenden. Noch im Rahmen der Bachelorarbeit? Das riecht nach kräftig Zeitaufwand... Ich würde ja tendentiell eher aufhören die Funktionalität zu erweitern. Das Thema der Arbeit nicht ausreichend einschränken dürfte einer der häufigsten Ursachen sein, nicht rechtzeitig fertig zu werden.
Andreas F. schrieb: > da der Code meiner Bachelorarbeit mit zunehmender Systemfunktionalität > mehr und mehr eine Art Spaghettiarchitektur annahm, frage ich mich ob es > an der Zeit ist, das Bare-Metal-Paradigma hinter sich zu lassen und > zukünftig FreeRTOS zu verwenden. Der Aufwand das System zu erlernen, zu strukturieren und mit den Einschränkungen klar zu kommen ist meist höher als sein Programm ordentlich zu strukturieren. Das RTOS hilft dir da nicht, macht das ganze aber komplexer. Du bist dann auch in der Hand des RTOS Machers und was er sich so gedacht hat, seine seien Intentionen auch noch so menschenfreundlich. "Free" hilft da auch nicht weiter. Ausnahme wäre der Komplexitätsgrad eines Betriebssystems so ab Android 1.0. Ne einfache Zeitscheibensteuerung bekommt man mit nem Timer und ein paar Zeitvergleichen hin. Das kann man komplett abschalten und hat die volle Kontrolle. Bei C kannst du dann alles in translation units Kapseln ohne irgendwelche Performance Einbussen.
Andreas F. schrieb: > mit FreeRTOS überhaupt nutzbar > sind. Du kannst sicher FreeRTOS für einige Zeit abschalten, aber da frage ich mich wozu dann ein Echtzeitsystem, das jederzeit eine schnelle Antwort garantieren soll. Und davon abgesehen wozu überhaupt ein solches Betriebssystem - ich würde das nur in Betracht ziehen wenn Netzwerkfunktionen wie ein TCP/IP-Stack o.ä. verlangt sind. Was aber wohl mit dem Schlafmodus sowieso nicht harmonieren würde. Georg
Ich benutze Free-Rtos, da ich einen Background-Task habe. Der braucht länger weil etwas Floating-Point Berechnung stattfindet. Den Rest habe ich in kooperiven Funktioen, die alle innerhalb bestimmter Zeit beendet sind, bzw an Interrupts gehängt. Ohne den Background-Prozess würde es auch ohne Free-RTOS gehen. Da reicht Bare-Metal. Vielleicht sollte man erst mal anfangen, den Code sauber zu strukturieren. Obekte und Klasse kapsel und saubere Parameter einführen. Sprich auch: Free-Rtos hilft dir dar nichts, ausser du brauchst nebenläufige Tasks.
Nicht aufweckbar ist mit rtos nicht vereinbarbar. Zwischen aufgeweckt und deep sleep klar, aber ohne Takt, quasi über einen reset hinaus, hilft dir kein rtos. Was es gibt, sind "ticklose" rtos, also wo kein scheduler alle x ms (oder us) läuft. Aber auch dort läuft ein Timer.
Wenn Du einen MSP432 und den TI COde Composer hast, dann sollte doch in der SimpleLink API auch ein TI RTOS rumliegen, das nur darauf wartet, benutzt zu werden. Normalerweise passt das alles relativ gut zusammen. fchk
FreeRTOS hat auch einen tickless mode, so dass der MCU nicht regelmäßig aufgeweckt werden muss. Aber das ist eher ein gefrickel ... Du kannst den jetzigen code einfach als "Event driven" deklarieren und kannst ja damit gegen FreeRTOS argumentieren :) falls du modern C++ einsetzt wäre vielelicht coroutines auch einen Blick wert, damit könnte man auch eine Art semi Nebenläufigkeit emulieren und damit seinen Code etwas besser strukturieren. Allerdings, wenn man das nicht gewohnt ist, macht es den Code meist komplexer
PittyJ schrieb: > Ohne den Background-Prozess würde es auch ohne Free-RTOS gehen. Da > reicht Bare-Metal. Ich habe in Bare-Metal auch einen Background-Prozess. Sogar mehrere preemptive mit unterschiedlicher Priorität, wenn ich das will. Sogar auf einer AVR8-Architektur. Man muss einfach nur programmieren können, dann ist das alles kein Problem. Sprich: statt der akademischen Abstraktionen die Hardware verstehen. Wobei die Formulierung "statt" nicht ganz korrekt ist, es geht natürlich darum, die akademische Abstraktion möglichst effizient auf konkrete Hardware umzusetzen. Und das klappt am besten, wenn ein "OS" garnicht existiert. Denn das hat im allgemeinen den Anspruch, auf mehr als einer Architektur zu laufen. Lobenswert, hat aber den Nachteil, auf der konkreten Zielarchitektur mit an Sicherheit grenzender Wahrscheinlichkeit suboptimal zu sein... So einfach ist das.
Andreas F. schrieb: > da der Code meiner Bachelorarbeit mit zunehmender Systemfunktionalität > mehr und mehr eine Art Spaghettiarchitektur annahm, frage ich mich ob es > an der Zeit ist, das Bare-Metal-Paradigma hinter sich zu lassen und > zukünftig FreeRTOS zu verwenden. Es ist ein typischer Anfängerfehler, Komplexität einfach mit noch mehr Komplexität zu erschlagen. Wenn Deine Systemarchitektur schon zu unübersichtlich ist, nützt es überhaupt nichts, einfach noch ein paar weitere Komponenten hinzuzufügen, für die die Architektur erst recht nicht vorgesehen ist. Früher(tm) war ich auch ein großer Fan von RTOS, und sie haben natürlich auch ganz klar ihre Daseinberechtigung. Mittlerweile setze ich auf Microcontrollern aber überwiegend wieder auf Bare-Metal-Implementierungen. Natürlich geht dies nur, wenn man keine "Langläufer" hat, die sich nicht einfach unterbrechen lassen.
Andreas S. schrieb: ... > Es ist ein typischer Anfängerfehler, Komplexität einfach mit noch mehr > Komplexität zu erschlagen. ... Wen den Fehler nur Anfaenger machen wuerden...
Uwe B. schrieb: > Andreas S. schrieb: > Wen den Fehler nur Anfaenger machen wuerden... "Der Profi" malt dann zusätzlich noch einen Haufen Powerpoint-Folien und verlagert die unnötige Komplexität lieber auf die organisatorische Ebene.
Roland D. schrieb: > FreeRTOS hat auch einen tickless mode, so dass der MCU nicht regelmäßig > aufgeweckt werden muss. Aber das ist eher ein gefrickel ... Das ist eigentlich ideal für seine Anwendung. Nur braucht es dann (wie ich schon schrieb) einen Timer, egal ob intern oder extern.
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.