Methodik zur Entwicklung echtzeitfähiger Software für Embedded Systems

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.

> ... 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.

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

> 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.

Zugespitzt schreibt man eine endlose Schleife so:

for (;;)
{
}

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

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

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

> 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.

>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.

>@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