Obwohl ich seit einigen Jahren gelegentlich mit diversen Sprachen spiele habe ich das Gefühl, dass ich nicht programmieren kann. Das ist wohl nicht ein Problem der Sprache, sondern der Planung. Programme entstehen bei mir immer Stückchenweise, hier eine Änderung, da ne neue Bedingung/Schleife etc, Kompilieren, Flashen, Ausprobieren, ... Das ist tierisch zeitaufwändig und läuft häufig darauf hinaus, dass am Ende wieder alles umgeworfen wird (Sackgasse), oder dass ich die Lust verliere an einem Projekt zu arbeiten. Wenn ich hier sehe, dass manche innerhalb von einem Wochenende komplette Grafikkarten etc. zustandebringen ist das sehr beachtlich und etwas frustrierend. Natürlich ist das auch eine Sache der Erfahrung/Übung. Allerdings suche ich eine Methode, im Rahmen meiner Möglichkeiten (Hirn und Zeit), meine Vorhaben zumindest effizienter umzusetzen. Wie schreibt man also innerhalb kürzester Zeit elegante Programme? Stichwort ist da wohl http://de.wikipedia.org/wiki/Softwaretechnik allerdings würde ich mich über persönliche Erfahrungen, Methoden, Vorgehen von Profi-Bastlern freuen, da ich vorerst keine wissenschaftlichen Ansprüche habe. Im Forum gibt es einen Thread mit Buchempfehlungen ( Beitrag "Wie geht man beim Programmieren richtig vor?")
Also ne Grafikkarte an einem Wochenende zustandezubringen hat nur mit Birnenfick zu tun und nicht viel mit Planung. Ansonsten arbeite ich viel mit UML, um aufzuzeichnen wie mein Programm aufgebaut sein soll. Da erkennt man dann Sackgassen schnell und kann schon reagieren, bevor eine Zeile Code geschrieben ist. Aber UML ist seeeehr umfassend und braucht ein wenig Einarbeitungzeit.
naja also uml finde ich für mikrocontrolleranwendungen wohl etwas übers ziel hinausgeschossen (naja zumindest wenn wir im 8-16Bit bereich bleiben...) Ich mach mir jeweils vor ich mit coden anfange ein blockdiagramm welches alle wichtigen bestandteile welche benötigt werden vorhanden sind. Bei schwirigeen programmteilen oder solchen wo ich extrem auf die effizienz achten muss, mache ich mir jeweils ein easy case diagramm...
Träumer wrote: > Wenn ich hier sehe, dass manche innerhalb von einem Wochenende komplette > Grafikkarten etc. zustandebringen ist das sehr beachtlich und etwas > frustrierend. Natürlich ist das auch eine Sache der Erfahrung/Übung. Es ist ein Unterschied, ob eine Software die ersten Zuckungen eines Funktionierens zeigt oder ob sie wirklich stabil und ausgereift läuft. Die Wochenend-Graka wird mit Sicherheit ersteres sein. Und unwartbarer Spaghetticode, den man schnellstmöglichst wieder entsorgt. > Allerdings suche ich eine Methode, im Rahmen meiner Möglichkeiten (Hirn > und Zeit), meine Vorhaben zumindest effizienter umzusetzen. Auch wenns schwer fällt, Planung und Disziplin helfen enorm bei der SW-Entwicklung. Man sollte sich viele Programme von anderen ansehen und was einem gefällt, übernehmen. In Foren kann man in der Regel den Autoren Fragen zu den Programmbeispielen stellen, nur zu. Nichts ist schlimmer, als Code zu übernehmen, den man nicht versteht. Ich teile Programme gerne in kleine universelle Module auf. Oftmals sieht man, daß dem Onchip-Debuggen ein extrem hoher Stellenwert eingeräumt wird. Manche fangen garnicht erst an, ohne JTAG-Schnittstelle. Ich hab sowas noch nie benutzt (nur mal kurz ausprobiert). Ich hab die Vermutung, es verleitet zu unnötig viel Trial&Error und erhöht damit die Gefahr, Fehler zu machen. Peter
uml muss ja nicht bis zum excess verwendet werden, kann aber für manche sachen ganz praktisch sein. ich persönlich verwende - je nach komplexität und art des projekts/programm - meistens fsm-, kommunikations-zeit- und block-skizzen und komme damit ganz gut zurecht. ausserdem schreibe ich programme meistens "bottom-up", also die kleinsten methoden zuerst (z.b. daten senden/empfangen), die dann in anderen methoden verwendet werden - bis das programm fertig ist ;-)
ich nehm für die planung das hier: http://www.myavr.de/download.php?suchwort=video UML und die C++ Codegenerierung sind etwas fett für nen µC aber ab 16K FLASH hatte ich mirbisher nie sorgen machen müssen... für kleinere dinge nehm ich den PAP mit codegenerierung in Assembler... also zusammenfassend: große Systeme in UML entwerfen und Codgenerierung in C++ kleine Systeme mit dem PAP entwerfen und Codegenereirung in Assembler mittlere Systeme mach ich dann in der Regel und an mit dem CodeWizard und reinem C gruß M.
Peter Dannegger wrote: > Manche fangen garnicht erst an, ohne JTAG-Schnittstelle. > Ich hab sowas noch nie benutzt (nur mal kurz ausprobiert). Kommt drauf an auf welcher Ebene und in welcher Komplexität man mit dem Projekt anfängt. Wenn wie bei WinAVR oder kommerziellen Paketen für solche Geräte Startup-Code und Runtime Lib vorliegen, und man für Debug-Ausgaben mindestens ein paar LEDs parat hat, ist es selten notwendig. Wenn man allerdings bei nahe Null anfängt, wie bei WinARM oft nötig ist, kann JTAG sehr hilfreich sein. Auch laufen Programme für Controller der ARM Klasse sehr gerne in irgendwelche Aborts rein, und wenn man da nicht schon eine nette Ausgaberoutine sitzen hat, ist man mit Debugger schon besser dran. Zudem programmiert sich ein ARM per JTAG meist schneller als per Bootloader.
Markus wrote: > UML und die C++ Codegenerierung sind etwas fett für nen µC aber ab 16K > FLASH hatte ich mirbisher nie sorgen machen müssen... für kleinere dinge > nehm ich den PAP mit codegenerierung in Assembler... Also Assembler bis herauf zu 16kB ist für mich etwas heftig. Bei mir liegt die Assembler-Grenze bei max 512 Byte. Darüber kommt nur noch C ran, sonst ist es zu zeitintensiv. > mittlere Systeme mach ich dann in der Regel und an mit dem CodeWizard > und reinem C Also Codewizzards tue ich mir nicht an. Damit holt man sich ja nur ne zusätzliche Fehlerquelle ins Boot ohne viel Nutzeffekt. Außerdem sind Wizzard-Ausgaben in der Regel unleserlich (Hexwerte statt Symbole) und in Stein gemeißelt. Man muß bei Änderungen (Quarz, Pinbelegung) immer wieder den Wizzard neu anschmeißen, statt einfach nur ein #define anzupassen. Peter
Das wichtigste bei mir ist Code aufteilen. Sprich ich schreibe meine Funktionen in verschiedene Dateien mit eindeutigen Namen. So kann ich diese in späteren Projekten einfach includen und mit der Zeit hab ich so nen kleinen Baukasten, mit dem ich die wichtigsten Grundfunktionen von Programmen einfach "zusammenstöpseln" kann. Macht anfangs enorm Arbeit, kommt aber später dicke raus :o)
@Träumer: Deine Probleme kenne ich. Auch ich beschäftige mich schon seit einigen Jahren mit diversen Programmiersprachen, sowohl für µC als auch für den PC. Was mich am meisten stört, ist dass es zwar zu den Programmiersprachen eine Haufen Bücher gibt die die Befehle der Programmiersprach beschreiben( und die Befehle/ Grundstrukturen sind ja meistens ähnlich) aber ich bisher kein Buch gefunden habe, das mal ein größeres Projekt( z.B. Taschenrechner, Editor o.ä.) beschreibt und dazu dann noch OpenSource-/ Freeware-Werkzeuge benutzt. Irgendwie sehr schade für diejenigen die gerne Programmieren würden (z.B. autodidaktisch lernende Schüler, Studenten usw.)
@tom und träumer schaut mal bei den openbooks von galileocomputing vorbei. "C von A bis Z" gutes buch und "praxisbuch objektorientierung". beides gute bücher. Dann gibt es hier im Forum eine Quellcodesammlung und einen Artikel zu Softwareprojekten. Seht nützliche und anschauliche quellen, vor allem die etwas größeren projekte wie die webserver. Man muss den Quellcode am anfang nicht verstehen. ich gebe zu ich schaue mir viele funktionen nichtmal an, hauptsache man sieht auf anhieb im namen oder in der dokumentation was sie machen soll. wenn nicht heist es code anschauen und verstehen. die meisten Coder denken irgendwie ähnlich zumindest ab einen bestimmten level. @träumer wenn du progammieren möchtest, ich meine nichtnur eine programmiersprache beherschen, dann musst du "wissen" was ein prozessor kann. das ist verdammt schwer zu erklären. Ich weiß worauf du hinaus wolltest mit deiner frage. Du schaffst es zwar irgendwie ein programm zu schreiben aber es dauert ewig. Ich weis auch nicht warum ich programmieren kann, keine ahnung. Ich habe ein "händchen" dafür. ich habe mit 11 oder 12 an einen Z80 clone angefangen und ich konnte es auf einmal. plötzlich wuste ich wozu schleifen gut sind. in den beispielen haben sie immer nur gezählt. Vieleicht kann das ja irgendwer besser erklären. Warum fällt es manchen leicht zu programmieren wo andere sich einen abquälen. und wie kann man den leuten die sich abquälen es leichter machen?
Modularisierung finde ich ganz wichtig: Kleine überschaubare Codeteile, die eine eindeutige Aufgabe kapseln. Sie sind für etwas zuständig und kümmern sich darum. Module untereinander kommunizieren über schmale Schnittstellen, das ist ganz wichtig. Solange sich diese Schnittstelle nicht ändert, kann man den Code des Moduls beliebig umstricken, ohne dass der Rest des Systems davon betroffen wäre. Etwas weiter gedacht kommt man natürlich zu objektorientierter Programmierung. Ein hervorragendes Buch ist Meyer - Objektorientierte Softwareentwicklung. ISBN: 3446157735 Und: Man kann auch in Standard-C viele objektorientierte Ideen umsetzen. Selbst in Assembler geht das.
>Programme entstehen bei mir immer Stückchenweise, hier eine Änderung, da >ne neue Bedingung/Schleife etc, Kompilieren, Flashen, Ausprobieren, ... Dieser Ansatz nennt sich *Code & Fix* und gilt als wenig effizient, wie Träumer ja schon festgestellt hat. Besser ist es, die Software von Beginn an zu strukturieren. Die Frage ist nun, welche Strukturen bewähren sich. (Denn auch eine vollkommen chaotische Struktur ist eben eine Struktur). Eine Patentlösung dafür gibt es nicht. Als Beruf gibt es den Software-Architekten. Um sich als Anfänger schnell ins Thema einarbeiten zu können, sind die Entwurfsmuster (engl.: Design Pattern) hilfreich. Das sind Strukturen, zu denen die Vor-und Nachteile diskutiert werden. Man kann dann entscheiden, ob das entsprechende Muster (sozusagen als Schablone) auf die eigene Aufgabe passt.
eines haben viele schon angesprochen. Vorher erstmal auf blatt papier über Grafiken und Bildern sich klar machen wie man ein konkretes Problem lösen könnte oder der Algorithmus aufgebaut sein kann. Wenn man direkt das coden anfängt, verliert das menschliche Gehirn schnell den überblick. Auf eins möcht ich aber auch speziell hinweisen. Das ist erstens ÜBEN, ÜBEN, ÜBEN. Nur durch Erfahrung lernt man und wird besser. Es ist noch kein Meister vom Himmel gefallen. Das zweite ist, schau dir Beispiel-Code an. Auf viele Dinge kommt man erst, oder grad strukturierter Code, sieht man schön wenn man guten Sourcecode anschaut. Es dauert manchmal bis man das ganze durchblickt hat, aber das AHA-Erlebnis ist danach umso größer. So sieht man oftmals sehr elegante Lösungen die man in eigenen Projekten umsetzen kann. Irgendwann mit viel Übung kriegt man mit wenigen Zeilen effizienten Code hin, aber das erfordert viel Zeit.
Roland wrote: > eines haben viele schon angesprochen. Vorher erstmal auf blatt papier > über Grafiken und Bildern sich klar machen wie man ein konkretes Problem > lösen könnte oder der Algorithmus aufgebaut sein kann. Wenn man direkt > das coden anfängt, verliert das menschliche Gehirn schnell den > überblick. Ist auch meine Erfahrung. Der erste Schritt beim Software entwickeln ist, PC ausschalten (damit man nicht abgelenkt wird). Dann Papier und Bleistift nehmen und los gehts. Viele Programmierer haben dazu nen Stapel alter Listings mit der leeren Seite nach oben auf dem Tisch liegen. Peter
Hallo, ich freue mich über die vielen Tipps! Was für eine Methode benutzt ihr auf dem Papier? http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm http://de.wikipedia.org/wiki/Programmablaufplan Oder wird ohne Symbole einfach drauflosgekrakelt? Vielleicht hat ja jemand sogar ein Foto?
Träumer wrote: > Was für eine Methode benutzt ihr auf dem Papier? Das wichtigste sind Zustandsdiagramme. Ansonsten noch diverse andere an UML angelehnte Diagrammtypen. Schau dir mal http://de.wikipedia.org/wiki/Unified_Modeling_Language an. Du musst dich nicht sklavisch an die UML-Konventionen halten, aber du findest dort ein paar Anhaltspunkte wie man was grafisch darstellen kann. > http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm Ist ein Krampf (siehe auch Abschnitt "Praxisrelevanz" im Artikel), um Algorithmen im Detail aufzuschreiben eignet sich Pseudocode besser.
So geht's richtig: http://en.wikipedia.org/wiki/DO-178B http://www.opengroup.org/rtforum/jan2002/slides/safety-critical/chilenski.pdf Was hier hauptsächlich angesprochen wird ist nur ein kleiner Teil eines Softwareentwicklungsprozesses. Der beginnt nicht mit UML, sondern mit Requirements. Das klingt auf den ersten Blick für den Hobbybereich übertrieben, ist es jedoch imho nicht. System- und Softwarerequirements, Codingstandard, Software Configuration Mngmt Plan und Software Design Standard sind nur einige Produkte, die man für Hobbyprojekte sicher nicht formal niederlegen muss, aber man sollte diese Dinge zumindest vor Augen haben und sich darüber im Klaren sein. Aus eigener Erfahrung kann ich sagen, dass es auch für kleine Projekte die Entwicklung enorm beschleunigt und weniger frustrierend ist, weil man deutlich zielgerichteter arbeiten kann.
Was noch wichtig ist: Beim Herstellen einer Prozedur Modul Funktion - kommentiere sie so, als wäre es für jemand anderen, der nicht ganz so fit ist wie Du - ein bischen ausführlicher und reichhaltiger. wenn Du Dir das in einem Jahr wieder anschaust und weiterverwenden willst - dann bist Du nämlich genau dieser Andere. Teste die Funktion gründlich und dann zweifle nicht mehr dran, mach sie schreibgeschützt und laß die Finger davon.
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.