UML (Zustandsautomaten) zur Controller Entwicklung nutzen

[astade]

Ich bin Entwickler in einem Open Source Projekt das eine Programmieroberfläche zur UML gestützten Softwarentwicklung entwickelt hat.

Oder anders ausgedrückt: Astade (http://astade.de) kann C Code für Zustandsmaschinen generieren, die grafisch gezeichnet wurden.

Dies funktioniert heute schon für Linux und Windows Programme.

Jetzt möchte ich mich in die Controller Programmierung einarbeiten. Ich plane, mir ein kleines Entwicklungsboard zu kaufen (warscheinlich AVR) und dann ein Framework zu schaffen, dass es ermöglicht grafisch entworfene Zustandsdiagramme auf dem Controller auszuführen.

Dies hätte mehrere Vorteile:
1. Der Code wird besser wiederverwendbar
2. Der Code wird besser verständlich
3. Der Code wird leichter dokumentierbar
4. Es ist leichter in einer Simmulation am PC zu testen

Meine Fragen dazu sind:
1. Gibt es sowas oder was ähnliches schon (als kostenlose Open Source Software)
2. Haltet Ihr das für nützlich (oder braucht das keiner)
3. Hat hier jemand Lust, mitzumachen
(weniger die Tool Realisierung, dass schaff ich schon. Aber bei der Definition der Anforderungen und dem Test des Tools könnte ich Hilfe gebrauchen, zumal meine Erfahrung in der Controller Programmierung noch ziemlich am Anfang steht ;-) )

[PICture]

Hallo astade!

Ich kenne die Astade nicht, deswegen möchte ich mich nur kurz über Programmieren von Microkontroller (µC) äussern.

Ich habe bisher verschiedene CPUs in Maschinensprache (Assembler bzw. ASM) programmiert bevor ich auf Microkontroller (µC) umgestiegen bin. Dafür habe ich in BASIC einen universiellen Assembler geschrieben und benutzt, wo für bestimmte CPU alle nötige Mnemonics in einer Textdatei enthalten waren, die für Erzeugung eines ausführbaren Codes benutzt wurde. Deswegen finde ich es auch für verschiedene µC als möglich.

Bisher musste ich immer ein Programmablaufdiegramm (PDA) "per Hand" in die von Assemblierungsprogramm verständliche Reihenfolge von Mnemonics übersetzen.

In unserem Forum sind überwiegend AVR und PIC µC benutzt und es gibt bisher keine Möglichkeit die Erfahrungen zwischen den Benutzern von unterschiedlichen µC auszutauschen. Es könnten PDAs sein, wenn sie automatisch in Maschinensprache für beliebigen µC übersetzt werden könnten. Ich kenne aber bisher kein solches Programm, obwohl es sehr nütlich wäre. Sowas würde die Wahl des µCs für jede Anwendung erleichtern.

Als Lektüre über PIC µCs würde ich dir einen Artikel aus unserem Wiki empfehlen:

https://www.roboternetz.de/wissen/index.php/PIC_Assembler

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.

MfG

[Ceos]

ich fände das eine super idee, aber ich sehe auch ein problem des aufwandes, wenn du dir z.B. die umfangreichen bibliotheken der Atmel controller anschaust

da ist so ziemlich JEDER controller bereits vollständig mit registern, sortiert nach funktionsgruppen, in form von makros und stukturen definiert

das AVR studio und AVR-eclipse plugin bedienen sich dieser headerfiles und bieten dynamische hilfen zu den einzelnen bits in den entsprechenden registern an ...


... wenn es dir gelingt diese headerfiles zu parsen und entsprechende grafische templates für die funktionen und register anlegst, sollte es ein kinderspiel sein, ein framework zu konstruieren

die weitere programmierung, nach der initialisierung der peripherie ähnelt extrem einer konsolenanwendung, sollte also danach recht leicht auf eure vorhandenen erfahrungen aufbauen können

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! desweiteren kann man die programme mit den entsprechenden stdlib-befehlen usw. so schreiben, dass man sie defakto auch mit dem normalen GCC für den PC compilieren könnte ... nach anpassung der includes ^^

