yanos

uCler wrote:

> Die Lockingmechanismen fuer
> konkurierende Hardwarezugriffe wurden auch immer komplizierter.

Wie hast Du denn das gelöst ?

Bei einer Mainloop sind solche Probleme ja sehr selten, da ja alles 
immer der Reihe nach abläuft.

Aber mit Deinem OS müssen ja solche Probleme alle Nase lang auftreten, 
da ja alles virtuell parallel ist.

Insbesondere auf 8-Bittern ist ja auch Datenmurx quasi vorprogrammiert, 
bei allen globalen Variablen, die mehrbytig sind (Zeitscheibe haut genau 
dazwischen, macht nen neuen Wert und man hat dann ein neues Byte + ein 
altes Byte).

Das ist es auch, was mich vor einem OS zurückschrecken läßt.

Die möglichen Deadlock und Datenmurx-Probleme sind mit einem OS ja kaum 
beherrschbar.


Die Datenzugriffe zwischen Main und Interrupts zu sichern 
(Interruptsperre), geht ja noch.
Aber wenn plötzlich jede Maintask die andere unterbrechen kann, sieht ja 
keiner mehr durch.


Ich hab z.B. mehrere Statemachines, wo zu Anfang alle Eingänge per SPI 
eingelesen werden, dann verarbeiten das die Statemachines und dann wird 
wieder alles per SPI ausgegeben. Das kann aber nur funktionieren, wenn 
die Daten während eines kompletten Zyklus konstant bleiben.

Bzw. es können auch zwischenzeitlich Fehlerstates auftreten, die 
keinesfalls ausgegeben werden dürfen.
Erst wenn der abschließende Fehlerchecker die Daten nochmal geprüft hat, 
das kein gefährlicher Zustand entstehen kann, dann dürfen sie angelegt 
werden.


Peter

Peter Dannegger wrote:
> Das ist es auch, was mich vor einem OS zurückschrecken läßt.
>
> Die möglichen Deadlock und Datenmurx-Probleme sind mit einem OS ja kaum
> beherrschbar.
>
>
> Die Datenzugriffe zwischen Main und Interrupts zu sichern
> (Interruptsperre), geht ja noch.
> Aber wenn plötzlich jede Maintask die andere unterbrechen kann, sieht ja
> keiner mehr durch.

Dafür gibt es Synchronisationsmechanismen wie Semaphoren und Queues. 
Richtig angewendet ist damit der "Murx" gut beherrschbar.

> Ich hab z.B. mehrere Statemachines, wo zu Anfang alle Eingänge per SPI
> eingelesen werden, dann verarbeiten das die Statemachines und dann wird
> wieder alles per SPI ausgegeben. Das kann aber nur funktionieren, wenn
> die Daten während eines kompletten Zyklus konstant bleiben.

Wenn kein anderer Task in diesen Daten herumpfuscht (warum sollte er 
auch?), dann gibt es da keine Probleme.

Andreas Schwarz wrote:

> Dafür gibt es Synchronisationsmechanismen wie Semaphoren und Queues.
> Richtig angewendet ist damit der "Murx" gut beherrschbar.


Das sind dann Notlösungen, die wieder zusätzliche Ressourcen 
verbrauchen, statt das Problem zu vermeiden.

Besonders heimtückisch sind die Queues.
Wenn man da nicht 101%-ig garantieren kann, daß der empfangende Prozess 
immer schneller als der sendende ist, läuft die Queue über.
Oder sie ist sehr groß und läuft sehr voll und dann arbeitet der 
empfangende Prozess noch völlig veraltete Daten ab und z.B. Dein 
Regelkreis schwingt.

Ich habe daher bessere Erfahrungen mit einem Datenpuffer für genau einen 
Datensatz gemacht.
Wenn dann mal der Empfänger nicht nachkommt, überschreibt einfach der 
Sender den Puffer mit den aktuelleren Daten, also z.B. ein alter 
AD-Wandler Wert geht verloren und alles läuft problemlos weiter.


Peter

Peter Dannegger wrote:
> Andreas Schwarz wrote:
>
>> Dafür gibt es Synchronisationsmechanismen wie Semaphoren und Queues.
>> Richtig angewendet ist damit der "Murx" gut beherrschbar.
>
>
> Das sind dann Notlösungen, die wieder zusätzliche Ressourcen
> verbrauchen, statt das Problem zu vermeiden.

Das sind "Lösungen", keine Notlösungen.

