mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Strukuriertes Programmieren


Autor: FranzK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da ich eigentlich beruflich mehr mit Programmierarbeiten, die einige
Abstraktionsebenen höher liegen, zu tun habe, würde mich mal
interessieren wie ihr vor der eigentlichen Programmierung den
Programmablauf modelliert. Ich bin da ziemlich auf eine
obejektoreintierte Sicht fixiert, deshalb fällt es mir schwer
prozedural zu denken.
Malt ihr euch Programmablaufdiagramme oder Struktogramme? Wie überführt
ihr die dann in sauberen, wartungsarmen Code? Wenn ihr da sowas wie
Rezepte oder Verogehensweisen kennt oder links dazu, wäre ich euch zu
tiefst entbunden, wenn ihr mir das mitteilen könntet, da ich weder im
Netz noch in diversen Bibliotheken fündig geworden bin. Irgendwie kommt
das Thema bei Büchern über prozeduralen Programmiersprachen immer zu
kurz oder wird gar nicht erwähnt. Die fangen meist mit den Daentypen an
und gehen dann Punkt für Punkt die verschiedenen Konstrukte wie
Verzweigungen Schleifen usw. durch, aber wie man letzendlich von einem
Problem zur Lösung kommt wird verschwiegen.
Ich hoffe ihr könnt mir hier Tipps geben.

Gruß Franz

Autor: Leopold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo franz,

ich programmiere sowohl microcontroller in assembler und c,
als auch windows (visual c++ / mfc objektorientiert).

der grund, warum es - denke ich - oft zu kurz kommt, liegt darin, dass
bei mc die software meist nicht so umfangreich und komplex ausfällt wie
z.B. in visual c++ mit 10000 zeilen programmcode!

wenn ich an einem mc-programm arbeite und es gibt unklarheiten, dann
programmiere ich einfach drauf los bis ich dieses teilproblem gelöst
habe. sind alle vorgänge klar, überlege ich mir wie das programm
ablaufen wird (unterprogramme, interrupts,...).

Gruß, Leo

Autor: Leopold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Burschen, wie macht ihr das?

mfg da|poidi

Autor: OliverK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich programmier einfach drauf los. Leider...
Gelernt habe ich auch, wie man "sauber" an die Sache rangeht, aber
das will meist keiner haben und auch nicht dafür bezahlen. Laufen muß
es, in kürzester Zeit und kosten darf es nix :-(

Grobkonzepte habe ich im Kopf. Bei etwas kniffligeren Assemblerroutinen
male ich mir mit dem Bleistift (weil gut radierbar) ein Ablaufdiagramm
auf. Ansonsten verpasse ich jeder Funktion einen dicken Kommentarkopf,
was die da so macht, was sie erwartet und wieder ausspuckt.

Grüße
Oliver

Autor: Leopold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@OliverK

Du bestätigst meine Meinung... :-)

Ich denke man mann es nicht wirklich eins zu eins vergleichen mit z.B.
Objektorientierten Programmiersprachen...

mfg leo

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich programmier einfach drauf los."

Davon rate ich grundsätzlich ab.
Sowas mache ich höchstens bei sehr einfachen Programmen, die man quasi
schon fertig im Kopf hat.

Ansonsten nehme ich mir einen Stapel Schmierpapier und male die
Programmablaufpläne drauf, erstmal die Hauptfunktionen und dann diese
unterteilt in einzelne Unterfunktionen usw..

Die einzelnen Funktionen werden dann auch in einzelne Files
geschrieben, damit man sie universell weiterverwenden kann.
Auch hat man damit eine gewisse Trennung zu den anderen Funktionen,
d.h. man muß sich einen Kopf machen, wie Informationen mit anderen
Funktionen ausgetauscht werden können.

Bei sehr großen Programmen schreibe ich auch für jede Funktion ein
eigenes *.h-File, in dem dann die Funktion und deren Variablen
deklariert werden.

Dann erkennt man auch später noch sofort, welche Funktion diese
Unterfunktion aufruft, da ja dazu das entsprechende *.h-File includiert
werden mußte.

Als Beispiel kann man sich das hier ansehen, ist aber noch ein eher
kleines Programm:

http://www.mikrocontroller.net/forum/read-4-49709.html


Ich halte nicht soviel von speziellen Tools für die
Programmstrukturierung, Papier und Stift geht einfach schneller.


