Ich bin dabei eine Steuerung mit GUI in C auf 'nem Mikrocontroller zu realisieren, habe aber nicht den Hintergrund in Softwareentwicklung, der zum effizienten Vorgehen notwendig wäre. Ich kann mir jetzt irgendwelche Kästchen auf Papier zeichnen, um zu versuchen, Daten, Programmfluss und -struktur übersichtlich zu dokumentieren/planen, allerdings wird das nicht übersichtlich und auch nicht wiederverwendbar (und für andere nicht unbedingt verständlich). Besser wäre da ein Vektorgrafikprogramm, aber effizient ist das nicht, wenn es echte Tools für sowas gibt. UML könnte man evtl. benutzen, da zumindest meine GUI mehr oder weniger objektorientiert ist, auch wenn C das natürlich nicht direkt unterstützt. Allerdings kann ich nicht einschätzen, ob UML der richtige Weg ist, da es sehr viele Dinge abdeckt, die ich nicht unbedingt brauche (habe mir kurz UMLet angesehen). Kennt sich damit jemand aus und könnte mich in die richtige Richtung weisen?
Hast du im Zugriff eine Bibliothek? Dann schau da mal nach dem Begriff "Software Design", da sollten dann Bücher zu Tage kommen, die sich mit der Softwareerstellung beschäftigen, wie man das ganze plant und entwickelt ;). Sicher findet man auch im Internet zu diesem Begriff den ein und anderen lehrreichen Link.
machs doch in c#, da hast du mit ein paar mauskicks eine super gui. die syntax ist nicht so schwer zu erlernen, sonst kannst auch native-c code über dlls einbinden
@gast ich z.b. gehe so vor, das ich mir ein system überlege wie ich die daten der grafik-objekte am besten beschreibe (bzw welche daten ich benötige, wie ich texte vereinheitlicht darstellen kann, wie "seiten" (zusammenschluß mehrerer objekte zu einer darstellungsseite) beschrieben werden und wie die schnittstellen zu meinen objekttypen (objekt-funktion) auszusehen haben. danach prüfe ich wieviel speicher in etwa für die gesamt-gui (sofern abschätzbar) benötigt wird und optimiere ggf die datenstrukturen. danach fange ich entweder direkt auf dem mikrocontroller an oder schreibe mir eine simulation. simulation heißt in dem falle das ich unter visual studio mir eine konsolenanwendung schreibe die über eine passende schnittstelle (z.b. memory mapped file oder mailslot) daten an eine "dumme" gui weiterschickt die mir auf dem pc das ergebnis präsentiert. mit "dumme" gui meine ich das z.b. ein grafik-display simuliert wird, welches einfach nur einen speicherbereich grafisch darstellt. dieser speicherbereich wird dann von der konsolenanwendung ferngesteuert. das hat den vorteil das wenn man die sw-schnittstelle zum display (egal ob virtuell oder in hardware) gleich hält (put/getpixel, kopieren von bitmaps, linien, rechtecke usw) so gut wie nichts am code (des eigentlichen gui-kerns wohlgemerkt) ändern muß um diesen vom pc auf den uc zu portieren (kleine ausnahme ist der avr, aber dafür kann man sich einfach makros schreiben und programmiert dann unter visual studio wie man den avr programmieren würde (stichwort : pgm_read_byte etc)). damit habe ich letztlich eine gui für ein touch-display geschrieben (zugegeben : die gui ist zuerst auf dem avr entstanden, habe aber nachher eine portierung geschrieben um erstmal alle seiten auf dem pc durchprogrammieren zu können, aber seitdem kann ich 1:1 zwischen simulation und echter hardware umschalten) ich hoffe dir mit dieser vorgehensweise tipps bzw. eine mögliche lösung deines problems geben zu können.
Hi Rene, danke, sehr aufschlussreich. Allerdings hapert es bei mir schon an dem von dir im ersten Satz beschriebenen System ("Seiten", Objekttypen, Schnittstellen). (Von der grafischen Darstellung der Strukturen mal abgesehen.) Ich bin allerdings auch kein C-Experte, d.h. wahrscheinlich fehlt mir auch das Wissen um die Möglichkeiten der Sprache, so dass ich manche Ansätze gar nicht entwickeln kann. Ein Gedanke war eine Art relationale Datenbank für die Menüstruktur. Also eine Liste aus Strukturen (ID, Parent, Name). Damit könnte man beliebige Baumstrukturen abbilden und mehr. Das bedeutet allerdings auch relativ hohen Rechen und Speicheraufwand. Wahrscheinlich müsste man auch die Reihenfolge der Elemente in einer Ebene sicherstellen. Also relativ viel Suchen und Sortieren. Dann könnte man durch die Struktur navigieren (hoch zu parent, runter zu allen elementen mit parent == id). Dann stellt sich die Frage, was denn eigentlich ein Knoten in dem Baum überhaupt darstellt. Ist es ein Wert? Ist es eine Funktion ("Seite")? Welche Art Wert ist es? Ich glaube ein Handy-Menü ist ein guter Vergleich. Man hat den Startbildschirm, ne Liste mit Einstellungsmenüs, Untermenüs, dann einzelne Werte (Datum, Telefonnummer, Zeit, Name, ..) Es ist aber auch ein Enter-Button zum Speichern, und die Softkeys (Optionen) Wie wird das gemacht? Dann die grafische Hierarchie. Bildschirm Aktive Fläche Darstellung von Werten (z.B. Liste) Eintrag in der Liste Bezeichner Wert Woher stammen Stil (Position, Farbe) Werte, Aktionen? Wird alles neu berechnet, wenn ein Element neu gezeichnet wird (z.B. nur die gerade bearbeitete Weckzeit)? Ist die Weckzeit ein "Objekt", dass seine Position und alles gespeichert hat? Gibt es irgendwo ne Liste mit Stilen, und das Objekt zeigt auf einen Listeneintrag? Es wird dann schon etwas kompliziert.. Der Hintergedanke ist ja, dass man das ganze so dynamisch umsetzt, dass man für Änderungen im Menü nicht an 3 Stellen irgendwelcher State-Machine-switch-Anweisungen herumdoktorn muss.
dave schrieb:
> machs doch in c#, da hast du mit ein paar mauskicks ...
wie programmierst du denn?
Rein vom Prinzip her ist UML schon der richtige Ansatz. Man kann auch durchaus nicht-objektorientierte Dinge mit ihr beschreiben, die Programmiersprache ist mehr oder weniger egal. C kommt jedenfalls absolut in Frage. Die Frage ist aber auch, wie komplex denn das Ganze überhaupt ist. Auf einem eher kleineren Mikrocontroller mit einer eher einfach GUI bringt es vielleicht nicht so viel, wenn man monatelang UML-Diagramme zeichnet ;-) Hab mal mit dem Enterprise Architect von Sparx Systems gearbeitet für ein Mikrocontroller Projekt... war im Endeffekt doch eher Overkill. Alternativen siehe hier: http://de.wikipedia.org/wiki/UML-Werkzeug#Programme Such Dir halt die Dinge raus an Deinem Projekt, die Du mit der UML vernünftig beschreiben kannst. Und sei es ein einfaches Sequenzdiagramm, das eben einen zeitlichen Ablauf verdeutlicht. Ansonsten, gibt es ein Pflichtenheft? Oder ein Lastenheft? Wenn nein, dann schreib eins: -Was soll die Software tun? (a, b, c und d) -Wie könnten die Eingabemasken aussehen (beispielhaft)? Wieviele Menuüpunkte wird man sinnvollerweise benötigen? -Wie kann man a, b, c und d sinnvoll in Module einteilen? Was gehört logisch zusammen, was nicht? Wie könnte die Interaktion zwischen den Modulen aussehen?
>Kennt sich damit jemand aus und könnte mich in die richtige Richtung >weisen? In solchen Fällen nehme ich das MVC Design Pattern. Guru
In solchen Fällen ist mein (und wahrscheinlich nicht nur meiner) erster Schritt, das Universalwerkzeug Papier und Bleistift zu benutzen. Hintergrund: Die µC die ich verwende sind zu klein, als dass es sich lohnt da ein 'One Size Fits All' Menüsystem zu entwerfen, bzw. das bringe ich einfach nicht in den µC rein. Also werden die Menüpunkte erst mal, unabhängig davon wo sie realisiert werden, aufgezeichnet. Welche Submenüs gibt es, wie hängen sie zusammen? Welche Möglichkeiten zur Eingabe habe ich? Wie kann ich mit meinen Eingabemöglichkeiten durch die Menüstruktur navigieren. Wobei: Durchnavigieren ist meistens eh kein Problem. 4 Eingabemöglichkeiten reichen da dicke: Menüpunkt rauf + Menüpunkt runter + Auswählen + Zurück Habe ich nur 3, dann kriegt Zurück keinen eigene Eingabemöglichkeit, sondern taucht als Menüpunkt im Menü auf. Interessant sind dann auch immer die unterschiedlichen Konzepte, wie Eingaben, sei es Texteingabe oder Zahleneingabe gemacht werden kann. Wie gesagt: Das alles passiert zunächst auf dem Papier und ein Radiergummi ist unverzichtbares Hilfsmittel. Ziel ist es, die Anforderungen an das fertige System festzulegen. Habe ich zb nur ein 4-zeiliges LCD, und in meinem Menübaum taucht ein Submenü mit 5 Menüpunkten auf, dann wäre zu überlegen, ob man das nicht umgestalten kann, sodass es nicht notwendig ist, durch Menüs zu scrollen. Sind jedoch 80% aller Menüs länger als 4 Zeillen, kann man sich überlegen ob man nicht 2 Menüpunkte nebeneinander stellt. Jetzt ist es zb wieder gut, die Hierarchie schon zu kennen, denn jetzt kann man alle Texte abklappern, ob das gehen wird. Etc. Und erst dann, wenn ich exakt weiß, welche Anforderungen ich an mein Menüsystem habe, geht es los die einzelnen Strukturen zu entwerfen. Zielpunkt ist es, dass ein Menü nach Möglichkeit eine einzige Struktur (natürlich mit Verkettungen in andere Menüpunkte/Menüs) darstellt. Aber da ich schon eine gewisse Vorstellung davon habe, wie dieses System verwendet wird, ist es auch leichter, die Einzelteile zu entwerfen. Wenn du allerdings wirklich hoch hinaus willst, ein komplettes graphisches GUI mit Fenster an allen Ecken und Enden, die sich überlappen und dynamisch auf und zu gehen, dann solltest du einem anderen GUI erst mal eine Zeitlang bei der Arbeit genau zusehen. Da finden sich dann so einige Gemeinsamkeiten und Spezialitäten, die auch in eine Klassen-Hierarchie einfließen werden. Aber allem gemeinsam ist: Selbst wenn du Dinge wie UML verwendest, geh nicht von der Vorstellung aus, dass dein erster Entwurf gleich perfekt sein wird. Da hilft es auch nichts, wenn du tagelang auf irgendwelche Klassendiagramme starrst. Ob die Einzelteile gut zueinander passen, ob und wenn ja welche, Änderungen notwendig sein werden, lernst du hauptsächlich dadurch, dass du implementierst. Wenn du dabei bei jedem Problem, auf das du unweigerlich kommst, darüber nachdenkst, ob dieses Problem durch eine Designentscheidung entstand oder nicht, und keine Scheu davor hast, auch wieder mal an den Anfang zurückzukommen und das Design zu ändern, hast du gute Karten. Was natürlich für dich erschwerend hinzukommt ist, dass du selbst von die sagst nicht der beste C-Programmierer zu sein. Ein allgemeines Menüsystem ist zb ohne Funktionspointer nur sehr umständlich zu realisieren. Mit diesem Hilfsmittel hingegen wird es deutlich einfacher. Nichts gegen UML und Konsorten. Aber ich hab schon des öfteren die Erfahrung gemacht, dass solche 'Hilfsmittel' ganz schnell zum Selbstzweck geworden sind. Unendlich viel Zeit wird darauf verwandt, wunderschöne Diagramme zu erhalten .... die dann leider mit der Implementierungsrealität nichts zu tun haben. Das heißt jetzt nicht, dass man nicht planen soll. Gott bewahre - nein. Aber mit Papier und Bleistift hat man eine Flexibilität, die ihres gleichen sucht :-)
@gast um dir mal ein paar anregungen bzgl realisierung zu geben ... bei mir sind die einzelnen grafik-elemente byte-codiert abgelegt. das erste byte bestimmt die operation bzw den objekttyp. die ersten 16 werte sind für einfache operationen (linie, text, pixel, feste bitmaps). alles über 16 bestimmt eine "externe" objekt-funktion die z.b. einen schalter oder einen schieber darstellt. dabei haben die unterschiedlichen objekte auch unterschiedliche längen (byte-mässig). es gibt daher auch einen mechanismus zu ermitteln wieviele bytes ein element belegt (das gilt für die festen operationen genauso wie für die objekttypen). dadurch ksnn ich die elemente durchparsen. das wird z.b. benötigt um zu testen ob ein klick (durch das touch-panel) innerhalb eines bestimmten objektes liegt. oder um eine komplette seite upzudaten. die byte-abfolgen sind dann in seiten organisiert. sprich ich habe einen zeiger und eine längenangabe und der zeiger zeigt auf die einzelnen grafik-elemente. durch verwendung eines indexes (dahinter verbirgt sich in einer tabelle dann der zeiger und die längenangabe) habe ich direkt einfachen seitenzugriff. der zugriff auf die daten erfolgt über das objekt. das läuft so : ich habe innerhalb des byte-streams ein byte welches auf eine tabelle zugreift in der ein pointer auf meine nutzdaten hinterlegt ist (das kommt daher das ich leider keinen direkten zeiger in den byte-strom einfügen kann (würde einiges erleichtern). die objekt-funktion weiß ja an welcher stelle innerhalb des byte-stroms das byte für die zeiger-tabelle steht. die objektfunktion bekommt als parameter den zeiger auf die aktuelle position im bytestream sowie einen opcode. der opcode kann z.b. initialisieren, zeichnen, teste auf position, behandle klick, behandle sonstige events sein, und je nachdem was dieses objekt kann muß die funktion entsprechend implementiert sein. ist vllt etwas kompliziert erklärt, aber das prinzip ist recht einfach und sehr mächtig. vor allem lässt sich dieses prinzip recht leicht skalieren (also für kleine displays 96x32 bis 640x400). bei gelegenheit stelle ich mal meine ergebnisse in der code-sammlung ein.
MVC + Papier & Bleistift. So clicki-tools halten nur ab. Kann man aber nachher immer nich damit machen wenn man es dokumentieren muß. Achso, MVC bedeutet nicht Microsoft Visual C! **örks** Gruß, Nick
>dave schrieb: >> machs doch in c#, da hast du mit ein paar mauskicks ... Klaus Wachtler > wie programmierst du denn? ja, die maus wird gekickt wenns nicht gleich funktioniert, das beruhigt hatte mich verlesen, dachte Gast will ein Gui Programm für den PC machen, mit dem er einen µC steuern kann. aber wenns schnell und einfach gehen soll: auch für µCs gibts das ".net micro framework", mit dem man c# auch für kleinere µCs programmieren kann (32 bit, schon etwas ram...). für guis ist sowas halt super geeignet, für echtzeitfähige sachen eher weniger. da brauchst dir dir dann auch nicht soviele gedanken über programmfluss zu machen, da alles sehr intuitiv über das visual studio funktioniert
und vor allem kann man dann auch eine Maus anklemmen, die notfalls dran glauben muß :-)
Vielen Dank für die ausführlichen Antworten! Das sind ein paar gute Ansätze, ich werd's ausprobieren!
Hallo Gast >Ich bin dabei eine Steuerung mit GUI in C auf 'nem Mikrocontroller zu >realisieren was denn ganau? Nen bsichen ausgabe auf 4*20Pixel oder eine 800*600 Windows klick klack Oberfläche? Gruß Daniel
Ich glaube MVC ist ein guter Tipp - gibt's dazu Beispiele für C?
> Ich glaube MVC ist ein guter Tipp - gibt's dazu Beispiele für C?
"Defensives Autofahren. Gibts dafür Beispiele für BMW-Fahrer?" ;-)
MVC ist Sprach-unabhängig. Es genügt wenn du dich ans Prinzip hältst.
Wenn du Beispiele in C lesen willst, musst du dich erst in die
Bibliotheken einarbeiten, das hält nur ab und verwirrt.
Gruß,
Nick
Gast schrieb:
> Ich glaube MVC ist ein guter Tipp - gibt's dazu Beispiele für C?
Was ist Dein Model, was ist Dein View, was ist Dein Controller?
MVC kenne ich eigentlich eher nicht losgelöst von einem Betriebssystem
mit grafischer Oberfläche. Und selbst dann verwendet man meist noch ein
Framework dafür (wie Qt, Swing etc.)
Auf einem kleinen Mikrocontroller mit wenig Speicher, kleinem LCD als
Anzeige und wenigen Tastern/Knöpfen zur Eingabe ist das ziemlich sicher
Overkill. Also, wie komplex soll es sein, und auf welcher Hardware soll
es laufen?
Auch interessant: Beitrag "Modellierung und Implementierung reaktiver Systeme, Statecharts, UML, C, Diagramme, OO/nicht-OO"
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.