> Besonders heimtückisch sind die Queues.
> Wenn man da nicht 101%-ig garantieren kann, daß der empfangende Prozess
> immer schneller als der sendende ist, läuft die Queue über.
> Oder sie ist sehr groß und läuft sehr voll und dann arbeitet der
> empfangende Prozess noch völlig veraltete Daten ab und z.B. Dein
> Regelkreis schwingt.
>
> Ich habe daher bessere Erfahrungen mit einem Datenpuffer für genau einen
> Datensatz gemacht.

Und was hindert dich daran das mit einem RTOS genauso zu machen? Für 
sowas einen Queue zu verwenden ist natürlich sinnlos.

> Wenn dann mal der Empfänger nicht nachkommt, überschreibt einfach der
> Sender den Puffer mit den aktuelleren Daten, also z.B. ein alter
> AD-Wandler Wert geht verloren und alles läuft problemlos weiter.

Wieso nicht gleich den Messwert im Regelungs-Task einlesen? Nur weil man 
einen Hammer (RTOS) hat darf nicht alles wie ein Nagel (Task) aussehen.

Andreas Schwarz wrote:

> Das sind "Lösungen", keine Notlösungen.

Für mich setzen Lösungen immer bei der Ursache an und Notlösungen 
bekämpfen aber nur die Wirkung.

> Wieso nicht gleich den Messwert im Regelungs-Task einlesen?

Weil ich keine Zeit verschwenden will.
Der ADC-Task ist freilaufend und kann mehrere Eingänge einlesen, glätten 
und in Puffern ablegen.
Und jede Task, die einen Wert braucht, liest ihn sofort aus dem Puffer.


Ich habe sehr gute Erfahrungen damit gemacht, daß ich alle Tasks in der 
Mainloop in einer eindeutig definierten Reihenfolge ohne gegenseitige 
Unterbrechung aufrufe.
Damit ergibt sich eine sehr geringe Fehleranfälligkeit und sehr stabiles 
Arbeiten.

Natürlich dürfen die Tasks keine Zeit vergeuden, jede Task bricht sofort 
ab, wenn sie grad nichts zu tun hat.
Und Prozesse, die erst nach einer bestimmten Wartezeit ausgeführt werden 
dürfen, übergebe ich dem Scheduler. Der ist auch eine Task in der 
Mainloop, d.h. wird auch nur zu ganz eindeutigen Zeiten ausgeführt.


Es ist halt nur ne klitzekleine Umstellung in der Programmierweise 
erforderlich, Bedingungen werden nicht wartend, sondern abweisend 
programmiert.
Also nicht: warte bis Bedingung wahr, sondern: breche ab solange 
Bedingung nicht wahr.


Peter

Peter Dannegger wrote:
> Andreas Schwarz wrote:
>
>> Wieso nicht gleich den Messwert im Regelungs-Task einlesen?
>
> Weil ich keine Zeit verschwenden will.
> Der ADC-Task ist freilaufend und kann mehrere Eingänge einlesen, glätten
> und in Puffern ablegen.
> Und jede Task, die einen Wert braucht, liest ihn sofort aus dem Puffer.

Wenn du kooperatives (also kein preemtives Scheduling verwendest), dann 
gibt es damit grundsätzlich kein Problem, weil der Kontextwechsel erst 
stattfindet wenn der ADC-Task fertig ist und sich schlafen legt.

Wenn du preemtives Scheduling verwendest (was in deinem Fall wenig Sinn 
macht), dann kannst du eine critical section verwenden um 
sicherzustellen dass der ADC-Task beim Schreiben der globalen Variablen 
nicht preemtiv unterbrochen werden kann:

taskENTER_CRITICAL();
globaler_adcwert = adcwert;
taskEXIT_CRITICAL();

> Natürlich dürfen die Tasks keine Zeit vergeuden, jede Task bricht sofort
> ab, wenn sie grad nichts zu tun hat.
> Und Prozesse, die erst nach einer bestimmten Wartezeit ausgeführt werden
> dürfen, übergebe ich dem Scheduler. Der ist auch eine Task in der
> Mainloop, d.h. wird auch nur zu ganz eindeutigen Zeiten ausgeführt.
>
>
> Es ist halt nur ne klitzekleine Umstellung in der Programmierweise
> erforderlich, Bedingungen werden nicht wartend, sondern abweisend
> programmiert.
> Also nicht: warte bis Bedingung wahr, sondern: breche ab solange
> Bedingung nicht wahr.

