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
Wo soll's dargestellt werden ? Auf einem PC ? Auf einem LCD ?
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.
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. ;)
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.
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
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.
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?
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
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.
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! ;)
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
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.
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
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.
> 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
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
@ 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
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
> 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
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
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
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.
@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.
@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.
> 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
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
@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
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.
>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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.