Komplexe Embedded Software

Deine Probleme sind nicht embedded-spezifisch. Du hast ganz normale 
Projektmanagement-, Projektplanungs-, Entwurfsmethoden-, 
Team-Organisations-, API-Entwicklungsproblem.

Darüber gibt es ganze Bibliotheken. Such dir halt was aus. Wenn moeglich 
etwas, was was taugt. Unabhängig von den Büchern, etwas Talent bei der 
Sache hilft ungemein.

Nicht neu schrieb:
> Du hast ganz normale
> Projektmanagement-, Projektplanungs-, Entwurfsmethoden-,
> Team-Organisations-, API-Entwicklungsproblem.
>
> Darüber gibt es ganze Bibliotheken.

Ja, das ist mir bekannt. Nur leider klären diese nie über praktische 
Umsetzung im Code auf, das ist ja mein Knackpunkt.

Oh ok danke avrGerd. Ich werde mir das Buch mal ansehen. Kann jemand 
noch eine kleine, grobe Lösung (Schnittstelle oder Verknüpfung) zu 
meinem Beispiel geben, das würde mich brennend interessieren, wie ihr 
sowas lösen würdet! :D

MFG

Wirf mal einen Blick in das hier:
"Modellierung von eingebetteten Systemen mit UML und SysML",
ISBN: 978-3-8274-1690-2
Ist eine ziemlich komplette Entwicklungsabahndlung am Beispeil eines 
Multimedia(MP3)-Players mittels UML2. Meiner Meinung nach schreibt der 
Autor von Teilen einer realen Entwicklung in seinem Unternehmen.
Generell würde ich dir dann auch zu UML2-Literatur raten, was deine 
Entwickler natürlich auch lernen sollten - falls nicht schon geschehen. 
Damit läßt sich die Schnittstellenbeschreibung sehr gut modellieren und 
du kannst vor dem Start der Programmierung schon die meisten Denkfehler 
eliminieren. Ein Buch auf deutsch dazu, was ich auf jeden Fall empfehlen 
kann, ist
"UML 2 glasklar", ISBN: 978-3-4464-3057-0

Interessent schrieb:
> Kann jemand
> noch eine kleine, grobe Lösung (Schnittstelle oder Verknüpfung) zu
> meinem Beispiel geben, das würde mich brennend interessieren, wie ihr
> sowas lösen würdet!

Okay, hier ein paar Tips.
1. Überlege Dir mehrere Ebenen (ähnlich dem ISO/OSI-Modell), in die Du 
Dein Projekt gliedern möchtest. Ganz unten die Hardware-Treiber, ganz 
oben die Anwendung. Die Abstraktion nimmt mit jeder Ebene zu.
Ziel ist, daß eine Funktion wie z.B. printf() nichts darüber wissen muß, 
wie Deine Debug-Schnittstelle aussieht, d.h. ob das über einen UART oder 
ein LCD oder was auch immer geht.
2. Jede Ebene und auch jedes Modul muß maximal gekapselt sein. Führ nur 
die Schnittstellen nach außen, wie wirklich unbedingt notwendig sind. 
Schnittstellen nach Möglichkeit in einer Struktur zusammenfassen.
3. Benutze lieber Methoden als Variablen.
Z.B. so etwas wie "if (Methode_UART_Is_Free() == true)" and statt "if 
(Variable_UART_Is_Free == true)". Damit kannst Du sicherstellen, daß 
niemand von außen in ein Modul hineinpfuscht (den Inhalt von Variablen 
kann man von überall überschreiben, den Rückgabewert einer Methode 
nicht).
Kostet etwas Code und Laufzeit, ist aber sicherer.
4. Mach im Header-File eines Moduls nur das sichtbar, was wirklich 
unbedingt notwendig ist. Ggf. ein internes (z.B. mit modulinternen 
defines) und ein externes Header-File (mit den Schnittstellen) anlegen. 
Die anderen Module sehen nur das externe Header-File.
Es ist z.B. nicht notwendig, daß außerhalb der Hardware-Kapsel-Ebene ein 
Controller-SFR sichtbar ist. Das würde nur zum Umgehen der Struktur 
verführen.
5. Verbiete strikt jegliche Umgehung der Strktur! Kein schnelles 
Patchen, kein schneller Hack zu Debuggen. Wenn die Struktur durchdacht 
ist, brauchst Du das nicht.
6. Denke an Wiederverwendbarkeit. Die unteren Ebenen wirst Du immer 
wieder verwenden können.

