Forum: Mikrocontroller und Digitale Elektronik grafische Benutzeroberfläche mit einem AVR?


von Michel K. (nover)


Lesenswert?

Hallo an all

Meine frage ist wie kann man am sinnvollsten eine grafische 
Benutzeroberfläche für einen AVR Programiren?
-Ich könnte mir vorstellen das man zum einen ein Bitmap lädt (speicher 
intensiv).
-Zum anderen könnte man Größe und Position einer form angeben und den 
avr denn Rest errechnen lassen(rechen aufwand) .

Ich würde lieber das zweite nehmen aber habe keine Ahnung wie es geht 
gibt es tutorials???

Ich danke euch im voraus

von sechsnullfuenf (Gast)


Lesenswert?

Wo soll's dargestellt werden ? Auf einem PC ? Auf einem LCD ?

von Michel K. (nover)


Lesenswert?

auf einem Lcd mit Touch-Screen das ist ja auch das Problem. Bei einem PC 
könnte man Bibliotheken nehmen das geht bei einem AVR nicht da es kein 
Betriebssystem gibt.

von Ronny (Gast)


Lesenswert?

Rein Textbasiert über die Konsole? Kein Problem.

Für den Anfang ist da sicher ein größerer AVR mit 8kB Flash ganz gut um 
mit C zu probieren.Grundsätzlich gehts aber auch auf kleineren in Asm.

Die nächste schwierigere Stufe wäre dann ein Textbasiertes Display. 
Deinen 1. Versuch mit der Konsole kann man dann entsprechend ausbauen.


Für ein vollgraphisches Menü mit Bitmaps und so weiter wirst du dir 
neben einer etwas komplizierteren Displayansteuerung auch noch ein 
passendes Speichermedium suchen müssen.Ein SD-Karte wäre hier z.B. eine 
gute Idee,allerdings führt das direkt zum nächsten Problem,nämlich die 
Arbeit mit FAT16.

Fragen:

1. Worauf soll das Menü ausgegeben werden? Textdisplay?Grafikdisplay?
   Terminal bzw Konsole?

2. Wie komplex solls werden? Ein paar Taster die jeweils einen Menüpunkt
   ansprechen? Oder was mit Cursor der bewegt wird?Bei letzterem 
scheidet
   die einfache Version per Konsole schonmal aus.

3. Welche Erfahrungen hast du in Sachen Mikrocontroller? Ein 
Grafikdisplay
   komplett in Eigenregie anzusteuern und nebenbei noch Dateien von 
einer
   SD Karte laden ist keine simple Aufgabe.Mit Bibltiotheken wär´s aber
   durchaus machbar. ;)

von Michel K. (nover)


Lesenswert?

Ich wollet es mit einem Graphik LCD machen und Vollgraphik ich dacht an 
einen externen Flash IC von Atmel mit 16MB speicher einen Cursor brauche 
ich nicht ist ehr lästig XD. Als AVR dachte ich an einen ATMega128 und 
2x externen Ram mit je 32k x 8bit eine SD-Card wollte ich auch noch 
anhangen. Der AVR soll sich nur um das GLCD kümmern und bekommt, sendet 
und verarbeitet nur Daten die er via SPI bekommt und sendet.

von Michel K. (nover)


Lesenswert?

Sry ich hatte die letze frage über lesen
Ich habe mich über das ansteuern einer LED hinausgearbeitet sagen wir es 
so. eine fat16 sollte nicht das Problem sein und das GLCD habe ich bis 
her im Text Modi probiert ist auch ok. ich habe nur Assam Kenntnisse und 
hatte auch schon über legt es in C zumachen nur die Umstellung ist 
(Vorsicht faul) das Problem XD

von I_ H. (i_h)


Lesenswert?

Je nachdem wie oft du das brauchst, musst du dir überlegen wie du das 
Framework aufbaust. Wenn's nur um 1 menu geht egal, bei 'ner kompletten 
Benutzerführung solltest du dir erstmal ein paar Grundsatzgedanken 
machen, und zum Vergleich 'n Blick auf die Architektur anderer GUIs (zB. 
GTK weil in C ohne +) werfen.

Sowas ordentlich aufzuziehen ist nicht ganz ohne.

von Michel K. (nover)


Lesenswert?

Danke das wede ich machen. Ich habe auch schon ein wenig gegooglet und 
habe noch fragen.

1.Gibt es auch solche Bibliotheken in AVR GCC?

