Hallo Leute Ich habe jetzt ein fertigen Programmcode für einen Frequenzzähler vorliegen, welches in meinen Spektrumanalyzer fest eingebaut wird. Dieses Programm möchte ich noch um weitere Funktionen erweitern. Meine Programmierkenntnisse sind in Basic eher rudimär, in C = Null. Als erstes möchte ich das vorhandene Basicprogramm verstehen. Dazu würde ich gerne aus dem Basicprogrammm ein Programmablaufplan erstellen, wo man sieht wann das Programm in welches Unterprogramm springt und wieder zurückspringt. Das Programm besteht aus einen relativ kurzem Hauptprogramm und viele Unterprogramme aus denen teilweise weitere Unterprogramme gestartet werden. Zudem gibt es noch zwei Hardwareinterups mit eigenen Unterprogramme. Gibt es ein Programm, das aus einen vorhandenen lauffähigen Basicprogramm welches als Quellcode vorliegt ein Programmablaufplan erstellt? Oder muss man sowas auf jedenfall mühsam von Hand machen? Der Prozessor ist ein Atmega 64 und das Programm mit der es geschrieben wurde Atmegabasic. Ralph Berres
Für große Programmiersprachen wie z.B.: C# gibt es sowas. In der Zeit wo du für derartige Programme, für deinen speziellen Fall, im Internet suchst, hast du das Programm schon unter Verwendung von Zettel und Hirnschmalz selbst entschlüsselt. Nebenbei lernst du auch noch was über Programmierung und zu den Programmdetails. Somit geht auch nacher die Umprogrammierung schneller. Christian_RX7
Gast
#5080940
Frag mal die Kuh: http://gcbasic.sourceforge.net/index.php Hatte ich mir vor langer Zeit angesehen, bin aber lieber bei C geblieben. Ging graphisch. Weiß zwar nicht was das für eine Sprache ist, aber zum ansehen: https://www.youtube.com/watch?v=z_Opcns20LE
Gast
#5080944
Hallo Ralph, hast Du einen Link zu Atmegabasic ? Habe ich noch nie gehört. Welche Funktionen benötigst Du noch? vy73, Ue
Es ist das Bascom AVR https://elmicro.com/de/bascomavr.html Ich benötige ein Programm, Tool was auch immer , welches mir aus ein vorhandes Basicprogramm einen Programmablaufplan generiert. Man kann zwar die ganzen Verzweigungen auch von Hand verfolgen, und daraus einen Ablaufplan zeichnen, aber das ist eine Arbeit für jemanden der Vater und Mutter erschlagen ,und die Katze vergewaltigt hat. Ralph Berres
Gast
#5080985
Ich habe mir die Kuh noch mal angesehen. Hast du ein kleines Basic Programm mit Unterprogramm zum Test da?
Gast
#5080987
Ok Ralph, Bascom AVR - dazu habe ich noch kein solches Tool gesehen. vy73 Uwe
Karl M. schrieb: > Bascom AVR - dazu habe ich noch kein solches Tool gesehen. Das habe ich befürchtet. Ralph Berres
Gast
#5081018
Das ist in der Demo-Version einen Versuch wert: http://www.aivosto.com/vbcatalog.html Zumindest ein Ansatz :-)
Angehängte Dateien:
-
Flow.jpg
(270 KB)
Gast
#5081027
Mit "RealBASIC" als Code-Basis sieht das Ergebnis besser aus :-)
Gast
#5081034
Karl M. schrieb: > Bascom AVR - dazu habe ich noch kein solches Tool gesehen. Mit Bascom kenne ich mich nicht aus. Die Basic-Interpreter, mit denen ich bisher im Leben Berührung hatte, hatten die Eigenschaft, dass sie Zeilenweise abgearbeitet wurden. Wenn man sich dann für eine Variable interessiert hat, hat man eben mit Print je nach verlangter Syntax den Wert auf dem Bildschirm oder Drucker ausgegeben. Wenn du eine Art Programmprotokoll im Sinn hattest, wird es da wohl nichts geben, weil das kaum was bringen würde, denn die Datenmengen würden das System wohl schnell lahm legen. Hat Bascom denn keinen Simulator/Debugger? Mit diesen Begriffen gibts im Web schon einige Treffer.
Denke auch nicht, daß man sowas findet. Es war ja früher bzw. ist es heute noch so, daß man sich einen Programmablaufplan geschrieben hat und dannach anfängt, den Code für die einzelnen Schritte im PAP zu schreiben. Also gerade umgekehrt.
Dieter F. schrieb: > Mit "RealBASIC" als Code-Basis sieht das Ergebnis besser aus :-) Das sieht schon nicht schlecht aus. Allerdings lässt es sich weder abspeichern noch drucken noc exportieren. Außerdem wird einige Stellen mit einer roten Demo Fläche überdeckt. Aber es ist legitim. Die wollen das Programm ja auch verkaufen. Ralph Berres
Gast
#5081064
Heinz B. schrieb: > Es war ja früher bzw. ist es heute noch > so, daß man sich einen Programmablaufplan > geschrieben hat und dannach anfängt, den > Code für die einzelnen Schritte im PAP > zu schreiben. vermutlich arbeiten weniger als 50% der Software Entwickler nach diesem Prinzip. Die meisten Programme für einen µC sind so überschaubar das man den groben Ablauf im Kopf hat und dann einfach anfängt. Wenn das VB Programm sinnvolle Funktionsnamen hat, dann muss man sie nicht im Detail verstehen, dann reicht es einfach den Aufruf zu sehen.
Gast
#5081074
Ralph B. schrieb: > Das sieht schon nicht schlecht aus. Ja, noch besser, wenn man UML unter Options wählt. Ralph B. schrieb: > Aber es ist legitim. Die wollen das Programm ja auch verkaufen. Hat ja wohl auch Arbeitszeit gekostet. Ggf. kannst Du ja die "Educational" oder die "90-Tage-Version" nutzen (günstiger).
Peter II schrieb: > Die meisten Programme für einen µC sind so überschaubar das man > den groben Ablauf im Kopf hat und dann einfach anfängt. So sehen sie dann aber auch aus. Fehlerüberprüfung, Änderungen oder Erweiterungen sind nur noch schwer möglich. Erst einen PAP anzulegen, hat noch nie geschadet. Die dafür benötigte Zeit holt man beim Coden um ein mehrfaches wieder raus. Gerade MC-Anwendungen mit ihren komplexen Hardwareinteraktionen profitieren davon.
Gast
#5081098
Peter D. schrieb: > So sehen sie dann aber auch aus. Fehlerüberprüfung, Änderungen oder > Erweiterungen sind nur noch schwer möglich. auch mit einem PAP sind Erweiterungen nicht immer möglich. Denn dann müsste man vorher wissen was man später erweitern will.
Peter II schrieb: > auch mit einem PAP sind Erweiterungen nicht immer möglich. Denn dann > müsste man vorher wissen was man später erweitern will. Mir geht es erst mal darum, zu verstehen, wo ich eine Programmerweiterung gefahrlos einfügen kann, ohne das plötzlich das Urprogramm nicht vorhersehebare Fehler produziert. Also ich muss erst mal ganz klar verstehen was das Programm genau macht. Ralph Berres
Ich habe Visustin auch mal ausprobiert (s. Anhang) und frage mich gerade, ob die graphische Darstellung (rechts) wirklich übersichtlicher als die textuelle (links) ist.
Angehängte Dateien:
-
visustin.png
(77 KB)
Gast
#5081219
Yalu X. schrieb: > frage mich > gerade, ob die graphische Darstellung (rechts) wirklich übersichtlicher > als die textuelle (links) ist Das kommt auf die gewählte Form der Darstellung an :-)
Angehängte Dateien:
-
flow2.png
(5,3 KB)
Dieter F. schrieb: > Yalu X. schrieb: >> frage mich >> gerade, ob die graphische Darstellung (rechts) wirklich übersichtlicher >> als die textuelle (links) ist > > Das kommt auf die gewählte Form der Darstellung an :-) Das ist aber eher Zufall. Fügt man bspw. eine weitere Programmezile (a = 0) ein, sieht das Ganze auch in der Darstellung als Activity-Diagramm ziemlich gruselig aus.
Angehängte Dateien:
-
visustin2.png
(53 KB)
Gast
#5081462
Yalu X. schrieb: > Fügt man bspw. eine weitere Programmezile (a = 0) ein, sieht das Ganze > auch in der Darstellung als Activity-Diagramm ziemlich gruselig aus. Wie geschrieben Dieter F. schrieb: > Das kommt auf die gewählte Form der Darstellung an :-)
Angehängte Dateien:
-
flow_3.png
(28 KB)
-
flow_4.png
(29 KB)
Hier mal das Quellprogramm und der PAP dazu. Die Fa war so nett mir das zu übersetzen. Dieses Programm ist ein Frequenzzähler für meinen Tek4113 Spektrumanalyzer und soll noch erweitert werden in dem zusätzlich die beiden Potis Frequenz Grob und fein abgefragt werden. Dazu muss ich das eigentliche Programm erst verstehen. Ralph Berres
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.