Forum: Mikrocontroller und Digitale Elektronik Nokia 6100 Display Atmel Mega8


von Jürgen (Gast)


Lesenswert?

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

von Elektrikser (Gast)


Lesenswert?

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

von Elektrikser (Gast)


Lesenswert?

...da sie im RAM des ATmega8 hinterlegt werden müssen...

von freaka (Gast)


Lesenswert?

"Er hat nur 1k"

normalerweise hat der mega8 .... 8kb flash, und da sollte einiges
reinpassen :)

von ape (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

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

von Elektrikser (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

sorry muß heisen:



glcdPrint("Dein Text hier", 0) für RAM, und
glcdPrint(PSTR("Dein Text hier"), 1) für FLASH.

Gruß Hagen

von emil (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

> 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

von Hagen (Gast)


Lesenswert?

>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

von emil (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

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

von Hagen (Gast)


Lesenswert?

> 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

von Elektrikser (Gast)


Lesenswert?

Vielen Dank, Hagen, für deine ausführlichen Infos!!

Gruß Elektrikser

von Jens (Gast)


Lesenswert?

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