2.Kann man ein Framework auch mit einer Art Bios (ein auf dem AVR 
laufendes mindes Programm das dann auf das Externe Flash zugreift du 
denn Rest lädt) machen das auf dem AVR im Grunde genommen nur die 
Hardware(z.B. LCD Routine TS-Controller usw.)  und das mindes Programm 
ist?

3.Und wie ist das mit dem Aufbau der Framework ich wüde mich freuen wenn 
jemand ein tutorials für mich wüste?

von Spess53 (Gast)


Lesenswert?

Hi

Ihr überschätzt den Aufwand für eine Grafische Oberfläche total. Wir 
setzen in einem Teil unserer Geräte 240x64 (T6963) Displays mit 8x2 
Touchpanel ein.

Für etwa 12 verschiedene Oberflächen mit eine Reihe von verschiedenen 
Zuständen auf den einzelnen Seiten benötige ich etwa 32 K Grafikdaten. 
Die Grafikroutinen (Assembler) belegen etwa 3k.

MfG Spess

von I_ H. (i_h)


Lesenswert?

Die Frage ist, was "Benutzeroberfläche" heist. Wenn's nur ein paar 
Buttons sein sollen, auf die man draufdrücken kann, wird die Sache 
wirklich einfacher. Wenn aber noch andere Sachen dazu sollen 
(Ausgabezeilen, vll noch 2..3 Formatierungen, Fenster, usw.) wird's 
schnell komplex, und dann muss man sich schon 'n paar Gedanken über die 
API machen.

von Daniel S. (sany)


Lesenswert?

Also,

Ich bin damit schon beschäftigt eine Art GUI für ein Grafisches LCD 
128x64 für mein Atmega32 zu Programmieren.

Grundlegend solltest du dir schon gedanken machen, über den Aufbau, die 
Struktur sowie auch Platz.. weil 8KB sind bei sowas sehr schnell weg! ;)

von Olaf (Gast)


Lesenswert?

Ich hab sowas schonmal vor ein paar Jahren programmiert. Allerdings 
nicht mit einem AVR, sondern mit einem 68332 und einem 320x240 LCD.
Rechnenleistung ist eigentlich nie ein Problem, da man ja meist einen 
Bildschirm aufbaut und sich dann nur noch sehr wenig darin aendert.
Die Grafikroutinen benoetigen irgendwas zwischen 30-40kb Flash. Du 
brauchst aber auf jedenfall ausreichend Ram um z.b den 
Bildschirmhintergrund zu speichern wenn du ein neues Fenster aufmachst.

Wuerde ich das heute nochmal programmieren muessen so wuerde ich das 
kompatible machen zu einer bekannten Grafikoberflaeche damit man deren 
tools (z.B designer/QT3) benutzen kann um die Grafik zu designen.
Ich muss das jetzt alles von Hand machen. Das geht zwar, ist aber etwas 
muehselig wenn man mal ein paar Elemente verschieben will oder etwas 
ausprobieren moechte.

Olaf

von Michel K. (nover)


Lesenswert?

Ich probier mal das etwas zu dilatieren
Eine Art Tablett oberflache auf der Messdaten und Eistellungen 
dargestellt werden. die Möglichkeit Fenster und Meldungen ein zu blenden 
sollte auf jeden fall da sein. Eine Diagramm Darstellung von Messdaten 
möchte ich auch gerne machen. Also ein wenig komplexer.

von Ulrich P. (uprinz)


Lesenswert?

Nicht wirklich, wenn man erst einmal zusammen sammelt, was man hat und 
was man braucht.
Einsparung 1:
Wenn man nicht für jeden Menüpunkt ein eigenes Symbol braucht, dann tut 
es auch ein Image für einen Button und der wird dann mit Text 
beschriftet. Oder man definiert kleine Images für die Symbole und malt 
diese in den Button.
Einsparung 2:
Ein Button hat eine linke und eine rechte Kante, dazwischen liegt ein 
oben und unten grafisch begrenzter freier Raum, der mit Text oder 
Grafiken gefüllt werden kann. Also male ich einen Button indem ich eine 
Anfangs-, n*Mitten- und einmal Endgrafik zeichne. Das hat dann den 
Vorteil, dass ich unterschiedlich breite Button malen kann ohne ein Byte 
mehr Grafik oder Code zu investieren.
Einsparung 3:
Man kann auch die Ecken als Grafiken definieren und das Strecken auch in 
der Höhe machen. So kann aus einem Button schnell auch die Maske für ein 
Menü oder ein Fenster / eine Meldung werden. Durch gleich große Grafiken 
für die einzelnen Button-Bausteine, kann man durch Übergabe eines 
Pointers an die Zeichenroutine auch unterschiedliche Rahmen für Buttons 
und so weiter definieren und das alles mit minimalem Code-Mehraufwand.

