Embedded LCD-GUI Programmierung

>Bitmaps(Buttons) mit funktionen belegt,komplette Seiten aufbaut usw.?
>Hierzu muss es doch fertige Libarys geben.

Warum? Es gibt Millionen von verschiedenen Displays.
Welches hast du? Welchen uC benutzt du?

>Wie wird soetwas umgesetzt auf einem uC auf dem kein Betriebssystem
>läuft?

Man programmiert es selbst.

uC und Display habe ich garnicht. Ich will mich nur ein wenig 
theoretisch
informieren.

Unabhängig von uC und Display muss ja der Aufbau so einer GUI immer der 
gleich sein. Sichtbar,Unsichtbar,Coordinaten,Events usw..

Daher frage ich ob jemand einen Link kennt der dieses Thema behandelt.

Jan schrieb:
> kennt jemand hilfreiche Links

Aber natürlich, such einfach mal in diesem Forum. Hier gibt es 
dutzendweise Beiträge, die dir hilfreich sein können.

Aber erwarte bitte nicht, daß andere dir den Brei kochen und du nur noch 
den großen Löffel zu nehmen brauchst. Studiere das, was du hier finden 
kannst und nimm es als Basis, denk dir für dein Vorhaben dann das 
geeignetste selbst aus und programmiere es.

W.S.

Deine Fragen sind ziemlich allgemein gestellt, also wunder dich nicht 
wenn meine Antwort genau so schwammig ausfällt.

Jan schrieb:
> Also wie man die Bitmaps vom uC ins Display bekommt
Über die Datenleitungen?

Jan schrieb:
> Hierzu muss es doch fertige Libarys geben.
Ziemlich viele sogar, googel einfach mal.

Jan schrieb:
> Wie wird soetwas umgesetzt auf einem uC auf dem kein Betriebssystem
Man muss halt alles selbst organisieren.
Aber schau doch einfach mal eines der tausend Projekte an:
http://www.mikrocontroller.net/articles/LCD

Ich glaube dem Jan geht es nicht um die konkrete Umsetzung von 
Graphikfunktionen auf einem bestimmten Display, sondern um eher um das 
Grundgerüst eines HMI Konzeptes.

Ich habe Beruflich ein-zwei Jahre mit EB-GUIDE gearbeitet, das ist ein 
professionelles HMI Design tool mit codegenerierung etc, aber natürlich 
für den Hobby Bereich vieeeeel zu groß.

Deswegen setze ich für mein 128*64 Display (mit touch) ein 
selbstgeschreibenes HMI ein. Das Prinzip ist recht einfach, jedes 
Graphische Element ist ein "widget". Jedes Widget kann eine beliebige 
Anzahl an Unterwidgets haben.
Beispiel: Ein Button-widget enthält ein Iconwidget und ein Textwidget.

Jedes Widget hat bestimmte Grundeigenschaften, z.b.:
  X,
  Y,
  Width,
  Height,
  visible,
  Funktionspointerliste für Funktionen die vor jedem Zeichnen ausgeführt 
werden sollen (z.B. um visible = true oder false zu setzen),
  Funktionspointerliste für Funktionen die bei Touch ausgeführt werden 
sollen.

Habe mir ein Grundset an ~10 Widgets geschreiben (für darstellung von: 
icon, text, zahlen, rahmen / fläche, button, listen, ...; sowie ein 
container widget)

Im Prinzip wird mit den Widgets ein Baum erstellt:
Mutterelement
+ View1
| + Rahmen
| + Button1
| | + Rahmen
| | + Icon
| | + Text
| + Button2
| | + Rahmen
| | + Icon
| + Nummer
| + Text
+ View2
| + ...

In deinem HMI Task (Zykluszeit z.B. 50ms) musst du dann 1) Die aktive 
View bestimmen, 2) Den/Die Touch Event(s) abarbeiten, 3) Die Widgets des 
aktuellen Baums zeichnen

Gibt natürlich auch viele andere Möglichkeiten so ein HMI aufzubauen, 
hier im Forum gabs schon ein paar Beiträge zu dem Thema. Wichtig ist 
eigentlich nur daß man sich vorher Gedanken zu macht wie man das ganze
a) Relativ einfach nutzbar macht, sprich wie schnell&komfortabel man 
sich die Views zusammenprogrammieren kann
b) daß man sich nichts verbaut was zukünftige Erweiterungen angeht

Sorry für den vielen Text, wollte eigentlich nur ein paar Zeilen 
schreiben, aber wenn man einmal dran ist ;-)

Peter

Wenn es was kosten darf:
SEGGER emWin (und ja, es ist von Segger, nicht von Micrium. Micrium 
verkauft es nur zusätzlich unter eigenem Namen genauso wie es die Segger 
J-Links mit anderen Labels von z.B. IAR gibt).
http://www.segger.com/emwin.html

Es gibt bei Segger auch kostenlose emWin Trial Version, entweder für ein 
bestimmtes Evalboard oder für den PC als Simulation (MS Visual Studio 
Projekt).

@Peterguy

Genau mich interessiert der prinzipielle Aufbau des HMI-Konzepts.
Kennts du hierzu vielleicht ein paar Code-Beispiele die ich mir
anschauen könnte. Vielleicht von irgendwelchen Eval-Boards

Schau doch mal hier rein:
Beitrag "Gui System fuer GLCDs"

Ich habe mir das nicht näher angesehen, aber in dem Thread gibt es schon 
mal 2 unterschiedliche Beispielcodes.
Dann gibt es auch noch den Thread hier:
Beitrag "Menu Designer für Grafik LCDs inklusive grafischem Editor"

Vielelicht kommst du auch an den Source code vom Elektor projekt 
"OBD-2-Analyser NG", das dort umgesetzte HMI Konzept finde ich auch 
interessant.
Den Code konnte man mal auf der Elektor seite oder bei Diamex 
runterladen.

Peter

Jan schrieb:
> Kennts du hierzu vielleicht ein paar Code-Beispiele...

Bei embedded Zeugs gibt es genau das meistens nicht. Der Grund dafür 
ist sehr einfach: Viele Leute, die sich sowas ausgedacht haben, haben 
sich für den PC etwas geschrieben, das man vielleicht einen grafischen 
Oberflächeneditor nennen könnte, also eine Soft, wo man die Oberfläche 
der uC-Anwendung am PC entwirft. Anschließend kommt da nur noch ein 
fertiger Quellcode für den uC heraus, der so speziell ist, daß du daraus 
garnix würdest lernen können. Nimm dir lieber die Worte von peterguy zu 
Herzen, er hat eigentlich schon alles Wesentliche zur 
programmtechnischen Umsetzung gesagt.

W.S.