Forum: Mikrocontroller und Digitale Elektronik Methodik zur Entwicklung echtzeitfähiger Software für Embedded Systems


von Marc (Gast)


Lesenswert?

Hallo zusammen,

ich soll im Rahmen eines Projektes eine Software entwickeln, die 
Sensordaten aufnimmt und weiterverarbeitet.

Das ganze soll auf einem AVR laufen und in C programmiert sein. Die 
Nutzung eines RTOS ist ausgeschlossen.

Jetzt bin ich auf der Suche nach einer guten Einführung in die 
Entwicklung echtzeitfähiger Software auf eingebetteten Systemen. Mir ist 
es wichtig da möglichst strukturiert ran zu gehen.

Hat mir jemand einen Tipp für gute Literatur zu diesem Thema?

Grüße,

Marc

von dsgfsdfgsdfg (Gast)


Lesenswert?

jo, das GCC Tutorial:

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Links in der Menüleiste ... RTOS auf ATMega...
wär evtl. auch etwas zu hoch gegriffen für die
Aufgabe ... zumindest nach Deiner Beschreibung.
Das da immer mit Kanonen auf Spatzen geschossen
werden müssen.

von Moritz E. (devmo)


Lesenswert?

Ich denke worauf es hinausläuft ist einige Komponenten eines RTOS selbst 
nachzubilden, daher könnte es helfen, wenn du dir die Konzepte von RTOS 
und Scheduling ansiehst...

Dazu kannst du dir auch ansehen, wie minimale Scheduler und Multitasking 
Ansätze in der Codesammlung hier oder bei AVRfreaks umgesetzt wurden, 
dort habe ich auch schon einiges in der Richtung gesehen.

Je nach Anforderung reicht vielleicht schon ein einfaches Round-Robin 
Scheldung ala Mainschleife, mit kooperativem Multitasking. Signal und 
Eventkonzepte sind für Interprozesskommunikation hilfreich.

von Frank N. (arm-fan)


Lesenswert?

>Das ganze soll auf einem AVR laufen und in C programmiert sein. Die
>Nutzung eines RTOS ist ausgeschlossen.

Warum? Per Definition? Oder ist der AVR zu klein für ein RTOS?

1. Definiere erst einmal deine konkreten Echtzeitanforderungen.
2. Schaue dich nach geeigneter Hardware um.
3. Abwägen ob Benutzung eines RTOS / eigener Scheduler Implementierung.
  z.B.
   - Ggfs. größerer Controller mit mehr Speicher für RTOS.
   + Getestetes RTOS gegenüber eigenem Scheduler -> weniger 
Enticklungszeit
  u.s.w.

von tuppes (Gast)


Lesenswert?

> ... eine Software entwickeln, die
> Sensordaten aufnimmt und weiterverarbeitet.

Was ist damit gemeint? Wie kommen die Messwerte in den AVR, zu was 
werden sie weiterverarbeitet, wie oft pro Sekunde passiert das Ganze, 
was passiert nebenbei?

Um zu beurteilen, welcher softwaretechnische Aufwand angemessen ist, 
muss man wissen, wie komplex die zu erledigenden Aufgaben sind. Davon 
hängt es ab, ob man einen richtigen Scheduler braucht oder eine 
Hauptschleife und ggfs. ein paar Interruptroutinen.

> Die Nutzung eines RTOS ist ausgeschlossen.

Es kann durchaus sein, dass das gar nicht erforderlich ist.

von Moritz E. (devmo)


Lesenswert?

Was gerne vernachlässigt wird, ist für ordentliche Kapselung bzw 
Modularisierung zu sorgen, was bei Echtzeit schwieriger ist. Besonders 
zum Debuggen sind Aspektorientierte Ansätze hilfreich, in der 
Entwicklung will man ja an vielen Stellen die Daten und ihre 
Verarbeitungsergebnisse Loggen und z.B. über UART ausgeben lassen 
können, was ein typischer "cross cutting concern" ist. Die Ausgaben und 
Formatierungen zu eigene Module/Tasks zu modularisieren geht dann wieder 
in Richtung von Model-View-Controller, bzw Model-View-Presenter 
Architekturen. Das Model-Modul würde die eigentliche 
Sensordatenverarbeitung behandeln, das View Modul übernimmt dann die 
Debug-Ausgaben, und der Controller/Presenter sorgt für die Steuerung und 
Abstimmung von View und Model. Damit kann man die beiden gut Entkapseln. 
Z.b. könnte das Model-Modul Signale bei bestimmten 
Verarbeitungsschritten senden, auf die die View-Ausgabe gegebenenfalls 
über den Umweg über Controller/Presenter reagiert, anstatt im eigenen 
Task View-Funktionen aufzurufen.