Einsparung 4:
Überlegt genau, was wann angezeigt werden muss und wo, bzw. wann es zur 
Verfügung steht. Soll ein Meldungstext als Fenster eingeblendet werden, 
so muss man nicht zwingend gleich den Display-Teil irgendwo speichern. 
Zur ständigen Ausgabe aktueller Werte auf dem Hauptschirm existiert ja 
schon eine Routine. Dieser muss man nur mitteilen, dass sie nichts 
ausgeben darf, weil die Einblendung aktiv ist. Wird die Einblendung 
deaktiviert, muss man nur einmal durch die Messwertroutine und schon ist 
das Fenster weg.

Einsparung 5:
LCD-Controller sind oft mächtiger und hilfreicher als man denkt. Also 
den passenden Controller für das Vorhaben aussuchen. Viele dieser 
Controller können mehr Speicher adressieren, als das eigentliche LCD 
benötigt. Diesen Speicher kann man entweder als Pseudo-RAM nutzen und 
darin Daten ablegen, oder Display-Inhalte sichern, oder man nutzt die 
Paging-Struktur um z.B. ein Grafik oder ein Menü un Ruhe aufzubauen und 
dann um zu blenden, wenn es fertig ist. Schon beim alten HD44780er kann 
man beim Booten das Menü im unsichtbaren Bereich des LCDs unterbringen 
und im sichtbaren Bereich Messwerte anzeigen. Auf Anforderung hin 
schreibt man nicht langsam erst das Menü zusammen, sondern setzt einfach 
das virtuelle Fenster des HD44780 auf das vorbereitete Menü. Man kann 
sogar im Hintergrund die Messwerte aktualisieren. Verlässt man das Menu, 
also schiebt man das virtuelle Fenster zurück, sind sogar alle Angaben 
schon aktuell.

Komplexe farbige Menüs auf großen Handy-Displays mit 260k Farben werden 
von etlichen MP3-Playern bereits realisiert. Und das alles auf AVR.

Gruß, Ulrich

von Steffen (Gast)


Lesenswert?

Genau:

Wie eigentlich bei jedem größeren Projekt solltest du die Anforderungen 
genau definieren.

Brauchst du wirklich Bilder? Wenn es um die Darstellung von Inhalten 
geht, kommt man meist mit Text und Linien aus (diese lassen sich recht 
einfach zeichnen). Wenn du dir für dein Display Routinen schreibst, die 
das Schreiben von Text (Normal, Fett oder Kursiv), Zeichnen von 
Rechtecken, Linien und Punkten beherrschen, dann kommst du schon 
ziemlich weit.

Vielleicht mal durch die Codesammlung rasen. Da findest du z.B. ne Bib 
von ape(genauen Namen habe ich vergessen) mit der du z.B. nen KS0108 
ansteuern kannst.

Fertige Bibs mit Update/Aktualisierungsgarantie/Support gibt es wohl 
nicht allzuviele, zumindest kenne ich jetzt ohne googeln keine.

Der Tipp mit den MP3-Playern auf Basis der AVRs scheint mir recht 
sinnvoll.

Steffen.

von Olaf (Gast)


Lesenswert?

> Soll ein Meldungstext als Fenster eingeblendet werden,
> so muss man nicht zwingend gleich den Display-Teil irgendwo speichern.
> Zur ständigen Ausgabe aktueller Werte auf dem Hauptschirm existiert ja
> schon eine Routine. Dieser muss man nur mitteilen, dass sie nichts
> ausgeben darf, weil die Einblendung aktiv ist.

Das ist natuerlich sehr sparsam. Ich hab das auch schonmal irgendwo so 
gemacht, aber der Haken dabei ist, das dann die programmierten Routinen 
nicht universel verwendbar sind.

> LCD-Controller sind oft mächtiger und hilfreicher als man denkt.

Das ist auch richtig, aber auch da ist man dann sehr auf einen 
Displaytyp festgelegt. Das wuerde ich mir in der Firma (bei kleinen 
Stueckzahlen) schon nicht antun, und privat wo man immer mal einen 
Restposten nimmt, erst recht nicht.

