Programmstruktur RTOS

>und das in festen Intervallen

Nein.

An schrieb:
> [...]
> Bisher habe ich immer eine table-driven State Machine benutzt, ...

Dann beschäftige Dich erstmal mit weiteren Design-Patterns. Denn 
https://de.wikipedia.org/wiki/Entwurfsmuster#Nachteile

und lies bitte auch die englischen Einträge.

Ich weiss: wenn man einmal hämmern gelernt hat, sieht alles wie ein 
herausstehender Nagel aus, aber das ist ein Wahrnehmungsproblem.

Okay.

Ich formuliere die Frage anders:

Wie strukturiert ihr euer Programm bei dem Einsatz eines RTOS.

An schrieb:
> Okay.
>
> Ich formuliere die Frage anders:
>
> Wie strukturiert ihr euer Programm bei dem Einsatz eines RTOS.

:-) Dann formuliere ich die Antwort mal anders: So, dass es die Probleme 
löst.

Bei allem menschlichen Respekt vor Deiner Person: Das ist eine typische 
(Wochenend-) Rundumschlags-Frage. Lerne die Grundlagen und dann 
diskutieren wir Details.

In der Dokumentation von FreeRTOS sind mehrere 
Realisierungsmöglichkeiten für ein hypothetisches Szenario drin.

Z.B. hier als PDF: 
http://thetoolchain.com/datasheets/FreeRTOS_manual.pdf. Ist 
wahrscheinlich als HTML auch auf freertos.org drauf, hab's aber auf die 
Schnelle nicht gefunden.

An schrieb:

> Wie strukturiert ihr euer Programm bei dem Einsatz eines RTOS.

Mit möglichst wenig Tasks, z.B. eine für die eigentliche 
Steuerung/Regelung mit einer State Machine innendrin, eine für die 
Benutzerschnittstelle mit Warteschleifen für Tastatur und Bildschirm und 
eine für den Rest, z.B. Blinken Lights oder Logging. Dazu ein paar eher 
fette Interrupt-Routinen. Die müssen nicht so kurz wie möglich sein, sie 
dürfen sich nur nicht selbst überholen und die Hardware hat gefälligst 
vernünftige Interrupt-Frequenzen sicher zu stellen.

Super. Dank euch beiden.

Für alle die es interessiert: In dem Manual von Pascal geht es ab Seite 
91 los. (Nicht die Seitenzahl der Abschnitte beachten, sondern global).

Falls andere noch Input haben, gerne her damit.