Damit machst du ja all das von Hand was dir ein kooperatives OS abnehmen 
kann. Statt dem Scheduler zu sagen wann die Funktion das nächste Mal 
aufgerufen werden möchte und zu returnen, hast du bei einem OS für jeden 
Task eine eigene Endlosschleife, und wenn es nichts zu tun gibt weil du 
z.B. auf den nächsten Abtastzeitpunkt für den ADC oder die Regelung 
wartest, rufst du sleep_until(t + 100) auf. Und zusätzlich hast du z.B. 
eine komfortable Möglichkeit über Queues Nachrichten zu verschicken, 
ohne dass du in jedem Empfängertask if(!neue_daten_vorhanden) return; 
machen musst, usw.

Meine Meinung ist, dass ein multitaskingfähiges OS in einem ROM ein 
totaler Overhead ist. Es sind ja alle Prozesse und Funktionen bekannt, 
ein OS zu verwenden ist eigentlich nur ein Grund, ineffizient zu 
programmieren. Anders sieht es aus, wenn zum Erstellungszeitpunkt 
"unbekannte" Prozesse später auch geladen und entladen werden sollen. 
Dann ist ein OS eine saubere Schnittstelle, gegen die auch nichts 
spricht. Zum Probieren kann man das auch im ROM machen...

Jörg

Joerg Wolfram wrote:
> Meine Meinung ist, dass ein multitaskingfähiges OS in einem ROM ein
> totaler Overhead ist. Es sind ja alle Prozesse und Funktionen bekannt,
> ein OS zu verwenden ist eigentlich nur ein Grund, ineffizient zu
> programmieren. Anders sieht es aus, wenn zum Erstellungszeitpunkt
> "unbekannte" Prozesse später auch geladen und entladen werden sollen.

Ich verstehe nicht wieso das ein Kriterium sein soll - die Vorteile 
eines RTOS, nämlich dass es einem abnimmt was Peter und viele andere von 
Hand machen, haben nichts damit zu tun ob Prozesse zur Laufzeit 
hinzugefügt/entfernt werden sollen. Das würde ja auch die 
Echtzeitfähigkeit und damit das "RT" in RTOS kaputtmachen.

uCler wrote:
...
> Der ganze IIC-Code ist in einem OS Task gekapselt.
...

Ich verstehe ehrlich gesagt überhaupt nicht, wo da das OS hilft.

Was bedeutet "I2C ist ein OS-Task" praktisch gesehen ?

Ich hätte I2C in seinen Interrupthandler gepackt und gut is.

Dann noch ein Struct definieren, in dem die Slaveadresse, Datenpointer 
und Datenlänge abgelegt werden und los geht der Interrupt.

Die Tasks, die dann I2C machen wollen, gucken nach, ob dieser Struct 
frei ist und starten dann I2C.
Oder man legt ein Array an (für jede Task ein Eintrag), das der 
I2C-Interrupt abklappert.


> Puuh - viel Text. Ein weiteres Beispiel nur noch in Stichworten. Es ist
> jetzt relativ einfach, gleichzeitig mehrere Files zu oeffnen, und quasi
> gleichzeitig zu lesen oder zu schreiben.

Hmm, Files öffnet man doch per Filehandler.
Auch in nem Single-Task-DOS kann ich mehrere Files öffnen (soviel, wie 
Handler frei sind).


Peter


P.S.:
Ein Kollege von mir, der den CAN-Bus programmiert, wollte auch gerne 
eine maximale Latenzzeit von 2ms haben.
Ich wollte aber einen 1-Wire Temperatursensor benutzen, was länger 
gedauert hätte.
Ich hab ihm dann einfach nen Timerinterrupt geschrieben, der dann 
bitweise das 1-Wire gemacht hat und dann gings wieder.
In nem Struct wurde abgelegt, wieviel Bytes nach dem 1-Wire-Reset zu 
senden sind, wieviel zu empfangen und wenn beide Zähler 0 waren, hat 
sich der Interrupt selber disabled.
Ich arbeite sehr gerne mit Interrupts.

