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
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.
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.
>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.
> ... 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.
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.
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
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.
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.
> 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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.