graphische Programmierung

Hallo !!!

Wie ich und meien Kollegen schon des öfteren festgestellt haben werden µC etwas umständlich programmiet. (Flags aus dem Usermanual suchen und soweiter, unleserlicher code...) .

Wir müssen uns bis nächstens Jahr ein Thema für eine Diplomarbeit suchen und da kamen wir auf die Idee ein Programm zu entwickeln wo man graphisch seine Funktionen aufziehen kann und Bausteine auswählen kann wo man dann komfortabel z.B die Baudrate der RS232 einstellen kann.
Ich stelle mir dass so ähnlich vor wie das bekannte Programm LabVIEW.
Als Resultat bekommt man dann eine fertige hex datei oder c datei.
Wo das Programm zu unflexibel ist könnte externer Code eingebunden werden, oder einfach im Programm dazugeschrieben werden. So ähnlich wie bei der Ablaufsprache (SPS) .

Mich würde jetzt interessieren ob für ein solches Programm grundsätzlich Interesse bestehen würde oder ob ihr graphische Programmierung überhaupt als Vorteil seht. Ich muss nämlich auch dazu sagen, teilweise kann einem sowas auch benachteiligen. Jedoch für Anfänger wäre es sicher besser.

Hallo ExtreamCoder!
Grundsätzlich dürfte das selbe Problem wie bei Basic-Programmierern, nur noch etwas extremer, herrschen.
Man verliert das Innere des Mikrocontrollers aus dem Auge und kann mit der internen Hardware garnichts mehr anfangen, was gerade bei Mikrocontrollern meiner Meinung nach sehr wichtig ist.
Allerdings kann ich mir vorstellen, dass es eine extreme Vereinfachung des Copy/Past ist und somit auch nicht schädlicher als das solche bzw. es ist genauso hilfreich, vielleicht sogar hilfreicher, da es grafisch dargestellt wird.
Das Problem der Hardwareentfremdung könnte man sicherlich in Grenzen mit ein paar grafischen Darstellungen aus der Welt schaffen, aber 100%ig wird das nie möglich sein.
Man kann dann halt sehr schnell Programme auf dem Copy/Past-Prinzip aufbauen, aber alles, was flexibler sein muss, wird schwierig zu erstellen sein.
Für einfache Programme dürfte das Programm ok sein und Zeit sparen und auch flexibler als Copy/Past sein, aber für richtige bzw. komplexere Programme kann man denke ich das Programm nicht verwenden.

Ich möchte Dir jetzt nicht die Euphorie zerstören und im Prinzip finde ich die Idee auch gut, aber ob sich in Zukunft eine grafische Programmierung durchsetzen wird ist die zweite Frage.
Ich werde mich überraschen lassen und bin gespannt, was ihr daraus macht!

Ich wünsche euch viel Erfolg! :o)

Zitat:

---

Diplomarbeit

---

Mit 17?!

Sowas in der Art?

Also Interesse wäre schon vorhanden, allerdings kommt man mit solchen Tools meistens nicht so weit, wie gleich reinen QT zu schreiben (s. Webentwicklungs-Tools ala Frontpage & Co.)...

Die Idee ist im Prinzip sicherlich gut, doch gerade bei µC muss man mit dem Speicherplatz aufpassen und eine grafische Programmiersprache muss sehr flexibel sein, weil man mit Text schon einiges machen kann.
Allgemein muss man ja auch sagen, dass sich grafische Programmiersysteme nicht wirklich durchgesetzt haben, genauso wie die Versuche deutscher Programmiersprachen. Man müsste mal schauen wieso (was ja sicher auch in eine Diplomarbeit sollte) und dann könnte man genau das berücksichtigen.

MFG
ProgDom


P.S.: Du schreibst mit 17 deine Diplomarbeit ? Ich meine das solls ja geben, aber ich bin froh, dass ich mit 17 anfangen kann zu studieren ^^

Das klingt ein wenig so wie Beans bei Java.
Ist eigentlich ganz praktisch und gibt es sogar schon für einige Controller
(z.B. von Freescale für deren 56fxxxx - Serie).
Ich habe gerade angefangen damit meine Diplomarbeit zu schreiben und finde ein Einstellen und einfachen anderen einfachen dingen ist das sehr schön.

Trotzdem muß man weiter wissen, wie der Controlelr aufgebaut ist, sonst ist das Programm alles andere als effektiv.