Das Thema ist aber zu komplex um es mit ein paar Tips zu erschlagen.

Ok, wie sieht dann dabei die Hierachie aus? Laut OSI-Modell von oben 
nach unten. Wenn wir uns vorstellen Entwickler B hätte den Stack 
vorcompiliert und würde ihn dann an Entwickler A geben. Also konnte 
Entwickler B in seinen Code noch keine Sende-Funktion ala UARTput 
einbauen. Nun müsste ja der Stack immer von der UART aufgerufen werden 
(wenn ich das nicht falsch sehe) und das ganze System kippt hinten rüber 
und sieht wieder nach einer kreuz und quer Bastellösung aus. Einer muss 
den Anderen initieren...das ist so das Verständnisproblem.

MFG

Interessent schrieb:
> Wenn wir uns vorstellen Entwickler B hätte den Stack
> vorcompiliert und würde ihn dann an Entwickler A geben. Also konnte
> Entwickler B in seinen Code noch keine Sende-Funktion ala UARTput
> einbauen.

Falsch!
Bevor irgendeiner drauflos programmiert, habt Ihr die Schnittstelle 
definiert. D.h. die Schnittstellen zu allen benötigten Modulen sind 
schon da. Ob die benötigten Module schon da sind, ist eine andere Frage.

Wenn Du ein Haus baust und noch keine Fenster hast, mauerst Du dann die 
Wand zu und haust später ein Loch rein, oder läßt Du von Anfang an ein 
Loch für die Fenster frei?
Daher braucht man den Plan, bevor man mit dem Mauern loslegt.

Udo Schmitt schrieb:
> Oder kommst du direkt von der Uni?

Könnte man so sagen, ja. Auf jedenfall habe ich bis jetzt nur weniger 
komplexe Software entwickelt und suche da nach Input um mich weiter zu 
entwickeln. Auf der Fachhochschule haben wir sowas nie gemacht. 
Software-Engenieering schon, aber UML hilft mir da gerade nicht weiter.

Pako schrieb:
> Bevor irgendeiner drauflos programmiert, habt Ihr die Schnittstelle
> definiert. D.h. die Schnittstellen zu allen benötigten Modulen sind
> schon da. Ob die benötigten Module schon da sind, ist eine andere Frage.

Ok, richtig. Entwickler A und B haben die Schnittstellen erfolgreich 
ausgetauscht, die Softwarekomponenten zusammengefügt. Das Projekt ist 
abgeschlossen. Nun wird der Stack von Entwickler B auf einer anderen 
Maschine gebraucht, somit stehen die Schnittstellen von beiden Systemen 
fest, passen aber nicht zueinander. Nun wird die UART von dem neuen 
System auf den Stack angepasst? Der Stack wird auf die UART angepasst? 
Oder beide ein bisschen? Hat hier ein Modul Vorrecht?

Ich komme auf die Idee, wenn ich an eine Anwendung auf Betriebssytem 
Ebene denke. Dort sind die Hardwareschnittstellen immer definiert und 
die Software wird auf die Treiberschnittstellen programmiert.

MFG

Gerd M. schrieb:
> Wenn Du dass machst, dann kann jeder Entwickler seinen Teil des Codes
> schreiben und VOLLSTÄNDIG Testen OHNE dass sie voneinander den Code
> kennen.
> Du kannst sogar Hardware Testen, die noch nicht existiert ...

