|
Anzeige
|
PAP von AVR-C-Code für Bachelorarbeit
Gast
#2565535
Hi wie erstellt ihr Programmablaufpläne eines AVR-C-Programms für Dokumentationen? Ist es sinnvoll so einen PAP in Bachelorarbeit einzusetzen?? Was haltet ihr vom PAP Designer? Oder gibt es mittlerweile eine bessere Alternative? Gruß Martin
Gast
#2565547
PAP-Designer gibt's wie Sand am Meer ... bzw. lassen sich viele dazu missbrauchen. Martin schrieb: > Ist es sinnvoll so einen PAP in Bachelorarbeit einzusetzen?? Natürlich! Wenn du den Code selber geschrieben hast, dann sollte das Erstellen auch schnell von der Hand gehen.
Gast
#2565548
Für jede trivialität gibts heutzutage Programme. Neumodisch "Designer" genannt. Zu meiner Zeit haben wir etwas so triviales mit der Hand auf Papier gezeichnet und gut wars. Bleistift, Papier und Gehirnschmalz, mehr war dazu nicht nötig. Heutzutage können die Leute aber wohl ohne Softwareunterstützung nicht mal mehr aufs Klo gehen.
Gast
#2565550
PAP kann man bedenkenlos mit einbauen wichtig ist aber das die dinger nicht auf jeder seite sind und quasi Text verdrängen/ersetzen. mit welchem Programm ist egal .. wichti ist das es nach NORM gemacht wird auf son mist achten die Profs dann auch mal ^^ Linus schrieb: > Softwareunterstützung nicht mal mehr aufs Klo gehen. Da gibts sicher eine App dafür.
Gast
#2565627
Ok danke euch. Werde den PAP-Designer nehmen, der macht einen simplen Eindruck und die Pläne sehen professionell aus. @Linus: naja ich hätte mit der Handzeichnung auch kein Problem, aber das will in einer schriftlichen Arbeit / Dokumentation keiner mehr sehen. Allgemeine PAP habe ich mir jetzt schon ein paar Beispiele angeschaut, aber gehören bei einem AVR-Code auch Includes, Defines, Funktionsprototypen oder Variablendeklarationen in so einem Plan?
Gast
#2565629
Linus schrieb: > Datum: 25.02.2012 09:47 > Für jede trivialität gibts heutzutage Programme. Neumodisch "Designer" > genannt. Zu meiner Zeit haben wir etwas so triviales mit der Hand auf > Papier gezeichnet und gut wars. Bleistift, Papier und Gehirnschmalz, > mehr war dazu nicht nötig. Heutzutage können die Leute aber wohl ohne > Softwareunterstützung nicht mal mehr aufs Klo gehen. Hallo Linus Dieses Forum wird mehr und mehr von Gehässigkeit und Häme durchsetzt. Warum hältst Du nicht einfach das Maul? nix für ungut GroberKlotz Karl Heinz Buchegger schrieb: > Linus schrieb: > >> Softwareunterstützung nicht mal mehr aufs Klo gehen. > > Da gibts sicher eine App dafür. http://ruthe.de/index.php?pic=1600
Gast
#2565660
Martin schrieb: > Allgemeine PAP habe ich mir jetzt schon ein paar Beispiele angeschaut, > aber gehören bei einem AVR-Code auch Includes, Defines, > Funktionsprototypen oder Variablendeklarationen in so einem Plan? der C- code gehört nicht an diese stelle der PAP zeigt das problem bzw der lösungssablauf wie das implementiert ist ist dabei total egal http://de.wikipedia.org/wiki/Programmablaufplan PAP ist meist sehr universell gehalten Martin schrieb: > Allgemeine PAP habe ich mir jetzt schon ein paar Beispiele angeschaut, > aber gehören bei einem AVR-Code auch Includes, Defines, > Funktionsprototypen oder Variablendeklarationen in so einem Plan? Dir ist klar, was der Sinn und Zweck eines PAP ist? Nämlich: Einen Ablauf, den Algorithmus zu dokumentieren. Bei einem PAP geht es um das Funktionsprinzip und nicht darum, wie man das in einer Programmiersprache umsetzt. Klar muss es auch bei einem PAP gewisse Regeln geben, aber formale Regeln einer Programmiersprache haben bewusst da drinnen nix verloren. Wenn du einfach nur deinen Code hernimmst und ein paar Rechtecke um Codeblöcke drum herum zeichnest, hast du das Konzept 'PAP' nicht wirklich verstanden und wozu man eines macht.
Gast
#2565691
Karl Heinz Buchegger schrieb: > Dir ist klar, was der Sinn und Zweck eines PAP ist? > > Nämlich: Einen Ablauf, den Algorithmus zu dokumentieren. Bei einem PAP > geht es um das Funktionsprinzip und nicht darum, wie man das in einer > Programmiersprache umsetzt. Du kannst einen PAP auf jeder Abstraktionsebene zur Darstellung eines Ablaufs im Programm verwenden ... Karl Heinz Buchegger schrieb: > Klar muss es auch bei einem PAP gewisse Regeln geben, aber formale > Regeln einer Programmiersprache haben bewusst da drinnen nix verloren. ... und je nach Abstraktionsebene, können natürlich (oder müssen sogar) auch Regeln der zur Implementierung verendeten Programmiersprache verwendet werden. PAP schrieb: > ... und je nach Abstraktionsebene, können natürlich (oder müssen sogar) > auch Regeln der zur Implementierung verendeten Programmiersprache > verwendet werden. Kannst du ein sinnvolles Beispiel nennen, bei dem ein Funktionsprototyp in einem PAP auftauchen muss?
Gast
#2565704
Hm...ich hatte mir das eigentlich so gedacht, dass ich den C-Code in
meiner Arbeit anschaulich und vereinfacht mit so einem PAP darstellen
will, damits jeder sofort versteht. Weil der eigentliche C-Code ja nur
in den Anhang gehört.
Also wenn ich euch jetzt richtig verstanden habe, gehe ich nicht auf
jede Funktion im C-Code ein.
Ich hatte jetzt angefangen mit: Timer1 initialisieren -> Ein-/ Ausgänge
initialisieren -> SPI Initialisieren -> Schleife{Ausgabe: } -> usw.
Habe ich hier einen riesigen Denkfehler? Sind die Initialisierungen gar
nicht relevant bei der Darstellung?
Also soll es nur einen ganz groben Ablauf darstellen?!
Martin schrieb: > Ich hatte jetzt angefangen mit: Timer1 initialisieren -> Ein-/ Ausgänge > initialisieren -> SPI Initialisieren -> Schleife{Ausgabe: } -> usw. > > Habe ich hier einen riesigen Denkfehler? Sind die Initialisierungen gar > nicht relevant bei der Darstellung? Natürlich sind sie es. > Also soll es nur einen ganz groben Ablauf darstellen?! Das kommt drauf an, was du mit deinem Betreuer ausgemacht hast! Mit dem legst du fest, bis auf welche Ebene du die Dinge in einem PAP dokumentierst. Wenn du bei mir deine Arbeit schreibst, dann würde die Vorgabe lauten: In einem PAP will ich in erster Linie das angewendete Verfahren, den Algorithmus erkennen können und dort die Richtigkeit des gewählten Verfahrens nachvollziehen können. Nicht jedoch seine technische Umsetzung. LED Port Pin auf Ausgang setzen | +--> LED einschalten | | | 500 Millisekunden warten | | | LED ausschalten | | | 500 Millisekunden warten | | +---------+ wäre für mich ein perfektes PAP für ein Programm, welches eine LED mit 1Hz blinken lassen soll. Die wesentlichen algorithmischen Teile sind darin enthalten. Ob du die LED am PORTB - Pin B0 oder wo anders anschliesst, welche Anweisung genau du benutzt um die LED einzuschalten, ob die LED eingeschaltet wird, indem du den Portpin auf 0 oder auf 1 setzen musst, das alles sind für MICH Implementierungsdetails, die ICH in einem PAP nicht sehen will, weil sie mich vom wesentlichen, nämlich dem Prinzip mit dem du das Blinken implementierst, ablenken. Wenn ich das sehen will, dann sehe ich mir den Programmcode an. Implementierst du die Blinkerei mit einem Timer, dann will ich das natürlich auch in einem PAP sehen können. Das kann dann eben aus 2 Teilen bestehen: Dem Hauptprogramm und einem nebenläufigen PAP für die Timer-ISR (wenn du eine ISR dazu benutzt). Oder es kann natürlich auch ganz anders aussehen, wenn du den Timer die Arbeit machen lässt. Aber für MICH ist in erster Linie der Algorithmus das, worauf ich mich in einem PAP konzentriere. Dinge wie Datentypen oder Funktionsprototypen sind mir dort egal. PAPs sind eigentlich eher für unstrukturierte Programmiersprachen. Für C ist es sinnvoller, ein Nassi-Shneiderman-Diagramm zu verwenden. Das kannst du auch ganz einfach in Tex machen. http://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm Das macht auch mehr Eindruck :) Wenn es Dir, beispielsweise für den Anhang, um eine saubere Dokumentation des Programms geht, mach folgendes: Du teilst jede Doppelseite in 3 Bereiche auf. Zum einen hast Du die Beschreibung, was das Programmstück macht, welche Daten es verarbeitet, etc. Dann hast Du das Nassi-Shneiderman-Diagramm, und dann daneben den Code. Eventuell noch einen 4. Bereich mit dem erstellten Assemblercode. Die NASA macht das so in ihren Softwareprojekten, denn da ist es wichtig, dass das Zeug läuft. Aber nochmal, so was gehört in der Regel in den Anhang. Es sei denn, Du hast einen wichtigen schlauen Algorithmus, auf dem die Arbeit basiert. Den kannst Du dann auch im Text und ausführlicher behandeln.
Gast
#2565731
Martin schrieb: > aber gehören bei einem AVR-Code auch Includes, Defines, > Funktionsprototypen oder Variablendeklarationen in so einem Plan? Kommt drauf an. Ich würde den prinzipiellen Programmaufbau in einen PAP packen, die Einzelmodule aber mit doxygen dokumentieren. Oliver So könnte ein "PAP" aussehen (nur als Beispiel!) Download "PAP-Designer": [http://www.gso-koeln.de/papdesigner/Download.html] Gruss Ottmar
Angehängte Dateien:
Gast
#2565900
Karl Heinz Buchegger schrieb: > Kannst du ein sinnvolles Beispiel nennen, bei dem ein > Funktionsprototyp in einem PAP auftauchen muss? Der Funktionsprototyp ist nichts anderes als die Signatur einer Funktion. Spontan fällt mir z. B. eine Schnittstellen- / Plugin-Funktion ein, die in einem PAP auftauchen könnte.
Gast
#2565908
So, danke nochmal für alle eure Tips und Vorschläge.. Hab im Anhang mal ein Bild, wie ich es gemacht habe. Der PAP-Designer ist wirklich spitze:-)
Angehängte Dateien:
Welchen Detailgrad man darstellt hängt von der Zielgruppe und allgemein dem Ziel ab. Bei sowas wie einer Bachelorarbeit würde ich die Professoren nicht großartig mit Implementierungsdetails langweilen. Lieber sich im Text mit Algorithmen und ingenieurwissenschaftlichen Überlegungen wichtig machen. Wenn allerdings mangels möglicher "wissenschaftlicher Überhöhung" wirklich Masse vor Klasse angesagt ist, dann würde ich den ganzen Sourcecode durch doxygen jagen. Das gibt zwar keine PAPs, aber viele Seiten und Diagramme (wenn The Dot installiert ist).
Gast
#2565946
Hannes Jaeger schrieb: > Wenn allerdings mangels möglicher "wissenschaftlicher Überhöhung" > wirklich Masse vor Klasse angesagt ist, dann würde ich den ganzen > Sourcecode durch doxygen jagen. Das gibt zwar keine PAPs, aber viele > Seiten und Diagramme (wenn The Dot installiert ist). Die Diagramme sind wirklich nicht gut für die schriftliche Ausarbeitung. Allerdings finde ich es für die eigentliche Dokumentation (z.B. für einen Nachfolger o.ä.) sehr hilfreich. Evtl. wird ja auch noch eine CD mit dem Sourcecode mit abgegeben? Dann finde ich die Doku mit doxygen in Ordnung, weil man dann mit ein paar Mausklicks sich durch den Quellcode hangeln kann. Grüße @Martin freut mich, dass mein Tip bei Dir gut angekommen ist mfG Ottmar
Gast
#2566164
GroberKlotz schrieb: > Warum hältst Du nicht einfach das Maul? Hast gerade gefehlt als in der Schule das Thema "Höflichkeit" dran war, oder? > Dieses Forum wird mehr und mehr von Gehässigkeit und Häme durchsetzt. Das hat nichts mit Gehässigkeit oder Häme zu tun. Nur ist es heutzutage wohl leider die Regel nicht mehr zuerst selber nachzudenken sondern gleich nach einer App zu fragen. Heutzutage gelten nur zwei Dinge: Geiz ist geil und für alles gibts ne App...
Gast
#2566234
@Linus: da muss ich dir zustimmen, dass man es sich mit Apps ziemlich einfach macht. Der Vorteil ist ja heutzutage gerade, dass man hier eher mal einen oder die ganze Community fragen kann. Früher ging das nicht so einfach und man musste sich eher mal selber einen Kopf machen und Stunden oder Tag lang drüber grübeln und probieren. Aber heutzutage ist es auch oftmals stressiger, als früher und da ist es Klasse wenn man sich das Leben mit einer "App" nen bisl leichter machen kann. Antwort schreiben |
Anzeige
|
