Grüße an Alle! Da ich komplexere Software Projekte im embedded Bereich realisieren möchte suche ich dazu Lektüre, aber auch Tipps aus dem Forum. Es geht darum ein Software Projekt in Subprojekte zu zerlegen und diese dann auf verschiedene Entwickler zu verteilen. Ein kleines Beispiel wäre Entwickler A programmiert die komplette UART und Entwickler B entwickelt parallel dazu einen Netzwerkstack XY. Die Softwarepakete sollen jetzt möglichst gekapselt und modular sein. Nach Fertigstellung der beiden Teilprojekte müssen diese zusammengefügt werden. Wie hat nun so eine "Schnittstelle" zwischen den Modulen auszusehen? Wie geht man bei der Definition dieser Schnittstelle vor? Definiere ich einen Datencontainer wie z.B. eine Struktur mit der Beide Softwaremodule arbeiten oder übergibt Entwickler A einfach nur seine Funktionsargumente, damit Entwickler B diese bei sich in der Software einbinden kann...aber wo bleibt dann die Kapselung und modularität? Und welches Modul würde ich dann in das Andere einbinden, Schichtenproblem, Henne und Ei :D? Leider konnte ich noch kein Buch aus dem embedded Bereich finden, wie man sowas praktisch macht. Entweder sind die Softwareprojekte in diesen Büchern nicht modular oder aber auf so einer hohen Abstraktionsebene, dass die praktische Umsetzung auf der Strecke bleibt. Danke für Eure Antworten. MFG
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.
Hallo, im Buch "Test Driven Development for Embedded C" von James W. Grenning wird u.a. auf sowas eingegangen. Ich habe das Buch studiert und kann es nur wärmstens empfehlen. Die verwendeten Methoden und Beispiele beziehen sich zwar auf C, können aber problemlos auf jede andere Programmiersprache angewendet werden. Ist halt auf Englisch, liesst sich trotzdem recht flüssig. Gruß, avrGerd
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
Der "The Pragmatic Programmer. From Journeyman to Master" von David Hunt ist zwar nicht embedded spezifisch aber er hilft ungemein. Im Embedded Bereich bist du immer in der Zwickmuehle zwischen "cleverem Ressourcen-Schonen", "Timing/Latenzen" und "super strukturiertem Modell". Gerade diese Gradwanderung verlangt sehr pragmatisches Herangehen. Sorry wenn ich Mythos zerstoere: "No rocket science, nur Handwerk".
Die angesprochene Problematik macht ja gerade die Schwierigikeit der Softwareentwicklung aus. Wenn man diese Probleme mit einem kurzen Leitfaden abhandeln könnte, bräuchte man keine SW-Entwickler. Das kann man auch nur durch fundiertes Wissen UND viel Erfahrung in den Griff bekommen. SW-Entwicklung von komplexen Projekten ist NICHT trivial. gruß cyblord
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
Irgendwie scheinst du nicht viel Erfahrung in der Entwicklung etwas komplexerer Systeme zu haben. Was ist eigentlich dein technischer Hintergrund und deine bisherigen Erfahrungen? Oder kommst du direkt von der Uni?
Interessent schrieb: > 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 Nein, da fehlt Dir etwas Verständniss. Wie Pako schon geschrieben hat, muss man sich (dem Problem angepaste) Abstraktionsebenen erarbeiten und Schnittstellen definieren. 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 ... Dies ist auch Beispielhaft in dem von mir empfohlenen Buch beschrieben und gut verständlich erklärt. Gruß, avrGerd
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
Hallo, folgendes Buch geht auf die Implementierung von "Sauberem Code" ein: Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code: Deutsche Ausgabe von Robert C.Martin Hier werden solche Techniken und Überlegungen wie sie Pako oben erwähnt hat beschrieben und am praktischen Beispiel angewendet. Die Beispiele sind zwar in Java, die Grundprinzipien gelten aber ebenso für andere Programmiersprachen. Meine Meinung ist, jeder Programierer sollte die beschriebenen Methoden wie beschrieben anwenden, dann wären die meisten Projekte die man von anderen Kollegen oder Drittanbietern auf den Tisch bekommt auch wartbar und viel einfacher zu ändern bzw. mit neuen Funktionen zu versehen sein. So würde auch ein gemeinsamer Stiel beim Programmieren unter Kollegen entstehen. Bei Amazon kann man mal einen "Blick ins Buch" werfen. Viel Erfolg, avrGerd
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.