Forum: Mikrocontroller und Digitale Elektronik Methodik/Werkzeuge zur Softwareentwicklung (GUI) in C


von Gast (Gast)


Lesenswert?

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?

von Michael (Gast)


Lesenswert?

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.

von dave (Gast)


Lesenswert?

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

von Rene B. (themason) Benutzerseite


Lesenswert?

@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.

von Gast (Gast)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

dave schrieb:
> machs doch in c#, da hast du mit ein paar mauskicks ...

wie programmierst du denn?

von Mark B. (markbrandis)


Lesenswert?

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?

von Guru Guru (Gast)


Lesenswert?

>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

von Karl H. (kbuchegg)


Lesenswert?

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 :-)

von TheMason (Gast)


Lesenswert?

@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.

von Nick M. (Gast)


Lesenswert?

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

von dave (Gast)


Lesenswert?

>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

von Klaus W. (mfgkw)


Lesenswert?

und vor allem kann man dann auch eine Maus anklemmen, die
notfalls dran glauben muß :-)

von Gast (Gast)


Lesenswert?

Vielen Dank für die ausführlichen Antworten! Das sind ein paar gute 
Ansätze, ich werd's ausprobieren!

von Daniel G. (daniel83)


Lesenswert?

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

von Gast (Gast)


Lesenswert?

Ich glaube MVC ist ein guter Tipp - gibt's dazu Beispiele für C?

von Nick M. (Gast)


Lesenswert?

> 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

von Mark B. (markbrandis)


Lesenswert?

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?

von Gastbenutzer (Gast)


Lesenswert?


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
Noch kein Account? Hier anmelden.