Auch wenn ich jetzt alle Zusammenhänge nicht kenne, versuche ich mal zu 
schreiben, wie ich an die Sache herangehen würde.
Das erste Problem sind die nichtkooperativen Tasks. Sowas sollte es 
eigentlich nicht geben, ausser sie wurden von einem anderen System mehr 
oder weniger übernommen. Da es jetzt ja funktioniert, scheinen sie ja 
vorher jede Menge Zeit nutzlos verbraten zu haben. Da muß ich Falk voll 
recht geben, so etwas kann nicht besonders gut programmiert sein oder 
stammt bereits aus einem Kontext wo das nichts ausmachte.
Manchmal werden auch Dinge in Interruptroutinen verfrachtet, die dort 
nichts zu suchen haben. Muß zum Beispiel die Routine für das Touchpanel 
unbedingt im Interrupt laufen oder werden bloß über AD-Wandler die 
Koordinaten abgefragt und dann berechnet. In dem Fall könnte man 
vielleicht den ADC im 1ms-Interrupt abfragen und die Ergebnisse in den 
Speicher schreiben. Die eigentliche Berechnung der Koordinaten kann dann 
im Hauptprogramm erfolgen. Meiner Meinung nach ist es besser, über ein 
Zählregister kleinere Aufgaben im schnelleren Interrupt mit zu machen 
und dafür eine Interruptquelle weniger zu haben.
Ich programmiere viel in C, aber auf den 8-Bit Controllern bin ich damit 
überhaupt nicht warm geworden. Hier halte ich einen guten Makroassembler 
und ein paar passende Bibliotheken für die bessere Wahl. Ich will damit 
jetzt keinen Glaubenskrieg auslösen wegen Portabilität und so weiter, 
aber bis jetzt ist bei mir eigentlich bei jedem notwendigen 
Systemwechsel (warum auch immer) nur die grundsätzliche Funktionalität 
des Programms geblieben, weil man viele Dinge schon lange anders machen 
wollte...

Gruß Jörg

Peter Dannegger wrote:
> Ein Kollege von mir, der den CAN-Bus programmiert, wollte auch gerne
> eine maximale Latenzzeit von 2ms haben.
> Ich wollte aber einen 1-Wire Temperatursensor benutzen, was länger
> gedauert hätte.
> Ich hab ihm dann einfach nen Timerinterrupt geschrieben, der dann
> bitweise das 1-Wire gemacht hat und dann gings wieder.

Es gibt immer eine Möglichkeit etwas in kleine Zeitscheibchen zur 
Ausführung in Hauptschleife/Interrupt zu zerteilen, aber MANCHMAL ist 
der Aufwand einfach größer als wenn man dafür gleich ein RTOS verwendet. 
Wenn man allerdings eine ideologische Abneigung gegen RTOS mit 
Vorurteilen wie "langsam/großer Overhead/Notlösung" hat...

Andreas Schwarz wrote:

> Es gibt immer eine Möglichkeit etwas in kleine Zeitscheibchen zur
> Ausführung in Hauptschleife/Interrupt zu zerteilen, aber MANCHMAL ist
> der Aufwand einfach größer als wenn man dafür gleich ein RTOS verwendet.
> Wenn man allerdings eine ideologische Abneigung gegen RTOS mit
> Vorurteilen wie "langsam/großer Overhead/Notlösung" hat...

Ich habe leider bisher nirgends ein Beispiel gefunden, woran man die 
Vorteile eine RTOS aufm MC sehen konnte.

Das 1-Wire ist ja gerade nicht für ein RTOS geeignet.

Eine Bitzeit muß ja zwischen 60..120µs lang sein, d.h. man muß 
garantieren, daß eine zusätzliche Verzögerung höchstens 60µs betragen 
darf.

Auf dem 8051 war das ganz einfach, der T0 wurde so eingestellt, daß nach 
60µs der nächste Interrupt auftritt und ihm wurde Priorität 3 
zugewiesen, d.h. er konnte sämtliche anderen Interrupts unterbrechen.
Zusätzliche Latenzen enstehen nur dort, wo atomare Zugriffe auf 
Mehrbytevariablen erfolgen und die sind ja nur wenige µs lang.

Ein RTOS mit nur max 60µs Latenz wäre dagegen auf dem 8051 unmöglich.

Anbei mal der komplette 1-Wire Code.


Peter

Auf http://www.embedded.com gibt es viele Artikel zu dem Thema.

Z.B. zu den Nachteilen von preemtiven Systemen: 
http://www.embedded.com/showArticle.jhtml?articleID=192701173

Andreas Schwarz wrote:
> Z.B. zu den Nachteilen von preemtiven Systemen:
> http://www.embedded.com/showArticle.jhtml?articleID=192701173


Da steht leider nichts neues für mich drin.

Hast Du denn keinen Artikel pro RTOS ?


Ich geb natürlich zu, daß ich mit Assembler angefangen hab (8051, AVR).
Dadurch kann ich ziemlich gut einschätzen, wie teuer eine Task ist und 
wo ich sie dann einordnen muß (Interrupt, Mainloop, Scheduler).


Peter

Erstmal musst du lernen zwischen preemtiven und kooperativen OS zu 
unterscheiden. Das was du von Hand machst ist exakt das was ein 
kooperatives OS macht.

Andreas Schwarz wrote:

> Das was du von Hand machst ist exakt das was ein
> kooperatives OS macht.


Bloß mit dem großen Unterschied, daß ich genau bestimmen kann, in 
welcher Reihenfolge sie ausgeführt werden.

