www.mikrocontroller.net

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


Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: dsgfsdfgsdfg (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Frank N. (arm-fan)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Moritz E. (devmo)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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...

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.

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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
while (1)
{
    get_analog_value ();
    little_calculation ();
    some_output ();
    wait_until_next_time ();
}
eher nicht so viel.

Autor: Henry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zugespitzt schreibt man eine endlose Schleife so:

for (;;)
{
}

Autor: Gastlicher (Gast)
Datum:

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

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Rik (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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/Wal...

Gruß!
Rik

Autor: tuppes (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Dino S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: ajax (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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:
int SensorCycleTime[40];
int Timer[40];

initSensorCyleTime(); // Die gewünschten Sensorlesezeiten einstellen
 
while (1)
{
  for(n=0;n<40)
  {
    Timer--;    
    if(Timer[n]==0)
        {
      Timer[n]=SensorCycleTime[n];

      get_analog_value (n);
      little_calculation (n);
      some_output (n);
    }
  }
    waitUntilFullMillisecond();
}

Und schon ist das Echtzeitsystem fertig ;-)

Gruß,
ajax

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht 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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.