von Marc (Gast)


Lesenswert?

Hallo und danke für die schnellen Antworten!

@Moritz E.: Danke für den Tip, werd ich mir gleich mal anschauen!

@Frank N.: Die Verwendung eines RTOS ist per Definition in der 
Aufgabenstellung ausgeschlossen. Ich bin mir auch nicht sicher, ob das 
Aufsetzen eines RTOS hier wirklich Sinn machen würde.

@tuppes: Mir gehts im Moment gar nicht so sehr um die konkrete Umsetzung 
(die kommt erst später). Viel wichtiger ist mir im Moment der 
Software-Engineering-mäßige Ansatz:
Wie gehe ich an eine solche Aufgabe heran?

Ich hab schon das ein oder andere Projekt im Embedded Bereich umgesetzt 
(z.T. auch mit RTOS). Allerdings war das immer so nach dem Motto "Wir 
stricken es mal zusammen und schauen dann obs irgendwo knallt".
Das möchte ich dieses Mal eigentlich nicht so machen.

Gruß

Marc

von Moritz E. (devmo)


Lesenswert?

Also zum Software-Engineering allgemein gibt es viel Literatur, ich 
denke der Strukturierte Ansatz (Anforderungsanalyse, Anwendungsfälle, 
Modellierung mit UML und so) der dir wichtig ist ist eine Allgemeine 
Frage, ob Embedded oder nicht.

Die andere Frage ist die der Softwaretechnischen Konzepte für Embedded 
und Echtzeit auf der 8-Bit Ebene.

Dazwischen stehen Software-Architekturkonzepte bzw "Patterns" die gerne 
für Embedded/Echtzeit verwendet werden, wie die Aspektorientierte 
Programmierung.

Ein Buch das soetwas vereint würde mich auch interessieren. Aber 
vielleicht wirst du fündiger, wenn du ein Buch zum Software-Engineering 
allgemein, und eins für technische Belange zu Embedded bzw RTOS nimmst.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Ich würde damit einsteigen.

Real-time Control Systems: A Tutorial
von A. Gambier
http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Ade%3Aofficial&hs=sdP&q=%22Real-time+Control+Systems%3A+A+tutorial%22+Gambier+filetype%3Apdf&btnG=Suche&meta=

Das noch ein Schritt vor dem, was du (IMHO zu speziell) suchst. Anhand 
dessen würde ich dann die Parameter/Anforderungen für das AVR System 
planen.

von tuppes (Gast)


Lesenswert?

> Viel wichtiger ist mir im Moment der
> Software-Engineering-mäßige Ansatz:
> Wie gehe ich an eine solche Aufgabe heran?

Löblich. Trotzdem noch mal die Frage, wieviel Software-Engineering 
braucht man hier überhaupt?

Für
1
while (1)
2
{
3
    get_analog_value ();
4
    little_calculation ();
5
    some_output ();
6
    wait_until_next_time ();
7
}
eher nicht so viel.

von Henry (Gast)


Lesenswert?

Zugespitzt schreibt man eine endlose Schleife so:

for (;;)
{
}

von Gastlicher (Gast)


Lesenswert?

also mir ist while true auch eher geläufig als die for-variante otsenf

von Marc (Gast)


Lesenswert?

Hallo,

@Moritz: Gute Idee, ich werde mal nach entsprechender Literatur suchen.

@Stefan: Sehr interessantes Paper, auch wenn es die Fragestellung nach 
der Herangehendsweise nicht direkt behandelt. Aber das ist echt mal ein 
gelungener Überblick über das Thema.

@tuppes: Wenn es so einfach wäre würde ich mir den Aufwand ja nocht 
machen. Es aber ca. 40 Sensoren die mit unterschiedlicher Frequenz 
abgefragt und ausgewertet werden sollen.

Grüße,

Marc

von Rik (Gast)


Lesenswert?

Hi!