Genau das ist das Ziel, kann mir gerade nur die Schnittstelle nicht 
vorstellen, wenn diese nicht aus Code besteht. Jeder Entwickler muss ja 
etwas implementieren und dazu den "Code" der Schnittstelle kennen.

Ganz vereinfacht und abstrakt gesehen gibt Entwickler A die Definition 
von UARTput() zu Entwickler B.

Entwickler B gibt Entwickler A eine Definition von DecodeDataframe() was 
von der UART aufgerufen werden kann.

Nur in diesem Fall haben die Entwickler schon Code ausgetauscht.

MFG

Bevor man komplexe Programme mit einiegen Leuten schreibt sollte man 
Erfahrung mit kleinen Projekten gesammelt haben. Mach das erst mal. 
Sonst wird da nichts draus.

Pako schrieb:
> Daher braucht man den Plan, bevor man mit dem Mauern loslegt.

Genau. Und das läßt sich beispielsweise wunderbar mit UML 2 abbilden, 
weil es dann unabhängig von Systemen und Programmiersprache definiert 
werden kann. Jeder Modulprogrammierer bekommt seine Portion davon und 
der Überblick bzw. das zentrale UML-Konstrukt bleibt bei dir.

Interessent schrieb:
> Software-Engenieering schon, aber UML hilft mir da gerade nicht weiter.
Wieso nicht? Diese Meinung hatte ich vorher auch, bevor ich mich mal 
tiefer in UML einarbeiten mußte. Die Vorteile habe ich oben schon 
beschrieben. Und eine graphische Abstraktion hilft dem Verständnis. 
Anders kann man meiner Meinung nach keinen Überblick bei komplexen 
Systemen bewahren.

Interessent schrieb:
> Nun wird der Stack von Entwickler B auf einer anderen
> Maschine gebraucht, somit stehen die Schnittstellen von beiden Systemen
> fest, passen aber nicht zueinander. Nun wird die UART von dem neuen
> System auf den Stack angepasst? Der Stack wird auf die UART angepasst?
> Oder beide ein bisschen? Hat hier ein Modul Vorrecht?

Wenn Du den Staubsauger in eine Steckdose steckst, ist die Schnittstelle 
klar. Du kannst den Staubsauger in jede kompatible Steckdose stecken. 
Und zwar unabhängig davon, ob diese Steckdose in der Küche oder im Bad 
ist.
Natürlich kannst Du den Staubsauger nicht in eine klingonische 
1200A-Steckdose stecken, aber dafür wurde er auch nie geplant.

Wenn Entwickler X einen Stack programmiert, dann soll dieser Stack ein 
in sich abgeschlossenes Paket sein. D.h. der Stack und seine 
Schnittstellen müssen so konzipiert sein, daß es ihm völlig egal ist, 
was jenseits der Paketgrenzen passiert, solange nur seine Schnittstellen 
korrekt bedient werden. Ob da jetzt ein UART drann hängt oder ein SPI 
oder ein WLAN, ist völlig egal, solange die Schnittstellen korrekt 
bedient werden.
Der Trick ist nun, die Schnittstellen so zu planen, daß sie universell 
verwendbar sind. Da ist Erfahrung gefragt ;)

Naja, was ändert sich? Der Stack oder die Treiber der UART?
In deinem Fall ja nur das Ansprechen der UART.
Der Stack verändert sich in den oberen Layern dann eigentlich gar nicht 
mehr, sondern nur der Treiber der UART muss angepasst werden.

So wie Pako beschrieben hat, kannst Du das dann ja machen. zB im Stack 
könnte man functionpointer verwenden, zu Beginn legst Du die pointer 
dann auf die jeweiligen readfunctions. Wenn die jetzt nicht 
implementiert sind kannst/musst Du ja noch eine Zwischenschicht 
einziehen.

Interessent schrieb:
> Jeder Entwickler muss ja
> etwas implementieren und dazu den "Code" der Schnittstelle kennen.

Nein er muss die Schnittstelle kennen... ZB im Fall von der verwendung 
von functionpointern wäre die Schnittstelle die bekannt sein muss der 
returnwert und die parameter der funktion auf die der Functionpointer 
zeigt.

