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
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-178Bhttp://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.
