Moin Zusammen, ich hab gerade als Quereinsteiger im Embedded Softwarebereich angefangen und bin leider Gottes 'etwas' überfordert mit den Unmengen an bestehenden Code die es in den einzelnen Projekten gibt. In der Regel soll ich kleine Projekte für Prototyp-Module erstellen und mich dabei an den bestehenden Code aus anderen Projekten orientieren. Es fällt mir aber total schwer mir einen Überblick in diesen Code zu verschaffen und auch die richtige Vorgehensweise für mich zu definieren. Kopiert man nun ein bestehendes Projekt und dünnt den Code aus, in dem man nicht benötigte Dateien entfernt oder eben die Funktionen? Oder erstellt man sich lieber ein eigenes leeres Projekt und fügt nur die Teile hinein, die nötig sind. Grundsätzlich hab ich mit Sicherheit das Problem sehr ungeübt in Quellcode lesen zu sein. Was mir aber auch rgendwie fehlt, ist ein Hinweis wie man bei sowas vorgeht. Struktogramme erstellen, oder einfach drauf los coden? Ist es in der Praxis tatsächlich so, dass jeder Entwickler sich einfach nur seine Gedanken macht und dann anfängt die Sache in Code zu meißeln, anstatt das vorher irgendwie schematisch festzuhalten? Freue mich auf hilfreiche Tips. Stefan.
Sorry aber du scheinst ja gar keine Ahnung vom Programmieren zu haben. Mein Tip: LASS ES. Sowas lernst man nicht von heute auf morgen und mit copy&paste wird du nicht weit kommen, zumal im Prototypen Bereich.
Weja schrieb: > Sorry aber du scheinst ja gar keine Ahnung vom Programmieren zu haben. Das befürchte ich auch. Keine gute Voraussetzung... Weja schrieb: > Mein Tip: LASS ES. Ich fürcht, dafür ist es zu spät. Anscheinend wird der TO für das, was er tut, bezahlt. Am einfachsten nimmt man sich die (hoffentlich) vollständige Dokumentation des Codes. Da sollten alle Fragen beantwortet werden ;) Im übrigen sind die "Unmengen an Code" im Nicht-Embedded-Breich noch viel größer. Oliver
Stefan M. schrieb: > Kopiert man nun ein bestehendes Projekt und dünnt den Code aus, in dem > man nicht benötigte Dateien entfernt oder eben die Funktionen? > Oder erstellt man sich lieber ein eigenes leeres Projekt und fügt nur > die Teile hinein, die nötig sind. Das ist auch für fortgeschrittene Programmierer keine so leichte Frage und kann man imo so pauschal nicht beantworten. Wenn man für die Plattform, die man verwenden soll, schon etwas lauffähiges hat, ist das ein guter Einstiegspunkt. Dann kann man das ausdünnen, umschreiben oder erweitern. Auch wenn man nur die absolute Grundstruktur übernimmt, man hat fängt gleich mit etwas lauffähigem an. Wenn der existierende Code allerdings für eine andere Plattform geschrieben ist, kann es ein Haufen Arbeit sein, bis man das bestehende Projekt überhaupt das erste Mal zum Laufen gebracht hat. Dann ist es sinnvoller, mit einem "Hello World"-Programm anzufangen und nach und nach Module aus dem anderen Projekt zu integrieren und einzeln zu testen.
> Weja schrieb: > Mein Tip: LASS ES. Das ist natürlich der einfachste Weg ^^ > Oliver S. schrieb: > Anscheinend wird der TO für das, was er tut, bezahlt. 'Noch' ist das so ;) > Am einfachsten nimmt man sich die (hoffentlich) vollständige > Dokumentation des Codes. Von so einer Doku träume ich nachts. Die objektivste Antwort war natürlich auch die motivierendste. Vielen Dank dafür XFR. Die letzten beiden Stunden habe ich natürlich weiter über die beste Vorgehensweise nachgedacht und denke, ein neues Projekt in den man sich seine benötigten Funktionen hineinkopiert und anpasst ist das sinnvollste. Der Debugger wird dann schon maulen, wenn ich was vergessen habe. Andersherum könnte es passieren, dass man Code mitführt, der gar nicht mehr aufgerufen wird. Kommt Zeit, kommt Rat :)
Stefan M. schrieb: > Die letzten beiden Stunden habe ich natürlich weiter über die beste > Vorgehensweise nachgedacht und denke, ein neues Projekt in den man sich > seine benötigten Funktionen hineinkopiert und anpasst ist das > sinnvollste. Der Debugger wird dann schon maulen, wenn ich was vergessen > habe. Andersherum könnte es passieren, dass man Code mitführt, der gar > nicht mehr aufgerufen wird. > Kommt Zeit, kommt Rat :) Hast du schon mal kopiert? Das klingt irgendwie nicht so. Der Debugger ist auch keine Magie, sondern ein Werkzeug, was man lernen muss zu bedienen.
Stefan M. schrieb: > In der Regel soll ich kleine Projekte für Prototyp-Module erstellen und > mich dabei an den bestehenden Code aus anderen Projekten orientieren. Weja schrieb: > Mein Tip: LASS ES. Würde ich auch so sehen, aber anders als dieser unverschämte arrogante und von allen guten Geistern verlassene Proll das meint (mein Beileid übrigens zu so viel Dummheit). Es hat keinen Sinn den Source Code anderer an eigene Bedürfnisse anzupassen. Mach dir deinen eigenen und schau dir das was andere machen als Beispiele und Anregung an. So gewinnst du die Sicherheit das die eigenen Sources was taugen und bist später in der Lage mehr aus ihnen zu machen. Außerdem: Andere kochen auch nur mit Wasser, zu viel Respekt ist da unsinnig). Wohin Cut and Paste, Beziehungen und sonstiges Segeln unter fremden Leistungen bei gleichzeitigem Mangel an erworbenen (und auch erlittenen) Fähigkeiten einen bringen, Tja dafür ist der Fall Guttenberg doch ein allseits bekanntes Beispiel ;-).
Hm was da rauskommt ist wohl eine Kaffeemaschine die man 8 mal am Tag restarten muß um eine Tasse Kaffee zu bekommen und nach kurzer Zeit mit Patentklagen überschüttet wird. Wenn man soetwas liest wundert es einem nicht wieviel Schrott by Design produziert wird.
Der Rächer der Transistormorde schrieb: > Wohin Cut and Paste, Beziehungen und sonstiges Segeln unter fremden > Leistungen bei gleichzeitigem Mangel an erworbenen (und auch erlittenen) > Fähigkeiten einen bringen, Tja dafür ist der Fall Guttenberg doch ein > allseits bekanntes Beispiel ;-). Jetzt wirds politisch :D
Hi, Stefan, den ersten Lerneffekt hast Du schon: Ab jetzt verständliche Kommentare am Programm und eine verständliche Dokumentation. Zweitens - das gilt nicht nur für Quellcode, sondern auch für Schaltpläne: 1. Systematisch denken. Es gibt 1000 Wege nach Rom heißt es. Ankommen tut aber nur, wer konsequent auf seinem Weg bleibt. Nicht derjenige, der alle Nase lang auf den Pfad wechselt, der ihm gerade interessanter vorkommt. Mein Weg ist vielleicht nicht der kürzeste, für mich bisher aber gut genug. 2. Braucht man die Antwort auf die Frage: "Wozu ist das gut?" Systemdenken, Prozessdenken. Mit den weiteren Fragen: "Was soll dabei rauskommen?" und "Was braucht es dazu am Eingang?" Den Quellcode beginnt man besser mit der Produktbeschreibung zu verstehen. 3. Die Funkion main() wirst Du schon längst gefunden haben. Nun aber fummele für jeden Output die zugehörige Funktion und Interrupt-Routine heraus und arbeite Dich von dort aus zu main() vor. Begründung: Mancher Code enthält Leichen aus älteren Zeiten. Funktionen, die zwar den Code aufblähen, aber gar keine Funktion mehr haben. Gibt wohl auch Programme, die zu eliminieren. Können das Verständnis verzögern. 4. Die Adaption auf neue Aufgaben - wie damals im Kinderzimmer, als Du die Lego-Kreationen zerlegt und die Bausteine in den Sortimentskasten zurückgetan hast, um dann daraus Deine neue Kreation zu erstellen: Zerlege den Quellcode in Funktionsblöcke für jeweils eine Aufgabe - und dann puzzele nach Spezifikation zusammen, was Du brauchst. 5. Versteck Deinen "Sortimentskasten für Module". Aber pflege ihn - Verbesserungen erst am Modul im "Sortimentskasten", dannn die Kopie in dem Quellcode, den Dein Qualitätssicherer zu Gesicht bekommt. Ciao Wolfgang Horn
Hey Wolfgang, ich habe selten so eine objektive und gut gegliederte Antwort hier im Mikrocontroller.net Forum gesehen. Damit hast du mir auf jeden Fall geholfen meinen Weg zu finden und nicht mehr ganz so unsicher durch den Code zu springen. Vielen Dank Stefan
Stefan M. schrieb: > Oder erstellt man sich lieber ein eigenes leeres Projekt und fügt nur > die Teile hinein, die nötig sind. Also ich mache es so, dass ich mit einem leeren Projekt anfange. Wenn es dann Teile von "fremden" Programmen sein sollen, dann kopiere ich nur das, was ich auch verstehe! Früher (TM) habe ich auch Code kopiert, ohne ihn zu verstehen - das musste ich dann oftmals bitter mit langwieriger Fehlersuche bezahlen. Bevor ich eine Zeile Code schreibe habe ich schon einige Seiten Papier voll geschrieben. Das muss dann nicht unbedingt ein vorzeigbarer Programmablaufplan sein. Doch die Haupt-Programmteile sollten schon erkennbar sein. Während dem Programmieren ändert sich dann ja auch oftmals das Eine oder Andere. Und noch etwas: Meine Programme sind so komentiert, dass ich auch nach 5 Jahren noch verstehe wie und weshalb ich es so gemacht habe. Ich werde da oftmals von Kollegen belächelt, mir hilft es aber sehr. mfG Ulli
Stefan M. schrieb: > Die letzten beiden Stunden habe ich natürlich weiter über die beste > Vorgehensweise nachgedacht und denke, ein neues Projekt in den man sich > seine benötigten Funktionen hineinkopiert und anpasst ist das > sinnvollste. Scheint mir viel zu wenig Nachhaltig zu sein. Du erfindest so das Rad immer wieder neu, fixt Probleme/Bugs immer wieder auf's Neue, usw. Funktionalität in Libraries kapseln und diese wieder verwenden. Bugfixes und funktionale Erweiterungen sind dann in allen Projekten wieder verfügbar. Nicht zu vergessen auch die Doku zur Schnittstelle! Versionskontrolle wie SVN und CVS verwenden. > Der Debugger wird dann schon maulen, wenn ich was vergessen > habe. ??? Eher der Compiler oder Linker... > Andersherum könnte es passieren, dass man Code mitführt, der gar > nicht mehr aufgerufen wird. Halbwegs aktuelle Compiler werfen nicht benötigten Code raus. YMMV.
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.