Interessent schrieb:
> Genau das ist das Ziel, kann mir gerade nur die Schnittstelle nicht
> vorstellen, wenn diese nicht aus Code besteht. Jeder Entwickler muss ja
> etwas implementieren und dazu den "Code" der Schnittstelle kennen.
Zuerst überlegst Du Dir, welche Informationen und Funktionen Du 
austauschen willst.
Dann legst Du fest, wie Du diese Informationen und Funktionen benennen 
willst (in C-Syntax).
Das macht aber nicht irgendein Programmierer für jedes Modul 
willkürlich, sondern das macht der zentrale Software-Architekt.

> Ganz vereinfacht und abstrakt gesehen gibt Entwickler A die Definition
> von UARTput() zu Entwickler B.
Nein! Der Software-Architekt legt diese Definition vorher fest.

> Entwickler B gibt Entwickler A eine Definition von DecodeDataframe() was
> von der UART aufgerufen werden kann.
Nein! Der Software-Architekt legt diese Definition vorher fest.

Pako schrieb:
> Interessent schrieb:
>> Genau das ist das Ziel, kann mir gerade nur die Schnittstelle nicht
>> vorstellen, wenn diese nicht aus Code besteht. Jeder Entwickler muss ja
>> etwas implementieren und dazu den "Code" der Schnittstelle kennen.
> Zuerst überlegst Du Dir, welche Informationen und Funktionen Du
> austauschen willst.
> Dann legst Du fest, wie Du diese Informationen und Funktionen benennen
> willst (in C-Syntax).
> Das macht aber nicht irgendein Programmierer für jedes Modul
> willkürlich, sondern das macht der zentrale Software-Architekt.
>
>> Ganz vereinfacht und abstrakt gesehen gibt Entwickler A die Definition
>> von UARTput() zu Entwickler B.
> Nein! Der Software-Architekt legt diese Definition vorher fest.
>
>> Entwickler B gibt Entwickler A eine Definition von DecodeDataframe() was
>> von der UART aufgerufen werden kann.
> Nein! Der Software-Architekt legt diese Definition vorher fest.

Ok so hatte ich mir die ganze Sache auch gedacht, vllt habe ich mich ein 
wenig schlecht ausgedrückt. Also werden vorher alle Parameter, 
Rückgabewerte und Container definiert "vom Software-Architekt". Dies ist 
dann die "Schnittstelle". Im Prinzip das gleiche, wie wenn man selbst 
ein größeres Projekt implementiert, der Software-Architekt definiert und 
die Entwickler setzen nach diesen Vorgaben den Code um. In einem 
Einzelprojekt ist man dann Architekt und Entwickler.


Gerd M. schrieb:
> Wenn Du dass machst, dann kann jeder Entwickler seinen Teil des Codes
> schreiben und VOLLSTÄNDIG Testen OHNE dass sie voneinander den Code
> kennen.
> Du kannst sogar Hardware Testen, die noch nicht existiert ...
Wie sieht das in der Praxis aus? Ich Teste mein Software-Modul und 
beobachte die Schnittstellen?


Schon mal danke an Alle für Eure Hilfe!!

MFG

Interessent schrieb:
> Ok so hatte ich mir die ganze Sache auch gedacht, vllt habe ich mich ein
> wenig schlecht ausgedrückt. Also werden vorher alle Parameter,
> Rückgabewerte und Container definiert "vom Software-Architekt".

Ja, und der Trick ist, die richtigen Schnittstellen zu finden.

Ich höre bei z.B. heraus, daß Du Deinen Stack immer im Zusammenhang mit 
Deinem UART siehst. Du mußt aber die Pakete getrennt und für sich 
betrachtet. Der Stack soll nichts von einem UART wissen. Der soll mit 
"irgendjemandem" seine Daten austauschen, und wer das ist, darf für ihn 
nicht relevant sein.

