graphische Programmierung

[Hanni]

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
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.

[izaseba]

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.

Da kann man gleich mit asm programmieren.

Den finden hier viele Leute gut...

Gruß Sebastian

[Florian]

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)

[ExtreamCoder]

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]

[BT]

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

[teslanikola]

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.

[johannuhrmann]

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

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

Ü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

[Hanni]

Ü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 ...

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*

[Satyr]

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!!!!
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

[pebisoft]

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.