Eine Simple I2C-Kommunikation in Software schaffte mit den Beans gerade mal 100kHz Bustakt. Per Hand (und gar nicht mal so viel mehr Aufwand) hab ich sie dann auf 10 MHz gebracht :-D

Heiiii ! Eine SPS auf AVR-Basis !! Goile Sache, das !!
Derzeit habe ich noch einige Siemens Logo-Steuerungen im Einsatz, die aus Platzgründen (Modellbau !!) unbedingt verkleinert werden müssen. Wenn diese Steuerung auch nur annähernd den Umfang der Logo hat, DAS wäüre super !!

http://www.microsps.com/

LabView ist eine geniale Sache, ich prgrammiere schon seit Jahren damit. Man erstellt damit Programme um den Faktor 5-10 schneller als mit C.

National Instruments ( die Firma, die LabView herstellt ) bietet mitlerweile auch schon die Möglichkeit, Mikrokontroller auch direkt in LabView zu programmiern, allerdings nur einige größere Derivate.

Ich persöhnlich verwende immer die Kombination LabView auf dem PC unc C im Mikrocontroller ( siehe chris.lugr.de ).

Eine Strategie von National Instruments dürfte die immer breitere Unterstützzung von Mikrocontrollern sein.

Für Matlab/Simulink gibt es ebenfalls Tools, den Code direkt in einen MC zu laden.

Gruss,
stochri

Jedoch für Anfänger wäre es sicher besser....

der anfänger wird sich schwer tun aus diesem grafischen trott herauszukommen. er wird sich später keine mühe mehr geben bei der kleinsten ungereimtheit den eigenen kopf anzustrengen um in das datenblatt zu schauen, sondern wird sofort ein forum belästigen.
es wird für diese programmierer der gassenblick entstehen der für ein eine zukünftige enwicklung der wirtschaft nicht gesund ist.

Zitat:

---

Zitat von Pebisoft

der anfänger wird sich schwer tun aus diesem grafischen trott herauszukommen. er wird sich später keine mühe mehr geben bei der kleinsten ungereimtheit den eigenen kopf anzustrengen um in das datenblatt zu schauen, sondern wird sofort ein forum belästigen.

---

Erinnert mich irgendwie an den Basecom Bereich hier im Forum ....

Andererseits ist eine Änderung in der µC-Programmierung längst von Nöten.
Es ist zeitaufwändig, fehlerproduzierend und nervig jedes bit im Usermanual nachzulesen. Da kann man gleich mit asm programmieren.
Toll wäre wenn man vielleicht die Programmierung von µC standadisiert und verschiedene Klassen zu den jeweiligen Controllern entwickelt. Um so einfach mit verschiedenen Methoden den Controller steuert.
Mir ist schon klar, dass alle Controller unterschiedliche Hardware besitzen jedoch könnte man eine Basisklasse Controller entwickeln und z.B davon 80C517 ableiten.

Zitat:

---

Zitat von ExtreamCoder

Andererseits ist eine Änderung in der µC-Programmierung längst von Nöten.
Es ist zeitaufwändig, fehlerproduzierend und nervig jedes bit im Usermanual nachzulesen. Da kann man gleich mit asm programmieren.

---

Ich rate mal, ein bascom User :D
Im übrigen, weiß ich bei ASM zumindest wieso was passiert ....

Sicherlich wäre für enige Anwendungsfälle so eine Graphische Programmentwicklung nicht schlecht.

Allerdings dürfte diese Art der Programmierung gerade bei umfangreichen Projekten und vor allem bei zeitkritischen Sachen recht unbrauchbar sein.

Des weiteren sehe ich ein gewisses Problem darin, den resultierenden Code nicht zusätzlich mit unwichtigem Kram zuzumüllen (z.B. in ner ISR erst mal pauschal alle Register auf den Stack schieben obwohl ich nur 2 brauche ...)


Grüße,
da Hanni.

Zitat:

---

Andererseits ist eine Änderung in der µC-Programmierung längst von Nöten.
Es ist zeitaufwändig, fehlerproduzierend und nervig jedes bit im Usermanual nachzulesen.

---

