Bewertung Programmierstrategie

Mache ich oft genauso. Ich verwende oft eine Kombination von Timer ISRs 
mit State Machines um den Programablauf im Time Slice Modus vollkommen 
unblockierend zu gewährleisten. Wenn man sich an diesen Programmierstil 
einmal gewöhnt hat, laufen solche Programme viel schneller als mit RTOS. 
Speziell bei bescheideneren uC lohnt sich das sehr. Die Programm Logik 
besteht dann nur noch aus Logik Evaluationen die die Funktionalität 
entsprechend steuern. Ist extrem zuverlässig und leicht erweiter- und 
veränderbar.
Works for me!

Christian schrieb:
> Was sagt ihr dazu?

Das ist eine von mehreren gängigen Vorgehensweisen. Für mich spricht 
nichts generelles dagegen.

Christian schrieb:
> ich programmiere schon etwas länger, habe Softwarearchitektur aber nie
> richtig "gelernt".
[..]
> Was sagt ihr dazu?
Hier genauso.
Ich habe mal mit Nut/OS experimentiert, habe aber dann fast zwangsläufig 
(oder zwanghaft ;-) ) einen Systick-Timer programmiert. Am Schluß war es 
ein Mix aus Threads und diesem Timer als Hauptbestandteil. War weniger 
Sinn der Sache...
Kompliziert wird es z.B. bei lwip ohne OS. Da kann man apps (z.B. sntp) 
erst nach Umschreiben nutzen, und viele Beispiele beziehen sich auf 
OS-gestützte Umgebungen. Da muß man etwas basteln.

Statemachines mit kooperativem Multitasking in der Main.

Für alles was getimed laufen muss, einen systick Timer den diese 
Machines auswerten. Klar, nicht deterministisch, aber meist ist das auch 
egal..

Harte Echtzeit dann natürlich per ISR zb mit gesondertem Timer, 
ringbuffer die die Tasks befüllen etc..

Christian schrieb:
> Die nicht
> genutzte Zeit dümpelt er in while als idle rum.

Wenn das heißt du lässt ihn in einer Schleife kreisen, dann kann man das 
je nach Prozessor und Aufgabe etwas verbessern. Man legt den Prozessor 
in eine Sleep-Modus und lässt ihn durch einen IRQ aufwecken wenn es 
wieder was zu tun gibt.

Christian schrieb:
> Was sagt ihr dazu?

Die Hauptschleife muss und sollte nicht leer sein.

Nur Sachen die zu einer bestimmten Zeit stattfinden müssen, in deiner 
Timer-Routine, bzw. in davon abgeleiteten zeitlich seltener aufgerufenen 
Funktionen, superkurz, superschnell, ggf. sogar Assembler.

Z.B. Anzeige Multiplex, Tastenabfragen, Schrittmotorpulse.

Andere Interrupts (Pin-Change, ADC Wandler fertig, Serielle 
Schnittstelle Puffer leer) bekommen andere Interrupt-Funktionen, die 
jeweils schnell fertig sein sollten.

Zeitunkritische Funktionen in der Programm-Hauptschleife, die kurzzeitig 
durchlaufen werden sollte (ich benutze sie meist zum zurücksetzen des 
Watchdog, es darf also keine Aktion länger as z.B. 1 sec dauern), und 
immer nur einen kleinen Job zu tun haben, sich aber an Variablen 
orientiert, die von den Interrupt-Routinen gesetzt werden.

Prinzip Microsoft Windows:

Das Programm läuft in der GetMessage Loop, die Hardware macht Interrupts 
und bedient die Puffer zwischen Programm und Interface, z.B. legt der 
Tastatur-Interrupt den Tastencode in einem Tastaturpuffer ab, inklusive 
Zeitstempel, und die nachfolgenden Routinen entnehmen daraus wenn 
benötigt, nicht mehr zeitsynchronisiert machen sie z.B. Umsetzung 
Tastencode in Zeichen, drücken und loslassen mit shift, all das ist 
nicht mehr zeitkritisch und wird vom Aufrufer, nicht der 
Interrupt-Routine gemacht.