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

Ü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