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.
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?
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
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?
"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?
