Zitat Zitat von PICture
Ich bin daran interesiert ein Programm zu entwickeln, dass die hardwarenahe Programmierung (ASM) von diversen µCs ohne Programmierungskenntnissen ermöglichst und werde mich gerne daran beteiligen. Als von CPU unabhängige "Programmiersprache" für alle mögliche µC sehe ich nur PADs.
PAD="ProgrammAblaufDiagram" ist nicht die einzige Möglichkeit Programmabläufe darzustellen. PADs sind immer dann geeignet, wenn relativ komlizierte Abläufe (Algorythmen) dargestellt werden sollen. Also z.B. ein Sortieralgorythmus.
Dies sind aber nicht die schwierigen Fälle, bei der µC Programmierung.

Richtig spannend wird das ganze, wenn auf unterschiedliche Ereignisse (Tasten, Sensoren, Timer) "gleichzeitig" reagiert werden soll und das natürlich auch noch unterschiedlich, je nach Betriebszustand. Solche Aufgaben löst man dann mit "Zustandsdiagrammen" (state charts).

http://astade.de/doku4a29.html?id=sc...ots:statechart

Der Link verweist auf ein sehr einfaches Zustandsdiagramm, das ein Treppenhauslicht realisiert.

Das Framework, dass mir vorschwebt, kann solche Zustandsdiagramme realisieren und mehrere davon gleichzeitig parallel ablaufen lassen. Das klingt vielleicht jetzt kopliziert, ist aber ganz einfach, wenn man weiss wie
Für Desktop Computer habe ich das bereits implementiert.

Zitat Zitat von Ceos
man müsst eben nur die parallelen prozesse berücksichtigen, wenn ein timer überläuft, springt dein programm aus dem prozess heraus und führt etwas aus, was den restlichen programmfluss beeinflusst!
Genau das kann man mit Zustandsautomaten realisieren! Man kann mehrere Zustandsautomaten quasi "parallel" betreiben. Alle Zustandsmaschinen im Programm "werkeln" quasi unabhängig von einander vor sich hin (Außer sie schicken sich gegenseitig "Nachrichten"). Man bekommt dann so etwas ähnliches wie "multithreading". Windows 3.11 funktioniert so.

Drücke ich mich verständlich aus?