Peter

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und man muss sogar oft Kompromisse machen. Je "sauberer" und
"universeller" programmiert wird, umso grösser und langsamer wird das
Programm. Programmspeicher und RAM sind oft genug eine kostbare
Ressource, nicht vergleichbar mit der PC-Welt.
Dazu kommt, dass ein MC-Projekt meist nur ein einziges Programm
ausführt und eine Art Betriebssystem i.a. nicht verfügbar ist. Insofern
lebt man auf einer Insel, man muss sich nicht an irgendwelche
Konventionen halten, um andere Dienste zu nutzen.
Ich habe es schon oft erlebt, dass ein Programm "sauber" angefangen
wird, im Laufe der Zeit kommt die eine oder andere Erweiterung dazu.
Dann wird der Programmspeicher knapp und man geht auf Byte-Jagd. Die
Folge sind dann mehr oder weniger trickreiche Verkürzungen, die dann
aber wiederum auf Kosten der Les-und Wartbarkeit gehen.

Autor: OliverK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich habe es schon oft erlebt, dass ein Programm "sauber" angefangen
wird, im Laufe der Zeit kommt die eine oder andere Erweiterung dazu."

Da sagst Du was Wahres! Ich nenne das immer "Wieder ein Balkon an den
Balkon programmieren"

Das wird sich aber nie ändern. Das Problem wird z.B. gerade bei Visual
C++ zu einem wirklichen Problem, wo alles miteinander verwurschtelt
ist.
Doc <---> View <---> GUI

Autor: Leopold (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@crazy horse
STIMMT!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

bei mir ist es ähnlich. Zuerstmal werden einzelne Teilprobleme gelöst
wie etwa das Ansteuern eines ADC, das Regeln eines Ventilstroms, das
Ansteuern eines Displays usw. Sind diese Teilprobleme gelöst wird
daraus dann eine .c und eine dazugehörige .h erstellt welche dann in
das Projekt eingebunden werden. In main wird dann die Ablaufsteuerung
erledigt. Um das ganze auch noch in einem halben Jahr zu verstehen sind
natürlich Kommentare sehr wichtig. Ich schreibe, sobald das Programm
mehr als ein paar 100 Zeilen hat Doxygen kompatible Kommentare. Damit
kann ich mir meine Entwickler-Dokumentation dann automatisch erstellen
lassen.
Schönes Beispiel für ein von Doxygen generiertes Dokument ist die
AVRLibc-Doku.

Matthias

Autor: Malte Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann werd ich auch mal meinen Senf dazu geben:

Das mit dem "schnell fertig sein, hauptsache es funktioniert - alles
andere wird eh nicht bezahlt" kann ich ebenfalls bestätigen.

Es zahlt mir keiner Stundenlange Planungen, sauberen Code, etc.
Änderungen dagegen (egal ob sie durch modulare / strukturierte
Programmierung kürzer ausfallen würden) werden ohne Meckern bezahlt.
KOMISCHERWEISE.

Naja, es plant halt anfangs niemand mit Änderungen denke ich.

Jedenfalls gehe ich im Kopf zuerst mal die Aufgaben des Programmes
durch, halte mir vor (den geistigen) Augen, wie die Eingaben /
Reaktionen sein sollen.
Danach fange ich mit dem Grundgerüst an (hab ich meistens im Kopf, wenn
es nicht allzu komplex ist).
Steht das Grundgerüst kommen nach und nach die verschiedenen
Programmteile dazu. immer eines nach dem anderen.
Tja. und zum Schluss dokumentiere ich noch einigermassen den Quelltext
durch (während des Programmierens markiere ich mir eigentlich nur
wichtige stellen, um das debuggen zu vereinfachen).

Das ist auch schon alles.

Mir geht es im Prinzip auch gegen den Strich, da ich von der PC seite
her anders Programmieren gewohnt bin (delphi, pascal, php).
Aber was solls.

Wenn ich Sachen in einem anderen Projekt wieder recyclen kann wird der
code eben kopiert und im neuen Projekt angepasst.

Autor: Johannes Raschke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir heißen viele Programme einfach "test.asm" bzw. "test.c",
weil aus dem kleinen Testprogramm, mit dem ich eigendlich nur eine
Klenigkeit ausprobieren wollte, dann doch das eigendliche Programm
wird... Bei kleinen Projekten geht das eigendlich ganz gut...

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

Bewertung
0 lesenswert
nicht lesenswert
Wie Matthias schon geschrieben hat, in C ist es relativ einfach ein
µC-Programm ordentlich zu strukturieren: jede Teilfunktion (ADC, SPI,
Sensoransteuerung) bekommt ihre eigene C- und H-Datei, die Funktionen
werden nach einem einheitlichen Schema benannt (SPI_Read(),
LCD_SetCursor(), Menu_AddItem()), und in main.c wird das alles
verknüpft.

Autor: Ratber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@FranzK

Info zum verständnis: "Programieren" tu ich eigentlich seit ender der
70er aber streckenweise nur wenig bis garnicht.


Also wie mach ich es ?

Anfangs war da natürlich der Spagetticode.

Also wild drauflos.
Vorn ,hinten und mittendrinn was reingeklebt bis es lief.

Dann irgendwann werden die Programme umfangreicher und man
vergaloppiert sich schnell,also kommen schon fast von allein
rudimentäre Strukturen rein.
Da der Speicher noch knapp und teuer ist muß man allerdings manchmal
tricksen womit wir wieder etwas "Spagetticode" drinne haben.

Irgendwann kam Pascal dazu und man höhrte erstmalig "offiziell" vom
"Strukturierten Programieren" und das man sich das vorher mittels
Struktogrammen oder Flußdiagrammen zurechtlegen sollte.
Dazu versucht natürlich jeder 2. Hersteller einem einzureden das Pascal
und ander "strukturierte Sprachen" Gut und Basic "Bäh" ist.

Tatsache ist : In der Zeit in der ich ein Struktogramm und anschließend
dessen Umsetzung unter strengen "Strukturellen Richtlinien" vollzogen
habe bin ich bei meinen kleinen Spagettiprogrammen schon längst bei der
Optimierung und mindestens V2.6 ;)