Interessent schrieb:
> Wie sieht das in der Praxis aus? Ich Teste mein Software-Modul und
> beobachte die Schnittstellen?
Ganz genau.
Angenommen Du programmierst eine CRC-Berechnungsfunktion für einen 
Microcontroller. Was spricht dagegen, sie auf dem PC zu entwickeln, weil 
man dort kann viel besser debuggen kann?
Geht natürlich nur dann, wenn sie korrekt gekapselt ist, d.h. wenn 
keiner in der CRC-Funktion plötzlich zum Debuggen auf einen UART 
schreibt, der nur im µC verhanden ist, aber nicht auf dem PC.

Einen schönen Guten Morgen an Alle!!

Pako schrieb:
> Ich höre bei z.B. heraus, daß Du Deinen Stack immer im Zusammenhang mit
> Deinem UART siehst. Du mußt aber die Pakete getrennt und für sich
> betrachtet. Der Stack soll nichts von einem UART wissen. Der soll mit
> "irgendjemandem" seine Daten austauschen, und wer das ist, darf für ihn
> nicht relevant sein.

Jetzt bin ich wieder aus dem Konzept :D. Das Ziel ist es nichts von dem 
anderen Paket zu wissen, so wie du das beschreibst. Allerdings muss ja 
z.B. der Stack den Übertragungsdienst ob UART, SPI oder Rauchzeichen 
antriggern damit die vorher zusammengestellten Frames übertragen werden 
können. Der Software-Architekt hat vorher die Schnittstellen definiert, 
also würde der Entwickler für den Stack in seinen Code ein 
UARTsend(&Data) implementieren, was in diesem Fall die Schnittstelle 
wäre. Leider weiß er jetzt etwas von der UART. Um die Software-Pakete 
wirklich getrennt von einander entwicklen zu können ohne, dass der eine 
von dem Anderen weiß könnte ich mir höchstens sowas wie eine Middelware 
vorstellen, welche die beiden Pakete anhand der Schnittstellen 
verknüpft. Allerdings müssen dann drei Pakete geschrieben werden.

MFG

Interessent schrieb:
> Jetzt bin ich wieder aus dem Konzept :D. Das Ziel ist es nichts von dem
> anderen Paket zu wissen, so wie du das beschreibst. Allerdings muss ja
> z.B. der Stack den Übertragungsdienst ob UART, SPI oder Rauchzeichen
> antriggern damit die vorher zusammengestellten Frames übertragen werden
> können. Der Software-Architekt hat vorher die Schnittstellen definiert,
> also würde der Entwickler für den Stack in seinen Code ein
> UARTsend(&Data) implementieren, was in diesem Fall die Schnittstelle
> wäre. Leider weiß er jetzt etwas von der UART. Um die Software-Pakete
> wirklich getrennt von einander entwicklen zu können ohne, dass der eine
> von dem Anderen weiß könnte ich mir höchstens sowas wie eine Middelware
> vorstellen, welche die beiden Pakete anhand der Schnittstellen
> verknüpft. Allerdings müssen dann drei Pakete geschrieben werden.

Okay, denken wir das mal durch:

1. Du baust in den Stack also ein "UARTsend()" ein. Dein Microcontroller 
hat jetzt vier UARTs. Also gibt es kein allgemeines "UARTsend()", 
sondern UART1send(), UART2send() usw.
Welchen UART benutztet Du im Stack? Willst Du 4 verschiedene 
Stack-Varianten schreiben, für jeden UART eine separate?
Das kann doch nicht zielführend sein.

2. Du baust in den Stack ein "UARTsend()" ein und hast irgendwo ein 
Mapping, welcher UART von eben diesem "UARTsend()" verwendet wird. Das 
ist nun schon deutlich besser, denn der Stack bleibt für alle vier UARTs 
identisch, Du mußt ihn nur noch konfigurieren, welchen UART er 
verwenden soll.