Ich weiß wirklich nicht, wo das Problem liegt...
Es ist wohl nicht sooooo schwer mal eben im Dattenblatt nachzuschauen.
Außerdem für Sachen wie UART,I2C,LCD kann man sich ja seine Bilbiotheken schreiben, und immerwieder benutzen, es ist wohl schneller getan eben eine Header Datei per COPY/PASTE in das neue Projekt einzufügen, als irgendwelche klicki,bunti Oberflächen zu benutzen.

Zitat:

---

Da kann man gleich mit asm programmieren.

---

Den finden hier viele Leute gut...

Gruß Sebastian

Zitat:

---

Den finden hier viele Leute gut...

---

Stimmt und ich gebe Dir recht, aber ich bin halt doch jetzt auf C umgestiegen, weil ich fauler geworden bin! ;o)

Zitat:

---

Ich rate mal, ein bascom User

---

Mit Basic hatte ich noch nie was am Hut.
Angefangen hab ich mit C.
Dann bin mit C zu C++ weutergewachsen und jetzt programmiere ich hauptsächlich Anwendungen mit Java.
µC programmiere ich hauptsächlich in C den 8051 oder den atmega8.
Es stimmt schon wenn man mal seine Funktionen zusammen hat kann man auch gut arbeiten, wie bei der Asuro-lib jedoch hab ich mich mittlerweile an objektorientierung gewöhnt. [/quote]

grafische programmierung? also ich arbeite hiermit:

http://www.myavr.de/download/video_pap.exe

wenn man sich erst mal dran gewöhnt hat ist es cool ;-)

Zitat:

---

LabView ist eine geniale Sache, ich prgrammiere schon seit Jahren damit. Man erstellt damit Programme um den Faktor 5-10 schneller als mit C.

---

Harhar ich Progge in ASM das versägt dein LabView schon beim anlassen!!!!

Ich muss Florian recht geben, das verständnis ist mei µCs wirklich wichtig und was die Flags angeht, die setzt der µC schon selber, nur was sie bewirken sollte dir geläufig sein oder du solltest wissen wos steht ;-)
Aber mal im ernst: Ein Code ist immer so unübersichtlich wie in der Programmierer tippt, wenn du mal ne Code ohne Komentierung und Formatierung gesehen hast zb wie es manche Dissassembler ausspucken, dann begint bei jedem Programmierer der Kopft zu rauchen. Ich muss jetzt echt mal sagen wie glücklich ich bin mit ASM angefangen zu haben, die Jahre in BASIC waren zwar richtig leichtu und für den Anfang recht IO aber seit ich mit ASM angefangen hab verstehe ich erstmals richtig wie in µC arbeitet wie man den Code optimal auf die Hardware anpassen kann ohne gleich alles Softwareseitig von meinem Compiler erzeugen zu lassen. Für mich ist ein µC nicht mehr eine Blackbox mit x-Pins, sondern eine kleine Welt in der ich Gott bin.

Von Grafischer Programmierung halte ich nicht viel, ist zwar nicht so komplex, aber das resultat ist einfach ein Tropfen wasser in einem Ozean, es gibt heute schon recht gute Compiler aber ich denkemal das die in vielen Jahren erst annähernd die leistung erbrigne werden was der Programmierer alles machen kann.

Zitat:

---

Zitat von Hanni

Allerdings dürfte diese Art der Programmierung gerade bei umfangreichen Projekten und vor allem bei zeitkritischen Sachen recht unbrauchbar sein.

---

Das kommt darauf an, wie gut das umgesetzt ist und wie flexibel sich auch mal
C oder Assembler einbinden lassen.

Oder anders gesagt: Warum ist C nicht "recht unbrauchbar", um Controller zu programmieren?
Weil man im Notfall auch schonmal auf Inline-Assembler zurückgreifen kann

Zitat:

---

Zitat von Hanni

Des weiteren sehe ich ein gewisses Problem darin, den resultierenden Code nicht zusätzlich mit unwichtigem Kram zuzumüllen (z.B. in ner ISR erst mal pauschal alle Register auf den Stack schieben obwohl ich nur 2 brauche ...)

---

Woher weiß den gcc, dass er nur zwei Register auf den Stack pushen muss?
Ganz einfach: Er optimiert.
Es ist nicht verboten, auch einen anderen Compiler optimieren zu lassen O:)

Übrigens: auch GCC + AVRLibC ist nicht perfekt, hier wird z.B. ein Register unnötig als "Zero register" verheizt.

Lange Rede, kaum ein Sinn:

