Guten Tag, ich wollte einen Drehzahlmesser als Projekt für die Schule benützen und bin dann auf dieses Projekt hier gestoßen http://extremeelectronics.co.in/avr-projects/avr-project-atmega8-based-rpm-meter/ . Jedoch muss ich noch ein Flussdiagramm bzw. PAP erstellen, aber kenne mich fast 0 damit aus. Ich bekomme schon Nachhilfe, jedoch fällt es mir schwer dieses Thema zu verstehen. Könnte mir vlt. jemand helfen? Danke im Voraus. Bitte keine Beleidigungen oder unnötigen Kommentare, bin leider kein Profi.
Wirklich diese alten PAP, die nicht einmal Schleifen kennen? https://de.wikipedia.org/wiki/Programmablaufplan Oder geht auch ein Nassi-Shneiderman-Diagramm https://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm
Hallo, ein Flussdiagramm wirste bestimmt schon einmal gesehen. Kannste in Powerpoint o.ä. erstellen. Abfragen bzw. Entscheidungszweige mit ja/nein in ein Karo. Reine Datenverarbeitung in ein Rechteck. Du musst nur den Code lesen und umsetzen. Ist fast einfacher wie umgedreht, also wie man es eigentlich macht. Bsp. if in while(1) in ein Karo "ist PD2 High?" ja und nein Verzweigung folgt am Karo ja im Rechteck "setze PB1 auf High" nein im Rechteck "setze PB1 auf Low" darunter Rechteck "warten" Ansonsten wäre die Frage, woran hängt es denn konkret bei der Umsetzung?
Ich glaube beide sind akzeptabel, aber der Lehrer bevorzugt das erste eher mehr.
Da hast auch ein PAP mit Interrupt: Beitrag "Re: Programmablaufplan mit Interrupt" Musst es halt um ein weiteren Interrupt erweitern.
Du musst bei der for- und while-Schleife bedenken, dass diese schon am Anfang auf die Schleifenbedingung testen (nicht am Ende) Eine for-Schleife besteht aus 4 Elementen
1 | for(Init;Bedingung;Inkrement) {Anweisungen} |
Diese kann man auch in eine while-Schleife umwandeln
1 | Init; |
2 | while(Bedingung) |
3 | { Anweisungen |
4 | Inkrement; |
5 | }
|
Bei while kommt die Raute, die bei false an den Anweiungen vorbei geht und hinter der Schleife weiter macht. Bei jedem Funktionsaufruf kommt der Kasten für Unterprogramm. Bei Anweisungen das Rechteck.
Andreas A. schrieb: > Guten Tag, > > ich wollte einen Drehzahlmesser als Projekt für die Schule benützen und > bin dann auf dieses Projekt hier gestoßen > http://extremeelectronics.co.in/avr-projects/avr-project-atmega8-based-rpm-meter/ > . Jedoch muss ich noch ein Flussdiagramm bzw. PAP erstellen, aber kenne > mich fast 0 damit aus. Ich bekomme schon Nachhilfe, jedoch fällt es mir > schwer dieses Thema zu verstehen. > Könnte mir vlt. jemand helfen? Danke im Voraus. > > Bitte keine Beleidigungen oder unnötigen Kommentare, bin leider kein > Profi. Sehr gute Ergebnisse kann man auch mit dem u.g. Tool bekommen. Eignet sich sehr gut für die Beschreibung der fachlichen, fachlich-technischen und technischen Prozessen oder Funktions-Abläufen. https://bizagi.com/de
Beitrag #6646246 wurde von einem Moderator gelöscht.
Andreas A. schrieb: > Ich glaube beide sind akzeptabel, aber der Lehrer bevorzugt das erste > eher mehr. Dann überzeuge ihn davon, dass sich Nassi-Shneiderman-Diagramme nach der DIN 66261 wesentlich besser zur Darstellung blockorientierter Programmabläufe eignen. Beim PAP kann man völlig problemlos strukturell den größten Mist verzapfen und merkt es nichteinmal.
Beitrag #6646267 wurde von einem Moderator gelöscht.
In Deinem Link ist der Quelltext des Programmes ja schon vorhanden, so daß Du nur noch "rückwärts arbeiten" mußt und den dortigen Algorithmus in einen Ablaufplan übertragen mußt. Ich bin ein Fan dieses Programmes für diesen Zweck: http://friedrich-folkmann.de/papdesigner/Hauptseite.html
HörBlossAuf schrieb: > In Deinem Link ist der Quelltext des Programmes ja schon vorhanden, so > daß Du nur noch "rückwärts arbeiten" mußt und den dortigen Algorithmus > in einen Ablaufplan übertragen mußt. Warum? Beim Structorizer kannst man den Quelltext direkt einlesen und erhält ein Struktogramm, dass man dann seinen Wünschen entsprechend überarbeiten kann. https://www.heise.de/download/product/structorizer-57868
Wolfgang schrieb: > HörBlossAuf schrieb: >> In Deinem Link ist der Quelltext des Programmes ja schon vorhanden, so >> daß Du nur noch "rückwärts arbeiten" mußt und den dortigen Algorithmus >> in einen Ablaufplan übertragen mußt. > > Warum? > Beim Structorizer kannst man den Quelltext direkt einlesen und erhält > ein Struktogramm, dass man dann seinen Wünschen entsprechend > überarbeiten kann. > https://www.heise.de/download/product/structorizer-57868 Warum? Weil der TO einen herkömmlichen Ablaufplan haben möchte und nicht diesen unübersichtlichen Nassi-Shneiderman-Kram. Darum.
HörBlossAuf schrieb: > Weil der TO einen herkömmlichen Ablaufplan haben möchte und nicht diesen > unübersichtlichen Nassi-Shneiderman-Kram. Und hinterher versucht jemand aus dem Ablaufplan wieder ein blockorientiertes Programm zu bauen - am liebsten noch mit ein paar eingestreuten "goto"s an strategischen Stellen - so ein Schwachsinn.
Wolfgang schrieb: > Und hinterher versucht jemand aus dem Ablaufplan wieder ein > blockorientiertes Programm zu bauen - am liebsten noch mit ein paar > eingestreuten "goto"s an strategischen Stellen - so ein Schwachsinn. Oh, ein Rechthaber vor dem Herrn... Na dann: Du hast Recht in allen Belangen -jetzt und auch zukünftig und der Mond ist ein Eierkuchen.
Veit D. schrieb: > also wie man es eigentlich macht. Das war vor der Existenz von Hochsprachen. Da entwarf jemand die SW mit solchen Ablaufplänen und jemand anders stanzte das dann. Oder hackte das in Assembler. Seit Hochsprachen machte man PAP oder Nassi-Shneydermann nur noch hinterher zur Doku.
Angehängte Dateien:
-
STX_ETX_ESC.png
58 KB
Hallo, mag alles sein, stelle ich nicht in Frage. Bei größeren Entscheidungsorgien hilft es mir, weil ich dabei nicht schon an den Syntax denken muss, sondern mich rein auf den Ablauf konzentrieren kann. Also der eigentlichen Logik. Erst wenn das dann in allen durchgespielten Situationen passt wirds in Code gegossen. Bei meinem ersten PAP ging es ums filtern von ESC Steuerzeichen im Datenstrom beim einlesen.
A. S. schrieb: > Seit Hochsprachen machte man PAP oder Nassi-Shneydermann > nur noch hinterher zur Doku. Nicht alles, was "man" so macht, ist auch wirklich sinnvoll; oft genug bohrt man auch nur das Brett an der dünnsten Stelle. Wenn ich Quelltexte vorher am Schreibtisch mit Zettel und Stift ausarbeite, ehe ich sie eintippe, enthalten die Programme WESENTLICH weniger Fehler. Trotzdem arbeite ich nur im Ausnahmefall so.
Egon D. schrieb: > Wenn ich Quelltexte vorher am Schreibtisch mit Zettel und > Stift ausarbeite, ehe ich sie eintippe Zettel und Papier aka "handschriftlich" ist etwas ganz anderes als ein PAP oder eine andere Formale Sprache. Wer in Sprache X modelliert um dann in Sprache Y zu tippen, sollte sich doch lieber um einen Codegenerator oder Programmierer bemühen.
Hallo, jetzt wird es aber Unsinn. Seit wann ist PAP eine Sprache? Was ist der Unterschied ob ich einen PAP auf Papier male oder mit einer Software erstelle? Mit Letzterem kann man nur bequemer radieren, korrigieren und verschieben. Ich kann mir auch nicht vorstellen, dass große Projekte ohne vorheriges PAP angegangen werden. Selbst wenn es nur in groben Zügen ist. In Teams sicherlich erst recht nicht. Da programmiert ganz bestimmt niemand wild drauflos. Da gehts ja schon alleine um die Aufgabenverteilung und Schnittstellen.
Du kannst auch erst alles aufschreiben was zu tun ist, und dann später alles an seinen Platz im PAP tun. Nur falls dein Gedächtnis nicht reicht oder das Programm zu groß ist.
Veit D. schrieb: > Seit wann ist PAP eine Sprache? Naja, genauso wie UML oder ein Kontaktplan bei SPS (oder Funktionsblöcke) > Was ist der Unterschied ob ich einen PAP auf Papier male oder > mit einer Software erstelle? Das eine sind Stichpunkte, Drafts, Kritzeleien, Skizzen, ... das andere ist Modellieren. > Ich kann mir auch nicht vorstellen, dass große Projekte ohne vorheriges > PAP angegangen werden. Wie gesagt, zum Austausch mit anderen oder als Vorgabe kann das OK sein. Vor allem, wenn manche die eigentliche Hochsprache nicht sprechen. Man sollte nicht blind losprogrammieren, ja. Das galt insbesondere für Lochkarten oder Assembler. Seit den Hochsprachen stellt sich aber die Frage, ob das, was ich mit PAP darstelle, für micht selbst nicht viel aussagekräftiger in der Zielsprache festgehalten werden kann, wenn diese ebenfalls imperativ ist.
A. S. schrieb: > Seit den Hochsprachen stellt sich aber die > Frage, ob das, was ich mit PAP darstelle, für micht selbst nicht viel > aussagekräftiger in der Zielsprache festgehalten werden kann, wenn diese > ebenfalls imperativ ist. Nee, stellt sich nicht, weil der TO das für jemand Anderen machen muß, dem offenbar der Quelltext unverständlich ist. Ein PAP hat den Vorteil, daß JEDER den Algorithmus sehen kann und auch ein Laie sieht, was getan wird. Daß passt natürlich nicht jedem, der aus seinen überragenden Programmierkenntnissen gern ein Brimborium macht. Davon gibt es ja gerade hier mehr als genug...
Hallo, wir streiten lieber nicht darüber. Wer ein PAP mag oder benötigt soll und darf es machen. Wer ohne PAP klar kommt erstellt eben keins. :-)
Ich verwende auch den Papdesigner und entwickel erst mal ein mehr oder weniger groben Ablaufdiagramm, ehe ich überhaupt anfange ein Programm zu schreiben. Das ist wesentlich übersichtlicher. Hartgesottene mögen einfach drauflos programmieren, und bei kleineren Programme erfolgreich sein. Ich persöhnlich plane lieber vorher ehe ich loslege. Ralph Berres
Oorschwerbleede schrieb: > Nee, stellt sich nicht, weil der TO das für jemand Anderen machen muß, Es ging um die beiden, die meinten, dass man ein pap vorher macht, für sich.
Oorschwerbleede schrieb: > Nee, stellt sich nicht, weil der TO das für jemand Anderen machen muß, > dem offenbar der Quelltext unverständlich ist. Neee, es ist doch offensichtlich. Aufgabe war wahrscheinlich eine typische Schulaufgabe: Zeichne einen PAP für X, dann programmiere X. Statt dessen hat sich der TS ein Programm für X aus dem Netz gezogen und muss jetzt den PAP per Reverse-Engineering gewinnen. > Ein PAP hat den Vorteil, daß JEDER den Algorithmus sehen kann und auch > ein Laie sieht, was getan wird. Oh je, der arme Laie. In PAPs fehlen prinzipbedingt wichtige Informationen und bei nicht-trivialen Algorithmen ist nichts mit sehen was getan wird. Aber hier ist es egal, der TS muss bei seinem Lehrer einen PAP abliefern.
Bei umfangreicheren Programmen,welches in der Bedienung womöglich noch Menues und Untermenues beherbergt, und jede Menge Verknüpfungen hat, macht es schon Sinn, vorher einen PAP zu erstellen. Spätestens nach 2 Jahren wird man Schwierigkeiten haben zu verstehen, was man damals in Code gegossen hat. Wenn ddas Programm alledings nur aus 5 Programmzeilen besteht , ist es in der Tat überflüssig. Bei professionell geschriebene Programme, dessen Quellcode womöglich verkauft wird, ist es ohnehin Pflicht das Programm umfangreich zu dokumentieren. Da ist ein PAP ein Bestandteil. Ralph Berres
Sagt mal habt ihr auch so gut wie immer Fehler im Programm ? Man muss dann immer suchen und hoffen etwas zu finden sonst steht man dumm da - vor allem wenn man nicht schrittweise debuggen kann.
Egal schrieb: > Sagt mal habt ihr auch so gut wie immer Fehler im Programm ? Bei mir hat noch nie ein Programm auf Anhieb funktioniert. Selbst ein Fünfzeiler nicht. Ich musste immer erst Fehler suchen. Aber das Problem sitzt in der Regel zwischen den Ohren. Ich bin nun mal kein geborener Programmierer. Ralph Berres
Ralph B. schrieb: > Bei umfangreicheren Programmen,welches in der Bedienung womöglich noch > Menues und Untermenues beherbergt, und jede Menge Verknüpfungen hat, > macht es schon Sinn, vorher einen PAP zu erstellen. Das geht mit PAP nicht wirklich. Was Du vermutlich meinst ist eine Doku oder eine Übersicht, in der auch Rechtecke, Kreise und Pfeile verwendet werden. Und ja, genau für eine Bedienung (Uhr, Programm, Videorecorder) ist so ein Ablaufplan ok. Der hat aber i.d.R. nichts mit dem inneren Aufbau der SW zu tun sondern stellt eine Beschreibung des sichtbaren Verhaltens dar.
A. S. schrieb: > Was Du vermutlich meinst ist eine Doku oder eine Übersicht, in der auch > Rechtecke, Kreise und Pfeile verwendet werden. siehe Beispiel Es handelt sich hier um einen Frequenzzähler welcher in einen Taketa riken Spektrumanalyzer TR4113 nachgrüstet wurde. Hier wuden sowohl die 4 Oszillatoren in dem Spektrumanalyzer erfasst, als auch die Betätigung der Potis für die Frequenzabstimmung, um eine geschätzte Frequenzänderung verzögerungsfrei angezeigt zu bekommen, bis die nächste echte Frequenzmessung beim Scandurchgang ermittelt wird. Das wäre ohne vorher eine PAP zu erstellen nur sehr schwer gegangen. Ralph Berres
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.