Dann lieber einen dickeren Controller nehmen. Ausser du machst 
natuerlich grosse Stueckzahlen bei Produkten die nur kurz laufen.


Olaf

von Oliver (Gast)


Lesenswert?

Ein paar Grafik-Libs gibt es schon, die da weiterhelfen können:

-glcd_ks0108_v11.zip von ape (Original-Site nicht mehr erreichbar, aber 
hier im Forum gibts die noch)
-ks0108.zip von http://www.holger-klabunde.de/

http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/
(allerdings z.Zt auch nicht downloadbar)

Hunderte K externer Speicher braucht es dafür nur, wenn Unmengen 
riesiger Icons verwendet werden sollen. Ansonsten tut es jeder der 
grösseren AVR's, wobei natürlich mehr Flash und Sram nie schaden. In 16K 
Flash nur für Menussystem und Grafik passt schin verdammt viel rein.

Oliver

von Falk B. (falk)


Lesenswert?

@ Olaf (Gast)

>> LCD-Controller sind oft mächtiger und hilfreicher als man denkt.

>Das ist auch richtig, aber auch da ist man dann sehr auf einen
>Displaytyp festgelegt. Das wuerde ich mir in der Firma (bei kleinen

>Dann lieber einen dickeren Controller nehmen.

Du hast das Prinzip der Modularisierung nicht wirklich verstanden.

MFG
Falk

von Ulrich P. (uprinz)


Lesenswert?

Olaf wrote:
>> Soll ein Meldungstext als Fenster eingeblendet werden,
>> so muss man nicht zwingend gleich den Display-Teil irgendwo speichern.
>> Zur ständigen Ausgabe aktueller Werte auf dem Hauptschirm existiert ja
>> schon eine Routine. Dieser muss man nur mitteilen, dass sie nichts
>> ausgeben darf, weil die Einblendung aktiv ist.
>
> Das ist natuerlich sehr sparsam. Ich hab das auch schonmal irgendwo so
> gemacht, aber der Haken dabei ist, das dann die programmierten Routinen
> nicht universel verwendbar sind.
>

Das stimmt so nicht, die Routinen wären damit immer noch universell für 
alle Projekte einsetzbar, in denen dieser Display-Typ verwendet wird.
Außerdem ging es dabei nicht um einen speziellen Typ ala HD44780, 
sondern um das Prinzip, wie man die Optionen eines Controllers für sich 
ausnutzen kann, auf unkonventionelle Art und Weise. Ich wollte also zum 
Um-die-Ecke-Denken anregen.

>> LCD-Controller sind oft mächtiger und hilfreicher als man denkt.
>
> Das ist auch richtig, aber auch da ist man dann sehr auf einen
> Displaytyp festgelegt. Das wuerde ich mir in der Firma (bei kleinen
> Stueckzahlen) schon nicht antun, und privat wo man immer mal einen
> Restposten nimmt, erst recht nicht.
>
Nein, denn wenn man das von untern herauf programmiert, also vom 
Interface über das Pixel-Setzen <- das Linie Malen <- Mini-Grafik 
Malen...
Dann braucht man nur das Interface und das Pixel-Setzen auf den 
jeweiligen Display-Typ anpassen.

> Dann lieber einen dickeren Controller nehmen. Ausser du machst
> natuerlich grosse Stueckzahlen bei Produkten die nur kurz laufen.
>
Das halte ich für typische Windows-Programmierung. Ein Programm, dass 
1+1 rechnet... Ich habe 2GB RAM und 500GB Festplatte für DLLs, das pass 
schon.

Zweitens ist es gerade die Masse, die den Kampf um jeden mct ( 
Milli-Cent) entfacht. Bei >1Mio Stückzahl macht es durchaus Sinn darüber 
nachzudenken, ob ein Kondensator 0.01 oder nur 0.0025ct kosten darf. Da 
fällt es erst recht auf, wenn ein Controller mit +80ct wegen +32kB Flash 
eingesetzt wird, von denen nachher alle blank liegen.

Eine Komplette Messdatenerfassung, Menüsteuerung und 
Backup-Akkusteuerung ( inkl. Refreshing) auf einem 8051er laufen mit 8k 
Flash und 256Bytes RAM. Dabei nutze ich sogar die reprogrammierbaren 
Icons vom 44780er aus um Betriebszustand und Akkuzustand anzuzeigen.
Das Projekt hat mich in Sachen LCD, Controller und effizientes 
Programmieren weiter gebracht als jede Windows-Code-Zeile.

Aber natürlich starte ich auch einen kleinen Adapter für Protokoll-X 
nach Y  auf einem Mega32 oder Mega128 weil ich die Dinger auf meinem 
Steckbrett klemmen habe. Aber das Serien-Layout kann dann durchaus mit 
einem tiny2313 oder kleiner enden.

Gruß, Ulrich

von Olaf (Gast)


Lesenswert?

> Nein, denn wenn man das von untern herauf programmiert, also vom
> Interface über das Pixel-Setzen <- das Linie Malen <- Mini-Grafik
> Malen...

Ach so, dann hatte ich dich wohl missverstanden. So mache ich das auch. 
Als Basis brauche ich dann nur eine Display abhaengige Libary zu 
schreiben die setpixel(), getpixel() und die Groesse des LCDs zur 
Verfuegung stellt.

Ich hab mir sogar eine ziemlich wueste Geschichte zusammengehackt welche 
das fuer X macht. So kann ich dann meine Anwendung zu Testzwecken in 
einem Fenster unter Linux laufen lassen.

> Das halte ich für typische Windows-Programmierung. Ein Programm, dass
> 1+1 rechnet... Ich habe 2GB RAM und 500GB Festplatte für DLLs, das pass
> schon.

Hey, gegen diese Beleidigung muss ich mich verwahren! Du hast natuerlich 
nicht ganz unrecht und ich prangere das bei PCs auch immer an, aber man 
kann es mit der Sparsamkeit auch uebertreiben. Einen Minicontroller mit 
1kb Ram oder aehnliches tue ich mir nicht mehr an.


> Zweitens ist es gerade die Masse, die den Kampf um jeden mct (
> Milli-Cent) entfacht.

Das hab ich doch auch gesagt. Wenn man genug herstellt dann kann man 
auch ein paar Tage extra Entwicklung in eine Sache stecken.

> Das Projekt hat mich in Sachen LCD, Controller und effizientes
> Programmieren weiter gebracht als jede Windows-Code-Zeile.

Effizienter zu sein als sowas ist ja keine Kunst. Ich sitze beim starten 
des Rechner oft davor und ueberlege was die Kiste in dieser Sekunde wohl 
gerade macht. Ich glaube ich wuerde echt Geld fuer ein Buch ausgeben das 
mir jede einzelne ms eines Windowsstarts erklaert. :-)