• Es gibt m.E. kaum einen Grund der gegen eine graphische Programmierung spricht

• Wenn es ein Cross-Compiler wird, der C-Code erzeugt, dann lassen sich die Optimierungen des C-Compilers nutzen. Das ist vermutlich einfacher, als die Optimierungen selbst nochmal zu entwickeln (siehe auch ISRs in Bascom)

• Das Komponentensystem der graph. Entwicklungsumgebung muss in der Lage sein, für die jeweilige Zielplattform die entspr. Komponenten bereitzustellen

• Idealerweise ist das Komponentensystem durch den Benutzer erweiterbar (Plugins)

Hans

Zitat:

---

Zitat von johannuhrmann

Übrigens: auch GCC + AVRLibC ist nicht perfekt, hier wird z.B. ein Register unnötig als "Zero register" verheizt.

---

Was IMHO nicht unbedingt schlecht sein muss ... es kann durchaus ein guter Schritt zur Code Optimierung sein ...

Zitat:

---

Zitat von johannuhrmann

Es gibt m.E. kaum einen Grund der gegen eine graphische Programmierung spricht

---

Doch, mindesetens einen ganz gewichtigen ... Der User wird nicht mehr gezwungen sich mit der Hardware ansich auseinanderzusetzen oder gar ein Datenblatt zu lesen.

Einen Trend dazu kann man hier im Bascom Bereich des Forums durchaus schon beobachten ...


Und zum Thema Zeitkritisch: Nur, wenn ich weiss, was der Compiler im jeweiligem Fall ausspuckt, kann ich sagen: Es dauert so oder so lange ... nur, sieht man eher selten, was der Compiler ausspuckt .... deswegen bleiben solche Applikationen wohl meistens eine Assemblerdomaine ...


*mal zurückzitier* :D

