Benutzt ihr ein Betriebssystem auf dem uC?

Johannes schrieb:
> Habe bisher immer nur
> die standard main-funktion mit while(1) erstellt.

Hat dein µC keinen Timer, der regelmäßig auszuführende Tasks anstößt?

Nein.

Johannes schrieb:
> Gerade im
> Mikrocontrollerbereich, ist mir eigentlich noch nie ein Beispiel
> untergekommen, wo man so etwas verwenden könnte

Multi-Tasking mit Ethernet und weiteren Kommunikationsschnittstellen 
wäre ein Fall, wo ein OS nützlich sein kann.

Johannes schrieb:
> Habe bisher immer nur
> die standard main-funktion mit while(1) erstellt.

Wenn du das auf einem ESP mit dem Arduino-Umgebung gemacht hast, dann 
hast du bereits sehr wahrscheinlich ein RTOS genutzt, ohne es zu wissen. 
Was sagt dir das?

Wolfgang schrieb:
> Hat dein µC keinen Timer, der regelmäßig auszuführende Tasks anstößt?

Doch, der hat aber keine Tasks angestoßen, da ich bisher noch nie 
mehrere hatte.

Eduardo schrieb:
> Wenn du das auf einem ESP mit dem Arduino-Umgebung gemacht hast, dann
> hast du bereits sehr wahrscheinlich ein RTOS genutzt, ohne es zu wissen.
> Was sagt dir das?

Habe es noch nie in der Arduino umgebung gemacht.

Stefan ⛄ F. schrieb:
> Multi-Tasking mit Ethernet und weiteren Kommunikationsschnittstellen
> wäre ein Fall, wo ein OS nützlich sein kann.

Hast du auch ein genaues Beispiel? Mir fehlt noch so ein Beispiel um das 
besser nachvollziehen zu können. Warum muss so etwas multi-tasking fähig 
sein?
Daten die übers Ethernet reinkommen können ja in einem Struct 
gespeichert werden. Gleiches mit Daten über anderer 
Kommunikationsschnittstellen (z.B. CAN). In der main-loop kann dann 
alles abgearbeitet werden.

Wenn man kein RTOS hat, dann macht man viele Dinge (z.B. Kommunikation, 
hochpriore Tasks) im Interrupt.

Typische Beispiele, wo ein RTOS mit Tasks sinnvoll sind:

 * Module in der Loop, die deutlich unterschiedlichen Takt haben
 * blockierende GUI (wo z.B. direkt auf einen Tastendruck gewartet wird)
 * sehr langsame Prozesse (Abarbeitung in einer Hintergrund-Task)
 * Nutzung fremder Module, die nicht als SPS-Loop arbeiten.

Wenn man Anfängt, deutlich allgemeinen Code in Interrupts zu 
verschieben, ist es Zeit, über ein RTOS nachzudenken.

Johannes schrieb:
> Hast du auch ein genaues Beispiel? Mir fehlt noch so ein Beispiel um das
> besser nachvollziehen zu können. Warum muss so etwas multi-tasking fähig
> sein?

Ein Webserver zum Beispiel kann Webseiten über mehrere Verbindungen 
gleichzeitig ausliefern. Browser laden z.B. mehrere Bilder parallel, 
während die Seite geladen wird.

Oder stelle dir eine smarte Lampe an, die von allen Familienmitglieder 
per Smartphone geschaltet wird. Da muss die Lampe mehrere Verbindungen 
gleichzeitig zulassen.

UDP giegne auch (ohne Verbindungen), aber das würde Web-Interface 
ausschlißeen.

Mal bisschen Grundlagenwissen aneignen, das gibts heute wohl nicht mehr?

Fire H. schrieb:
> Ich trenne die Computeranwendungen in Low-Level und High-Level
> Anwendungen.

Die Welt ist nicht schwarz-weiß.
Es gibt Zwischendinge zwischen Multicore Programmierung in C++ und 
Bitzchieberei in Assembler.

> Stefan ⛄ F. schrieb:
>> Ein Webserver zum Beispiel kann Webseiten über mehrere Verbindungen
>> gleichzeitig ausliefern. Browser laden z.B. mehrere Bilder parallel,
>> während die Seite geladen wird.

Andreas S. schrieb:
> Es ist möglich und auch gängige Praxis, mit einem Prozess/Thread/Task
> mehrere Netzwerkverbindungen gleichzeitig zu bedienen.

Ja Andreas. Man kann alles widerlegen. Der TO hatte nach einem Beispiel 
für den Einsatz eines OS gefragt, und dafür war es ein sehr gutes 
Beispiel. Man kann ALLES ohne OS programmieren, genau so wie man jeden 
Ort der Welt ohne Auto erreichen kann. Dennoch ist die Fahrt in den 
Urlaub ein gutes Beispiel, wozu Autos gut sind.