Olaf

von gast (Gast)


Lesenswert?

vieleicht bringt dich das .net micro framework weiter, soll ohne 
betriebssystem auch auf ARM 7 und kompatiblen Controlern laufen.

http://blogs.msdn.com/frankpr/archive/2007/11/01/cooles-gui-mit-dem-net-micro-framework.aspx

der Typ hat ein paar gute blogs gemacht

von Ulrich P. (uprinz)


Lesenswert?

Olaf wrote:

> Effizienter zu sein als sowas ist ja keine Kunst. Ich sitze beim starten
> des Rechner oft davor und ueberlege was die Kiste in dieser Sekunde wohl
> gerade macht. Ich glaube ich wuerde echt Geld fuer ein Buch ausgeben das
> mir jede einzelne ms eines Windowsstarts erklaert. :-)
>
Dann hättest Du in deinem Postboten einen lebenslangen Feind, weil er 
das Buch zu Dir schleppen müsste :)

Aber wegen der Sparsamkeit gebe ich Dir auch ein wenig Recht. Vermutlich 
entwickeln wir auch unterschiedliche Dinge und haben damit 
unterschiedliche Anforderungen. Bei meinen Sachen ist es meist auch eine 
Frage des Stromverbrauches und da ist ein kleiner Controller eben 
sparsamer als ein fetter.

Gruß, Ulrich

von Michel K. (nover)


Lesenswert?

Leider konnte ich gestern nicht weiter antworten

Ich mache es zum ersten mal und habe auch schon ein wenig gegooglet.
Dabei bin ich immer wider darauf gekommen das, dass Ram oft zu klein
ist. Und ich war der Meinung das ich ja mein Rambord wider an die STK zu
hängen (zwei mal 256k 32kx8). Da muss man dann erstmal nicht sparsam
sein.