Hallo Leute!
Ich arbeite in einem Kraftwerk als Leittechniker. Hier finden sogenannte GET-Systeme ihre Verwendung. GET bedeutet Graphic Engineering Tool.
Da stehen die verschiedenartigsten Bausteine am oberen Bildschirmrand zur Auswahl, welche man dann sehr bequem in den Plan einfügen kann. Zuletzt werden die Ein- bzw Ausgänge miteinander und mit den ZULI`s (Zuordnungslisten) verbunden.
Auch bei den S5 Systemen von Siemens hat man mehrere Modis zur Auswahl-->AWL (Anweisungslisten)-KOP (Kontaktplan)-FUP (Funktionsplan).
Bei uns werden ausschließlich AWL und FUP verwendet.
Natürlich werden diese Pläne danach generiert, wobei der Computer die Pläne in den Maschinencode umwandelt und auf Fehler überprüft. Ist dieser Fehlerfrei, gibt er ihn zum Codetransfer frei. Wenn nicht, heist das Fehlersuche bis der Arzt kommt!!!! :-s
Danach müssen noch die HMI´s generiert und übertragen werden (Human Machine Interface). Sonst sieht die Wartenbesatzung nichts!
Natürlich bekommt man bei dieser Arbeitsweise vom eigentlichen µProzessor NICHTS mit!!
Diese Programme laufen unter Unix und sind Anwendungen in der Art wie Excel bei Windows.
Allerdings ist der Prozess auch so schon anstrengend genug!!!! Wenn ich da noch die Bausteine selbst programmieren müßte........und die Ingres-Datenbank....aaaargh!
So gesehen sind grafische Programierhilfen sehr angenehm!!
lG Satyr

grafische programmierung? also ich arbeite hiermit:

http://www.myavr.de/download/video_pap.exe

wenn man sich erst mal dran gewöhnt hat ist es cool ....und man bleibt doof über das innenleben des avr...


nicht empfehlenswert von der stiftung warentest.

Zitat:

---

.und man bleibt doof über das innenleben des avr...
nicht empfehlenswert von der stiftung warentest.

---

wie meinst du das? das hardcore avr assembler... an welcher stelle bleibt man denn da doof über das innenleben des avr?

cu BT

Hallo BT!
Im Pulsdetektorforum kenne ich einen, der sich auch BT nennt. Ist die Abkürzung für Böses Tier. Bist du es etwa.....?
lG Satyr

Hallo Satyr,
tja das Internet ist eben doch nur ein Dorf ;-)
Hast du dir mal angesehen was wir mit dem Hobbyelektroniker in letzter zeit so angestellt haben? Wir bräuchten da noch die eine oder andere Anregung um dem Elektrosmog Herr zu werden :-k ... schau mal unter dem Thema Motherbord ins Forum.

cu BT
483!

Den Grundgedanken find ich gar nicht so übel.
Mir stellt sich nur die Frage wie man alle Funktionen für den Programmierer erreichbar machen will. Ich progge selbst mit Bascom weil ich mir die Sprache selber beigebracht hab. Da dort aber trotz des großen Funktionsumfanges nicht alles Verfügbar ist (die Hardware PWM des Timer0 zum Beispiel) fummel ich immer mehr ASM-Befehle in die Bascomtexte mit ein. Lohn der für mich recht mühseeligen rumfuchserei (hab von ASM eigentlich kaum nen Schimmer) ist der deutlich kleinere Code. Bei einem reinen Grafiktool sehe ich auch die "Gefahr" das der Anwender aus mangelndem Wissen über den Controller selbigen einfach zumüllt anstatt sich durch die Bedienungsanleitung zu lesen. Letzteres wird im allgemeinen übrigens gerne immer weniger gemacht was manchmal zu recht bescheidenen Fragen seitens der Lesefaulen führt. ;)

P.S.: Mit der SPS (Step5) stand ich von Anfang an auf Kriegsfuss - aber nur weil ich eine Vorschädigung in Sachen Basic hatte und mir viele Sachen in letztgenannter Sprache hätte wesentlich schneller programmieren konnte als die Aufwändige Fuchtelei in den jeweiligen Programmiermodi der SPS. Hab ja "zum Glück" jetzt nix mehr damit zu tun.

Hallo zusammen,

bin im Begriff ein kleines Projekt aufzubauen.
Da ich von MC's (noch) nicht so viel Ahnung hab, hab ich die Funktion erst mal über eine kleine Siemens SPS realisiert.
Würde das ganze aber gern kleiner besser schneller machen ;)
Leider kann ich nur HTML. und etwas Basic.
Vielleicht hab ja einer von euch Lust und Zeit mir bei der Programmierung eines ATmega8 unter die Arme zu greifen.

hier mal das bestehende SPS Prog. aber nicht lachen
http://mikado.dyndsl.com/index.htm

gruß mikado

ich glaube für die Lego Mindstorms gibts so eine graphische programmieroberflöche. denk kids haben auch keine lust sturen quelltext zu schreiben.

Jo für Mindstorms gibts sowas, da zieht man einfach so kleine Blöcke hin und her und ich muss sagen dass das Programm eig. ganz gut gelungen ist.
Nur so ein Lego Teil hat ja nur 3 Aus und 3 Eingänge, damit bietet er einem auch nicht so viele Möglichkeiten.
Ich denke für einen richtigen Mikrocontroller ist sowas nicht geeignet, da man halt wie gesagt nicht alle Möglichkeiten ausnutzen kann.
Ich glaube sogar für Anfänger ist es auch nicht so gut da man nicht lernt wie das überhaupt funktioniert, und das ist ja eigentlich das wichtigste.

ich fänds ganz toll!

weil:
ich den microdingens noch nicht wirklich kapiere, und damit auch nicht die weltherrschaft an mich reißen möchte.
Hab beim ASM schrieben immer das Gefühl, in den großen zahnrädern in meinem hirn hängt sand unds läuft ganz zäh..
hab ich sonst nie, das Problem,stundenlang dazuhocken und es wird nix...

Nur sollte man dann umschalten können, zwischen den grafikteilen, und dem asm-code.

so könnte man wenn man will immernoch die einzelnen teile optimieren wie man sie braucht.

##############################################
Beispiel was ich gerne hätte:
Eingabe:
5Pins abfragen: spannung, lambdawert, temperatur sowas.
Ausgabe:
Anzeige aufm lcd in der und der anordnung

Das wären jetzt 3 oder 4 fertige bausteine. die ich anreihen müsste und mit pfeilen verknüpfen
und ich hätte mal was was funktioniert, und was ich mir dann bei Bedarf im Code anschauen kann.

Tja, nur wenn du dich nicht mit dem ASM ausseinandersetzt wirst du es dann wahrscheinlich nie ganz lernen... Ich kann dir übrigens Bascom empfehlen, schau's dir mal an ;-)