Pogramm Ablaufplan für Atmegabasic.

[Ralph B. (rberres)]

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

[Christian K. (christian_rx7)]

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

[pegel (Gast)]

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

[Karl M. (Gast)]

Hallo Ralph,

hast Du einen Link zu Atmegabasic ? Habe ich noch nie gehört.

Welche Funktionen benötigst Du noch?

vy73, Ue

[Ralph B. (rberres)]

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

[pegel (Gast)]

Ich habe mir die Kuh noch mal angesehen.

Hast du ein kleines Basic Programm mit Unterprogramm zum Test da?

[Karl M. (Gast)]

Ok Ralph,

Bascom AVR - dazu habe ich noch kein solches Tool gesehen.

vy73 Uwe

[Ralph B. (rberres)]

Karl M. schrieb:
> Bascom AVR - dazu habe ich noch kein solches Tool gesehen.

Das habe ich befürchtet.

Ralph Berres

[Dieter F. (Gast)]

Das ist in der Demo-Version einen Versuch wert:

http://www.aivosto.com/vbcatalog.html

Zumindest ein Ansatz :-)

[Dieter F. (Gast)]

Mit "RealBASIC" als Code-Basis sieht das Ergebnis besser aus :-)

[Cerberus (Gast)]

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.

[Heinz B. (Firma: Privat) (hbrill)]

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.

[Ralph B. (rberres)]

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

[Peter II (Gast)]

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.

[Dieter F. (Gast)]

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 D. (peda)]

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.

[Peter II (Gast)]

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.

[Ralph B. (rberres)]

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

[Yalu X. (yalu) (Moderator)]

Ich habe Visustin auch mal ausprobiert (s. Anhang) und frage mich
gerade, ob die graphische Darstellung (rechts) wirklich übersichtlicher
als die textuelle (links) ist.

[Dieter F. (Gast)]

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 :-)

[Yalu X. (yalu) (Moderator)]

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.

[Dieter F. (Gast)]

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 :-)

[Ralph B. (rberres)]

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