Ich kenne C nur bedingt und auch das nur vom PC meist benutze ich
Delphi  wenn ich das richtig verstanden habe muss ich C aber sehr gut
können und das nach Möglichkeit für PC und AVR um Rückschlüsse zeihen zu
können.

Dann also Bücher raus und in der U-Bahn lesen. XD

Wie kann man denn am besten das mit dem Framework lernen ich denke mir
wenn ich das am PC kann bekomme ich es auch mit nem AVR hin.

von I_ H. (i_h)


Lesenswert?

@Olaf

Bei Linux weist du, was passiert ;)

@Michael

Guck dir mal die kleineren GUIs an, die's so gibt. Zb. motif oder Tk. In 
GTK kannst du auch mal reinschnuppern, ist aber schon etwas 
leistungsfähiger. Da findest du auch unzählige gute Tutorials im Netz.
Von der windows gui würde ich an deiner Stelle die Finger lassen, sowas 
willst du nicht programmieren. Motif und Tk müsste es auch für windows 
geben.

Was du dir auch genau angucken solltest sind Zeiger. Die wirst du 
ziemlich oft brauchen.

von Michel K. (nover)


Lesenswert?

@I_ H
Danke erst mal für die Tipps

Ich hatte vor mir das unter dos anzuschauen da hat es weniger was von 
Lego ;) ich bin immer noch der Meinung das Windows mir da zufiel 
Routinen hat die dann die Arbeit machen die ich machen möchte. ich hatte 
auch schon überlegt mir so eine Linux Live CD zu saugen da gibt es eine 
mit der man Software Schreiben kann weil alle Komponenten drauf sind die 
man braucht. Und unter Linux gibt es bessere Tutorials im iNet. Ich habe 
auch noch ein par Bücher die das Programiren unter  C  rech anschaulich 
erklären.

von Olaf (Gast)


Lesenswert?

> Bei meinen Sachen ist es meist auch eine Frage des Stromverbrauches und
> da ist ein kleiner Controller eben sparsamer als ein fetter.

In den Produkten die ich fuer die Firma entwickel befinden sich fast 
immer 1-2 Oefen die 100-200W verbrauchen. Da ist meine Elektronik immer 
vernachlaessigbar. :-)

> Zb. motif

Aeh..m ich glaub ich motif erstmalig auf einem 486/133 benutzt und da 
war das noch recht lahm. Ich moechte mir nicht vorstellen etwas dazu 
kompatibles auf einem Controller zu haben.

Aber ich glaube irgendwann wenn die Controller noch etwas 
leistungsfaehiger sind und man selbst in seinem Batterielader schon 
320x240Pixel hat weil das LCD bei Reichelt nur 10Euro kostet, also dann 
mach ich mich mal dran und probier olwm zu implementieren.
Allerdings muss man fairerweise sagen das sowas nicht ganz unkritisch 
ist weil vorhandene grafische Oberflaechen meist auf Mausbenutzung 
optimiert sind.

> Ich hatte vor mir das unter dos anzuschauen da hat es weniger was von
> Lego ;) ich bin immer noch der Meinung das Windows mir da zufiel
> Routinen hat die dann die Arbeit machen die ich machen möchte.

Das Problem geht noch tiefer. Wenn du etwas auf einem AVR, oder 
irgendeines anderen Controller, programmierst, so gibt es da kein 
Betriebssystem. Dein Programm laeuft alleine und veranlasst alle 
Entscheidungen. Zum Beispiel fragst du einen Eingangsport ab um zu 
schauen ob eine Taste gedrueckt wurde.

Programmierst du auf einer modernen grafischen Oberflaeche, egal ob 
Windows, Linux, Palmpilot usw., so laeuft dein Programm normalerweise 
garnicht. Erst wenn jemand einen Button drueckt oder etwas anderes 
passiert wird dein Programm darueber informiert und verarbeitet das.

DOS liegt da natuerlich viel naeher am Controller. Bloss war da die 
Grafikausgabe noch nicht standartisiert. Damals konnten Programme ja nur 
mit bestimmten Grafikkarten sprechen. Obwohl, ist schon lange her, CGA 
sollte fuers erste ja mal reichen. :-)

Olaf

von Spess53 (Gast)


Lesenswert?

Hi