3. Du baust in den Stack ein "Send()" ein und hast irgendwo ein Mapping, 
welches dieses "Send()" mit einer beliebigen 
Kommunikationsschnittstelle (UART, SPI usw.) verknüpft. Denn Du warst so 
clever, daß diese Send()-Schnittstelle so universell gehalten ist, daß 
sie sowohl mit UART, SPI und Rauchzeichen funktioniert und keinerlei 
Abhänigkeiten zu irgendwelchen Hardware-Eigenschaften hat.
Nun mußt nur noch konfigurieren, welche Kommunikationsschnittstelle 
verwendet wird.

Der Trick ist: mach Deine Module universell, unabhängig von einander und 
konfigurierbar, um so aufeinander abstimmen zu können.


Wie macht man nun dieses Mapping?
Verschiedene Möglichkeiten wären z.B.:

1. Du baust eine eigene "Routing-Ebene" zwischen den Stack und die Ebene 
mit den Hardware-Schnittstellen.

2. Du siehst im Stack eine Konfigurationsdatei (z.B. "stack_config.h") 
vor, in der die "Send()"-Schnittstelle (z.B. per #define) der 
"UART3send()"-Funktion zugeorndet wird. Hier kannst Du per #ifdef 
wunderschöne Blöcke bilden, so daß Du am Ende nur noch an einer Stelle 
konfigurieren mußt "Stack benutzt UART3" und alle Schnittstellen werden 
in Folge korrekt zugeordnet.

3. Du baust Dir Perl-Skripte, die Dir aus XML-Konfigdateien C-Code 
erzeugen (so macht es ein großer Automobilzulieferer).

4. usw.


Wie Du es letztendlich lösen willst, hängt von verschiedenen Faktoren 
ab:
1. Wie komplex ist das Projekt?
2. Wieviele Varianten wird es geben?
3. Macht es Sinn, eine Plattform zu erstellen, und die Varianten darauf 
aufzubauen?
4. Deine Erfahrung und Dein Stil.


PS:
Erstelle auch gleich Coding-Guidelinies, damit nicht jeder Entwickler 
macht, was er will.
Es wäre doof, wenn die eine Schnittstelle "Stack_Send_1Byte_u8()" heißt 
und die andere "UBYTE_SENT_TO_UART()".

Ah super, danke dir Pako. Eine Erklärung in der Richtung habe ich 
gesucht, um den roten Faden zu bekommen. Nun werde ich mir noch die 
Bücher zulegen und versuchen alles richtig zu machen und Erfahrung zu 
sammeln.

Eine Code-Guideline habe ich schon geschrieben, sie ist zwar noch im 
Entwurfsstadium, allerdings finde ich das auch schon für einen 
Entwickler sinnvoll um sich immer wieder an die gleichen Vorgaben zu 
halten.

MFG

Der bewährteste Weg, um solch ein Problem anzugehen, ist immer noch, 
nachzusehen, wie andere das gelöst haben. Denn du wirst es eventuell 
nicht glauben wollen, aber Implementierungen für Stacks und uarts gibt 
es tatsächlich schon einige ;)

Such dir Sourcen von Microcontroller-Echtzeitbetriebssystemen, 
Kommunkationsstacks, clibs, ..., und schau dir an, wie da Architektur, 
Schnittstellen, Initialisierungen, etc. gelöst wurden. Das erweitert den 
Horizont ungemein.

Und ganz eventuell wirst du nebenbei rausfinden, daß es das alles, was 
du brauchst, schon fertig gibt. Ob du die verfügbaren Sourcen dann in 
deinem Produkt nutzen kannst, ist dann nur noch eine Frgae der 
benötigten Lizenzen.

Oliver

Oliver schrieb:
> Der bewährteste Weg, um solch ein Problem anzugehen, ist immer noch,
> nachzusehen, wie andere das gelöst haben. Denn du wirst es eventuell
> nicht glauben wollen, aber Implementierungen für Stacks und uarts gibt
> es tatsächlich schon einige ;)

Richtig, das habe ich mir auch schon gedacht. Leider habe ich noch 
nichts passendes gefunden oder ich bin einfach zu blöd zum Suchen :D

MFG