[astade]

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=screenshots: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.


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?

[PICture]

Man bekommt dann so etwas ähnliches wie "multithreading". Windows 3.11 funktioniert so.

Ich bin eher Hardwarespezialist und kenne den Unterschied zwischen einem PC (den ich früher in ASM für selbstentwickelte Hardware programmiert habe) mit Betriebsystem und einem "primitiven" µC (den ich jetzt für Robotersteuerung in ASM als Multitasking programmiere).

Die Zustandsdiagramme kenne ich nur theoretisch und habe ich sie bisher in der Praxis noch nie angewendet. Deshalb sehe ich sie für µC ungeeignet, weil sie zu umfangsreich sind.

MfG

[astade]

Die Zustandsdiagramme kenne ich nur theoretisch und habe ich sie bisher in der Praxis noch nie angewendet. Deshalb sehe ich sie für µC ungeeignet, weil sie zu umfangsreich sind.

Das werden wir sehen. Ich glaube das eigentlich nicht. Wir haben bei meiner letzten Firma schon auf dieser Basis für µCs entwickelt, und zwar mit großem Erfolg. Allerdings mit "Rhapsody" einem sehr teuren (und trotzdem gar nicht so guten) komerziellen Programm.

Aber ich will gar nicht theoretisieren. Ich werde ein Code Beispiel machen, und dann können wir das Beispiel diskutieren. Werde allerdings einige Tage dazu brauchen. Melde mich wieder :-)

[PICture]

Ich versuche immer objektiv zu sein und werde sicher nicht sagen, dass mir etwas gutes nicht gefällt. Viel Erfolg und bis irgendwann ! :)

MfG

[Richard]

Kennt ihr Proteus ? Ein Bekannter arbeitet damit und "Klickt" aus
Symbolen ganze Anwendungen für z.B. AVR's zusammen. Der Mann
schreibt sietdem keine einzige Zeile Code mehr und die Schaltungen
arbeiten ohne Probleme.

Selber habe ich damit noch nicht gearbeitet, weil ich weder die original
Russische noch die Englische Version "brauchbar" verstehe. :-(
Außerdem befürchte ich das Mensch damit auch leicht "verblödet" und
ganz verlehrnt was sein µC eigendlich macht.

Gruß Richard

[PICture]

Hallo!

Ich habe vor zig Jahren, wenn noch keine µC gegeben hat, gelernt, dass die Zustandsdiagramme sich nur für Automaten eignenn, die synchron arbeiten und nicht von aussen beeinflüsst werden.

Deswegen könnte ich sie bisher bei µCs nicht anwenden, weil durch Interrupts, konnte ich die Zustandsdiagramme, ohne sie erheblich zu komplizieren, nicht erstellen, da die Interrupts einen synchronnen Automaten zum unsynchronen machen.

Bei bisher von mir benutzten PADs habe ich das Problem nicht gehabt, da sie jederzeits prüfen von allen inneren und ausseren Automatenzuständen ermöglichen.

Ein mit µC gesteuerten Roboter kann man als Mealy-Automat betrachten und ich habe ihn bisher als nichtdeterministischer endlicher Automat programmiert, da der Zustandsgraf des Automaten sich leicht in PAD umwandeln lässt.

Ich lasse mich aber gerne über inzwischen enstandenen Neuigkeiten belehren, damit ich wieder hoffentlich auf dem Laufendem bin.

MfG

[astade]

Ich versuche immer objektiv zu sein und werde sicher nicht sagen, dass mir etwas gutes nicht gefällt. Viel Erfolg und bis irgendwann
MfG

Ich habe das Framework die letzten Tage entwickelt und auf meinen Desktop läuft es jetzt eigentlich ganz gut. Leider ist der Nutzen nicht so einfach darstellbar, wenn man es nicht anhand eines konkreten Projekts sehen kann :( Jetzt müsste ich ein schönes Beispiel für einen Mikrocontroller machen, wo man dann man den Nutzen des ganzen sehen kann.

Dazu habe ich jetzt unter systeme ( https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=51671 ) einen Thread eröffnet und suche jemanden für ein kleines Beispielprojekt.