Electronic Assembly (lcd-module.de) bietet Touchscreen-Module mit 
grafischen Oberflächen an. Dort kannst du dir zu den einzelnen Kids 
Simulationen herunterladen. Wenn mich nicht alles täuscht, gibt es auch 
Software um eigene Oberflächen zu erstellen und in die simulierten 
Displays zu 'laden'. Das sieht dann schon etwas anschaulicher aus.
Wenn du das z.B. auf einem AVR machen willst würde ich gar nicht an 
Windows oder Linux denken. Da sind zwischen dem, was du machst und dem 
was du siehst mehrere Ebenen Betriebssystem und noch einige Treiber 
dazwischen. Windows, (Linux weiss ich nicht) ist zu einem geraumen Teil 
mit sich selbst beschäftigt. Du brauchst deine Maus nur schief ansehen, 
und schon geht ein Feuerwerk von Botschaften durch das System. Das 
willst du doch keinem µC antun.
Wie du richtig erkannt hast gibt es eine Zeit- und eine 
Speicherintensive Methode. Wobei der programmtechnische Aufwand 
(Speicher) der ersten Methode wesentlich grösser ist. Ich habe mich 
deshalb für den zweiten Weg entschieden, da ich den Speicher einmal 
kaufe, Rechenzeit aber immer wieder bereitstellen muss.

MfG Spess

von Michel K. (nover)


Lesenswert?

@Spess53
Ich möchte kein neues LCD sondern lernen es funktioniert ich setze mir 
gerne ziele die es zu erreichen gilt und gehe nicht den der geringsten 
Arbeit (auch wenn ich gerne mal ein wenig faule bin).
Zitat: denn der Weg ist das Ziel.

Hat eventuell jemand einen Code der mir das ein wenig veranschaulicht 
ich suche nun schon seit zwei Wochen danach und habe nur ja das geht und 
das nicht aber von ca. 1000 google Treffern sind 999 Mühl . ich kann mir 
nicht vor stellen wie ich nem AVR beibringen soll (setze posi X-Y auf 1) 
und das so das da noch was raus kommt .
Das wäre verdammt nett von euch

von gast (Gast)


Angehängte Dateien:

Lesenswert?

Nur als kleine Anregung. Falls du dir eine GLCD Lib bauen möchtest die 
nicht Display abhängig ist. So könntes du es machen habe ich auch so 
gemacht.

von Oliver (Gast)


Lesenswert?

>Hat eventuell jemand einen Code

Liest du eigentlich, was hier geschrieben wird?
Es gibt fertige Grafik-libs für den AVR, links siehe oben.

>Ich möchte kein neues LCD sondern lernen es funktioniert
Jeder LCD-Treiberbaustein hat nunmal seine eigene Ansteuerung. Irgend 
einen wirst du lernen müssen.

Oliver

von Spess53 (Gast)


Angehängte Dateien:

Lesenswert?

Hi

Ich wollte dir kein neues Display aufschwatzen. Mein Augenmerk lag mehr 
auf den Simulationen. Hab dir mal ein Beispiel angehängt.

Zitat: Viele Wege führen nach Rom.

MfG Spess

von Jan M. (gallig)


Lesenswert?

Michel K. wrote:
> @Spess53
> Ich möchte kein neues LCD sondern lernen es funktioniert ich setze mir
> gerne ziele die es zu erreichen gilt und gehe nicht den der geringsten
> Arbeit (auch wenn ich gerne mal ein wenig faule bin).
> Zitat: denn der Weg ist das Ziel.
>

Hi Michael,
wollte dir nur mal eben meine Erfahrungen mitteilen.
Wir benutzten hier bei einem Project auch das Display von Electronic 
Assembly jedoch "nur" das 270er ohne Touch und ich muß sagen durch die 
internen Funktionen läßt sich dieses leicht Programmieren und durch 
Makros spart man auch einiges an Speicher des AVR. Schließlich soll die 
grafische Benutzeroberfläche ja wahrscheinlich noch irgend einen Zweck 
erfüllen und nicht nur schön aussehen. Ich will damit sagen du sparst 
auf diesem weg Zeit und Resourcen, welche dir dann für dein eigentliches 
Programm zur Verfügung stehen. Weiterhin verlierst du durch die 
Ansteuerungsmöglichkeit per I2C/TWI nur zwei bzw. keine Pins an deinem 
AVR.

von I_ H. (i_h)


Lesenswert?

Musst dir garkein Linux besorgen, cygwin reicht auch. Du kannst dir das 
auch angucken ohne es zu programmieren, es geht ja nur darum, dass du 
ein gefühl bekommst wie man sowas angeht.

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.