Flowcode

Moin,

ich dachte mir, man könnte ja mal einen neuen Thread aufmachen ;-).

Habe hier die Januar Ausgabe der Elektor liegen (ich weiß, ich weiß). Die stellen dort ein Board mit einer Software Flowcode 3 vor. Eine Webseite dazu gibt es auch:

formatting link

Kennt jemand die Software Flowcode und taugt die was? Liest sich irgendwie interessant und mit der Trial von TINA CAD der gleichen Firma habe ich mal etwas rumgespielt und das sah nicht schlecht aus.

Wobei ich mich frage, ob so ein Tastatur-Jünger wie ich überhaupt mit so einem KlickiBunti Kram klar kommt ;-).

73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Reply to
Thomas 'Tom' Malkus
Loading thread data ...

Hi,

Das System kenne ich nicht (allerdings habe ich auch erstmal interessiert geschaut). Ich habe aber vor Jahren mal ein graphisches Entwicklungssystem für Java verwenden _müssen_ (der Kunde bestand darauf) und fand es einfach nur grauslich... in der Zeit, in der man da Symbole durch die Gegend schob, hätte man mit "richtigem Code" wesentlich mehr bewirken können.

_Mir_ erschien das damals als Notnagel, um Leuten, die nicht in Programmabläufen denken können, trotzdem die Entwicklung von Progrämm_chen_ zu ermöglichen.

Deshalb... > Wobei ich mich frage, ob so ein Tastatur-Jünger wie ich überhaupt > mit so einem KlickiBunti Kram klar kommt ;-).

würde es mir da jedenfalls wohl so gehen.

Gruss Michael Kutscher

--
www.kutschersoft.de
Reply to
Michael Kutscher

Ich kenne Flowcode auch nicht, aber prinzipiell ist es nicht schlecht, grafisch zu entwickeln. Mit LabView geht das gut. Flowcode sieht allerdings so aus, als wäre es nur eine umständlichere Schreibweise für ein lineares C-Programm, in das es übersetzt wird (so sieht es zumindest in den Videos aus), ohne die Vorteile, die z.B. LabView bietet, wie implizite Parallelverarbeitung, ähnlich einer Schaltung.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Michael Kutscher schrieb: ...

Grmpf... Ich darf jetzt CodeWarrior "benutzen".^K Ich werde gerade durch CodeWarrior am Programmieren gehindert.

Ich hatte mich sogar noch durch Übungen mit qt-designer auf Klicki-Bunti-IDEs vorbereitet, aber der Schock war dennoch groß.

Volle Zustimmung! Der Zyklus vi XXX.c - make - gdb XXX ist schneller durchlaufen als die ganze Klickerei. Leider läuft arm-gcc schreiend weg, wenn er die vom Kunden bereitgestellt Bibliothek linken soll...

Ich bin da ganz sicher. Diese IDEs kann jeder Depp bedienen. Als Folge werden die auch überwiegend von Deppen bedient und so sehen die Ergebnisse dann auch oft aus.

Die Schmerzen vergehen...

Falk P.S.: Zum Glück gehen im Norden die Uhren anders. Fertigstellung war für's 4. Quartal geplant, weil aber ein Ing. Erziehungsurlaub machte, wurde auf das 1. Quartal verschoben. "Prima, denke ich, drei Monate Zeit." Es kommt aber noch besser: Es ist *nicht* das 1.Q. 2009 gemeint, sondern das 1.Q. 2010!

Reply to
Falk Willberg

,

Tja, Weihnachten (2009) kommt immer so pl=F6tzlich... :-) Gruss Harald

Reply to
Harald Wilhelms

Harald Wilhelms schrieb:

Macht nix, dann sind ja noch drei Monate Zeit.

Falk

Reply to
Falk Willberg

Frank Buss meinte:

Hmm, das verstehe ich nicht, gibt es bei der Erstellung von FlowCharts eine Parallelverarbeitung? Das wird doch eigentlich soweit heruntergebr- ochen, dass immer nur eine Funktion überbleibt.

