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
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
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
@OliverK Du bestätigst meine Meinung... :-) Ich denke man mann es nicht wirklich eins zu eins vergleichen mit z.B. Objektorientierten Programmiersprachen... mfg leo
"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
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.
"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
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
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.
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...
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.
@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.
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.