Stefan ⛄ F. schrieb:
> Dennoch ist die Fahrt in den Urlaub ein gutes Beispiel, wozu Autos
> gut sind.

... jedenfalls, falls man gewillt ist, seinen möglichen Urlaubsort auf 
größenordnungsmäßig weniger als 1 Prozent der Erdoberfläche 
einzuschränken.

Johannes schrieb:
> Oder ist ein Betriebssystem für ein Controller to much?

RTOS gab und gibt es zwar auch für AVR, aber wenn man jedes Byte zählen 
muss dann macht das keinen Spaß.
Mit den aktuellen Cortex-M oder den Tensilica sieht das schon anders 
aus. Auf den CM mache ich daher alles mit Mbed-OS, da ist RTX als RT 
Kern drin. Das kostet schon einigen Overhead weil auch gleich die Newlib 
statt Newlib Nano verwendet werden muss. Da fängt der Spaß z.B. bei den 
STM32F4 an, was aber auch kein Problem ist weil so ein fertiges Modul 
wie Blackpill mit F401/F411 auch nur ca. 5 € kostet, oder ein F407 Board 
mit Display ca. 20 €.
Mit RTOS kann man einiges aufgeräumter machen, z.B. langsamen GUI 
Thread, schnellem IOThread und weitere für Kommunikation. Ein 
Interruptsystem sehe ich da als RTOS für Arme, das braucht zwar weniger 
Resourcen, wird aber schnell chaotisch weil nix blockieren darf. Und ein 
RTOS ist nicht nur für Timingfunktionen da, es bringt auch Semaphore, 
Queues und Threads mit Prioritäten mit.
Threads brauchen vor allem mehr RAM weil jeder einen eigenen Stack 
bekommt und auch Kontextwechsel kosten Zeit. Alternativ kann man auch 
mit EventQueues arbeiten. Das geht bei Mbed sehr elegant weil man 
einfach Callbacks in die Queue werfen kann. Man kann dann auch den RTOS 
Teil weglassen, wieder die Newlib Nano benutzen und schon passt es 
wieder in kleinere Controller.
Das läuft leider nicht auf den ESP weil die keinen ARM Kern haben und in 
der Espressif Firmware auch schon das FreeRTOS werkelt.

Weiter oben hat jemand Protothreads genannt. Die habe ich mal in 
Kombination mit einem Webserver verwendet. Ehrlich gesagt will ich damit 
nie wieder arbeiten müssen. Damit korrekte Programme zu schrieben, 
empfinde ich als sehr mühsam.

Aaaaaaber: Es war sehr lehrreich, damit zu arbeiten. Insofern ist es 
vielleicht doch nicht so verkehrt, es wenigstens einmal auszuprobieren 
(ist wie mit Assembler).

Zu dem Thema hatte ich mal einen Aufsatz geschrieben: 
http://stefanfrings.de/net_io/protosockets.html

Die Protothreads sind ja eine leichtgewichtige Alternative zu einem 
'richtigen' RTOS und es gab nicht immer so fette Cortex-M. Dafür war das 
schon cool was der Adam da gezaubert hat, aber heute möchte ich sowas 
auch nicht mehr anpacken.

Johannes S. schrieb:
> Die Protothreads sind ja eine leichtgewichtige Alternative zu einem
> 'richtigen' RTOS

Und genau das sorgt dafür, dass das Konzept weiterhin (z.B. für die 
kleinen AVR) interessant bleibt.

Dem Dunkel sein Ding, etwas umgemodelt, passt fein in die Arduino Welt.

Andreas S. schrieb:
> Entscheidend ist dabei vor allem, dass eine RTOS entgegen vielfältiger
> Annahmen eben nicht ein Echtzeitverhalten aus dem Nichts herbeizaubern
> kann, sondern ganz im Gegenteil muss jeder Programmteil so ausgelegt
> sein, dass er das Echtzeitverhalten des Gesamtsystems nicht stört.

Vor allem im Embedded-Bereich geht es oft um: SPS-basiert oder 
Event-basiert. Mit dem Ergebnis, dass Event-basiert schön einfach und 
straight ist, in der Praxis aber dann ganz schnell zu komplex und 
fehleranfällig wird. Und  nur dort gut performt, wo es nicht drauf 
ankommt, nämlich im "Normal-Betrieb".

Ich nehme Free RTOS auf meinem ARM-M0.
Ich würde es jetzt nicht als Betriebssystem bezeichnen, dafür kann es zu 
wenig.
Aber es hilft mir wunderbar, wenn ich zwei oder drei Tasks mit 
unterschiedlicher Priorität habe.
Der Rest ist Bare Metal.