Hi, ich habe mal ne Grundsatzfrage. Die grafischen Programmierumgebungen werden immer besser. Zum Beispiel - Flowcode 3- Nemmen wir mal nicht den Super µC Fetischisten, der jeden einzelnen Transistor im Controler kennnen und ansprechen will, sondern den einfachen User der gelegentlich mal ne Anwendung ralaisieren möchte. Z.B. die der beliebten Heizungssteuerung. ......10 Sensoren, paar LEDs, Relais...... Ist es in diesem Fall noch sinnvol sich in C oder gar Assembler rein zu wurschteln ??? Habt Ihr da Erfahrungen ??? Grüße Micha
Natürlich kannst du für jede Steuerungsaufgabe gleich einen kompletten PC verbauen. Dadrauf läuft dann auch Windows mit VMware, in der wiederum ein Linux läuft, wodrauf dann mit einem Dos-Emulator Windows95 läuft, in welchem dann eine Java-Laufzeitumgebung läuft, die einen AVR emuliert, der dann die Steueraufgabe übernimmt. Die Frage ist halt, stimmt das Kosten-Nutzen-Verhältnis?
>Dadrauf läuft dann auch Windows mit VMware, in der wiederum >ein Linux läuft, wodrauf dann mit einem Dos-Emulator Windows95 läuft, in >welchem dann eine Java-Laufzeitumgebung läuft, die einen AVR emuliert, >der dann die Steueraufgabe übernimmt. LOL
Ja mal abgesehen das VM-Ware ne schöne Sache ist :-) haste schon recht. Aber mal nur die Kosten betrachtet. Ein C-Kurs kostet bei Elektor 250 Eur. aufwärts. Ein Flowcode 189.- . Die Kosten dürften also ziemlch gleich sein. Jetzt musste ja auch noch sehen, was ich an Entwicklungszeiten habe. Meine Frage ging deshalb eher in das für und wieder der beiden Programmierungen. Wie lange brauchst du um z.B. besagte Heizungssterung in C zu schreiben oder in Flow ? Nochmal zur Erklärung. Ich will hier nicht C schlecht machen oder Flowcode vergöttern. Ich wollte nur mal Möglichkeiten und (zeitliche) Grenzen beider Sachen beschnuppern
Micha wrote: > Ja mal abgesehen das VM-Ware ne schöne Sache ist :-) haste schon recht. > Aber mal nur die Kosten betrachtet. Ein C-Kurs kostet bei Elektor 250 > Eur. aufwärts. Ein Flowcode 189.- . Naja, du hast zwei Dinge nicht bedacht: 1. Du musst dir dieses Flowcode-Entwicklungskit noch kaufen. Für C kriegste alles kostenlos und nachgeschmissen (GCC usw.) 2. Vergleich mal die Möglichkeiten und Mächtigkeiten von C und Flowcode. Aber da du sagst, dass es für Gelegenheitsverbrecher gedacht ist, ist das erstmal zweitrangig. >Die Kosten dürften also ziemlch > gleich sein. Jetzt musste ja auch noch sehen, was ich an > Entwicklungszeiten habe. Kann ich leider nich beurteilen, ich kenne Flowcode nicht. > Meine Frage ging deshalb eher in das für und > wieder der beiden Programmierungen. Wie lange brauchst du um z.B. > besagte Heizungssterung in C zu schreiben oder in Flow ? Wie gesagt. > Nochmal zur > Erklärung. Ich will hier nicht C schlecht machen oder Flowcode > vergöttern. Ich wollte nur mal Möglichkeiten und (zeitliche) Grenzen > beider Sachen beschnuppern Hat dir ja auch niemand unterstellt ;-) Stark subjektiv würd ich mal so sagen: * C ist STANDARD. Von wem der Compiler kommt, ist wurscht. Und auf welcher Architektur es nachher laufen soll, ist auch erstmal wurscht * für C krieg ich alle nötigen Programme kostenlos * mit C-Kenntnissen kann ich später auch in anderen Sparten weitermachen (Linux, Desktop-Programme etc.) * Wie lange gibts Flowcode und den Support dazu noch? * Wie abhängig/ausgeliefert bin ich [vom] Hersteller? * Wie Rechenintensiv ist die Sache verglichen mit C? * Wie erweiterbar ist Flowcode verglichen mit C?
In der Entwicklungsphase bist du sicher mit dem Flow-Kram schneller. Vieles wurde dir von dessen Schöpfern abgenommen. Gibt ja mehrere solche Ansätze. Und es kann durchaus besser funktionieren, als so manche Holper-Software, wie man sie hier manchmal sieht. Der Preis, den du dafür zahlst: du wirst die Möglichkkeiten, die der Chip an sich bietet, nicht ausreizen können. Laufzeit wird leiden, ebenso der verfügbare Speicher. Für das og. Beispiel sind das alles keine Kriterien, das hast du in kürzester Zeit zusammengehackt. Brauchst du die volle Performance oder muss das ganze aus Kostengründen in einen kleineren Chip (die Kaufleute sitzen jedem Entwickler ständig im Nacken) wird das eher nichts.
@crazy ja. so isses wohl. da ich auch nur Gelegenheitstäter bin, hatte ich diese Überlegung. Wenn ich mal betrachte was ein "kleiner" oder "großer" AVR kostet macht das bei 3-4 Stück eigentlich nichts weiter aus. Ja und die µC sind ja mittlerweile sowas von "Speichersatt" das man da nicht immmer um jedes Zellchen kämpfen muss. Für mich wäre eigentlich nur wichtig, schnell ( saubere ) Ergebnisse zu haben. Ich möchte ein paar Maschienensteuerungen basteln. Deshalb war meine überlegung mich in C oder Flowcode ein zu arbeiten. Denke mal, ich werd mir mal das Flow kaufen und gucken... Grüße Micha
@sven. Ja du hast auch Recht. Nur die Frage die sich mir stellt, wie lange brauche ich, um meine Ergebnisse zu haben. Ich liebäugle ja auch mit C. Nur ich habe keine Zeit mich da super ein zu arbeiten oder so. Das Problem ist, das ich keinen richtigen Vergleich im Aufwand einer Aufgabe bei beiden Sachen finden konnte. Ich denke mal Flowcode ist da schneller.
Wie siehts z.B. mit folgendem aus: Ansteuerung eines Grafikdisplays das nicht direkt unterstützt wird (was z.B. bei einer Steuerung ja nichtmal so unüblich ist). Ist das mit Flowcode auch so ohne weiteres möglich oder artet das dann richtig in Arbeit und seitenweise Flussdiagramme aus ? Oder der Ansteuerung einer SD Karte um irgendwelche Daten mitzuloggen. Ist man dann auf den Hetsteller (und ein eventuell teures Zusatzpaket) angewiesen, oder kann man auch das selber machen ?
Aus der Werbung: : Verbesserte und neue Eigenschaften der Version Flowcode 3 sind: 16-Bit-Arithmetik, Strings und String-Manipulation, .... : Sowas kann C schon von Anfang an. Wenn du nur mal schnell für 1 einziges Mini-Projekt ein Programm hinmalen willst, mag diese "modernste grafische Programmiersprache" schon so ihren Reiz haben. Aber Industriestandard ist das nicht. Urig ist die Aussage: : ...die Steuerung von komplexen Bausteinen wie 7-Segment-Anzeigen... : Da fallen mir aber auf Anhieb 10 wesentlich komplexere Bausteine ein. Und wenn ich dann auf der Elektor-Seite sowas sehe: : Flowcode 3 für AVR-Mikrocontroller. Flowcode 3 gehört zu den modernsten grafischen Programmiersprachen für AVR-Mikrocontroller..... : Und etwas weiter unten bei den Features dann das: : ...Unterstützung der 18er-Reihe... : Wenn ich zudem weiß, das damit ein PIC18 gemeint ist, dann gibt mir das zu denken. Und ich kann dir nur raten: Auch wenn der Anfang etwas schwerer ist, mit C kommst du weiter.
... lacht nicht über "Flowcode" die µC werden immer leistungsfähiger ( + mehr Speicher), genau wie die damaligen 8068er und deren Nachfolger, werden diese heute auch nicht mehr in ASM programmert! C hat sich auf dem heutigen Entwicklungstand durchgesetzt. Ich bin aber gespannt was in 20 Jahren sein wird!?
Carsten wrote: > ... lacht nicht über "Flowcode" > > die µC werden immer leistungsfähiger ( + mehr Speicher), > genau wie die damaligen 8068er und deren Nachfolger, werden > diese heute auch nicht mehr in ASM programmert! Aber das genau ist doch der Knackpunkt: Dass mehr Leistung z.B. mit mehr Energieverbrauch verbunden oder höherer Störanfälligkeit verbunden ist, ist nicht zu bestreiten. Die Frage ist doch: Ist das gerechtfertigt? Ich meine, natürlich kann ich für den Wecker, den ich gerade bastel, nen ARM mit 60 MHz und mehr einsetzen, obwohl ein AVR voll ausreicht. Die Programmierung wäre dann natürlich viel einfacher und schneller in einer noch höheren Umgebung als ASM oder C zu bewältigen (eben in Flow oder sowas). Aber in diesem Fall beispielsweise würde das Kosten-Nutzen-Verhältnis total schief liegen: Nur um einmal schneller mit dem Programmieren fertig zu werden ("schneller ein Ergebnis zu haben"), nehme ich es dabei in Kauf, dass das Gerät während seiner Lebzeit wesentlich mehr Energie verbrät. Und wenn ich mal ganz übertrieben ein Jahr zur Programmierung C veranschlage und annehme, dass ich das mit Flow in drei Tagen erledigen könnte, ist das immer noch garnichts im Vergleich zur Lebensdauer von meinethalben 70 Jahren. Anders war das bei Computern: Die zunehmende Leistungsfähigkeit hat wesentliche Neuerungen gebracht (Satz, Bild, Video, Ton und so weiter). Aber selbst hier geht es meiner Meinung nach in letzter Zeit den Bach runter. Die Rechner werden nur immer leistungsfähiger, um immer leistungshungrigere Systeme (Paradebeispiel: Vista in der Originalkonfiguration) zu bedienen, die aber ihrerseits keine nennenswerten Fortschritte mehr machen. Immer mehr Klicki-Bunti und Transparenz und Bewegung und Hastenichgesehn, aber außer schön aussehen tut das doch praktisch garnichts. Was Flowcode im Speziellen angeht, muss man aber auch eingestehen, dass die Software da auf ein ganz bestimmtes Klientel abzielt. Das fällt in die Schublade "Man könnte es mit noch einfacheren Mikroprozessoren erledigen, aber deren Beschaffung wäre wiederum unverhältnismäßig". Wie gesagt, da liegt nur ein sehr schmaler Grad zwischen unverhältnismäßig, weil leistungsmäßig total übertrieben und unverhältnismäßig, weil hoffnungslos überaltet und nicht mehr zu beschaffen.
HI >Ein C-Kurs kostet bei Elektor 250 Eur. aufwärts. Ein Flowcode 189.- . Wenn du das Geld in ein paar vernünftige Bücher investierst, hast du wesentlich mehr und wesentlich länger etwas davon. >die µC werden immer leistungsfähiger ( + mehr Speicher), >genau wie die damaligen 8068er und deren Nachfolger, werden >diese heute auch nicht mehr in ASM programmert! Falsch. Ich benutze zur PC-Programmierung Delphi Professional und habe daher auch den kompletten Quellcodes der Libaries. Und da ist noch einiges an Assemblercode drin. >... lacht nicht über "Flowcode" Nö. Warum sollte man über Totbeburten lachen. Etwas Pietät sollte man schon haben
wird ja langsam spannend hier :-) hat den von uns-euch oder wie auch immer schonmal Flowcode "untersucht" ich noch nicht. leider. kenne nur die bunten tollen Bildchen, aus der Flowcode Werbung ...... Aber ich denke mal, wenn man gelegentlich ne Anwendung braucht, nicht unbedingt auf genau -die- Bauelemente beschränkt ist, ist das ne gute Sache. Aber das ist nur meine Meinung :-)
>Z.B. die der beliebten Heizungssteuerung. >......10 Sensoren, paar LEDs, Relais...... Genau richtig für eine mini-SPS. Ganz leichte grafische Programierung (KOP oder FUP). Zum Beispiel.
Hallo zusammen Ich kann`s nur empfehlen.Sollte mal was nicht mit den Flowcode-Macros zu proggrammieren sein,kann man ein c- oder asm- macro erstellen und einfügen.Habe im letzten Jahrhundert Z80,8085 in erfolgreich in assembler programme geschrieben,aber einen modernen pic in asemblersprache anzu- sprechen.........Habe meine Schwierigkeiten als c-Neuling überhaupt in der ide ein komplexes Programm mit int zum Laufen zu bringen. Wie gesagt,mit Flowcode wirklich ein Kinderspiel;aber was man wie machen möchte nimmt einen diese art der Programmerstellung natürlich auch nicht ab!
Die Frage ist was will ich zu welchem Preis erreichen. Will ich schnell eine Steuerung für EINE Maschine haben, dann ist ein Überdimensionierter uC mit toller Grafischer Programieroberfläche bestimmt ganz toll. Als Beispiel: Wenn wir mal eben schnell ne Steuerung für für ein Messe Muster o.ä. brauchen, dann erschlagen wir das mit einer Beckhoff SPS einige tausend Euro teuer und einer flux angepassten Visu in C#, teilweise über Remotedesktop mit nen Laptop im hintergrund. Wenn ich davon eine Serie fertigen Würde könnte das ganze auch mit einer Steuerung für ca 100€ gehen, nur ist der Entwicklungszeitraum entsprechend länger. Natürlich sind in der schnellen Variante die Kosten zur Laufzeit auch deutlich teurer, aber wehn störts ich will ja keine 5 Mio. Stück davon betreiben. Bis aber die Energiekosten die Entwicklungskosten übersteigen dauert es einige Zeit. Also um mal etwas damit zu machen, was man mal ein, zwei mal braucht, und dass vllt. schon gestern, ist eine solche Möglichkeit mit sicherheit nicht verkehrt.
Ich bin der meinung, dass man sich in C einarbeiten sollte. Ich habe jahrelang Assembler geschrieben und habe hier zum Sylvester einen Thread gestartet, ob ich auf C umsteigen sollte. Tja, nach 11 Tagen fühle ich mich in C fit genug um auch größere Projekte anzugreifen. Ich bin begeistert und wundere mich, warum ich es so lange mit Assember ausgehalten habe. Klar fehlt mir noch einiges, um das letzte aus dem Prozessor heraus zu kitzeln, aber das kommt nach und nach... Aber Flowcode? Naja, ich sehe schon die nächsten Posts im Forum, wie der hier letztens: Das ist ja in C, kann das nicht mal jemand schnell ins Bascom übersetzen? (ein 2000 Zeilen Code) Ausserdem hat C einen gewaltigen Vorteil: Der Austausch von Programmen oder Programmteilen mit anderen Usern ist möglich, es muss keine Library zwei mal geschrieben werden, große Hersteller bieten fertige Librarys an. Das waren richtige einsame Zeiten mit Assembler, weil jedes Projekt, das ich mir anschauen wollte, oder nachbauen wollte, in C war, und ich mit Assembler keine Ahnung davon hatte... Und ich bin mir sicher, die Zeiten mit Flowcode sind noch einsamer, als die mit Assember :c)
Die Frage ist auch, wie zuverlässig diese Flowcode-Libs geschrieben sind. Man ist dann quasi in "Gottes Hand", d.h. hat keinerlei Kontrolle, ob Bugs drin sind. Z.B. Stichwort atomarer Datenaustausch zwischen Interrupts und der Main-Task. In Assembler kann und muß man das selber machen. Im AVR-GCC bietet die "atomic.h" komfortable Funktionen dazu an. Man muß aber selber erkennen, wann man sie einsetzen muß. Gerade Bugs in Zusammenhang mit Interrupts sind sehr schwer zu debuggen. Wie sieht es überhaupt mit dem JTAG-Debuggen beim Flowcode aus, ist das möglich? Peter
Hmm.
Hab mir gerade das Flowcode-Demo Video auf Youtube angesehen.
Das Ganze erinnert mich irgendwie an einen graphischen Editor, der über
etwas BASCOM ähnlichem drüber liegt.
Soll heißen:
Der graphische Editor sieht mir mehr nach einer Weiterentwicklung der
syntaxgesteuerten Editoren aus, die es ja schon langge gibt. Der
Programmierer wird davon befreit die exakte Syntax seiner
'Programmiersprache' zu kennen, einfach deswegen, weil es keine gibt,
bzw. weil der Editor sie in Symbole verpackt.
Dazu kommt dann noch ein Vorrat an fertigen Komponenten (wie es sie ja
auch in BASCOM gibt), die angesprochen werden können.
Das damit ein Unbedarfter relativ schnell zu einem Ergebnis kommen kann,
ist von meiner Seite unwidersprochen. Allerdings, denke ich, haben wir
genau das gleiche Problem, das auch hier im Forum immer wieder
auftaucht: BASCOM Programme die einfach zu kurzsichtig linear
herunterprogrammiert werden und die nie vernünftig funktionieren werden,
solange nicht das Grundprinzip geändert wird. Da wimmelt es dann nur so
von Warteschleifen etc. und hinterher wundert man sich, warum man
zeitweilig keine Reaktion vom µC bekommt, wo die doch 'so schnell
wären'. Dass man den µC, durch ungeschicktes programmieren, im Grunde
mit angezogener Handbremse betreibt, bleibt dem Programmierer verborgen.
Er kennt es nicht anders.
Die Frage, die sich hier grundsätzlich stellt, ist doch: Kann man den
Vorgang des Programmierens soweit in ein Schema pressen, dass man einen
Neuling relativ schnell und ohne Vorkenntnisse zu einem halbwegs
vernünftigen Programmierer in diesem System ausbilden kann. Und die
Antwort darauf ist IMHO: jain. Natürlich gibt es immer wieder
Standardfälle, die man in so einem System gut abbilden kann. Für
weitergehendes benötigt man dann aber schon jemanden, der Erfahrung mit
Programmiersprachen und deren Flexibilität hat. Ich erinnere mich nur
allzugerne an die Zeit, als MS mit Excel eine einfache Möglichkeit auf
den Markt brachte, um sich damit mit 'Programmen' das Leben zu
erleichtern. Die Excel-Anwendungen schossen hervor, wie Pilze nach einem
Sommerregen. Und dann wurde alles und jedes in das Excel-Schema
gepresst, egal wie sinnvoll sich der Tabellen-Ansatz eines Spreadsheets
für die Aufgabenstellung eignete. Genauso sahen dann auch die Programme
aus und waren dementsprechend zu bedienen :-)
Sieht man einmal von der Bereitstellung fertiger Komponenten ab, bleibt
für mich eigentlich nur übrig: Ich werde nicht mehr von Fehlermeldungen
des Compilers wegen vergessener ';' oder einer falschen {} oder ()
Schachtelung belästigt, habe dafür aber den Nachteil, dass ein C
20-Zeiler plötzlich 3 Bildschirmseiten mit Ablaufdiagrammen füllt.
Also ich kann Flowcode auch nur empfehlen . Es ist für mich ,der nur ab und an mal etwas programmiert, ein super Programm. Ich habe auch C programmiert , jedoch nach einem Jahr Pause , habe ich den ganzen Syntax vergessen . Es ist wesentlich einfacher mit Symbolen zu arbeiten . Die Erklärungen in der Hilfe sind zwar etwas dürftig aber im Grunde gibt es kaum Probleme . Für alle die hier immer meckern man sei ausgeliefert ... Das ist Schwachsinn . Man kann die Macros ALLE einsehen und ggf. auch bearbeiten . Wie jemand oben schon erwähnte , kann man auch selbst fehlende Programmteile in C oder ASM einfügen . Die Programme sind so viel besser struktiriert und übersichtlicher . Auch nimmt das Programm einem bei der Docu einiges ab . Bevor hier jetzt noch mehr "Freaks" meinen es sei scheiße . Probiert es doch erst einmal aus bevor ihr immer "aber" sagt! Es gibt eine Demoversion die mit begrenzter Chipanzahl arbeitet .
Antifreak schrieb: > Wie jemand oben schon erwähnte , kann man auch selbst fehlende > Programmteile in C oder ASM einfügen . Das setzt dann wieder voraus, daß man eine der Sprachen auch kann ...
Hallo, ich denk das so eine Art Flow-Code sich in bestimmten Bereichen bestimmt durchsetzen wird :-) Programmiere mit C, C# C++, Assembler, LabView. Gerade LabView ist eine sehr mächtige grafische Programmiersprache die auch seine Berechtigung hat. Gruß Gerhard PS: Lerne C die hilft dir bei allen Lebenslagen und Programmiersprachen weiter. --> Nachhaltig wie die Politik so sagt .....
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.