Hallo, ich habe schon öfter mal gelesen das man Nokia Displays am Mega anschließen kann. Hat da jemand Erfahrung ? Kann man auch Farb Displays betreiben ? Wie kann ich das Display an den Mega8 anschließen? Wäre toll wenn einer eine Lösung parat hat Gruß Jürgen
Schau mal bei www.apetech.de vorbei. Oder die Threads von Hagen in der Codesammlubg. Funktioniert, aber du kannst nicht viele Fonts darstellen, da sie im RAM des ATmega8 hinterlegen mußt. Er hat nur 1k, da wird es ein bisschen knapp. Hruß Elektrikser
"Er hat nur 1k" normalerweise hat der mega8 .... 8kb flash, und da sollte einiges reinpassen :)
er hat nur 1k RAM ja aber die Fonts liegen im Flash und können mit geringem Aufwand auch in ein externes EEPROM o.ä. ausgelagert werden. also das geht schon mit nem mega8...
Zudem werden die Fonts in meiner GLCD Library komprimiert. Im Normalfalle sollten damit 2 bis 3 mal mehr Fonts in den gleichen Speicherbereich reingehen als bei anderen Bibliotheken. Allerdings solltest du trotzdem überlegen einen größeren AVR zu benutzen. Eine Grafische Anwendung benötigt von Hause aus mehr Speicherplatz, zB. Menusysteme, Bitmaps und viel aufwendigere Mehrfarbenfonts. Ansonsten würde sich ja ein GLCD nicht lohnen wenn man es nicht auch bunter und besser haben möchte. Die GLCD LIB benutzt stark sequentiell konzipierte Font Strukturen, d.h. sie können mit der Angabe einer eigenen Lese-Callback in glcdSelectFont() aus jedem beliebigen Medium heraus in der Library benutzt werden. Es ist also im Grunde egal wo du die Fonts speicherst, Du musst der Library nur mitteilen wie der aktuelle Font zu laden ist. Ich persönlich habe das natürlich auch mit externen I2C EEPROMS ausgetestet und eine solche Callback könnte so aussehen: uint8_t MenuFontRead(uint16_t Index) { uint8_t Result; if (i2cMemRead(0xA8, Index, &Result, 1) != 1) { Result = 0; } return(Result); } void MenuSelectFont(uint8_t Index) { uint16_t Address = 0; for (; Index > 0; Index--) { Address += (MenuFontRead(Address) << 8) | MenuFontRead(Address +1); } glcdSelectFont(Address, MenuFontRead); } Im I2C EEPROM wurden einfach sequentiell mehrere Fonts nacheinander gespeichert. Über obigen Index im Source gibt man dann einfach die Nummer des Fonts im EERPOM an. Die oben benutzte i2c Routinen findest du auch hier in Forum. Da nun alle Fonts ausgelagert wurden benötigt die LIB maximal 2Kb für ihren Code, abhängig was du alles so an Funktionen benutzt. Ich komme bei meinen Projekten, die keine Ellipsen/Kreis/Linien benutzen, auf ca. 1300 Bytes an Codeverbrauch mit Mehrfarbenfonts usw. Im ATMega8 haste also meistens noch 6Kb-7Kb für deine eigenen Sachen übrig. Gruß Hagen
Ich habe es mit einem ATmega32L probiert. Funktioniert sehr gut. Dank an Hagen und Ape. Bin mir gerade am Überlegen, ob das mit den Kreisen und Ellipsen nicht auch auf ein T6963C-Display übertragbar wäre. Ist zwar kein Farbdisplay, aber Kreise zeichnen sollte man doch können. Ich bin ziemlich gut mit der Bibliothek klar gekommen, obwohl ich ein AVR-Einsteiger bin (komm von den MC51ern). Das was ich am längsten gesucht hate, war wie man die Hintergrundfarbe verändert. @Hagen Eine Frage hätte ich noch: Den Befehl glcdPrint_P hast du ja einmal in einen Post beschrieben. Hast du ihn später herausgenommen? Ich finde ihn in der Bibliothek nicht. Gruß Elektrikser
Jo, weil er überflüssig geworden ist. Alle Funktionen die auf Strings oder Speicherbreiche Zeichenweise was machen wollen nutzen nun Callbacks. Zb. glcdPrint("Dein Text hier", 0) wurde intern so codiert: glcdCharsCallback("Dein Text hier", 0, glcdDrawChar); D.h. es gibt für Strings die im FLASH oder RAM gespeichert wurden die Funktion glcdCharsCallback() die dann diesen String Zeichen für Zeichen bis der Null Terminator auftritt an die Callback Funtion übergibt. Die Callback Funtion sollte so definiert sein: uint8_t glcdDrawChar(char c); Wobei das Resulat dieser Callback Funktion zB. die Zeichenbreite in Pixel sein könnte und in glcdCharsCallback() zusammen addiert wird. Diese Summe wird wiederum als Resultat von glcdCharsCallback() zurückgegeben. Man kann somit auch OHNE das man irgendwas zeichnet über Textbreite = glcdCharsCallback("Dein Text hier", 0, glcdCharWidth) die Breite eines Textes in Pixel der im RAM steht berechnen lassen. Nungut letztes Beispiel wäre exakt das was glcdCharsWidth() intern macht. glcdCharsCallback() kann also auch unabhängig vom Rest der Library benutzt werden um einen String der im RAM/FLASH steht Zeichenweise an eine Callbackfunktion zu übergeben. Diese Methode hat somit die alte Funtion ersetzt. Grundsätzlich kannst du in meinen Funktionen angeben ob der Text im RAM oder FLASH steht. Einfach glcdPrint("Dein Text hier", 0) für RAM, und glcdPrint("Dein Text hier", 1) für FLASH. Gruß Hagen
sorry muß heisen: glcdPrint("Dein Text hier", 0) für RAM, und glcdPrint(PSTR("Dein Text hier"), 1) für FLASH. Gruß Hagen
hallo, ich würde dennoch sehr gerne wissen, wieviel RAM gebraucht wird; nach meiner erfahrung mit nokia3310 und nur einem (1-bit) font werden ca. 500 bytes RAM benötigt, was ja alles unter mega8 ausschliesst...
> in mir gerade am Überlegen, ob das mit den Kreisen und > Ellipsen nicht auch auf ein T6963C-Display übertragbar wäre. Hm, kommt auf die Funktionsweise des T6963C an. Die GLCD läuft zB. schon auf dem Nokia 3150 Displaycontroller, Volkmar Dierkes hat das portiert. Soweit wie ich das erkennen konnte waren nur 4 bis 5 Änderungen am Source an der richtigen Stelle notwendig. Der 3150 Controller ist noch ziemlich kompatibel zum Philips Teil. Denoch liegt die Schwierigkeit solcher Änderungen eben darin sie an der richtigen Stelle zu machen, das was Volkmar gemacht hat ist also nicht ganz sooo einfach, man sollte zumindestens grundsätzlich verstanden haben was die Lib wie zu welchem Zeitpunkt macht. Es gibt einige grundsätzliche Einschränkungen: - maximale Displayauflösung der Library ist 254x254 Pixel - unterstützte Farbauflösung der Sofwareroutinen sind Monochrome, 4,8,16,32,64,128,256 und 65535 Farben. Im Grunde arbeiten die Ellipsen/Linien/Rechtecke immer Monochrom, d.h. sie benutzen 2 Farben. Wie groß die Farbtiefe dieser 2 Farben ist ist eine Sache ! Die Fontroutinen arbeiten mehrfarbig, jenachdem was in COLOR_TABLE_BITS eingestellt wurde und der Font selber an Farbtiefe in Font.BitsPerPixel besitzt. Die Fontroutinen extrahieren aus den Fondaten UNABHÄNGIG von der Hardware die zu setzenden Pixel und translieren sie in die Werte die in der Lookuptabelle glcd_Colors[] stehen. Erst diese Werte (8 oder 16 Bit groß) werden an glcdPutPixel() übergeben. Du könntest also ganz einfach in glcd_Colors[] die Werte auf 0,1,2,3,4...x setzen und dann in glcdPutPixel() darauf reagieren. - die Software unterstützt nur Hardware die entweder Pixel mit 8Bit oder 16Bit setzen können. Sollte also der Controller in 1 oder 2 Bytes 1 Pixel setzen können dann ist das kompatibel. Sollte der Controller aber zb. 8 Pixel pro Byte setzen dann muß man wesentlich mehr an der Library ändern. Eine relativ einfache vorstellbare Änderung wäre dann die Lib so umzuschreiben das sie einen eigenen Display RAM unterstützt und somit getrennt von der Hardwareansteuerung nur auf diesem RAM arbeitet. Dafür müsste man nur eine Funktion ändern -> glcdPutPixel(). Alle Hardware spezifischen Änderungen beziehen sich im Grunde nur auf die Datei glcd000.S. Alle Routinen wie Fonts, Linien, Rechtecke, Kreise, Ellipsen sind im Grunde genommen Hardwareunabhängig und über die Farbtabelle glcd_Colors[] unabhängig von der realen Farbtiefe der Hardware. - Kommunikation sollte SPI sein, könnte man ändern solange die Daten Byteweise übertragen werden. Um das SPI zu ändern muß man nur 4 Funktionen ändern. - die Ansteuerung der Koordinaten muß separat einstellbar sein. D.h. so wie die meisten Controller das auch können, sollten die Controller die X/Y Speicheraddressen automatisch inkrementieren können. Nach jedem setzen von Pixeln müssen die Controller auch die X/Y Koordinaten entsprechend automatisch inkrementieren/dekrementieren können. Die Art & Weise wie das der Controller macht muß dynamisch einstellbar sein, da die Font/Linien Routinen auf diese unterschiedlichen Modis angewiesen sind. Per Default stellt die Library den Modus auf X+1/Y+1 ein, also Spalten dann Zeilen inkrementieren. Nun die Fontroutinen stellen das immer um auf Y+1/X+1 also Zeilen dann Spalten inkrementieren. Dies dürfte das schriwerigste Problem sein falls der Controller das nicht unterstützt. Aber bei allen Grafik-Controllern die ich bis jetzt studiert habe geht das einzustellen. Gruß Hagen
>ich würde dennoch sehr gerne wissen, wieviel RAM gebraucht wird; >nach meiner erfahrung mit nokia3310 und nur einem (1-bit) font werden > ca. 500 bytes RAM benötigt, was ja alles unter mega8 ausschliesst... Da die Library keinen Display RAM simuliert, so wie es bei dein kleineren Displays üblich ist, fällt der RAM Verbrauch tatsächlich sehr gering aus. Er besteht nur aus dem Stack und den globalen Variablen. Die Anzahl der globalen Variablen hängt nur davon ab welche Funktionen dein Program tatsächlich benutzt. Gehen wir mal davon aus das du ohne schräge Linien und Ellipsen arbeiten willst, und die Fonts maximal 4 Farben benötigen und das Display im 256 Fraben Modus arbeitet und das due das Clipping nicht brauchst. Dann benötigt die Lib ca. 900 Bytes Code im FLASH Speicher und 21 Bytes an globalen RAM Speicher. Maximal verbraucht die Lib. in den Font Routinen dann 24 Bytes an Stackspeicher. Ergo: im Worstcase werden 45 Bytes an RAM benötigt. Wenn du die anderen Funktionen wie Linien/Ellipsen etc. benötgst erhöht sich nur noch der FLASH Verbrauch für den zusätzlichen Code. Nur falls du auf 65535 Farben erhöhst oder das Clipping aktivierst wird der RAM Verbrauch unwesentlich höher. Beim Clipping sinds glaube ich 8 Bytes, und bei den Farben verdoppelt sich der Verbrauch als der der nötig wäre beim 256 Farbmodus. D.h. eine Farbe wäre dann 2 Bytes statt 1 Byte groß. Diese Änderung betrifft aber nur das glcd_Colors[] Array. Gruß Hagen
@ hagen: hm, bist du schnell :))) vielen dank für die ausführliche antwort, hast mir sehr geholfen! btw, wann sehen wir pics von deinem space-age-wecker? :)))
Falls du dich aber auf die Fonts beziehst dann gilt: Fonts werden standardmäßig immer im FLASH gespeichert. Du hast aber die Freiheit die Fonts auf jedem beliebigen Medium zu speichern. Die Library unterstützt sowas von Hause aus OHNE das du irgendwas daran ändern musst. Das Einzigste was DU machen musst ist dieses Verhalten der Library mitzuteilen. (wo wie im vorherigen Posting gezeigt). Der Speicherverbrauch eines Fonts selebr ist sehr schwer einzuschätzen. In der Readme.txt habe ich mal eine Beispielrechnung aufgemacht. Dort steht etwa: Ein 8x11 Monochrome Font mit 95 Zeichen benötigt 684 Bytes statt ca. 1520 Bytes wie bei den meisten anderen Libraries. Macht schonmal nur 45% des üblichen. Erkennt nun der Font Editor das man diese Daten noch komprimieren kann so steigt dieses Ratio noch zusätzlich. Allerdings ist dies meistens erst der Fall wenn man größere Fonts definiert die eventuell mehr als nur 2 Farben enthalten. Bei meinen Clock Font, 29x51 Pixel a 2 Farben mit 12 Zeichen wären das 1706 Bytes unkomprimiert und 1208 Bytes komprimiert. Mit der normalen Speichermethode anderer Libs sind das dann minimal 2436 Bytes. Macht 50% Ratio. Dies betrifft aber in keiner Weise den RAM Verbrauch sondern nur den allgemeinen Speichervrebrauch des jeweiligen Fontes. Wohin DU nun den Font speicherst ist DEINE Sache. Normalerweise speichert man in im FLASH indem die erzeugte Heder-Datei des Fontes einfach in deinem Projekt eingebuden wird. Aber, wie oben gesagt, der Library ist es Schuppe WO du den Font speicherst, ob FLASH, RAM, MMC, Festplatte, CF oder weis was ich sonst, Hauptsache du teilst der Library mit wie si die Daten zu laden hat. Gruß Hagen
> btw, wann sehen wir pics von deinem space-age-wecker? :)))
Gute Frage, peinliche Frage, Schlechtes-Gewissen-Frage. Die damalige
Deadline -> Geburtstag meiner Freundin, hatte ich ja nicht halten
können, also liegt es erstmal auf Eis bis es wieder in den Fingern
juckt. Mein damaliges Problem war und ist einfach das ich noch nicht in
der Lage bin Layouts und Platinen herzustellen. Die Software ist
eigentlich schon rund, was man unter einer Beta Version verstehen kann.
Auf dem Steckbrett funktionierte schon alles sauber.
Bilder sind immer so'ne Sache: selbst mit meiner SemiProfi DigiCam
bekommt man das Display niemals so fotografiert wie es in der Realität
super aussieht.
Gruß Hagen
Vielen Dank, Hagen, für deine ausführlichen Infos!! Gruß Elektrikser
Hi Hagen... Die Layouts kann ich gerne erstellen leider habe ich bisher noch nicht viel Erfahrungen mit den MicroControllern gemacht, allerdinge ist das thema sehr interresant. Wie werden die Programmiert ueber den ISP?? Gruss Jens j[at]dinspel[dot]com
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.