Bei einem ähnlichen Problem fand ich Kapitel 3 aus dem Buch "Object 
Oriented Analysis and Design with Applications" von Grady Booch (et. 
al.) sehr hilfreich. Im Gegensatz zu anderer mir bekannter Literatur zum 
Thema ist es sehr nah an der Realität/Praxis.

Das Kapitel gibt es online:

http://www.objectmentor.com/resources/articles/Walking_through_A_UML_Design.pdf

Gruß!
Rik

von tuppes (Gast)


Lesenswert?

> Mir gehts im Moment gar nicht so sehr um die
> konkrete Umsetzung (die kommt erst später).
> Viel wichtiger ist mir im Moment der
> Software-Engineering-mäßige Ansatz:
> Wie gehe ich an eine solche Aufgabe heran?

Ein wichtiger Ansatz ist z.B. Modularisierung. Hier könnte das so 
aussehen:

Um 40 Analogsignale in einen AVR zu kriegen, brauchst du irgendein 
Bussystem, I2C, CAN, was auch immer. Die Peripherie-Ansteuerung für 
diesen Bus kommt in ein Modul, da ist praktisch nur Registergeklapper 
drin.

Das nächste Modul enthält das Protokoll, das auf dem Bus gefahren wird, 
also das Zusammenbauen von Buspaketen und die Schritte, die nötig sind, 
um ein Paket wegzuschicken oder anzunehmen.

Da hier immer wieder dieselben Schritte durchlaufen werden (Paket bauen, 
Paket losschicken, auf Antwort warten, Antwortdaten extrahieren und 
weiterreichen), könnte es ratsam sein, eine ereignis-getriebene 
State-Machine einzusetzen. State-Machines erfindet man nicht immer 
wieder neu. Man bildet hierfür ein eigenes Modul, das die Grundfunktion 
der Maschine enthält, den "Motor", der ist immer gleich.

Die Events und State-Transitions sind problemspezifisch, die definiert 
man gesondert in einer "Zustands-Tabelle" und parametriert eine 
State-Machine-Instanz damit. Hat man in der gleichen Software ein 
weiteres Problem, das sich auch mit einer Statemachine lösen lässt (z.B. 
eine Display-Ansteuerung), dann erzeugt man sich hierfür eine andere 
Statemachine-Instanz.

Und so weiter.

von Dino S. (Gast)


Lesenswert?

>Es aber ca. 40 Sensoren die mit unterschiedlicher Frequenz
>abgefragt und ausgewertet werden sollen.

Das ist alles zu vage. Ist f >= 1Hz oder f <= 1Hz?
Ohne nähere Angaben, kann man nur herumspinnen und damit weit über das 
Ziel hinausschießen.

Genauso könnte man fragen: wie komme ich am besten von A nach B?
Was ist A, was ist B? Komme ich oder gehe ich oder fahre ich? Muß ich 
schwimmen?
Eine allgemeine Antwort auf dieses Problem wäre: mit dem Hubschrauber.
Wenn A das Zuhause und B die Bäckerei ist, wäre das zuviel Aufwand um 
Schrippen zu kaufen.

von ajax (Gast)


Lesenswert?

>@tuppes: Wenn es so einfach wäre würde ich mir den Aufwand ja nocht
>machen. Es aber ca. 40 Sensoren die mit unterschiedlicher Frequenz
>abgefragt und ausgewertet werden sollen.

Das ist auch kein Problem:
1
int SensorCycleTime[40];
2
int Timer[40];
3
4
initSensorCyleTime(); // Die gewünschten Sensorlesezeiten einstellen
5
 
6
while (1)
7
{
8
  for(n=0;n<40)
9
  {
10
    Timer--;    
11
    if(Timer[n]==0)
12
        {
13
      Timer[n]=SensorCycleTime[n];
14
15
      get_analog_value (n);
16
      little_calculation (n);
17
      some_output (n);
18
    }
19
  }
20
    waitUntilFullMillisecond();
21
}

Und schon ist das Echtzeitsystem fertig ;-)

Gruß,
ajax

von Karl-heinz S. (cletus)


Lesenswert?

Marc wrote:
> Jetzt bin ich auf der Suche nach einer guten Einführung in die
> Entwicklung echtzeitfähiger Software auf eingebetteten Systemen. Mir ist
> es wichtig da möglichst strukturiert ran zu gehen.

Schlag mal die Definition von Echtzeitfähigkeit nach.

Was willst du da genau wissen?

Bitte 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
Noch kein Account? Hier anmelden.