Dann später kommt irgendwann ein relativ großes Projekt und nach
einigen Fehlern die nicht mehr auffindbar sind fängt man tatsächlich an
die Geschichte etwas Generalstabsmäßiger aufzuziehen.

Und siehe da ,es klappt (Meist jedenfalls).

Ich mach mal nen großen Sprung ins "Jetzt"

Mittlerweile sind alle Hochsprachen "Strukturiert".Auch Basic kennt
längst Prozeduren,Globale und Locale Variablen usw.

Kurzum:Irgendwie haben die Verfechter aller Sprachen sich gegenseitig
die vernünftigen (Ab und an auch die unvernünftigen)Ideen abgekupfert
und entsprechend umgesetzt.

Basic und Pascal (Pardon,"Delphi") sind sich Streckenweise so ähnlich
das man manchmal muß man in die Titelleiste schauen um zu merken womit
man Programiert.

Assembler ist dabei eigenlich geblieben wie es sit aber die Oberflächen
sind schöner ;)

C und Folgende stellen natürlich das derzeitige Non plus Ultra dar sind
aber auch reichlich überladen und für meinen Geschmack viel zu
Kryptisch (Es wäre dienlich die Befehle ruhig was länger
ausfallenzulassen damit man die Quellcodes auch etwas flüssiger lesen
kann.).
Vieleicht bin ich aber auch schon zu alt dafür.Keine Ahnung)

Der Rest (Cobol,Fortran usw.) ist eigentlich nurnoch hier und da
anzutreffen da fast schon tot.

Tja,und heute ?

Wie ich Programiere kommt immer drauf an worum es geht.

Bei kleinkram mache ich es immernoch Frisch,From,Fröhlich,Frei von der
Leber weg ohne vorarbeit.

Bei größeren Geschichten überlege ich mir natürlich strategieen und
kritzel ein halbgares Konzept auf nen Stück Papier aber größtenteils
gehts noch ohne Plan.

Selten steht mal was ganz großes (Was immer auch "Groß" ist)an.

Dann ist natürlich etwas Planung ind die Generelle Struktur angesagt
damit das Chaos nicht über einen hinwegalloppiert.
Im Bereich "wiederkehrende Berechnungen" ist dann natürlich viel
Platz zu sparen.

Mit Obkelkten hab ich nur selten was zu tun.

Ich bin nicht so der Fan vom "Modulekleben" (Is nicht so ersnt
gemeint also nicht weinen)
Universelle Module mit fester "Schnittstelle" sind zwar leicht zu
handhaben aber dafür kosten se meist Platz,Rechenzeit und/oder sind
unflexibel weil se mal nicht in die Wunschliste passen.

Meine Methode ist zwar auch Routinen zu sammeln die ich selber
erstellt habe oder die ich  von irgendwo bekommen habe aber für den
einen oder anderen Fall passe ich se dann an oder wenn es sein muß
schreibe ich se komplett neu wen ich nen Vorteil sehe.

Mit der Effektiven Programierung ist es wie auf der Arbeit.

Für beide werden weitgehends Strukturen vorgeschrieben aber wenn man
sich dran hält ist man zu unflexibel und die Arbeit geht nur zäh
vonstatten.

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.