mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Richtig Programmieren/ Softwareentwicklung


Autor: Träumer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?")

Autor: Ralf Schwarz (spacedog) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: df311 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.)

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Träumer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: EFA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So geht's richtig:

http://en.wikipedia.org/wiki/DO-178B

http://www.opengroup.org/rtforum/jan2002/slides/sa...


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.

Autor: nixwisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.