Was mir eigentlich vorschwebt ist eine Software mit der man grafisch das Grundgerüst des Programmablaufes darstellt und daraus dann ein Codegerüst erzeugt, mit dem man dann die Details ausarbeitet. Es geht mir auch etwas um die Ablaufdokumentation.

73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Reply to
Thomas 'Tom' Malkus

Nein, bei einem normalem Flussdiagramm gibt es keine Parallelverarbeitung:

formatting link

Es gibt allerdings bei UML sogenannte Aktivitätsdiagramme, die ähnlich sind und parallele Pfade zulassen:

formatting link

Man kann auch andere Funktionen daraus aufrufen, was Grundkonzept der strukturierten Programmierung ist.

Flussdiagramme beschreiben den Ablauf eines Programms. Gerade für Hardwaresteuerung ist es meist besser, den Datenfluss statt den Programmfluss zu modellieren. Ladder Logic ist z.B. ein erster Ansatz, das besser zu machen:

formatting link

Das ist nicht beschränkt auf grafische Darstellungen. VHDL ist ein Beispiel für so einen Ansatz in eher konventioneller Programmtext-Form (wobei Quartus von Altera es aber auch erlaubt, Funktionsblöcke, die in VHDL programmiert sind, visuell und auch rekursiv zusammenzuschalten), aber nicht gut geeignet, es per Microcontroller-Programm umzusetzen, weil da fast alles parallel ist und sehr feste Timingvorgaben eingehalten werden müssten.

Ein anderes Beispiel ist Flow-based programming:

formatting link

Hier sind die einzelnen Blöcke eigenständige kleine Programme, die quasi parallel laufen (oder auch real parallel auf Mehrprozessorsystemen) und über definierte Schnittstellen untereinander kommunizieren. Gibt Abwandlungen davon speziell für den Embedded Bereich, z.B. hier:

formatting link
formatting link

Ich habe mal mit einem der Entwickler in comp.lang.lisp diskutiert und der kannte zufälligerweise auch den Entwickler des Flow-based programming Konzepts persönlich.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Historisch gabs im Telecombereich SDL seit den End-70er in grafischer Form und aus praktischen Gründen parallel dazu in ASCII. Nicht unmittelbar für Parallelverarbeitung gedacht sondern für Austausch von Nachrichten zwischen Programmen, Signalisierung. War CCITT Projekt, wurde von Akademiologen, zeitweise Firmen wie Ericsson, Philips usw. in Telefonanlagen & Endgeräten verwendet. Wurde für ISDN-Specs verwendet. Auch automotive Firmen wie Bosch scheinen sich zeitweise dafür erwärmt zu haben. Hat sich aber trotzdem nicht durchgesetzt. Und wird heute "durch UML abgelöst". Wenns SDL nicht in geschafft hat ( d.h. relativ kompakte Variante für konkrete Anwendung ) bin ich aber mal skeptisch ob UML ( eierlegendes Wollmilchschwein ) jemals praktisch relevant wird.

MfG JRD

Reply to
Rafael Deliano

Frank Buss meinte:

Beruhigend, das mein Wissen nicht schon wieder veraltet ist ;-).

Das kenne ich aus meiner Schulzeit, Schützschaltungen und SPS.

Man kann sich auch das Gehirn künstlich verknoten ;-). Das mag vielleicht bei großen Projekten sinnvoll sein, möchte ich ja nicht abstreiten.

Für einen Einzelentwickler wie mich, der eher eine Arbeitsentlastung durch ein simples Tool für die Dokumentation sucht ist das dann etwas übertrieben.

Ich denke, FlowCode ist für mich auch nicht das ultimative Tool. Aber Dein Tip mit der Ladder Logic ist nicht übel, das ist eine mir vertraute Darstellung mit der man schnell die Zusammenhänge zwischen In und Out grafisch gestalten kann. Auf die einfachsten Varianten kommt man nicht.

Dazu noch doxygen für die Code-Dokumentation und DocBook für die Hand- bücher und Online-Hilfen und es paßt.

73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Reply to
Thomas 'Tom' Malkus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.