Nur bei den Tasks, die ich dem Scheduler übergebe, weiß ich die 
Reihenfolge nicht mehr, aber bei denen ist es in der Regel auch nicht 
kritisch.
Und nur diese Tasks haben dann auch den Scheduler-Overhead.


Peter

Vielleicht reden wir auch aneinander vorbei, weil jeder eine andere 
Definition von "OS" hat. Eine Kombination aus Taskmanager, Scheduler 
etc. die ich an meine Tasks anpassen muß, ist für mich kein OS. Beim uC 
wäre das (für mich) ein monolithischer Kernel, dem ich die zu 
bearbeitenden Tasks als Tabelle vorgebe (Einsprungadresse, Intervall, 
Priorität). Die Schnittstellen sind definiert und alle Tasks (auch noch 
zu schreibende ;-) müssen sich daran halten. Der Overhead entsteht bei 
der Prozessumschaltung und im Task selbst, da zumindest beim AVR zur 
Laufzeit nur Resourcen im RAM (über Pointer) zugewiesen werden können.
Richtig preemptives Multitasking geht meiner Meinung nach sowieso nur, 
wenn ein unkooperativer Task es nicht verhindern kann. Wenn aber jeder 
Task einfach die Interrupts abschalten kann, dann wird da wohl eher nix 
daraus. Oder es ist eben doch kein OS (nach meinem Verständnis)

Gruß Jörg

Joerg Wolfram wrote:
> Vielleicht reden wir auch aneinander vorbei, weil jeder eine andere
> Definition von "OS" hat.

Ein OS ist etwas, das Hardwareressourcen (=Rechenzeit) verwaltet und 
zuteilt.

> Eine Kombination aus Taskmanager, Scheduler
> etc. die ich an meine Tasks anpassen muß, ist für mich kein OS.

Dass man den Scheduler an seine Tasks anpasst wäre so ungefähr Peters 
von-Hand-Modell.

> Richtig preemptives Multitasking geht meiner Meinung nach sowieso nur,
> wenn ein unkooperativer Task es nicht verhindern kann. Wenn aber jeder
> Task einfach die Interrupts abschalten kann, dann wird da wohl eher nix
> daraus.

Anders geht es nicht, oder wie willst du sonst Hardwarezugriffe oder IPC 
realisieren, wenn überall der Scheduler dazwischenfunken kann?

Andreas Schwarz wrote:

> Ein OS ist etwas, das Hardwareressourcen (=Rechenzeit) verwaltet und
> zuteilt.

Zu den Resourcen die verwaltet und verteilt werden müssen, gehören aber 
auch Speicher und Zugriff auf die Peripherie. Bei einem Controller ohne 
umschaltbare Registerbänke kann man den Tasks viele Register zur 
Verfügung stellen, die dann natürlich auch während der Taskumschaltung 
gerettet und restauriert werden müssen (=>braucht Zeit und Speicher). 
Oder man beschränkt sich auf wenige Register und der Task muss häufiger 
auf den Speicher zugreifen.

> Anders geht es nicht, oder wie willst du sonst Hardwarezugriffe oder IPC
> realisieren, wenn überall der Scheduler dazwischenfunken kann?

Für Hardwarezugriffe gibt es OS-Routinen (z.B. BIOS). Und ein Task 
sollte die auch nutzen, anstelle selbst auf die Hardware zuzugreifen.

Ich will auch nicht den Sinn eines OS in Frage stellen, aber um das 
Timing von quasiparallel ablaufenden Funktionen in einem Mikrocontroller 
zu verbessern, halte ich es für eine schlechte Wahl.

Gruß Jörg

Joerg Wolfram wrote:
> Andreas Schwarz wrote:
>
>> Ein OS ist etwas, das Hardwareressourcen (=Rechenzeit) verwaltet und
>> zuteilt.
>
> Zu den Resourcen die verwaltet und verteilt werden müssen, gehören aber
> auch Speicher und Zugriff auf die Peripherie.
...
> Für Hardwarezugriffe gibt es OS-Routinen (z.B. BIOS). Und ein Task
> sollte die auch nutzen, anstelle selbst auf die Hardware zuzugreifen.

Die Unterscheidung zwischen Hardwaretreibern und normalen Tasks, wie man 
sie bei größeren Systemen (Linux, Windows) kennt, gibt es bei den 
kleinen Mikrocontroller-OSen nicht. Sie bestehen aus Scheduler, Timer, 
Synchronisationsmechanismen. Es geht nicht darum Hardware zu 
abstrahieren, sondern nur darum Rechenzeit zuzuteilen.