- LiTime Speicher und Akkus         
Ergebnis 1 bis 10 von 10

Thema: UML (Zustandsautomaten) zur Controller Entwicklung nutzen

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    61
    Beiträge
    22

    UML (Zustandsautomaten) zur Controller Entwicklung nutzen

    Anzeige

    Praxistest und DIY Projekte
    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 )

  2. #2
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    72
    Beiträge
    11.077
    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/in.../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

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    39
    Beiträge
    3.416
    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 ^^

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    61
    Beiträge
    22
    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?

  5. #5
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    72
    Beiträge
    11.077
    Zitat Zitat von astade
    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

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    61
    Beiträge
    22
    Zitat Zitat von PICture
    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

  7. #7
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    72
    Beiträge
    11.077
    Ich versuche immer objektiv zu sein und werde sicher nicht sagen, dass mir etwas gutes nicht gefällt. Viel Erfolg und bis irgendwann !

    MfG

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    08.01.2006
    Beiträge
    4.555
    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

  9. #9
    Erfahrener Benutzer Lebende Robotik Legende Avatar von PICture
    Registriert seit
    10.10.2005
    Ort
    Freyung bei Passau in Bayern
    Alter
    72
    Beiträge
    11.077
    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

  10. #10
    Neuer Benutzer Öfters hier
    Registriert seit
    11.12.2009
    Ort
    Darmstadt
    Alter
    61
    Beiträge
    22
    Zitat Zitat von 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
    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/ze...ag.php?t=51671 ) einen Thread eröffnet und Suche jemanden für ein kleines Beispielprojekt.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus