mikrocontroller.net

Forum: Projekte & Code Nokia 6100 Grafiklibrary die Zweite


Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier meine WinAVR Sourcen zur Ansteuerung des Nokia 6100 GLCD's und
Kompatiblen.

Enthalten ist ein Fonteditor zur einfachen Erzeugung von Mehrfarben
Fonts oder dem Import von Windows Zeichensätzen.
Die Library kann also mehrfarbige Fonts ausgeben. Dieses Feature kann
dazu benutzt werden eigene Icons/Bitmaps darzustellen. Desweiteren sind
effiziente Zeichenroutinen für Rechtecke, Ellipse, Linien usw.
enthalten. Die Ausgabe der Grafikroutinen kann um 0°,90°,180° oder 270°
gedreht werden, es ist also egal wie ihr das LCD auf euren Boards
aufbaut. Die Library unterstützt durch Konfiguration auch mehrere
Slaves am SPI. Die Fonts können auf einfache Weise auf externen Medien
verwaltet weren, zb. I2C EEPROMS usw.

Mehr könnt ihr in der Readme lesen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Version 1.1.
- komprimierte Fonts sind nun möglich, die Kompressionsrate beträgt
zwischen 30% bis zu 50% und bei ganz großen Fonts sogar weit über 200%.
Mit meinen Mehrfarben-Fonts konnte ich mehr als die Hälte an Speicher
einsparen.
- Fontroutinen wurden becleant und sind jetzt effizienter
- Fontroutinen unterstützen nun auch Fonts mit 8,16,32,64,128 und 256
Farben, eg. 1,2,3,4,5,6,7,8 Bits per Pixel.
Dazu muß aber in glcd.h der Wert COLOR_TABLE_BITS angepasst werden.
- komprimierte Fonts werden schneller und effizienter angezeigt als
nicht komprimierte Fonts
- Der Font Editor wurde komplett überarbeitet:
Bei großen Fonts hatte der alte Editor starke Probleme mit der
Performance, beseitigt.
- Der Editor kann nun Fonts mit bis zu 16 Farben erzeugen. Es sind
theoretisch aber mehr möglich.
- Der Editor unterstützt nun auch das Füllen von Pixelbereichen.
- Der Editor unterstützt und erzeugt automatisch komprimierte Fonts,
wenn diese weniger Resourcen verbrauchen.
- Der Editor hat nun eine Zeichen-Vorschau.
- In glcd.h wurde zusätzliche #define's eingefügt mit denen es möglich
ist bestimmte Grafikfunktionen zu deaktivieren, das sind
  USE_LINES -> glcdLine()
  USE_ELLIPSES -> glcdEllipse()
  USE_FONTS -> alle Font Funktionen
  Dadurch kann man den Resourcenverbrauch tunen.
- USE_ISR, damit kann eingestellt werden ob das Chip Select Signal des
PCF8833 automatisch nach Beendigung der SPI Transmission
  zurückgesetzt werden soll. Normalerweise muß man dieses define
aktivieren falls mehrere Slaves am SPI hängen. Es zeigte sich aber
  das ohne USE_ISR, also mit dauerhaftem CS Signal für den PCF8833, die
Störanfälligkeit bei langen Zuleitungen zum LCD erhöht wird.
  In meinen Test's betraff dies immer das Ein/Ausschalten der
Schreibtischlampe. Wurde USE_ISR nicht definiert so kommt es beim
  Display Test Program sehr schnell zu Abstürzen des LCD Controllers.
Leider gibt es keine Möglichkeit den Status der Übertragung
  zum LCD querzuchecken. Deshalb empfehle ich USR_ISR zu definieren,
auch wenn dadurch die Performance ganz leicht runter geht.
  Auf alle Fälle hat USR_ISR die Anfälligkeit des LCD's enorm
reduziert, in fact selbst 1000'maliges Ein/Ausschalten meiner
Schreibtisch-
  lampe hat keine Absütze mehr provoziert. Fairerweise muß ich aber
sagen das 1.) die Zuleitungen zum LCD ca. 50cm lang sind, das 2.) die
  Lampe direkt ca. 25cm über dem STK500 Board angebracht ist, 3.) die
Lampe eine normale Glühbirne ist und 4.) der Schalter einer von
  diesen Leitungs-Schnappschaltern ist. Gleich neben dieser Zuleitung
liegt meine Logitech-Funkmaus.
  Irgendwelche Entstörmaßnahmen wie zusätzliche Kondensatoren oder
Pullup-Widerstände wurden nicht benutzt, und das STK500 und somit das
  LCD + ATmega32 16MHz wurden auf 2.7V Vcc eingestellt !! Bei diesen
Testbedinungen ist es eigentlich logisch das eventuelle Störungen
  auftreten müssen. Um so erfreulicher ist es das mit dem USE_ISR
keinerlei Abstürze vorkamen, besonders wenn man bedenkt das das
  LCD mit dem benutzten 8MHz SPI eigentlich overtuned wurde (PCF8833
kann laut Datenblatt nur 6.5MHz SPI).


Die Font Komprimierung:
  Für eine effiziente Komprimierung auf AVR's habe ich mich von
vorhinein für ein einfaches RLE = Run Length Encoding entschieden.
  Weil eben die Dekomprimierung sehr effizient ist. Ich konnte aber
keine normale RLE Komprimierungen wie sie in Windows-Bitmaps
  benutzt wird verwenden. Es zeigte sich das diese Verfahren zu
schlechte Kompressionsraten für Fonts liefern und zudem noch
unhandlich
  bei vielen verschiedenen Font-Farbtiefen sind. Desweiteren reagieren
fast alle RLE Verfahren nicht dynamisch auf die Erfordernisse
  die die zu komprimierenden Daten stellen. Ok, man hätte ja eine
Huffman Codierung benutzen können, aber auch diese wäre ziemlich
  ineffizient in unserem Fall, auf Grund der sehr großen Lookup
Tabellen.
  Nun, die Font Routinen benutzen ein RLE Verfahren mit dynamisch
angepasster Längentabelle. D.h. bei der Komprimierung werden 4 Längen-
  codes ausgewählt so daß die erzielte Komprimierung die bestmögliche
ist. Dabei werden die am "häufigsten" vorkommenden Pixellängen mit
  gleicher Farbe als 2 Bit Werte codiert. Sogesehen ist das von mir
benutzte RLE Verfahren auch eine Mini-Huffmann-Codierung.
  Insgesammt gibt es nur 4 solcher Längen in einer Tabelle mit 4
Einträgen. Logischerweise ist der erste Eintrag in dieser Tabelle
  immer die Länge 1, sprich 1 Pixel mit der aktuellen Farbe.
Erstaunlicherweise arbeitet das Verfahren ziemlich effizient,
  und ich konnte Komprimierungen erzielen die weit über 200% lagen.
Insgesammt benötigt diese dynamische-RLE-Komprimierung nur 4
  zusätzliche Bytes. Oben habe ich das "häufigsten" separiert um
auszudrücken das dies nur eine starke Vereinfachung des Verfahrens
  ist. Tatsächlich werden nicht unbedingt die häufigst vorkommenden
gleichfarbigen Pixellängen als Längentabelle benutzt sondern
  die jenigen die mit absoluter Sicherheit die tatsächlich beste
Komprimierung ergeben. Dazu wird mit einem speziellen "Such-
  Algorithmus" alle Kombinationen der auftretenden Häufigkeiten
durchgespielt, und die kompletten Fontdaten mit jeweils allen
  Kombinationen komprimiert. Diejenige Längenkombination mit der
höchsten Komprimierung wird dann gewählt. In einem normal großen
  Mehrfarbfont gibt es ca. 100 verschiedene Pixellängen. Davon muß nun
eine Kombination von 3 Längen gefunden werden die die höchste
  Komprimierung liefern. Jede der möglichen Kombinationen kann die
beste Kombination sein, unabhänig von ihrer eigenständigen
  Häufigkeit. Eine andere Annahme als Suchstrategie ist grundsätzlich
falsch, auch ich hatte dies erst übersehen. Denn alle nicht
  in der RLE-Längentabelle erfassten Pixellängen müssen ja
zusammengesetzt werden aus diesen 4 Längenangaben, und die Reihenfolge
des
  Vorkommens der einzelnen Längenhäufigkeiten in den Fontdaten ist
ebenfalls ausschlaggebend. Dies ist auch der Grund warum die
RLELänge[0]
  immer 1 sein muß. Eine druchschnittlich gute Komprimierung erhält man
bei einer Längentabelle der Form (1,2,4,8). Allerdings auch hier
  kann es durchaus sein das zb. beim jeweiligen Font die Längentabelle
(1,2,5,13) doppelt bessere Komprimierungen ergibt !!
  Der Suchalgorithmus zur Komprimierung der Fontdaten muß also nicht
nur die Häufigkeiten der einzelnen gleichfarbigen Pixellängen
  berücksichtigen, sondern auch deren Auftreten in den Fontdaten und
das möglichst clevere Zerlegen aller nicht in der 4 Bytes
  Längentabelle codierten Pixellängen. Dies geht nur mit einem
testweisen Komprimieren der Fontdaten. So, dies erklärt auch warum
  bei sehr großen Fonts der Font Editor eine längere Zeit zur
Komprimeirung der Daten benötigt. Allerdings dürfte dies nicht so
  enorm stören da diese Komprimierung im Hintergrund in einem eigenen
Thread abläuft. Auf alle Fälle ist die benutzte RLE Codierung
  weit effizienter als die in Windows-Bitmaps oder in PNG Bitmaps
benutzte, das habe ich getestet.



Nachdem ich die MAP Files des durch den WinAVR Compiler erzeugten Codes
genauer analysiert habe musste ich feststellen das er an einigen
Stellen enorm ineffizient optimiert und der Linker noch ineffizienter
arbeitet, schade :(
Besonders erschüttert war ich über den Resourcenverbrauch der
integerierten rand() Funktion. Mehr als 800 Bytes an Code ist definitiv
viel
zu viel für einen stink normalen LCG (linear congruential generator).
Aus diesem Grunde habe ich mal meinen LFSRG aus meinen Delphi Sourcen
portiert. Nach der ersten, reinen C Umsetzung, musste ich
wieder feststellen das der WinAVR Compiler aus einem so einfachen und
echt Hardware-nahem LFSR unmöglichen Code erzeugt. Deshalb findet
ihr den LFSR als Assembler Source im Ordner \lfsr\. Wenn man den C
Overhead entfernt, der die Register sichert, kommt man auf einen
reinen
Assemblercode von 72 Bytes ! Der Source könnte also auch für ASM Freaks
sehr interessant sein.

Das von mir benutzte mathematische Verfahren ist
1.) schneller als der LCG von rand()
2.) wesentlich code effizienter als rand()
3.) hat bessere statistiche Eigenschanften, er ist also zufälliger als
ein LCG
4.) ist kryptographisch weit sicherer als der LCG von rand()

Das Verfahren ist ein LFSR-SG, also ein Linear Feedback Shift Register
Shrinking Generator mit einer Periode von 2^63 -2. Diese Periode
IST IMMER garantiert, egal wie die Seedregister belegt sind. Der LCG()
von rand() hat eine maximale Periode von 2^31-1 diese ist aber
abhängig vom Seed des Generators, kann also wesentlich kürzer sein. Für
die "Nicht-Mathematiker", wenn man die Seed Register mit einem
beliebigen Wert füllt dann muß man 2^63 -2 Bits erzeugen bis die
Seed-Register wieder den Anfangswert bekommen. Man kann also
9223372036854775806 Bits nacheinander erzeugen ohne statistische
Wiederholungen in der Zufallsfolge. Das sind 1023 Penta Bytes ==
1023 * 1024 Terra Bytes !!

Damit der LFSR-SG arbeitet benötigt er zwei nicht reduzierbare Polynome
(irreducible polynoms) im GF(2) -> Galois Field 2.
Um euch die Erzeugung bzw. Auswahl solcher Polynome leichter zu machen
habe ich in der Datei lfsr.inc jeweils 1000 solcher Polynome
hinterlegt. Diese Polynome sind auf ihre "Nicht-Reduzierbarkeit"
geprüft und wurden zufällig erzeugt. Wichtig ist nur das ihr
als Polynom_S und Polynome_A in der Datei lfsr.S aus der richtigen
zugehörigen Tabelle auswählt. Dabei wird das LFSR S mit dem Polsynom_S
betrieben, welches ein Degree von 32 besitzen muß. Das LFSR A wird mit
Polynom_A betrieben welches einen Degree von 31 haben muß.
Die kryptografische Sicherheit dieses LFSR-SG beträgt 126 Bits, solange
die benutzten Polynome NICHT für Aussenstehende bekannt sind !
D.h. die Funktion lfsr() kann als Source benutzt werden für eine
einfache XOR Verschlüsselung, man muß aber sicherstellen das die
beiden
Polynome A & S nicht öffentlich bekannt werden. In den Registern lfsr_S
und lfsr_A kann man den Verschlüsselungs-Schlüssel ablegen.
Dieser Schlüssel hat dann eine effektive Länge von 63 Bits + die 63
Bits der beiden Polynome ergeben 126 Bits. Sind dieser Schlüssel
und die Polynome für einen Angreifer nicht bekannt so muß er eine
Bruteforce Attacke auf 126 Bit Schlüsselraunm durchführen.

Als Randbemerkung: die BasicCard's, das sind SmartCard's einer
deutschen Firma, benutzten lange Zeit das gleiche Verfahren. D.h. der
Code
ist kompatibel mit den in diesen BasicCard's eingesetzem
Zufallsgenerator.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
minor changes:

- Atmega128 support hinzugefügt
- Test-DEMO geändert

Gruß Hagen

PS: danke für die viele Verbesserungsvorschläge eurerseits :)

Autor: AVR FREAK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du mal ein paar neue Bilder posten ?
Ich meine von irgendwelchen Displayspielereien :-D in Farbe ?

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:
  • i4.zip (229 KB, 2686 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Au mann, viel Spaß beim Download. Es ist ein ganz schöner Aufwand gute
Bilder vom LCD zu schießen. Meine Casio QV-5700 hat einfach eine zu
gute Auflösung und im ersten Moment dachte ich das durch die
Interferenzen echt schlechte Bilder rauskommen. Mit Blitz kann man das
Display schon garnicht knipsen.

Hier im ersten ZIP seht ihr die Ausgabe eines 4 Farbenfonts innerhalb
eines Clipping-Bereiches, d.h. die Zeichen werden in der Zeichenroutine
auf das äußere Rechteck beschnitten. Dann seht ihr eine Textausgabe in
proportionalem Font innerhalb eines Frames mit Schatten. Dies
Textausgabe benutzt für den Zeilenumbruch und Ausrichtung am linken
Rand die automatischen Funktionen der Library. D.h. für diesen Text
ruft man nur glcdPrint_P(PSTR("text, bla bla hier")); auf, In den
letzten Bildern seht ihr übergroße Fonts, sozusagen Icons/Images in 4
Farben. Allerdings sind diese 4 Farben hauptsächlich so gewählt das ein
Anti-Aliasing stattfindet.
Das allerletzte Bild gibt die echten Größenverhältnisse wieder, relativ
zu einem 17" Monitor mit 1152x864 Bildschirmauflösung.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, und damit man mal sieht was meine DigiCam beim obigen letzten Bild
gesehen hat, hier noch mal ein Bild un-gestützt.

Allerdings musste ich es beschneiden und die Jpeg Kompressionsrate rauf
setzten damit ich es von 4 Mb auf 1 Mb runter bekomme.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, beim Bild mit der "Uhrzeit" ist das dunkle Blau das was das LCD
unter Schwarz versteht !! Sogesehen sieht man schon in der
Farbdarstellung gravierende Unterschiede zu den Farb-TFT-Display's der
heutigen Handheld's.

Gruß Hagen

Autor: Conlost (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

schöne Bilder, kommt das blau statt schwarz eventuell von
der Hintergrund-Beleuchtung?

Eine Frage hab ich noch, wo bekommt man diese riesigen
Euro-Münzen?  :-)

Gruß,
Arno

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, meine ich nicht. Das LCD ist ein STN Display und eigentlich sind
das technologisch gesehen "Auslaufmodelle". Das Display hat immer
einen Blaustich bei dunklen Farben, egal ob mit oder ohne
Hintergrundbeleuchtung. Ich habe alles ausprobiert,
Kontrasteinstellungen, Farbtemperatur, Hintergundbeleuchtung hell,
super hell und dunkel bis aus eingestellt, das schwarz ist und bleibt
eben bläulich. Allerdings! fällt das nicht so sehr auf wenn die
Dunkelblauen Bereiche nur ein Pixel breit sind, heist also Rahmen oder
Linien neben anderen hellerern Farben.
Interessant ist aber der Fakt das Rot, Gelb, Grün farblich sehr satt
rüber kommen und eben keinen Blaustich haben.

Ich habe mal die Farbeigenschaften mit denen meines Palm's IIIc und
Tungsten T verglichen, bei diesen beiden Display's wird eben das
Schwarz auch Scharz dargestellt.

Wie gesagt ich vermute das es in der STN Technologie begründet liegt.

Und jo, das LCD ist klein, aber immerhin noch besser und größer als
mein Siemens S55 Display. Aber aich hier, das S55 stellt schwarz nicht
bläulich dar. Die Baugröße kann aber durchaus auch ein Vorteil sein,
denn eines hat das Display auf alle Fällen -> eine sauscharfe und
unverwaschene Anzeige.

Eventuell liegt es ja an meinem LCD ?? Maximilian was sagt's du dazu
?? Oder man benötigt noch einen speziellen Filter vor dem LCD aus
Plastik ??

Gruß Hagen

Autor: Conlost (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Größe ist schon ok und wenn man nicht weiß das blau eigentlich
schwarz sein sollte, merkt man das kaum.
Ich spiele mit dem Gedanken dieses Display in meinem geplanten
Eigenbau KW-QRP-Transceiver zu verwenden als Multifunktionsanzeige.
Aber bis das Ding fertig ist dauert es noch etwas.

Gruß,
Arno

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Erklärung gäbe es noch: Nachdem ich mal meinen Tungsten
aufgeschraubt habe konnte man sehen das die "weißen" LED's der
Hintergrundbeleuchtung beim 6100 LCD doch ziemlich blaues Licht
erzeugen. Die Hintergrundbeleuchtung beim Tungsten hat wesentlich
weißeres Licht. Wer weis.

Gruß Hagen

Autor: ape (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so auch ma wieder da
mhmm also ich weiß jetzt nich in wieweit das auf den fotos vielleicht
noch verfälscht ist, aber ich denke mein Display ist nicht ganz so
blau.
aber wie gesagt kann sein das das täuscht.

meine leds hab ich noch nicht genauer betrachtet, aber wenn deren licht
zu blau wäre, sollte doch eigentlich das weiß blau sein und nicht das
schwarz.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Bilder treffen sehr gut das Blau, ähm Schwarz meines Displays.
Die LED's betreibe ich auch nur mit 6.2 Volt, über'ne Zenerdiode.
Alleine wenn nur die Hintergrundbeleuchtung an ist und das LCD ansich
aus, leuchtet es dunkelblau.

Nungut, da die anderen Farben sehr gut rüberkommen, und ich meistens
einen weißen Hintergrund benutze, kann ich damit leben.

Der Unterschied in den weißen LED's fällt aber nur im direktem
Vergleich auf. Ich dachte auch erstmal das die LED's gutes weißes
Licht liefern. Erst beim direktem Vergleich mit der Tungsten
Beleuchtung viel mir der Unterschied auf. Aber dann echt drastisch. Die
weißen LED's des Nokia's sind wirklich bläulich. Die Tungsten LED's
leuchten irgendwie mir einem wärmerem Weiß.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Version 2.0 ist fertig.

Die Lib ist jetzt eine echte Link-Bibliothek und somit hat der
gcc-Linker die Chance nicht benutzte Funktionen weg zu optimieren.
Die Lib wurde komplett neu gecodet in handmade Assembler. Dies hat zur
Konsequenz das die Funktionen weitaus efizienter als ihre C Pendants
sind und zusätzlich noch der Codeverbrauch von 4500 Bytes auf maximal
2800 bytes reduziert wurde. Im besten Falle kommt die Lib zur
Ansteuerung des LCD's mit 600 Bytes aus. D.h. es war mir möglich ca.
50% code einzusparen im vergleich zum WinAVR gcc Compiler und zusäzlich
die Performance zu steigern und sogar die Features zu verbesseren.
Schade das gcc so mittelmäßig ist.

Mehr im ZIP File, Readme.txt und Install.txt.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Version 2.1.

- kleinere unwesentliche BugFixes in glcdEllipse()
- Performance von glcdLine(), glcdEllipse() wesentlich verbessert
- mehr Dokus
- Test DEMO leicht geupdated
- einige Optimierungen in den Font Routinen die Codegröße reduzieren
und Performance erhöhen.

Gruß Hagen

Autor: Kofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... na wer schlägt sich denn da wieder die Nacht um die Ohren ?!

Ist ne coole Sache mit dem Display... Ich hoffe meins kommt auch bald
an!

Soein Display in Groß (4") würde mich mal reizen !!

Wie wärs wenn du uns mal ne nette Grafik-routine für verbreiterere
controller als den KS108 z.B. HD61830 oder T6963 zaubern würdest?
Da lässt sich doch dann sicher auch viel portieren ?
grin

gute n8

Kofi

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite meistens Nachts :)
Nich so schnell, ich programmiere erst seit 4 Wochen auf AVR und MCU's
im allgemeinen.

Ich würde noch warten, bis die heutigen Handys in einem Jahr
Auslaufmodelle sind. Und schon gibts dann 128x160 und 160x240
Display's wie Sand am Meer, also schon QVGA. Die weitere Entwicklung
dürfte klar sein. Bisher sind mir die Dinger mit rund 40? noch zu
teuer.

Die KS108, HD61830 oder T6963 habe ich in meinem Leben noch nie gesehen
geschweige denn verbaut. Würde ich so'n Ding besitzen gäbs
wahrscheinlich auch eine Grafik Library dazu. Allerdings sind das nicht
meistens nur monochrome Display ??


Gruß Hagen

Autor: Kofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja sind es... aber ungeschlagen günstig im vergleich zu Handy Displays.

http://www.lcd-module.de/giff/grafik/p128-6n7.jpg (30€)

Damit es bei den Handydisplays Sinn macht müsste schon das Display
eines P800 / P900 herhalten ... (dann gleich mit Touchpanel-Auswerrtung
g)

http://homepage.hispeed.ch/p800_info/p800/pics/Angepasst.JPG

Gruß
Kofi

Autor: Martink (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
30 Euro sind doch teuer!!!
Ich habe für mein Nokia 6100 Farbdisplay 23 Euro bezahlt.
Natürlich gibt es noch viele andere gute Handydisplays, aber das
Hauptproblem ist es, an die Datenblätter zu gelangen.
Somit hat das Nokia 6100 Display zur Zeit das beste
Preis-Leistungs-Verhältnis.
(P.S. die echten Profis warten noch, bis es die Farb-OLEDs
günstig zu kaufen gibt)

An Hagen: Wie lange hast du eigentlich gebraucht, um die Routinen
zu programmieren? Auch der Fonteditor hat es mir sehr angetan.
Mach weiter so!!!

MartinK

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist immer schwierig, man sitzt ja nicht zu hause neben einer Stechuhr.
Also am FontEditor habe ich ca. 3 Tage gesessen, wobei der jetzige Font
Editor schon sichtbar unterschiedlich zur 1. Version ist. Dabei ging
ca. 1 Tag = 9 Stunden für die neue Font Komprimierung drauf (muß ja
auch erstmal erdacht werden :) Allerdings, in Delphi code ich
professionell schon seit dem es auf dem Markt ist. Es wäre schon'ne
Schande länger als 3 AT dranzusitzen.

An den GLCD Sourcen, ca. 2 Wochen insgesammt, ich habe ja nebenbei noch
Geld zu verdienen.
Da die Portierung vom C nach Assembler erst kürzlich war habe ich da
bessere Zahlen. Insgesammt hat es mich 4 Tage intensiv (ca. 12h pro
tag) gekostet, über Ostern die meiste Zeit, um die C Source nach ASM zu
portieren. Nachdem die größsten Hürden genommen waren ging's ruckzuck,
Atmels in Assembler zu codieren ist eine der einfachsten
ASM-Geschichten der Welt im Vergleich zu vielen anderen Assemblern
(Motorola usw.).
Viel viel mehr Zeit, ca. 10 Stunden, habe ich dagegen verbraten um
durch die WinAVR gcc assembler Syntax durchzusteigen, die optimalsten
Mittel der codierung zu finden -> Macros funktionieren zb. auf Grund
der Registerdefinition im gcc-as nicht korrekt. Erst nachdem man die
Registernamen neu den Registerindizes zuweist funktionieren auch
Macros. WinAVR hat da scheinbar Mist gebaut und den direkten Zugriff
auf Ports und Register über Defines verhindert. Nungut, ich meine wenn
man Assembler codiert dann sollte man ALLE Freiheiten haben, ein
Assemblercodierer ist IMMER Schlud wenn irgendwas nicht funktioniert.
Nachdem das alles geklärt war, und der Source schon fertig im Kopf ist,
muß man ihn nur noch einhämmern und die kleineren Tipp-Bug's finden.
Dann noch 1 Tag "Source-Schönmach-Doku-Tag".


Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das mein erstes gößeres Projekt für Atmels ist, ich also vorher noch
nie mit Atmels oder irgendwelchen anderen MCU's gebastelt habe, bin
ich eigentlich mit dieser Einarbeitungszeit von 2 Monaten ganz
zufrieden. Die Software ist auch nicht das Problem für mich, es ist die
Hardware :(

Wie lange hat es bei euch denn gedauert ?? Vielleicht bin ich ja viel
zu optmistisch :)

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Damit es bei den Handydisplays Sinn macht müsste schon das Display
> eines P800 / P900 herhalten ... (dann gleich mit Touchpanel-
> Auswerrtung g)

Dies ist richtig, allerdings rechne mal nach 240x320 Pixel in 16Bit =
154KB Display-RAM zu beackern. Eine 32x32 Bitmap würde 2Kb Speicher
fressen und denoch nur 1/75'tel des Displays ausmachen.
Ich halte die 176x220 Displays vom Nokia 6600 oder Siemens SX1 für
ausreichend. Ein 9x14 Font waagerecht ergäbe ein 24x12 Zeichendisplay
das super gut abzulesen ist. Der Preis dieser Displays MUSS aber erst
auf unter 32? fallen. Derzeit liegen sei bei 80?.
Vorher schätze ich aber mal das die Nokia 6100 Display's für 15-10? im
Ausverkauf zu haben sind.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine wichtige Bemerkung zur Library:
Die Lib nutzt ja Hardware SPI als Master. Wenn in der glcd.inc die Pin
Konfiguration verändert wird, so das das ~SS Pin NICHT benutzt wird, so
ist es trotzdem wichtig diesen ~SS Pin als Output zu definieren, oder
immer auf High zu setzen falls es ein Input ist.
Genaueres könnt ihr in den Datenblättern nachlesen.

Gruß Hagen

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat schon jemand versucht, den C Code umzuschreiben für das 3510i?
Wäre sehr von Interesse.

mfG

Matthias

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

läuft bei mir schon einige Zeit mit einem 3510i. Hatte ich in dem
Nachbar-Thread http://www.mikrocontroller.net/forum/read-4-71176.html
auch schon geschrieben. Hatte auch eine erste Version an Hagen
geschickt. Eigentlich wollte Hagen dies in die Lib einarbeiten, hatte
aber noch keine Zeit dazu.

Meine Version ist wohl noch nicht so aufgeräumt wie sie sein sollte,
aber ich kann sie Dir gerne zukommen lassen.

Volkmar

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,

gibt es eine ähnliche library auch für den msp430 oder müsste man sich
das selbst umschreiben.

mir würde auch ein einfaches beispiel zur ansteuerung reichen. den rest
der grafiklib kann man dann selbst entwickeln

Autor: olegk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
hat jemand Datenblätter für  Nokia 6600 oder P800 Display?
Gruß,
oleg

Autor: Deramon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weis jemand wie das mit dem Color Set/RGBSET funktioniert, also wie ich
z.b. eine Farbtabelle mit den 256 Farbwerten eines 8bit Bitmaps in den
pcf8833 übertrage ? Die Angaben im Datenblatt sind leider sehr wenig
und mit diesem "8bit auf 12bit mapping" kann ich überhaupt nichts
anfangen :/
Ich hab gelesen das es in der Grafiklib eine funktion dafür gibt, nur
mit Assembler kenne ich mich nicht wirklich aus :)

MfG
Thomas W. aka Deramon

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Grunde dürfte das egal für dich sein, denndie interne Collormap musst
du so oder so initialisieren im 8Bit Modus. Zudem eine 8bit Bitmap die
du auf deinem Rechner schon farbig siehst muß nicht zwangsläufig
genauso auf dem Display erscheinen, denn dessen Farbqualitäten sind
doch recht eingeschränkt.

Um nun in der GLCD die Colormap zu verändern benutzt du die Funktion

glcdDisplaySetColors(const uint8_t *red, const uint8_t *green, const
uint8_t *blue, uint8_t flashstored);

red, green, blue zeigen dann auf Speicherarrays wobei red und grenn
arrays mit 8 Bytes sind und Blue verkürzt nur 4 Bytes enthält. Dies
liegt hauptsächlich daran das das LCD von vornhereineinen Blaustich
hat.

Intern baut der Displaykontroller daraus eine Tabelle mit 256 Einträgen
auf. Jeder Eintrag hat dann 12 Bit Breite, und entspricht somit einer
12Bit Farbe ala 4 Bits pro Farbe.

Wird nun ein Pixel im 8Bit Modus gesetzt so stellt dieser Farbwert im
Grunde nur ein Index in diese Tabelle dar. Der Controller empfängt
diesen 8Bit wert, transliert ihn über diese Tabelle in einen 12Bit
Farbwert und speichert diesen dann im Displayram.

Die Arrays[] red/green/blue stellen also im Grunde pro Farbe deren
Graustufenverlauf dar.

Um zB. eine Windows-Bitmap in ihrer Farbe möglichst exakt auf's
Display zu übertragen müsstest du erstmal eine 12Bit Farbtabelle
anlegen die die realen Farbverhältnisse auf dem Display darstellt.
Sprich das Display stellt nacheinander alle seine möglichen Farben dar.
Diese werden abphotographiert und in eine reale Farbtabelle konvertiert.
Nun hat man also eine Farbtabelle die die Realen Verhältnisse der
Farbdarstellung des Display repräsentiert. Dabei wird man festestellen
das BLAU viel viel stärker vertreten ist als Rot oder Grün. Nun, mit
hilfe dieser Tabelle muß man nun auf dem PC die Bitmap in ihrere Farbe
so konvertieren das die möglichst stark an die Ausgangsbitmap
herankommt. Die dazu benutzten Farbwerte der 12Bit Tabelle muß nun
komprimiert werden auf eine 8Bit = 256 Farbwerte. Nach diesem Schritt
kann man nun aus der konvertierten Bitmap heraus die nötigen Werte für
die arrays red/green/blue berechnen und mit obiger Funktion an das
Display senden. Nur über diesen Weg bekommt man die höchstmögliche undf
realste Farbwiedergabe der Bitmap zu stande.

Ich vermute das du eine Bitmap a 128x128 Pixel Displayfüllend
darstellen möchtest, und nun nach einem Weg suchst diese Bitmap
möglichst farbtreu darzustellen. Nungut den korekten Weg dahin weist du
ja nun.

Gruß Hagen





Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht nochmal zur Verdeutlichung:
über glcdDisplaySetColors() überträgt man eine Farbtabelle mit 8 Werten
Rotanteil, 8 Werten Grünanteil und 4 Werten Baluanteil, macht im
gesammten 8  8  4 = 256 Farbwerte in der realen Tabelle. D.h. aus
diesen Informationen baut der Controller intern einfach über
Kombination der einzelnen Werte pro Tabelle die 256 Werte umfassende
Tabelle zusammen. Diese Tabelle enthält also nach ihrer Fertigstellung
256 Werte a 12Bit.

Der Vorteil dabei liegt daran das man nur sehr wenige Daten an das
Display senden muß, der Nachteil ist aber der Fakt das man nicht frei
und beliebig ALLE 256 Werte der internen Tabelle setzen kann, sondern
eben nur die Kombination von 8*8*4 Werten. Dh. zB. pro rotem
Farbeintrag kann es nur 4 echte Blaukombinationen in der 256 Tabelle
geben und diese Balukombinationen sind direkt verknüpft pro grünem
Eintrag. Wenn also in den 4 blauen Werten im Array Zb. kein 0x0F
vorkommt so kann es auch kein Rot und Grün geben das absolut weis
erscheint.

Somit erreichst du die beste Farbbrillianz nur wenn du die Pixel im
12Bit Farbmodus setzt und die Bitmap selber in ihrer Farbdarstellung an
das Display vorher angepasst wurde.
Zum Glück ist es mit der Library theoretisch möglich während der
Laufzeit den Farbmodus temporär von 8Bit auf 12Bit und sogar 16Bit zu
erhöhen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Empfängt der Controller einen 8Bit Pixel so berechnet er daraus die
Indizes in die 8+8+4 Arrays die du über glcdDisplaySetColors()
übertragen hast. Das ist ganz einfach

BlauIndex = Pixel % 4;
RotIndex = (Pixel / 4) % 8;
GrünIndex = ((Pixel / 4) / 8);

12BitRGB = BlauArray[BlauIndex] | RotArray[RotIndex] << 4 |
GrünArray[GrünIndex] << 8;

Gruß hagen

Autor: Deramon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die ausführliche Erklärung :)
Im moment benutze ich ein c script zur Ansteuerung des Lcds und
compactflash. Die ASM lib hab ich nur kurz mal ausprobiert, hat aber
nicht hingehauen(verwende nicht SS als CS, war aber bisher zu faul ein
neues adapterkabel zu löten)

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen,

ich habe die Tage einen Bug in der glcd festgestellt. Dieser tritt beim
ATmega128 auf wenn die Library in die oberen 64K rutscht. Insbesondere
hängt es (zumindest) and dem Makro ENTER:

// macro to enter a stack with gcc

.macro ENTER unused_regs stack_locals

ENTER:
        clr     XH
        ldi     XL, \stack_locals
        ldi     ZH, hi8(ENTRY)      // there is no way to rescale an
address by 0.5
        ldi     ZL, lo8(ENTRY)      // thus we have to right shift the
address with additional code
        lsr     ZH
        ror     ZL
        xjmp    (_prologue_saves_ + 2 * \unused_regs)
ENTRY:
.endm

Wenn die Adresse ENTRY im oberen 64K-Block liegt, dann wird der Inhalt
von Z falsch berechnet. Leider habe ich auf die Schnelle nicht
herausgefunden, wie man an das 3. Byte der Adresse kommt um das LSB
noch in ZH reinzuschieben. Vielleicht hast Du es ja zur Hand?

Volkmar

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
versuche mal das

// macro to enter a stack with gcc

.macro ENTER unused_regs stack_locals

ENTER:
        clr     XH
        ldi     XL, \stack_locals
        ldi     ZH, pm_hi8(ENTRY)
        ldi     ZL, pm_lo8(ENTRY)
        xjmp    (_prologue_saves_ + 2 * \unused_regs)
ENTRY:
.endm


es gibt nämlich eine Möglicheit die ich damals noch nicht kannte ->
pm_hi8() statt hi8().

Ob das real hilft kann ich dir nicht sagen da ich noch nie mit einem
ATMega128 zu tun hatte.

Ansonsten mal testweise eine C Source Funktion die im oberen Bereich
liegt mit vielen lokalen Variablen compilieren. Danach mal im *.lst
File nachschauen was der Compiler als Code erzeugt hat.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier mal version 2.2. du scheinst noch mit 2.1 zu arbeiten. In dieser
Version hatte ich überall schon das hi8(),lo8() durch pm_hi8() und
pm_lo8() ausgetauscht.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
shit, obige ist noch die alte version, hier die richtige, sorry.
das ist die demnächst zu veröffentlichende version 2.2. an der eben
noch eventuell zu arbeiten ist. Also nicht stören wenn überall noch
version 2.1. drinnensteht, und die pm_hi8() änderung noch nicht in der
readme.txt auftauchen.

gruß hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volkmar,
wenn du deine Anpassungen für den ATMega128 in der GLCD fertig hast,
und diese funktionieren könntest du mir diese änderungen dann zukommen
lassen ? Wäre nett, denn ich könnte sie dann direkt in die offizielle
Version einbauen.

Gruß Hagen

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen,

mache ich gerne. Ich habe zur Zeit leider nur ein zeitlichen Problem.
Hast Du denn schon eine zeitliche Vorstellung, wann Du die 2.2
offiziell machen möchtest?

Obiges war aber eigentlich das einzige Problem, welches ich wegen dem
M128 hatte (abgesehen von Port-Definitionen). Aber ich habe einiges
wegen dem Nokia 3510i geändert, und noch ein paar andere Kleinigkeiten.
Das wäre sicher interessant für die 2.2. Ich schaue mir Deine aktuelle
Version mal an und den Rest machen wir dann offline, würde ich
vorschlagen.

Volkmar

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal ich,

habe gerade nachgeschaut. Die 2.2 wurde schon mal veröffentlicht (Ende
April). Und das ist auch die, die ich nutze. Der einzige Unterschied
liegt im angesprochenen pm_hi8() und pm_lo8(). Sonst habe ich keinen
Unterschied entdecken können.

Jedenfalls werde ich es, sobald ich dazu komme, testen und Dir Bescheid
geben. Wenn ich es heute abend nicht schaffe (und auch da ist der
zeitliche Rahmen schon eng), wird es erst nächste Woche was.

Volkmar

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
korrekt es ist die einzigste Änderung, irgendwann tritt jedes Projekt in
die Phase des "Tiefschlafes" ein wenn man es nicht mehr braucht ;)
Und danke das du mir die Änderungen mailst. Bin schon gespannt darauf.
Allerdings, am Font Editor habe ich einige Bugs beseitigt.

Version 2.2 sollte eigentlich offiziell deine Nokia 3510i Änderungen
enthalten. Auch die Anpassungen für den Epson Controller wären schön
gewesen, nur hatte ich bisher in diesem Punkt noch keinerlei Feadback
von anderen (ich selber habe ja kein Epson Display). Aber du weist ja
wie das ist, wenn man es selber nicht konkret benötigt dann lässt man
es zeitlich schleifen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Volkmar, lass dir Zeit es eilt nicht, bin eh nächste Woche in London.

Gruß Hagen

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kurze Rückmeldung: Mit den Änderungen in pm_lo8() etc. funktioniert es
an dieser Stelle. Der Rest kommt dann wie besprochen später.

Volkmar

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe ein Problem mit dem Fonteditor.
Wenn ich eine Font im Editor öffne zum bearbeiten, dann kann ich sie
nichtmehr bearebiten. Nur Fonts die ich neu anlege können von mir
bearbeitet werden.
Habt ihr auch dieses Problem, was kann ich da machen? Ich moechte mir
eine Icon-Font anlegen und die Icons nicht staendig neu machen, wenn
ich an einem etwas verändere...

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da gabs noch einen Fehler, probier mal den aus dem Anhang aus.

Gruß Hagen

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, funktioniert glaube ich besser :-)

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so ganz funktioniert das immer noch nicht... :-/

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, jetzt müsste es aber definitiv funktionieren. Leider kann ich
nicht mit deinen Daten austesten ;)

Gruß hagen

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

da ich auch Probleme mit dem Fonteditor hatte (vielleicht erinnerst Du
Dich ;-), habe ich eben mit dieser Version folgendes ausprobiert
(nachdem ich meine alten Dateien auch damit nicht bearbeiten konnte):
- Fonteditor starten
- Neuen Font erstellen, Höhe 5 Pixel
- Zeichen '0' erstellt (3 Pixel breit)
- Font abgespeichert
- Font wieder geladen
- Zeichen '0' ist leer, und ich kann auch keine anderen Zeichen
ändern/hinzufügen

Wo wir schon dabei sind: Ich hätte noch folgenden Wunsch. Mit "Export
font" wird ja die header-Datei für den Compiler erzeugt. Solange man
den Font nur aus einem Modul heraus verwendet, ist die auch
ausreichend. Wenn ich jedoch mehrere Module in meinem Projekt habe in
denen ich den gleichen Font verwende, wird dieser Font n-mal
eingebunden. Kannst Du nicht zwei Dateien exportieren? Eine .h und eine
.c? So habe ich die Font-Dateien bei mir von Hand angepaßt. Hier ein
Beispiel:
----- Datei f3x5.h -----
#include <inttypes.h>
#include <avr/pgmspace.h>

#ifndef f3x5_H
#define f3x5_H

#define f3x5_WIDTH 4
#define f3x5_HEIGHT 5

extern uint8_t _attribute_ ((progmem)) f3x5[];

#endif
----- Datei f3x5.h -----

----- Datei f3x5.c -----
#include <inttypes.h>
#include <avr/pgmspace.h>

uint8_t _attribute_ ((progmem)) f3x5[] = {
    0x00, 0xFA, 0x04, 0x05, 0x01, 0x30, 0xB0,
    ...
};
----- Datei f3x5.c -----

Volkmar

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das lässt sich beides machen. Der Fehler ist noch drinnen, habs in
15 Jahren Profi-Programmierung noch nie erlebt das man eine Software
fehlerfrei bekommt, ich beete das ich diesen tag mal erleben darf.

So wie es aussieht entsteht dieses Problem NUR wenn man einen Font
speichert der nur 1 Zeichen enthält.

Das Speichern könnte ich mir so vorstellen das man verschiedene
Templates erzeugt. Wir haben ja jetzt schon "font.template" das als
Vorlage zur Erstellung der Header datei dient. Ich werde es nun so
umbauen das in der Konfiguration Font.ini mehrere solcher Templates
angegeben werden können. Die Endung des Templates gibt dabei die Endung
der zu exportierenden Font Datei an. Der Inhalt des Templates den Inhalt
der exportierten Datei. Somit ist es frei konfigurierbar was du wie wo
abspeichern willst. Ich müsste dann nur nochmal eine kleine Hilfe zu
den Templates und deren Aufbau erzeugen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ok, Änderungen sind eingearbeitet und der blöde Editierungsfehler beim
geladenen Font sollte jetzt wirklich raus sein.

In der Datei "Templates.txt" steht drinnen wie die Templates
aufgebaut sind, Diese werden in der "Font.ini" angegeben und diesen
als Vorlage beim Export der Fontdatei. Es können mehrere solche
Vorlagen als Datei in der INI angegeben werden, und der Editor
exportiert dann nacheinander die gleichen Fontdaten in diese Dateien.
Die Extension dieser Template Files werden dann zu den Endungen der
exportierten Dateien.

Gruß Hagen

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

vielen Dank für die prompte Bearbeitung. Auf den ersten Test sieht das
alles gut aus.

Volkmar

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ist es ein größerer Aufwand das Font-Program so abzuändern, das
man damit 256 Farben nutzen kann? Ich möchte ein paar Icons entwerfen
und da komme ich mit 16 Farben nicht so weit. Wie kann ich mir da sonst
weiterhelfen?

Danke

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in den Font Dateien steht ausserdem drin, das die nicht komprimiert
sind, wie schalte ich die komprimierung ein, so verbrauchen die
naemlich schon sehr viel speicher...

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal eine 256 FontEditor Version. Einzigstes "Manko" ist die
Auswahl der Farbe in der Farbpalette. Man muß halt umständlich
scrollen.

Du musst dann aber testen ob die GLCD Fontroutinen mit 256 Farben noch
sauber arbeiten, eventuell sind Änderungen an den Font Routinen nötig.

Der FontEditor selber versucht immer den Font zu komprimieren. Im Memo
des FE's kannst du nachschauen wieviele Bytes ein komprimierter Font
und ein un-komprimierter Font benutzt. Sollte der Font unkomprimiert
weniger Speicher verbrauchen so wird der Font immer unkomprimiert
gespeichert, logisch.

Die verwendete Komprimierung (ähnlich wie RLE) kann natürlich nur
komprimieren wenn viele Pixel mit gleicher Farbe hintereinander im
Zeichsatz vorhanden sind. Dies ist bei Fonts auch die wahrscheinlichste
Grafik. Bei Bitmaps/Icons aber sind die Bildinhalte wenig Monochrom und
deshalb sinkt das Komprimierungsverhältnis drastisch. Aber, einen Trost
gibt es, bis auf das komplizierte JPEG Format (verlustbehaftet) gibt es
im Grunde keine wirklich gute Komprimierungsart die kribbelbunte Bilder
komprimieren kann (auf'm AVR :)


Gruß Hagen

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank, das ist echt genial das du immer so schnell reagierst!
eine andere Frage habe ich allerdings noch,
meine momentanen 16 Farben Icons werden wenn ich sie auf den AVR lade
anders angezeigt, als sie im fonteditor waren, also z.B. rot ist nicht
rot sondern blau. die Farben wirken alle sehr blau/gruen stichig. Muss
ich irgendwas speziell konfigurieren oder vorher setzen um die Farben
so zu sehen wie im Editor? Habe schon versucht fuer die 16 Farben den
glcdSetColor Befehl auszufuehren, aber das bringt nichts, bzw. beim
setzen von allen ist der AVR abgestuerzt.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Fonts speicher nur indirekt die Farbe. In der GLCD Library gibt es
ja das glcd_Colors[] Array. Dieses speichert die realen Farben. Du
musst also 2 Dinge machen:
1.) glcd_Colors[] muß die korrekte Größe besitzen, dazu
glcd_ColorTableBits in deinem Falle auf 4 setzen, da 2^4 = 16 ist.
2.) nun musst du natürlich vor dem Zeichnen einen Fontzeichens dieses
glcd_Colors[] Array mit den richtigen Farben füttern.

Diese Vorgehensweise der GLCD hat im Grunde nur Vorteile. Man kann
x'beliebige Fonts erzeugen, unabhängig von der realen Farbe, und dann
zur Laufzeit kann man die gleichen Zeichen in unterschiedlichen Farben
zeichnen lassen. Oder im Falle einer Portierung der GLCD Library kann
das bedeuten das die Art und Weise wie die Farbapixel gesetzt werden
müssen unabhängig von der Fontroutine ist.

Und ja, das Display ist Blaustichig. Das musst du vorher
berücksichtigen und in glcd_Colors[] eben Farben benutzen die deinem
Gechmack entsprechen. Ich habe die Erfahrung gemacht das man zwar mit
den maxiaml 4096 Farben arbeiten kann, aber effektiv nur 256, oder
sogar 16 Farben sich real sauber unterscheiden. D.h. die meisten Farben
der 4096 möglichen sind enorm Balustichig. Besonders die dunklen Farben
bis hin zu schwarz sind immer bläulich.

Woran das liegt weis ich nicht, entweder an den bläulichen
Hintergrund-LEDs, oder am Typ des Displays.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denoch, für den Preis bekommt man momentan kein besseres und einfachers
und kompakteres Display als das Nokia. Schau dir mal die Grafikdisplays
bei den einschlägigen Händlern an, vergleichbare Typen kosten das 5 bis
6 fache, und sind in der Bauform viel globiger.

Gruß Hagen

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo bekommt man das Display

lG chris

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@chris: am besten bei ebay, ich habe ca 16Eur gezahlt. Achte aber darauf
das die Platine braun ist!!!, die mit der gruenen Platine haben einen
anderen Controllerchip drauf und lassen sich nicht so gut ansteuern.

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe versucht die Farben wie folgt zu setzen, aber die Farbtoene
sind trotzdem alle schwarz  bla  gruen

glcdSetColor(0, RGB(0xff, 0xFF, 0xff));
usw.
was mache ich falsch?

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1.) du hast in GLCD.inc auf den 256 Farben Modus eingestellt

#define USE_CLIPPING                                        // support
clipping
// #define USE_HIGHCOLOR                                       // 65536
color mode
// #define USE_ORGINALCOLORS                                   // in
256 color mode use original color table
// #define USE_AUTOINIT                                        // call
glcdDisplayInit() automaticaly on startup

2.) in GLCD.inc hast du

#ifndef COLOR_TABLE_BITS
#define COLOR_TABLE_BITS            4                 // 2^4 = 16
colors in color table (minimum)
#endif


stehen. Falls Punkt 1.) oder 2.) nicht zutraf so musstdu dies ändern
und die GLCD Library erneut vollständig compilieren.

3.) glcdSetColor() ist nur ein Makro und benutzt glcd_Colors[Index] =
Farbe; Du hast im Fonteditor in der Farbpalette zb. folgende Farben
eingestellt: Schwarz, Weiß, Rot, Grün, Blau usw. Einstellen kannst du
dies per Doppelklick auf die Farbe. Wichtig ist nur eines, der Index
dieser Farbe entspricht dem Index in glcd_Colors[]. Also Schwarz = 0,
Weiß = 1, usw.
Demzufolge setzt du nun glcdSetColor(0, BALCK); glcdSetColor(1, WHITE);
glcdSetColor(2, RED); usw. usw.

Gruß Hagen

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm, merkwuerdig, das habe ich eigentlich gemacht gehabt, aber es geht
irgendwie trotzdem nciht, habe bis jetzt nur 16 Farben Fonts, aber die
werden alle immer in Blau/Gruen/Schwarz angezeigt, auch wenn die
sonstige Schrift andersfarben ist (glcdSetColor fuer 0 und 1)

gibt es sonst noch irgendeine Option die ich vergessen haben koennte?
kompiliert wird eigentlich auch immer alles. Die glcd.inc liegen in den
avr-gcc Verzeichnissen, das ist ja eigentlich auch korrekt... hmm...
muss ich noch weitersuchen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne deine Sourcen und Fonts zu kennen kann ich dir da auch nicht
weiterhelfen, irgendwo must du einen kleinen Fehler gemacht haben. Die
GLCD selber läuft garantiert. Im Source solltest du meine EMail
Addresse finden, kannst mir ja mal deine Fonts und Sourcen mailen.

Hast du denn mehr als ein Display ? Eventuell man das LCD austauschen
und schauen ob das zweite genauso reagiert. Vielleicht haste ja dein
LCD durch Überspannung beschädigt ?

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benutzt du eigentlich die Backlight LEDs ?
Wenn du das LCD ohne Hintergrundbeleuchtung ansteuerst musst du schon
sehr genau hinschauen (mit entsprechender Beleuchtung) um die
Farbunterschiede zu erkennen.

Gruß Hagen

Autor: sammy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe zwei Displays, aber ich denke nicht, das es beschaedigt ist,
bei der Schrift zeigt es ja die verschiedensten Farben an.
Ich betreibe das Display mit 6,5V Hintergrundbeleuchtung.
Ich werde nochmal selbst schauen wodran es liegt, ansonsten mail ich
dir mal die Source.
Danke fuer deine Hilfe!

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze CodeVision und einen ATMEGA162 mit 8MHz.
Habe mir die Library runtergeladen und das Makefile angepaßt (CPU und
Quarz).
Nur wie kann ich nun das Make ausführen ohne mir vorher nen anderen
Compiler zu installieren?
Kann ich das irgendwie in mein Projekt mit einbinden?

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@smartie

Da mußt Du wohl alle Sourcen an CodeVision anpassen, dann kannst Du die
Lib auch unter CodeVision verwenden.

Volkmar

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habs mittlerweile hinbekommen, hab das winavr installiert, war ganz
easy. Testprogramm aufgespielt. Aber Display bleibt außer der
Beleuchtung dunkel.
Habe an
Port B4 Chip Select Pulse mit 3 µs breiten High Pulsen, Pulsabstand
50µs
Port B5 Data Pakete im 50 µs Abstand
Port B6 Reset High Pulse von 3 µs im 50µs Abstand
Port B7 Clock 1 breiter Puls und 8 schmale Pulse, Pakete auch im 50µs
Abstand

Sieht also soweit schonmal ganz gut aus. Nur die Datenpakete scheinen
konstant zu sein, da ändert sich nicht viel.
Ist das mit den ständigen reset Pulsen auch korrekt?
Ist das Chip Select denn so korrekt oder muß es invertiert werden?

Zur Anpassung der 5V auf 3,3 Pegel habe ich je nen Widerstand drin,ne
Z-Diode nach Masse und nen Pull down nach Masse. 3,3V hab ich auch so
erzeugt, mit nem Elko dran.

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, die Reset-Leitung müßte nach dem Anfangsimpuls (habe es nicht mehr
im Kopf ob High- oder Low-Pegel) konstant bleiben. Da bei Dir alles
scheinbar nach 50µs wieder von vorne anfängt, stimmt da was wohl
nicht.

Invertieren ist nicht notwendig. Ich habe die Leitungen direkt über
einen Widerstands-Spannungsteiler direkt mit dem Display verbunden. Ich
mußte nur bei meinem ATmega128 die Reset-Leitung vom MISO-Pin weglegen.
Aber den von Dir beschriebenen Effekt hatte ich nicht.

Volkmar

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heißt also der Controller resettet sich aus irgendeinem Grund.
Das erklärt auch warum die Daten so konstant aussehen.
50 µs sind auch so eine typische Watchdog-Zeit.
Gerde nochmal geschaut, die Fuses sind alle 1 also unprogrammiert.
Hatte den ATMEGA162 als ATMEGA16 compiliert.

Jetzt hab ich die glcd.inc erweitert um

#elif defined (_AVR_ATmega162_)
  #define   LCD_PORT                _SFR_IO_ADDR(PORTB)
  #define   LCD_PIN                 _SFR_IO_ADDR(PINB)
  #define   LCD_DDR                 _SFR_IO_ADDR(DDRB)
  #define   LCD_CS                  PB4   // SS
  #define   LCD_SDA                 PB5   // MOSI
  #define   LCD_RESET               PB6   // MISO
  #define   LCD_SCL                 PB7   // SCK

und den ATMEGA162 in die makefiles geschrieben.
Außerdem Clock 8000000 in makefile und glcd.inc geändert (hatte ich
schon vorher)
Ergebnis:

Der Resetpuls kommt nun nach 60ms. Das Chip Select Signal besteht nun
aus 2 High Pulsen.
Irgendwie seltsam das ganze.

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wirklich keiner ne Idee, wie man die Library mit nem ATMEGA162 ans
laufen bekommt?

oder wohl wieder mal was für die Kiste mit angefangen Projekten...

Umschreiben für Codevision ist fast unmöglich, da die Variablen immer
erst bei Bedarf deklariert werden, das mag Codevision nicht.

Oder gibts irgendwo ein einfaches C-Code Beispiel nur zum Testen für
das Display?

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will mal erhlich sein: das von dir beschriebene Verhalten deutet mit
hoher wahrscheinlichkeit auf einen Fehler deinerseits hin. Die GLCD
wurde schon mehrfach erfolgreich verwendet ohne das es zu Problemen
führte. Wie sollen wir aber nun eine Bewertung und Hilfe anbieten wenn
wir nicht wiessen:
- wie deine Hardware aussieht
- wie deine Software aussieht
- wie groß dein Wissenstand ist

Sorry, falls ich mit diesen Aussagen ein bischen zu erhlich und direkt
bin, aber nur so kommen wir weiter.

So wie ich die Sache einschätze Reset sich der AVR selber. Dafür könnte
es viele Ursachen geben, zB. Kurzschlüsse an einem Pin oder Stackfehler
in Software ect. pp.

In der GLCD ist ein Testprojekt enthalten. Du konfigurierst erstmal die
GLCD Library, compilierst sie neu, kopierst die Lib Dateien in den
richtigen Pfad. Dann konfigurierst du das Testprojekt, compilierst es
und installierst das HEX auf'm AVR. Alle Schritte sind in der GLCD
beschrieben.

Gruß Hagen

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"wie deine Hardware aussieht"
wie schon beschrieben: ATMEGA162, Hardware ist geprüft und
funktioniert. Port B hatte ich vorher ein VFD-Display dran, daher war
der komplett frei.

"wie deine Software aussieht"
Testprogramm aus der ZIP-Datei GLCD V22
geändert:
- ATMEGA162 in die beiden Makefiles
- 8 MHz in das Makefile der Library
- Eintrag in die GLCD.H:
#elif defined (_AVR_ATmega162_)
  #define   LCD_PORT                _SFR_IO_ADDR(PORTB)
  #define   LCD_PIN                 _SFR_IO_ADDR(PINB)
  #define   LCD_DDR                 _SFR_IO_ADDR(DDRB)
  #define   LCD_CS                  PB4   // SS
  #define   LCD_SDA                 PB5   // MOSI
  #define   LCD_RESET               PB6   // MISO
  #define   LCD_SCL                 PB7   // SCK

- Library compiliert und in das entsprechende Verzeichnis kopiert
- Testprgramm compiliert und auf den Prozessor programmiert

"wie groß dein Wissenstand ist"
groß bezüglich Microcontroller, klein bezüglich WINAVR


Da die Definition des MEGA162 gefehlt hat, wurde wohl die Library auch
noch nie auf diesem Prozessor ausprobiert.

Wäre es vielleicht möglich, das Demo als ATMEGA162 mit 8MHz zu
compilieren und mir zuzuschicken?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das kannst du dir doch selber kompilieren, so schwer ist das nun echt
nicht.

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann schon, aber dann funzt es ja nicht.
s.o.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hardware:

- mit welcher Spannung ?
- haste Spannungsteiler am LCD ?
- wie lang ist das Kabel zum LCD ?
- was ist noch am AVR angeschlossen ? und wie ?
- wieviel Ampere liefert die Stromversorgung ?

Es sind also noch einige Punkte offen.

Gruß Hagen

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
5V DC/DC Wandler 1A
noch gar kein LCD angeschlossen solange der Microcontroller nicht
läuft.

Habs heute mal selbst probiert, wenn ich die SPI-Schnittstelle von Hand
programmiere, funktioniert sie einwandfrei, hab dann mal angefangen die
glcd.h für codevision umzuschreiben. Die glcd_Send Routine funktioniert
schonmal.
Bei der glcd_init bin ich dann schon fast verzweifelt, hab nirgendwo
die set_color routine gefunden. Werde morgen weiter suchen.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also 5V sind für das LCD zu viel, aber das dürftest du ja hier im Forum
nachgelesen haben. Desweiteren MUSS das LCD angeschlossen sein damit
die GLCD funktioniert. Die GLCD fragt bei der Initialisierung das LCD
ab. Ist es nicht vorhanden kann die GCLD auch kein LCD abfragen.

Gruß Hagen

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohne Display sollte das Programm sich hier aufhängen, aber nicht ständig
resetten:
// wait for booster
    d = 0;
    while (!(d & 0x80000000)) {
      glcdDisplayCommand(DISPLAY_STATUS);
      d = glcdDisplayRead(33);
    }
    glcdDisplayCommand(DISPLAY_ON);
 // wait for display
    while (!(d & 0x00000400)) {
      glcdDisplayCommand(DISPLAY_STATUS);
      d = glcdDisplayRead(33);
    }

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und ? haste den Watchdog aktiviert ? Du hast schon recht das in obiger
Loop ohne Display eine Endlosschleife auftritt. Somit wäre nur noch der
Watchdog meiner Meinung nach für den Reset verantwortlich.

Ich habe jetzt mal angefangen die GLCD für mein ATmega162 Board
anzupassen. Übers Wochenende werde ich mal sehen das ichs real testen
kann. Vielleicht sogar im Zusammenspiel mit meiner MMC-SPI Library.

Gruß Hagen

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
funktioniert jetzt, die Reset Pulse kommen von der SPI, MISO nicht als
Reset verwendbar.
Selbst wenn ich den PIN nach dem Reset Puls als Input schalte, habe ich
dort die MOSI Daten drauf, schon irgendwie seltsam.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast auf der MISO Leitung die Signale der MOSI drauf ?
Dann ziehe mal den ISP Stecker vom Board,und mach dann einen Reset des
Boards. Scheint wohl so zu sein das dein ISP Programmer da nicht ganz
mitspielt. Was nutzt du ?

Gruß Hagen

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit dem MISO Pin und Reset hatte ich bei meinem Mega128 aber
auch. Der AVR machte zwar keinen Reset, aber das Display bekam kein
ordentliches Reset-Signal. Ist schon eine Weile her, daher kann ich
mich nicht erinnern, ob das abhängig vom ISP Programmer ist.

Volkmar

Autor: Tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Wie veränderst du denn die gelbe Hintergrundfarbe, die bei init
automatisch genommen wird?
Mit setColor(s) kann ich nur die Farben in und um einen Font bzw.
Rechteck oder Kreis ändern.
Vielen Dank

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Hintergrund beim Init des Display, sprich der Display RAM des
Controllers ist mit zufälligen Daten = Muster gefüllt. Das Init muß
also auch immer mit glcdFillRect(), eg. glcdClearScreen() initialisiert
werden. Dazu wird der Bildschrim in der Hintergrundfarbe gefüllt. In
glcdClearScreen() wird intern glcdFillRect(0, 0,132,
132,SCREEN_COLOR);aufgerufen. SCREEN_COLOR == SCREEN_COLOR0 == YELLOW
ist in der Datei glcd.inc gefiniert, also hardcoded, das spart ein par
bytes. Du kannst also entweder SCREEN_COLOR0 auf eine andere Farbe
ändern und dann die GLCD neu compilieren, diese Änderung ist dann
dauerhaft. Oder aber nach dem Aufruf von glcdDisplayInit() eben
glcdFillRect(...) statt glcdClearScreen() aufrufen. Schau mal in die
Datei Test.c des Demo Projektes rein.

Gruß Hagen

Autor: Tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar.
Vielen Dank für die schnelle Hilfe.
Echt ne super LIB von dir.
Nur weiter so....

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir funktioniert der glcd_wait nicht, da hängt sich der Prozessor
bei auf.
Kann ja eigentlich nur mit dem 8 MHz Quarz zusammenhängen.

glcdMoveTo mit anschließendem glcdDrawChar funktioniert nur nach einem
glcdclearscreen

Autor: Martin Steghoefer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde mir gerne ein entsprechendes Display bei ebay besorgen. Da
gibt es aber, so weit ich das gesehen habe, 3 Typen:
1. komplett braune flexible Leiterplatte (sehr, sehr selten!)
2. flexible Leiterplatte bei der Windung von der Vorder- zur Rückseite
braun, am Stecker aber grün (siehe Anlage)
3. komplett grüne flexible Leiterplatte

Muss ich unbedingt Typ 1 kaufen oder funktioniert Typ 2 genauso?

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hab diese blöde WINAVR in die Tonne getreten und alles nach
Codevision portiert. War ein paar Tage Arbeit aber nun funktionierts
super. Die Library war leider nicht zu gebrauchen, deswegen hab ich die
1.1 Version genommen.

Hat denn schonmal jemand weitere Routinen geschrieben?
Hex, Dezimal und Balkenausgabe waren schnell programmiert, aber möchte
nun ein Zeigerinstrument realisieren, bin aber noch am überlegen wie.

Möglichkeit 1 wäre 90 Zeiger (0-90 Grad) als Font abzulegen, alles
andere bekommt man mit der Orientierung. Vielleicht die eleganteste
Lösung, da man auch schöne Grafikzeiger basteln kann. Problem sehe ich
dabei, daß jedesmal auch die Skala neu geschrieben werden muß, da der
Zeiger als Font ja eckig ist.

Möglichkeit 2 wäre, den Zeiger aus drei Linien immer zusammenzubauen
und neuzuschreiben, ist sicher die schnellst Variante, und braucht
wenig Speicher.

Möglichkeit 3 wäre, den Zeiger in ein RAM-Feld zu schreiben und das
dann immer komplett auszugeben.


@Martin Steghoefer: das 1. kenn ich nicht, das 3. hat nen Epson
Cntroller und funktioniert nicht mit der Library, also die Version 2.
kaufen.

Autor: Martin Steghoefer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schönen Dank!

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Library war leider nicht zu gebrauchen, deswegen hab ich die
> 1.1 Version genommen.

Tja, auf meinem ATmega162 Board mit 16Mhz hat sie auf Anhieb
funktioniert, sogar zusätzlich mit SD/MMC Karte am SPI.
Umkonfiguiert musste nur XTAL werden, das wars. Mir ist es im Grunde
egal was du für eine Meinung über die GCLD hast, denn nicht bei mir
läuft sie nicht sondern bei dir.

Möglichkeit 1:
das ist grafisch die schönste Methode und es gibt auch keinen
Widerspruch oder Probleme mit dem Neuzeichnen der Scala. Besonders bei
der neuen GLCD Version 2.2 unterstützen die Font Routinen ein Clipping.
Es ist also sehr effizient möglich nur den Teil der Scala unter dem
neuzuzeichnenden Part des Zeigers darzustellen. Das dürfte flickerfree
gehen. Tja, aber das dürfte eben nur mit der Version 2 der GLCD so
gehen.

Möglichkeit 2:
geht auch, du bindest nur die mathermatischen Libs ein und kannst das
durch einfachste Geometische Winkelberechnungen die Koordinaten der
Linien berechnen.

Möglichkeit 3:
Ist nichts anders als ein Double-Buffering und wohl die langsammste
Alternative. Macht eigentlich nur Sinn wenn wie in einem Game mehrer
Layer wie sich bewegende Backgrounds und Sprites benötigt werden. Da
die GLCD alle Grafikfunktionen immer direkt auf das LCD anwendet müsste
man alle nötigen Funktonen umschreiben damit sie im Doublebuffer
arbeiten. Also einiges an Umschreiberei und ein erhöhter
Speicherbedarf. Immerhn 128x128 = 16KByte SRAM maximal.
Nun in der Version 2 der GLCD gibt es sogar schon eine einfache
Funktion, glcdDisplayBuffer(), die effizient einen rechteckigen
Speicherbereich als Bitmap an das LCD sendet. Tja, aber eben nur in
Version 2.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, bei der Möglichkeit 1, bzw. bei der Verwendung des FontEditors in
der Version 1.1der GLCD solltest du aufpassen. Denn erst ab Version 2
der GLCD werden die komprimierten Fonts des FontEditors unterstützt. Da
aber der FontEditor ohne Benutzereingriff autom. entscheidet ob ein Font
komprimiert oder nicht komprimiert wird,kann es sein das die erzeugten
Fonts nicht mit der Version 1.1 angezeigt werden können.

Übrigens: die Version 2 zeichnet Linien, Rechtecke und Ellipsen ca. 15
mal schneller als die reine C Version 1.1. Das liegt eben auch an den
Assemblerroutinen.

Gruß Hagen

Autor: smartie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
funktioniert hatte es bei mir ja auch mit der 2er version, nur hab ich
keine Lust, mich mit dem WINAVR rumzuärgern, wenn ich doch was
gescheites hab.
Außerdem hatte ich meine bestehenden Projekte alle schon in
Codevision.
Das mit dem komprimierten Fonts funktioniert bei mir auch.
Der Font-Editor ist einfach genial. Hat man ganz schnell einen Windows
Font mit konvertiert.
Hatte versucht, die Library einzubinden, funktioniert aber nicht, da
sie zu spezifisch für das WINAVR programmiert ist, werde aber
vielleicht den einen oder anderen Teil daraus noch portieren.
Aber erstmal mach ich mich an mein Zeigerinstrument.
Werde wohl auch die Möglichkeit 1 nehmen. Braucht halt ziemlich viel
Speicher. Zum Testen lass ich aber erstmal ne Linie rotierne nach
Möglichkeit 2

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der "Vektor"-linie benötigst du ja keine Skalierung, d.h. die
komplette Anzeige bleibt ja immer gleich groß. Falls du nun auf die
aufwändigen Math Routinen verzichten willst, dann kannst du ja die
Pixelkoordinaten vorrausberechnen und in einer Lookuptable speichern.
Dafür reicht im Grunde ein 1/8'tel Kreissegment, sprich 45 Grad.

Nur der Aufwand um die Linie zu bewegen, sprich Linie zeichnen, Linie
löschen und Linie an neuer Position zeichnen, ist genausgroß wie bei
den Fonts. Denn die Linie kannst du nur löschen indem du sie nochmal in
der Hintergrundfarbe zeichnest. Wenn nun die Linie ein Teil der Grafik
der Skale überzeichnet zu muß dieser Teil ebenfalls neu gezeichnet
werden.

Mit den Fonts verhält es sich genauso. Das Zeichen des Zeigers wird ja
mit transparenter Hintergrundfarbe gezeichnet. Somit werden nur die
Pixel überzeichnet die auch zum Zeiger gehören. Beim Löschen dieses
Zeigers wird das selbe Zeichen wiederum mit Transparentem Hintergrund
gezeichnet, diesmal ist aber die Zeigerfarbe die Farbe des
Hintergrundes der Skala.

Wenn du die Komprimierung drinnen hast dann solltest du mal abtesten
wie viel Speicher eine komplette Skala für 90 Grad benötigt. Falls nur
2 Farben benutzt werden und schlanke Zeiger so dürfte die Komprimierung
relativ hoch sein.

Generell würde ich aber auf eine Bufferung der Bilddaten im SRAM
verzichten, da das viel zu viel Speicher benötigt.

Wenn du es wirklich einfach und informativ haben willst dann stell doch
alles digital dar, einfach eine Zahl zwischen 0-100% statt einer Skala
;)

Das besondere an den Font Routinen ist es ja das die Farbe
"Transparent" ein "nicht-setzen" eines Pixels zur Folge hat. D.h.
die Zeichenroutine überspringt diesen Pixel und somit wird der
vorhandene Pixel im DisplayRAM des Controllers nicht geändert.
Man könnte nun die Font Routine so abändern das zusätzlich zum Zeichen
selber eine Maske mit übergeben werden kann. Ob nun der aktuelle Pixel
des Fontzeichens gesetzt wird oder nicht hängt dann von der Farbe und
eben auch der Maske ab. Die Maske könnte nun ein Zeichen sein das
sozusagen über den Pixeln der Skale liegt und diese vor überschreiben
schützt. Im Grunde würde man das Recheckige Clipping erweitern mit
einem beliebigem Maskenbasiertem Clipping. Das ist die einzigste
Methode die ich kenne die kein zusätzliches RAM benötigt und auch ohne
Lesezugriffe auf das DisplayRAM auskommt.

Ich persönlich würde aber den Zeiger per Fontroutinen in den 90 Grad
Segmenten einzeichnen und dann sofort das 90 Grad Segment der Skale
darüber zeichnen. Das ist zwar nicht elegant sollte aber mit
entsprechendem Takt ziemlich schnell und flickerfree gehen.

Der Vorteil mit den Fonts liegt bei deren Mehrfarbfähigkeiten. Du
benutzt zb. 4 Farben Fonts. 1 Farbe ist transparenter Hintergrund, 1
Farbe ist Vordergrund des Zeigers zB. Schwarz und 2 Farben sind
Anti-Alias, sprich Hell- Dunkelgrau. Nun kannst du die Zeiger so sauber
zeichnen das sie auf dem Display in jeder Position nicht Pixelig
aussehen. Bei einer Linie ist dies nicht so sauber hinzubekommen. Ich
vermute mal das du die Skale ja nur benutzt damit am Schluß grafisch
auch ein tolles Aussehen entsteht,das kostet eben Resourcen ;)

Gruß Hagen

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat schon jemand versucht die Temperatur des Displays auszulesen?
Ich lese immer 0xFF aus dem TD Register was also einer Temperatur von
199°C entspräche. Gibt es bei der Sache einen Haken?

Gruß,
Markus

PS: Ich habe die Philips Variante, am Lesen an sich scheitert es also
nicht.

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht bei mir auch nicht. Im Datenblatt steht das man im OTP ROM die
technischen Betriebsdaten des Displays festlegen kann. Das macht
normalerweise der Hersteller des Displays. Dort kann man auch festlegen
welche Features der Controller unterstützen soll. So wie es aussieht
kann man die Temparatur nicht korrekt auslesen. Ich habe das aber nicht
weiter verfolgt.

Gruß Hagen

Autor: C Baumbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@volkmar

wo gibt es den test-code für den ATMEGA-128 ? sind dort die Anschlüsse
noch gleich, oder ist Reset anders verdrahtet?

gruss
christian

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

der Mega128 ist doch schon in den Original-Sourcen von Hagen enthalten.
Ich hatte nur das Reset-Signal für das LCD umgelegt, weil es bei mir mit
der Verwendung des MISO nicht klappte. Alle weiteren Änderungen betraf
die Verwendung des Nokia 3510i anstelle des 6100.

Volkmar

Autor: C Baumbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank volkmar,

ich habe die sourcen vom April 2004 version 2.1, gab es da nicht
inzwischen was neueres. das file test ist für den mega-32.
mein AVR-Studio gab beim übersetzen einige Fehler aus und das Display
blieb dunkel. ich wollte nur ein hex-file zum testen der displays  für
den Anschluß an einem STK-501 haben. Beim letzten Mal waren die
Portdefinitionen für den 128L nicht dabei und so habe ich dann wohl
Feher beim verändern gemacht. Falls es was neures gibt, dann hätte ich
gern den link. vielen dank

christian

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

schau mal hier im Thread das Posting von Hagen datiert 16.09.2004
13:10. Dort ist der Mega128 enthalten. Mit der Übersetzung des
Beispielprogrammes hatte ich keine Probleme. Nur stellte ich halt fest,
daß das Reset-Signal nicht ordnungsgemäß generiert wurde. Daher hatte
ich diese Pin-Zuweisung verändert. Das kann aber auch an meinem Aufbau
gelegen haben.

Volkmar

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:

Hallo,

eine kleine Frage hab ich noch. Das Display arbeitet ja mit VCC=2,7V -
3,3V. Sind die SPI-Pins 5V-kompatibel, oder sollte man besser die 'L'
Version des Mega 128 nehmen (3,3V)?

Grüße,
André

Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andre
das Display verträgt laut Datenblatt maximal 3,6 V.
Das gilt auch für die digitalen Eingänge.

MartinK

Autor: André Kronfeldt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

okay. Dann wohl ein ATmega8 in der 3,3V Version. komisch nur, weil das
nirgends erwähnt wird (weder hier im Thread, noch in der Readme). Kann
aber auch sein, daß ich es übersehen habe.

Danke & Grüße,
André

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi zusammen!

Kann ich die Library auch mit nem Atmel 89C52 betreiben?
Was müsste ich da denn alles anpassen?

Danke

MfG Kev

Autor: Tobias Kopelke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe den ganzen Text noch nicht gelesen, werde das aber bald
nachholen. Aufgrund des Datums einiger Post's schreibe ich lieber
jetzt schonmal, und hoffe auf eine Reaktion.

Ich bin auf der Suche nach einem günstigen, kleinen Display, und die
Handydisplays sind ja mit 15€ doch schon recht billig :)
Ich wüsste gerne welche Displays diese Bibliothek unterstützt, und auf
was ich bei einem kauf achten muss.

Danke
Tobias

Autor: Benjamin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich weiß es wird in Euren Kommentaren immer darauf hingewiesen das man
möglichst ein Display mit dem braunen Platinenmaterial nehmen soll.
Aber ich habe diese nicht bekommen. Jetzt ist auf der Leiterplatte so
ein schöner SMD- Stecker aufgelötet.... Kennt vielleicht rein zufällig
jemand den Hersteller, oder einen Distributor??? Dann würde ich mir
meine Platine, die ich sowieso inmoment noch erstelle gleich mit
Stecker versehen!

Ich hoffe einer von Euch kann mir zu der Problematik helfen!!

Danke schon mal vorab!!

Gruß
Benjamin

Autor: Benjamin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe noch etwas vergessen....

wenn schon jemnad von euch den Stecker verwendet hat, dann werdet Ihr
doch bestimmt auch die Pinbelegung haben!? Oder?

Gruß
Benjamin

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
die Stecker kaufe ich immer hier:
http://www.shop.display3000.com/pd-1033582389.htm?...
10 Stück für 19,95 sind ein guter Deal (gibt dort auch kleinere
Stückzahlen). Distributoren kannst du vergessen, die verkaufen die nur
als 2000er Rolle und da die nirgends auf Lager sind, haben die 8 Wochen
Lieferzeit.
Dort gibt es übrigens auch das Display mit der besten Bildqualität -
ich weiß nicht was daran anders ist, aber das Bild ist um Längen besser
als die der anderen Displays die ich ausprobiert habe.

Übrigens: es gibt 6 oder 7 verschiedene Displays auf dem Markt, viele
mit unterschiedlicher Ansteuerung - einfach nur ein beliebiges Display
kaufen wird schnell zur Enttäuschung führen - die Ebay-Anbieter
verkloppen auch immer gerade das, was momentan am billigsten eingekauft
wird (dem Telefon ist das egal, das erkennt den Typ und passt sich an;
der Mikrocontroller aber eben nicht). Das Thema mit grün und braun
stimmt schon seit 1,5 Jahren nicht mehr, wird aber immer noch gerne
erzählt. Das ist Bullshit und sollte schnellstens vergessen werden!
John

Autor: noch ein "John" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lol, geile Werbung :)
Früher wurden da auf Anfrage nur Set´s mit Krempel den man nicht
braucht angeboten, hat sich das geändert?

Autor: Hans Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe die Grafik LCD Libary mal ausporbiert (Besitze ein D62 Board von
Display 3000 mit GLCD Display und Mega128).


Leider wird das Display nicht initalisiert.

Wenn ich es mit Soft SPI mache geht es.

Benötige aber Hardware SPI weil ich noch eine SDCARD ansteuern will
über SPI.

Die SDCARD funktioniert im augenblick nur wenn ich das Display vom
Controller entferne(Abstecke).

Das Display ist orginal von Display 3000.

Die schreiben in den Datenblätten das die Ansteuerung im Beispiel
Software SPI ist aber Hardware SPI kein Problem wäre weil das Display
an den Hardware SPI Pins liegt das stimmt auch aber die Libary von
APATECH funzt nicht.

Ports richtig eingetsellt nur SS ist nicht belegt und CS ist auf der
B5.


Vieleicht hat einer einen TIP

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist das Display von Display 3000 ein Nokia6100?

Gruß Michael

Autor: Jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, ist es meiner Meinung nach nicht. Es ist wohl ein S1D17G10 - steht
zumindest so in den Bascom Sourcen dafür. Datenblatt hatte ich keines
gefunden, also habe ich für meine Bedürftnisse fremden Code angepasst
und ein wenig ergänzt.
Wie hast du denn vor die MMC mit dem Display gleichzeitig zu benutzen?
Das Hardware SPI CS ist doch, wie ich das in erinnerung habe fest mit
dem Display verbunden?!?
Gruß,
Jörg

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
au welcher Schmiede stammt das S1D17G10 ? Sharp ?

vielen Dank für die Antwort

Autor: Hans Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also es scheint tatsächlich ein Epson Dipslaycontroller zu sein und kein
Phillips.

Aber laut Anleitung von Display 3000 ist es möglich das Display mit
Hardware SPI anzusteuern.

Habe es unsauber gelöst indem ich wenn ich das Display anspreche einen
Flag setzte sodas dei MMC nicht aktiv wird.

Und nach den Display Commands den SPI deaktiviere und bei benutzung der
MMC den SPI nach der MMC Vorgabe aktiviere.

Gefällt mir absolut nicht weil es vorkommt das das Display nur Müll
anzeigt.

Eine Saubere Variante wäre nur den Slave auswählen mit CS low und
fertig.

Soll aber mit dem Phillips Display Controller gehen der aber nicht mehr
hergestellt wird.

Was machen wir denn dann????

Ich denke ich werde mal ein anderes Display ausprobieren von Siemens
S65 oder Nokia 7250.

Autor: Frank Nobody (z80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans Peter:

Ich schlage mich mit dem gleichen Problem UND Modul herum.
Mit einer (angepassten Variante) der GLCD1.1 von Hagen (DANKE AN HAGEN 
!!!) läufts super, nach meiner Ansicht ein wenig zu langsam ...

SPI habe ich allerdings noch nicht hinbekommen.

Kannst du mir mal den Teil posten, den du anpassen musstest (für das 
D062) ??

Wäre super

Frank

Autor: Fichte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hay @all

Danke an Hagen für seine Mühe.

Ich habe das ganze in Codevision geschrieben.
War ein Haufen Arbeit den Code von Hagen zu Zerlegen und
an Codevision Anzupassen deshalb schrieb ich eigene Routinen
aber mit hilfe von Hagen´s Code.

Also in diesem Sinne ein riessen Dank an Hagen.


MFG: Fichte

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke zurück und freue mich das es einen Nutzen für euch hat. 
Demnächst gibts eine ähnliche Library für das S65 -> LPH88xxx -> Philips 
HD66773R Controller. Neu sind dann Abgerundete Rechtecke (die Kreis, 
Ellipsen Funktion in der Nokia GLCD kann nämlich so umgebaut werden das 
man abgerundete Rechtecke zeichnen kann ;) und komprimierte Bitmaps. 
Selbstverständlich gibts zum Konvertieren der Bitmaps eine Software für 
den PC, wie bei den Fonts.

Gruß Hagen

Autor: Fichte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hay Leute



Ich habe mir ein Nokia 6610 Display gekauft nun habe ich das Problem es 
sind nur 9 Lötfahnen dran.

Bei meinen Orginal Display sind es 11.

Kennt den jemand die Belegung der 9 Lötfahnen.?


MFG: Fichte

Autor: Fichte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab es heraus gefunden wie die Belegung ist.

Hier für alle


1  3,3V
2  GND
3  LED-
4  LED+
5  3,3V
6  RESET
7  SDATA
8  SCLK
9  CS

Das ist das LCD mit der Grünen Leiterplatte.



MFG: fichte

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
das Display von Display 3000 scheint ja recht nett zu sein, aber die 
machen ein Geheimnis aus der Ansteuerung. Die Pinbelegung ist vermutlich 
gleich, aber läuft das Display mit dem Nokia kompatiblen Code oder muß 
man sich das Display mit Doku kaufen damit man es anpasst ?

Autor: SeppK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an Frank Nobody und alle anderen, die auch ein Display mit Epson 
Controller S1D15G10 haben.

Ich habe mir ebenfalls die GLCD1.1 von Hagen angepasst. Läuft soweit. 
Auch über die SPI. Was noch nicht funktioniert ist die Darstellung von 
Schrift. Da funktioniert die Darstellung mit dem Philps-Controller doch 
wohl anders. Da mir jetzt die Zeit wegrennt wollte ich mal fragen, ob 
jemand sich eine funktionierende  GLCD für den Epson-Controller 
zusammengestellt hat. Vielleicht kann mir derjenige die Lib auch 
überlassen. Mein Dank würde ihm/ihr auf Ewig hinterherschleichen.... ;-)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal die ursprüngliche GLCD genommen und für den Wickenhäuser 
C-Compiler angepaßt fürs 3510i. Läuft noch nicht über SPI, aber über 
Standard Ausgänge. Mit Bildern scheint es nicht zu gehen, aber Texte 
gehen. Wer Interesse hat, bitte melden. Ich habe einige Änderungen 
vorgenommen, damit es bei mir lief. Läuft bei mir auf einem AT89C51CC03.

Autor: Mircro=>DIsP_chix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Irgendwie soll man ein Oszilloskop auuf dem Display anzeigen lassen 
können.
Kann mir jemand schreiben wie man das macht.
Oszilloskop am besten über Mikro eingang.

Grüße, Micro=>DIsP_chix

Autor: Bla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du machst ein Bild von einem Oszilloskop und einem Mikro Eingang , 
wandelst das alles in ein großes C Array und schon hast du ein Bild von 
einem Oszi mit Mikro Eingang auf dem Display! Super Statisch und mit 
allen Knöpfen und Reglern eines 10k€ Oszis mit Mikro Eingang!! Analog 
kann man das natürlich auch auf das S65 Display anwenden. Um das SNR in 
den Threads etwas zu erhöhen
könntest du dir mal die AVR Tutorials zu Gemüte führen. Nix für ungut!

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo  Matthias und Hagen,

beschäftige mich mit einen 320x240 monochrom display von 
crystalfontz.com cfag320240cx (gute Erfahrungen bei Direktbestellung in 
USA) monochrom transflectif mit s1d13700 epson controller. Zur 
Ansteuerung benutze ich einen FlexGateIII von Wickenhäuser (51ED2) 
einschließlich Wickenhäuser-C. Kurven, (Texte mit eingebautem 
Zeichensatz) gehen. Da der eingebaute Zeichensatz einfach nur billig 
aussieht, suche ich nach einer Möglichkeit, mit scalierbaren 
Zeichensätzen zu arbeiten, sodaß auch verschiedengroße Buchstaben aus 
einem Zeichsatz heraus dargestellt werden können.
2 Fragen:

1.:Ist die Portierung nach Wickenhäuser C '51 von GLCD zu bekommen, die 
Anpassung an den s1d13700 via parallel-Ansteuerung bekomme ich hin.

2.Gibt GLCD diese Scalierung her?

Grüße Klaus

Autor: Matthias 2000 (zeras)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

die Quellen kannst Du bekommen. Vielleicht sind noch ein paar Bugs drin, 
oder vielleicht alles noch ein wenig überarbeitungswürdig, aber bei mir 
auf dem Schreibtisch läuft das 3510i ganz gut.
Ich brauche nur eine Emailadresse.

Meines Wissens können die Zeichensätze nicht scaliert werden, es stehen 
aber einige zur Auswahl. Auch kann man mit einem Programm, was mit 
dabeiliegt, selber einen Zeichensatz bauen oder erweitern.

Matthias

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich stimme Matthias zu.

Die Font Routinen benutzen Bitmap-Fonts und keine 
True-Type-Vektor-Fonts. Mann kann zwar auch Bitmap Fonts skalieren, 
meistens habe ich Skalierungen um x2,x3,x4 im Netz gesehen. Ehrlich 
gesagt: sehen scheiße aus. Dann ist es effizienter die Bitmap-Fonts nach 
Möglichekit per Komperssion kompakt zu machen und dann eben 2 bis 3 
solcher Fonts zu unterstützen. Und gerade dahin zielte auch die 
Entwicklung meiner Fontroutinen. Man kann also sehr schnell und recht 
fexibel eine kleine Datenbank von Fonts in der MCU verwenden.
Ein weiteres nötiges Tool war der FontEditor. Mit ihm kann man quasi in 
Sekunden einen beliebigen Windows-True-Type-Font in einen Bitmap Font 
umwandeln, ihne nachbearbeiten und als komprimierte Daten exportieren.

Man muß auch immer die Relationen betrachten. Normalerweise kann man in 
guten grafisch orientierten Systemen 3-4 verschiedene Fonts 
unterscheiden, das reicht auch. Ein TTF ist zwar beliebig scalierbar, 
aber die Frage stellt sich ob das mit dem herheblichen Aufwand der 
Programmierung einer solchen Vektorengine einhergeht mit einem realen 
Nutzen später im GUI.

Auch der Speicherverbrauch solcher TTFs ist größer. Verglichen zu den 
vielen Schriftgrößen usw. die sich damit anzeigen lassen ist diese 
Datengröße super, aber für eine kleine MCU sind durchschnittlich 200Kb 
für einen TTFont doch schon wieder enorm. Da bekome ich mit meinen 
FontEditor lässig 10 verschiedene Bitmap Fonts unter.
Ich habe sogar TTFs auf meinen Rechner die brauchen 22Mb, wohlgemerkt 
für einen TTF !!

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, eventuell wäre es sogar cleverer meine S65 GLCD Library zu 
benutzen. Ich habe bei dieser "Neu-Portierung" der Nokia-GLCD aufs S65 
auf einige Punkte stärker geachtet, zb. Portierbarkeit. So ist fast der 
komplette Source in C und die wenige ASM Stellen lassen sich 
auskomentieren. Der HW Zugriff ist als Makro-Schnittstelle sehr flexibel 
anpassbar. Die grafikfunktionen sind dadurch weitaus portabler. Und 
Bitmaps/Icons mit Kompression werden unterstützt -> auf Monochrome mit 
besonderst guter RLE Komprimierung.
Ansonsten kann man sagen das beide Bibliotheken in ihren Font-Routinen 
absolut kompatibel sind, besonders im benutzten Datenformat.

Schick mir per PN ne Nachricht falls du Interesse am Source hast.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>320x240 monochrom display von

das könnte das eigentliche Problem werden. 240 passt ja noch in 1 Byte, 
320 aber nicht mehr. Alle Grafikfunktionen, besonderst Linien, Kreise, 
Ellipsen, abgerundete Rechtecken, ja sogar das Clipping arbeiten mit 
Koordinaten bis maximal 255x255. Ich habe zwar in beien Libraries darauf 
geachtet das für Koordinaten ein eigener Datentyp benutzt wird, ist also 
schnel geändert auf 16Bit, aber denoch müssen einige Korrekturen in oben 
genannten Funktionen gemacht werden. Meistens dürfte die Vergrößerung 
der lokalen Variablen von x Bits auf 2x Bits ausreichend sein, aber 
überprüfen muß man das denoch.

Gruß Hagen

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Antworten waren sehr interessant. Die Möglichkeit der 
FontKompression wird wahrscheinlich eine praktikable Variante sein, da 
sich der notwendige FlashSpeicher in der erwarteten Größe integrieren 
läßt. Einen Spline bzw. Bezier-basierten Fontgenerator für scalierbare 
Zeichensätze in einer auf Speicherplatz und Taktrate beschränkten 
Hardwareumgebung aufzubauen, ist sicher schwierig und vor Allem 
zeitaufwendig. Stellt sich noch die Frage, ob sich die z.B. 4 
Zeichensätze nach kursiv zur Laufzeit manipulieren lassen, oder ob  sie 
explizit ebenfalls hinterlegt werden müssen.

Ich würde gerne die Portation nach 51er C nutzen. Dafür fehlen mir aber 
noch Informationen, die z.Z. auf anderem Wege erfragt werden. Ich melde 
mich diebezüglich dann wieder.

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hagen,

erstmal vielen Dank für diese Lib, war wirklich ein Haufen Arbeit! Gut 
kommentiert an jeder Stelle, sehr schön nachvollziehbar. Bekomme 
demnächst ein paar Displays und zwar aller Wahrscheinlichkeit nach Epson 
S1D... Controller. Frage: Reicht es aus, wenn ich in glcd.inc die 
Hexwerte der Befehlstabelle anpasse oder muss ich mehr ändern? Sollte 
eigentlich reichen, oder? Klar, eventuell ändern sich Werte wie Kontrast 
oder LCD Spannung usw, aber nix weltbewegendes (hoffe ich).

Danke & Grüße

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, du musst wohl schon mehr ändern. Ich benutze zb. in den Font 
Routinen die speziellen Addressierungsmöglichkeiten des LCD Controllers 
auf seinen Grafik RAM. Dazu gehört als erstes das man über das GRAM ein 
Window legen kann. Dieses Window stellt sicher das wenn man zb. 100 
Pixcel setzt und ein Window mit 10x10 Pixel Ausdehnung definiert hat das 
dieses Rechteck komplett gefüllt wird. Nun kann man innerhalb dieses 
Window dem LCD Controller mitteilen in welche Richtung dieses Window 
gefüllt werden soll. Also mit welcher Ecke begonnen wird (RAM Address) 
und in welche Richtung die Piexel nacheinander gesetzt werden.
Meine Font Routinen definieren ein Window das so hoch ist wie der Font 
selber. Dann beginnt man von Links Oben Spaltenweise nach Unten den Font 
zu zeichnen.
Du musst also auch die Window Funktionen, RAM Address Funktion und RAM 
Direction Register anderst setzten.

Dann noch das problem der Initialisierung. Die glcdDisplayInit(), 
glcdDisplayOn()/Off() Funktionen müssen komplett geändert werden.
Das betrifft dann auch die Initialisierung der Farbtabelle falls 
vorhanden.

Anderst ausgedrückt: falls das display die gleiche Pixelauflösung hat 
dann sind im Grunde nur die High-Level Grafikfunktionen Hardware 
unabhängig, leider.

Gruß Hagen

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar, Danke. Werde es auf jeden Fall mal angehen und versuchen, 
daß Ganze hin zu biegen. Der Init ist sicher anders, stimmt, ist mir 
vorhin entfallen. Die Window Funktion gibts im S1D... Controller genau 
so, ich muss nur mal vergleichen, ob die zugehörigen Parameterwerte die 
selben sind, gute Frage. Die Farbtabellen sollten ebenfalls kein Problem 
darstellen.

Na, ich seh schon, wird nix Einfaches, aber dann haben wir´s wenigstens 
mal. ;)

Danke & Grüße! :)

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Ich versteh noch nicht so ganz, wie Nokia das gelöst hat. Ich meine, 
es kann doch nicht sein, daß da ein Nokia-Techniker vorm kaputten LC 
Display hockt und erst das Eine, dann das Andere ausprobiert, jenes, das 
funktioniert, bleibt drin. Irgendwie müssen die Handies doch beide 
Displays vertragen können, oder nicht? blödguck

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig. Der Controller im Nokia wird wohl erstmal das Philips Teil 
versuchen zu detektieren, da das auch ausgelesen werden kann. Gibts 
keine Antwort wird davon ausgegeangen das es der andere Displaytyp sein 
muß.

Gruß Hagen

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht bei Nokia-LCDs mit angeblichem Epson-Controller: es gibt einige 
(z.B. GE8 von Olimex) die nur einen Teil des Epson-Funktionsumfangs 
implementieren und z.B. keinen 8-Bit-Modus beherrschen.

Autor: Sylvio (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen

Gibt es eine Möglichkeit die Kompression in Deinem Fonteditor zu 
deaktivieren ?
Falls nicht,könntest Du eine Version ohne Kompression zur verfügung 
stellen ?

Danke

mfg Sylvio

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. habe ich einen kleinen Bug gefunden: Mein Winavr hat rumgemotzt, 
es fehle in glcd.h eine Kleinigkeit (hat nix compiliert): (Zeile 49)

Original:

            Clipping:1;              // activate clipping
    }
} glcdFlags_t;

Korrektur: (Strichpunkt nach "}" )

            Clipping:1;              // activate clipping
    };
} glcdFlags_t;

Ist das korrekt?

Grüße! :)

PS: Display läuft bisher noch ned, brauch (noch immer) Teile.

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der "neue" Font Editor hat eine Checkbox mit der man explizit angeben 
kann das der Font komprimiert werden soll, Standardmäßig also 
"unkomprimiert".

Im ZIP enthalten auch der Bitmap Converter für das S65 Display, hier im 
Forum kann man im S65 Thread nachlesen wie das Datenformat aussieht.

@pay.c: falsch ist es nicht aber bei meckert er auch nicht rum.

Gruß Hagen

Autor: Sylvio (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Hagen

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SO! FUUUNZT! :) :) :)

Einziges Prob noch: Die Füllfarben schauen bei mir noch wie sonst was 
aus. Ich habe momentan test.c am Laufen. Linien und Ähnliches werden 
anscheinend in korrekten Farben dargestellt, aber sobald etwas gefüllt 
wird (Rechtecke oder auch die diagonal durchlaufenden Schattierungen) 
wird das Ganze wild: Verschiedenste Farbcodes (schaut ähnlich zu 
Graustufen aus) werden dargestellt.

Hab schon nach sonst was geschaut, aber bisher nix gefunden...

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, kleines PS: Habe anscheinend ein Japaner Display, da der 256 
Farbenmode nicht funktioniert (sogar die Bildschirmweite wird falsch 
initialisiert). Mit 65k Farben funzts soweit einwandfrei. Evtl hats auch 
damit was zu tun, kann gut sein...

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmmm, dritte Anmerkung (SORRY!!!): Ich verwende einen ATMEGA32, der 
Code hat 23 kByte und bei ClearScreen(1) schauts fast so aus, als würde 
irgendein Codeschnipsel nochmal geschrieben werden (nach einem Reset 
gibts beispielsweise ein Teilbild von vor dem Reset bei ClearScreen - 
Reste im Display RAM?). Hilft evtl. weiter.

Autor: pay.c (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also, irgendwie komme ich noch so überhaupt nicht mit dem Display klar. 
Ich bin mir wirklich nicht sicher, ob die Schaltung so in Ordnung ist. 
Ich habe jetzt einen 74HC4050 als Pegelwandler drin (ziemlich exakt 3,3V 
und 3,0V ausprobiert). Beides funktioniert nur mit deutlichen 
Kondensatoren an der DATA Line und ich kriege immer noch völlig wirre 
Graphiken (siehe Bild im Anhang). Also grundsätzlich funzt alles, aber 
irgendwie fehlt mir der letzte Schliff...

Öhmmmm, Hilfe?

Autor: pay.c (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hände über den Kopf zusammenschlag

Ach Gott, nööö. Update: Habe eben herausgefunden, warum die ganze 
Geschichte nicht bei mir läuft: Habe Displays mit dem S1D15G17 
Controller (Achtung! NICHT S1D15G10 wie sonst). Das ist anscheinend ein 
weiterer Controllertyp, der noch nirgends wirklich dokumentiert ist, 
aber anscheinend recht gerne verwendet wird.

Toll, gaaanz toll... ich update eben mal den LCD-Artikel in die Richtung 
um andere vom gleichen Fehler abzuhalten und mache mich dann an die 
Programmierung in die Richtung (stöhn).

Autor: pay.c (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Puh! Cool, war doch nicht so viel, wie ich dachte.

Also bei mir läufts jetzt. @Hagen: Anbei die in erster Linie angepasste 
Datei. Ich musste ein wenig was im Init ändern (mehr Pausen, Sleep Out 
und Display On auch gleich mit rein, statt erst später aufzurufen). Der 
G17 Controller braucht da anscheinend etwas mehr Zeit, um 
"hochzufahren", aber mehr ist es nicht. Sollte so auch zum 
Nachfolgermodell dem "S1D15G27" kompatibel sein und bleiben.

Ein einziges Problem gibts noch: Bei den 0° und 180° Orientation gibts 
im Testproggi noch Probleme beim String schreiben (Linien usw. funzen 
einwandfrei). Habe versucht mich reinzudenken, aber da hast Du ja ganz 
schön "elegant" programmiert. ;) Nebenbei: Spitzen Programmierstil, da 
kann man sich was abkupfern!

Wenn Du lustig bist, geb ich Dir mal die entsprechende Seite aus dem 
Datenblatt für die Orientation Geschichte, es gibt leichte 
Unterschiede zwischen PCF und G17. Ansonsten versuche ich mich bei 
Gelegenheit wieder reinzudenken und eine für beide Controller kompatible 
Lösung zu finden... vorerst reicht mir der bisherige Funktionsumfang 
nämlich voooohoooollkommen aus. :) :) :)

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand ne Idee, wie man ein Bitmap zu einem font konvertiert (in 
Farbe)? Und wie mache ich aus den Font-Dateien von Hagens Editor 
eigentlich Datazeilen ?

Gruß,
Thomas

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Font Editor "exportiert" den Font beim Speichern gleich in mehrere 
Format. *.font Dateien sind binär und stellen das interne Format des 
Editors dar. Dann kannst du noch über die INI die Template-Dateien 
angeben von denen ausgehend die Font Dateien erzegt werden. Dabei kann 
über diese Templates eingestelt werden ob man zb. ein *.h und *.c Datei 
haben möchte mit getrenntem Header und Datenbereich. Oder gleich alles 
in ein h oder .c Datei exportiert, also Header und Daten in einer 
Datei. Unterstützt werden auch Dateiformate für BASIC und ASM. Einfach 
mal die INI Datei anschauen und die dort eingeplegten Templates. 
Eventuell im S65 Thread hier die neuste Version des FontEditors laden.

Für Bitmaps/JPEGs/GIFs/PNGs/WMFs/ICOs/ANIs/PCXs usw. habe ich einen 
eigenen Converter geschrieben, allerdings für das S65 Display. Im S65 
Thread findet sich auch dazu einiges an Erklärungen. Für das Nokia ließe 
sich dieser Converter umschreiben, allerdings fehlt mir dazu die Zeit 
(ab morgen in Jamaika, juchuh :)

Du kannst auch "Bitmaps", eher frabige Symbole mit den Fonts machen. Die 
Farbanzahl ist auf 256 Farben begrenzt. Schau dir mal meine 
mitgelieferten Farbenfonts an, zb. die Clock oder Weltkarte.

Eine Bitmap kannst du folgendermaßen importieren:
Öffne die Bitmap mit MSPaint oder jedem anderen kompatiblen Bitmapeditor 
der über die Zwischenablage arbeiten kann, zb. Corel Photopaint, WinWord 
usw. Markiere den Bereich oder die ganze Bitmap den du haben möchtest, 
achte dabei darauf das die Farbanzahl <= 256 ist. Kopiere diesen in die 
Zwischenablage. Gehen in den FontEditor und drücke den Paste-Button. Der 
Font wird dann autom. auf die Größe der Bitmap erweitert und die Bitmap 
aus der Zwischenablage eingefügt. Nun ist es dann aber so das die Farben 
nicht mehr stimmen. Das liegt daran das der FontEditor defakto ohne 
Farbe arbeitet sondern mit Farb-Indexen. Dh. die Farbpalette im 
FontEditor muß angepasst werden. Doppelklicke dazu auf die Farbe in der 
Farbpallete und stell dort die richtige Farbe ein. Oder exportiere die 
Farbpallette der Bitmap selber und speichere sie dann in deinem AVR 
projekt in glcd_Colors[]. Beachte das dieses Array[] über das #define 
GLCD_COLOR_COUNT korrekt eingestellt sein muß.

Man kann also sehr einfach Bitmaps in den FontEditor importieren, per 
Copy&Paste aus anderen Anwendungen. Bis dahin sehr einfach und schnell. 
Aber die Farben sind das eigentliche Problem. Ich hatte mir damals ein 
Tools geschrieben das die Farbpalette der Bitmap in der Zwischenablage 
abspeichern kann.
Das problem ist halt das die GLCD nur eine, zwar ladbare, globale 
Farbtabelle kennt die nicht durch das Laden eines Fonts aktualisert 
wird. Das muß der Programmierer selber machen, auch das 
Verwalten/Speichern dieser Farbtabelle.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach übrigens, dieses Kopieren geht auch in umgekehrter Richtung. Du 
kannst ein Symbol/Fontzeichen aus dem FontEditor kopieren und in jedes 
bessere Malprogram einfügen ;)

Und beim Einfügen solcher Bitmaps kannst du vorher im Editor noch einen 
grafischen Bereich auswählen und dann wird diese Bitmap nur dort hinein 
kopiert und beschnitten.

Gruß Hagen

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey ! Vielen Dank Hagen.

Das mit der Farbpalette bekomme ich hin. Wünsche Dir viel Spaß in 
Jamaika !

Gruß,
Thomas

Autor: Jochen Kühner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollte nur Fragen ob die Hompage mit der glcd lib irgendwann wieder 
online geht???

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit ApeTech's Homepage habe ich nichts zu tun, da musst du Ape fragen. 
Er war so freundlich meine Lib zu hosten.

Ich selber habe mit dem Nokia schon seit jahren nichts mehr gemacht. 
Verbaue wenn überhaupt erstmal meine S65 Displays.

Gruß Hagen

Autor: Max Murks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Hagen
> Verbaue wenn überhaupt erstmal meine S65 Displays.

Wie viele hast du denn noch übrig? Kannst ja welche verkaufen.

Autor: sven s. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,

ich kann den code von hagen mit dem neuen winavr nich comilieren und den 
alten gibts nirgens gibts.

gibt es evtl einen neueren code von Dir ?

mfg sven

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für's Nokia ? nein. Alles ist hier in den Threads zu finden.
Den FontEditor habe ich weiterentwickelt, also par kleinere Änderungen 
und denn kann ich dir mailen. Melde dich einfach heir als registrierter 
Benutzer an und sende mir eine PN indem du auf meinen blauen Namen 
klickst.

Von den S65 Displays habe ich nur noch 2 wobei eines schon in meinem 
elektronischen Drum Projekt verbaut ist. Ergo habe ich nur noch 1 als 
Reserve das bei mir rumliegt. Eventuell könnten wir uns einigen da ich 
bis jetzt noch nicht die Zeit oder ein Projekt habe um es zu verbauen. 
Ist ungenutzt und neuwertig und ein LPHxxxx Teil das durch meine S65 
Library angesteuert werden kann. Die S65 Lib kannst du bei mir per 
PN/Email bekommen, haben schon viele User hier gemacht. Am liebsten 
tausche ich unter Bastlern ;)

Gruß Hagen

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten tag Schweden calling

Tried to write to you in in German but i'm not that good:-(

Anyhow found this site during my websearching and downloaded the 
GLCD.zip file from 040414. I have the same problem, can't compile it 
with Winavr 20071221, i get the following during the compile steps:

C:\make clean
-------- begin --------
Cleaning project:
..
..
Errors: none
-------- end --------
C:\make all
set -e; avr-gcc -MM -mmcu=atmega32 -I. -Os -mcall-prologues 
-funsigned-char -fun
signed-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes 
-Wa,-adhl
ns=test.lst  -std=gnu99 test.c \
        | sed 's,\(.*\)\.o[ :]*,\1.o \1.d : ,g' > test.d; \
        [ -s test.d ] || rm -f test.d
-------- begin --------
avr-gcc (GCC) 4.2.2 (WinAVR 20071221)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

Compiling: test.c
avr-gcc -c -mmcu=atmega32 -I. -Os -mcall-prologues -funsigned-char 
-funsigned-bi
tfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes 
-Wa,-adhlns=test.l
st  -std=gnu99 test.c -o test.o
In file included from test.c:2:
c:/avr/include/glcd.h:49: error: expected identifier or '(' before '}' 
token
c:/avr/include/glcd.h:49: error: expected ';' before 'glcdFlags_t'
make: *** [test.o] Error 1
Press any key to continue . . .

----
Error as shown below:
    }
} glcdFlags_t;    <<<<<<----------

removed one "} " by using //
Then i got the :
In file included from test.c:2:
c:/avr/include/glcd.h:52: error: expected specifier-qualifier-list 
before 'extern'
Which is the line below:

extern uint8_t         glcd_MemCtrl;  // display RAM access and degree 
of rotation

I've done the installation steps by editing and copy the requested 
files... i assume....

All hints are welcome..

Best regards,
Hans

Autor: min (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe genau das gleiche Problem wie Hans aus dem vorigen post.

<<<Mein Display läuft in allen Tests super>>>

Aber beim Copilieren des test.c Codes von Hagen
(-bei dieser Gelegenheit: Vielen Dank für die Bereitstellung des 
Codes:-)

kommt auch der folgende Compilierungsfehler:
In file included from test.c:2:
./glcd.h:49: error: expected identifier or ‘(’ before ‘}’ token
./glcd.h:49: error: expected ‘;’ before ‘glcdFlags_t’
make: *** [test.o] Fehler 1


Für eine Hilfe bei Lösen des Problems wäre ich sehr dankbar.

Gruß min

Autor: Ralf W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>error: expected ‘;’ before ‘glcdFlags_t’

The answer is this thread at this post:
Schaut mal in diesem Thread in diesen Post:

Autor: pay.c (Gast)
Datum: 02.09.2007 18:37

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche gerade meinem ATmega16L das schreiben auf das Nokia6100
(Epson Controller Variante) beizubringen.

Mit dem Code von
http://www.e-dsp.com/controlling-a-color-graphic-l...
klappt das schon ganz gut. Es fehlt mir aber noch die Unterstützung von
Schriftzeichen und Bildern.
Mit dem Code von Hagen klappt es jedoch nicht :-(
Da bleibt das Display stumm.

Die Anpassungen laut install.txt hab ich brav gemacht, jedoch glaube
ich, das sich noch irgendwo ein böses define versteckt, was meiner
Schaltung nicht schmeckt. Ich verwende 4 statt 16MHz und habe die
Steckerbelegung von der http://www.e-dsp.com -Seite (die Anpassung im
glcd.inc habe ich doch gemacht).


Gruß Sebastian

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach all den Spambeiträgen, mal wieder was anderes:

Auf meiner kleinen Blogseite Zipfelmaus (Link: 
http://www.zipfelmaus.com/blog/how-to-nokia-6100-display/) habe ich ein 
Programm zum Konvertieren von BMPs in das RGB8-Format veröffentlicht. 
Das Programm erzeugt ein fertiges h.-file, das man ganz einfach in das 
eigene Projekt einbauen kann.

Downloaden kann man es hier:
http://www.zipfelmaus.com/wp-content/uploads/2008/...

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohje wieder Spam

mal eine Frage, hat jemand mein BMP-Konvertierungstool (von 
zipfelmaus.com) ausprobiert und mag über seine Erfahrungen damit 
berichten?

die Seite habe ich nun auch ein wenig angepasst:
http://www.zipfelmaus.com/nokia6100lcd_en/

Autor: Roland S. (seagal)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

momentan bin ich dabei eine kleine Karte mit einem Atmega88 und dem 
Nokia 6100 zu bauen  - basierend auf dem Elektorprojekt ATM 18 (Stecker, 
etc).

Smartie hat geschrieben, dass er den Code umgeschrieben hat für den 
Codevision AVR.

Gibt es einen Link, wo man den Code bekommen kann ?

Gruss

- bin übrigens neu hier

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hoffe mal es meldet sich noch jemand....

Hallo euch allen, das ist ja ne echt starke leistung, was hier alle 
vollbrahct haben.
leider bekomme ich keine der Display version zum laufen.

Ich suche eine Software für die Displays.
       Nokia 6100   leider die EPSON version
       S65
       Nokia 3310

       mit ATmega128

Nutzen möchte ich diese mit dem aktuellen WinAVR und einem ATmega128
kann mir jemand einen brauchbaren CODE zusenden?

Vielen DANK
martin

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin J. (bluematrix)


alter, du nervst langsam. Wie wärs mit selber schreiben oder mindesten 
googlen ?

Und nicht alle alte threads hier ausgraben. Das ist schon dein 
mindestens 10tes posting.

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na irgendwer muss doch mal ncoh was ordentlich es haben ...
ist das nun nen forum wo man sich gegenseitigt hilft oder bekommt man 
hier immer nur blöde sprüche von solchen wie dir zu hören.
...

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach und nochwas...

es ist echt toll, dass hilfe immer gerne angenommen wird, aber wenn man 
selber mal nach etwas fragt.. kommen nur hirnlose antworten.

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber wenn man selber mal nach etwas fragt ?

lese erst:

[http://www.mikrocontroller.net/articles/Netiquette]

Du hast in einigen threads immer wieder selbe mist geschrieben - obwohl 
fett / rot steht "der Originalbeitrag ist mehr als 6 Monate alt".

Öffne einfach neues thread, beschreib dein problem und dann wird jemand 
schon helfen können, alte leichen ausgraben ist hier nicht willkommen.

Autor: someGeek72 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

erstmal Danke für die Infos von denen, die sich sachdienlich beteiligen.
Und vor allem grosses THX to Hagen, für das Bereitstellen dieser 
ausgereiften Bibliothek.
Ausserdem möchte ich mich pay.c anschliessen der den Programmierstil 
lobt.

Trotzdem bin ich fast am Ende einer zweitägigen Leidensgeschichte mit 
der Lib.
Daher hab ich im Folgenden ma die Punkte zusammengefasst die ich ändern 
musste damit die Geschichte bei mir läuft.

Meine Hardware:
  ATMEGA8 @5V und @8Mhz, keinen Hacken bei Watchdog
  Spannungsteiler fürs Display: 1,8k/3,3k (suboptimal, ich weiss)
  DisplayController PCF8833: (glaube ich, da ja die DispCommands sonst 
andere wären) auf jeden Fall braune Platine
  Programmer (Hardware): 0815 selbstbau, seriell, (der mit den 2x 4,7k 
und 2x 10k, etc.), Schaltplan bekommt man im Internet überall 
hinterhergeschmissen
  Programmer (Software): PonyProg2000

PinConfig:
  #define   LCD_CS    PB2   // ICP1
  #define   LCD_SDA    PB3   // MOSI
  #define   LCD_RESET  PB1   // MISO
  #define   LCD_SCL    PB5   // SCK

Änderungen an 'glcd00.S':
- SOFT_RESET entfernt (Zeile 207 + 208),
- ganz wichtig für alle die mit Füllfarben Probleme haben, und bei denen 
es so aussieht wie bei 'pay.c' am 'Datum: 19.09.2007 23:05':
  'glcdDispCommand' statt 'glcdDispSend' bei COLOR_INTERFACE (Zeile 211)

Änderungen an 'glcd01.S':
- nicht vom Display lesen: d.h. 'glcdDisplayOn1' und 'glcdDisplayOn2' 
ersatzlos entfernt,
 'glcdDisplayOn' besteht nur aus SLEEP_OUT, INVERSION_OFF, DISPLAY_ON, 
über BOOSTER_ON kann man sich streiten
 ohne diese Änderung bekam ich nur einen schwarzen Bildschirm, an 
LCD_SDA lag dann permanent nur eine Dreiecksspannung an.

Änderungen an 'glcd.h': (neben dem, was in der install.txt beschrieben 
ist)
- das semikolon hinter dem 'struct' in 'union' vor 'glcdFlags_t'

Habe die geänderten Versionen ma angehangen. Hoffe ich konnte damit wem 
helfen.

Offene Probleme:
- die testBitmaps() sieht seltsam aus, hab mir aber noch nicht 
angeschaut, wie man die bedient.
- die testSymbols() ist bei genauem hinsehen nicht ganz sauber
- die testOrientation() erzeugt nicht sauber die strings f. 0,180,270 
Grad, lediglich 90 ist lesbar

Lösungen für die offenen Probleme sind selbstverständlich willkommen.

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe mich in meinem Weihnachtsurlaub daran gemacht, die libglcd 
zusammen mit einem Octopus (AT90CAN128) von EmbeddedProjects ans Laufen 
zu bekommen. Um den gängigen HW-Problemen aus dem Wege zu gehen, habe 
ich mir ein Trägerboard gebastelt, das die HW mit 3,3V versorgt. Das 
Display ist über den Display3000-Adapter angeschlossen (der nicht sauber 
gelötet war und einige Probleme verursacht hat)

Prinzipiell hat die Inbetriebnahme mit dem guten alten Beispiel von 
Thomas Pfeiffer recht schnell funktioniert. Mit der libglcd komme ich 
bisher aber nur Schrittweise voran.

Das erste Problem war, dass die SPI-Register in dem Controller außerhalb 
des I/O-Adressbereichs bis 0x1f liegen. Da musste dann einiges am 
Assembler angepasst werden, was aber in der ISR nicht sehr effektiv war. 
Inzwischen habe ich ein recht gute Lösung. Ich werde diese in den 
nächsten Tagen hier posten.

Das zweite Problem war das Display selbst. Die HW-Variante benötigt 
neben RESET Low auch noch SDA Low und Clock High, und dies stabli 
während der Reset-Phase. Außerdem muss der Reset-Pegel einige Zeit im 
Low-Zustand verbleiben. Muss man erst mal drauf kommen....

Danach hat das Demo endlich etwas ausgegeben, allerdings waren die 
Farben falsch und sind es noch bis heute. Rot wird zu Magenta, Grün zu 
Türkis und Blau bleibt Blau. Hat aber nichts mit dem Inverter zu tun, 
das habe ich bereits probiert. Darauf hin habe ich ein einfaches 
Beispiel mit Quadraten in den Farben Rot, Grün Blau und Weiß 
geschrieben, wobei diese einmal über die lib und einmal direkt über das 
Testprogramm generiert werden. Das Display wird hierbei aber nur einmal 
über die Lib initialisiert. Interessanter Weise sind die Farben über die 
Lib falsch und im Testcode korrekt.

Das ist natürlich fein, denn jetzt sollte sich der Fehler finden lassen. 
Also habe ich den Code zu glcdDisplayRect() angesehen und in glcd04.S 
ist mir etwas Merkwürdiges aufgefallen:

In der Funktion glcdSetAddr werden die 2 x- und die 2 y-Adressen für die 
folgende Pixel-Ausgabe gesetzt. Es wird aber 2 Mal das Kommando 
SET_X_ADDR an das Display gesendet (Zeilen 19 und 27). Wenn MEM_90 nicht 
gesetzt ist, wird dies so beibehalten, ansonsten wird auf das Kommando 
SET_X_ADDR+1 (SET_Y_ADDR) gewechselt. Sollte es hier nicht so sein, dass 
einmal das X- und einmal das Y-Kommando ausgegeben wird?

Das war jetzt leider bereits ein bisschen länglich, aber ich hänge schon 
seit vielen Stunden an der Sache und habe auch schon so einiges 
weggekämft, da ist dann Historie einfach etwas länger.

@Hagen: Vielen Dank für die Lib. Das ist wirklich ein umfangreiches 
Werk! Gerne steuere ich meine Erfahrungen bei, im Moment ist aber alles 
im Hacker-Status. Wenn Du an dem Thema noch dran bist, wäre es super, 
wenn Du mir an dem obigen Punkt einen Hinweis geben könntest.

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

auch ich habe die Lib mit dem CAN128 am Laufen. Daher versuche ich mal 
einige Kommentare abzugeben ;)

> Das erste Problem war, dass die SPI-Register in dem Controller außerhalb
> des I/O-Adressbereichs bis 0x1f liegen. Da musste dann einiges am
> Assembler angepasst werden, was aber in der ISR nicht sehr effektiv war.
> Inzwischen habe ich ein recht gute Lösung. Ich werde diese in den
> nächsten Tagen hier posten.

Das ist korrekt, ich habe alle cbi und sbi durch ein Makro ersetzt, 
welches abhängig von den Vorgaben die richtigen Kommandos auswählt. 
Desweiteren habe ich die Warteschleifen ähnlich behandelt.

> Das zweite Problem war das Display selbst. Die HW-Variante benötigt
> neben RESET Low auch noch SDA Low und Clock High, und dies stabli
> während der Reset-Phase. Außerdem muss der Reset-Pegel einige Zeit im
> Low-Zustand verbleiben. Muss man erst mal drauf kommen....

Mit dem Reset habe ich auch so meine Probleme, das muß ich mir in Ruhe 
noch mal anschauen. Zur Zeit initialisiere ich 2 Mal ;)

> Danach hat das Demo endlich etwas ausgegeben, allerdings waren die
> Farben falsch und sind es noch bis heute. Rot wird zu Magenta, Grün zu
> Türkis und Blau bleibt Blau. Hat aber nichts mit dem Inverter zu tun,
> das habe ich bereits probiert. Darauf hin habe ich ein einfaches
> Beispiel mit Quadraten in den Farben Rot, Grün Blau und Weiß
> geschrieben, wobei diese einmal über die lib und einmal direkt über das
> Testprogramm generiert werden. Das Display wird hierbei aber nur einmal
> über die Lib initialisiert. Interessanter Weise sind die Farben über die
> Lib falsch und im Testcode korrekt.

Ich hatte ähnliche Probleme mit den Farben, und habe dann eine Änderung 
an gemacht, die hauptsächlich bei Rechtecken zu tragen kommt. Ich glaube 
in der Demo wird immer glcdClearScreen verwendet (vorher das Clipping 
entsprechend gesetzt). Hier habe ich die folgenden ldi-Befehle ersetzt. 
Bin mir aber nicht 100%ig sicher, ob es das war.
//        ldi     D0, lo8(SCREEN_COLOR)
        lds     D0, glcd_Colors
#ifdef USE_HIGHCOLOR
//        ldi     D1, hi8(SCREEN_COLOR)
        lds     D1, glcd_Colors+1
#endif
Falls es das nicht ist, müsstest Du mal posten wie die Quadrate mit der 
Lib aufgerufen werden und wie es mit dem Testprogram erfolgt.

> In der Funktion glcdSetAddr werden die 2 x- und die 2 y-Adressen für die
> folgende Pixel-Ausgabe gesetzt. Es wird aber 2 Mal das Kommando
> SET_X_ADDR an das Display gesendet (Zeilen 19 und 27). Wenn MEM_90 nicht
> gesetzt ist, wird dies so beibehalten, ansonsten wird auf das Kommando
> SET_X_ADDR+1 (SET_Y_ADDR) gewechselt. Sollte es hier nicht so sein, dass
> einmal das X- und einmal das Y-Kommando ausgegeben wird?

Das ist schon richtig so, was da abläuft, ist ziemlich tricky.

Hoffe das hilft erstmal.

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar,

Volkmar schrieb:

>> Das erste Problem war, dass die SPI-Register in dem Controller außerhalb
>> des I/O-Adressbereichs bis 0x1f liegen. Da musste dann einiges am
>> Assembler angepasst werden, was aber in der ISR nicht sehr effektiv war.
>> Inzwischen habe ich ein recht gute Lösung. Ich werde diese in den
>> nächsten Tagen hier posten.
>
> Das ist korrekt, ich habe alle cbi und sbi durch ein Makro ersetzt,
> welches abhängig von den Vorgaben die richtigen Kommandos auswählt.
> Desweiteren habe ich die Warteschleifen ähnlich behandelt.

So habe ich das auch zuerst gemacht. Vor allem in der ISR wird dann aber 
massiv zus. Code notwendig, da über die in und out-Befehle zusammen mit 
dem andi insgesamt 2 Register auf den Stack müssen. Alles in allem 
kommen 10 Instruktionen hinzu, und das bei jedem Byte das übertragen 
wird. Ein Implementierung über das GPIO1-Register ist da auch nicht 
schneller.

Darum habe ich dies wie folgt verändert: Ich habe ganz auf das 
Deaktivieren der SPI in der ISR verzichtet. Diese hört nämlich von 
alleine auf wenn das Byte draußen. In den Funktionen glcdDispSend() und 
glcdDispRead() habe ich die SPI dann aktiviert. Das Warten geht dann 
anstelle über

sbic    LCD_SPCR, SPE

einfach mit

sbis    LCD_PORT, LCD_CS

Achtung: Auch in glcd02.S wird einmal gewartet.

Hinzu kommt dann noch vor dem Ausgeben des D/C-Bits die SPI zu 
deaktivieren und ebenso in glcdDispRead(). Um diese Blöcke müsste man 
eigentlich noch ein cli/sei nehmen, da man sonst durch einen anderen 
Interrupt der ebenfalls am PortB "schraubt" gestört werden könnnte (kein 
atomare Operation!) Kostet dann aber auch wieder extra Code.

Ich bin der Meinung, dass die Lib dadurch schneller wurde. Da ich noch 
ein paar Debugging-Ports drin habe, die ich in den nächsten tagen noch 
brauchen werde, habe ich die Änderungen noch nicht gepostet. Wenn Du 
interessiert bist, mache ich das Debugging kurz raus.

>
>> Das zweite Problem war das Display selbst. Die HW-Variante benötigt
>> neben RESET Low auch noch SDA Low und Clock High, und dies stabli
>> während der Reset-Phase. Außerdem muss der Reset-Pegel einige Zeit im
>> Low-Zustand verbleiben. Muss man erst mal drauf kommen....
>
> Mit dem Reset habe ich auch so meine Probleme, das muß ich mir in Ruhe
> noch mal anschauen. Zur Zeit initialisiere ich 2 Mal ;)
>

Das war auch recht unschön gemacht. Zuerst den Reset setzten, im 
Hintergrund die SPI aktivieren, dann warten, und dann erst den Reset 
wieder  wegnehmen finde ich ziemlich unschön beim Lesen des Codes. Hier 
ist nun wirklich keine Performance gefragt. Auch hier kannst Du mal 
meine Variante ansehen, wenn ich diese gepostet habe.

>> Danach hat das Demo endlich etwas ausgegeben, allerdings waren die
>> Farben falsch und sind es noch bis heute. Rot wird zu Magenta, Grün zu
>> Türkis und Blau bleibt Blau. Hat aber nichts mit dem Inverter zu tun,
>> das habe ich bereits probiert. Darauf hin habe ich ein einfaches
>> Beispiel mit Quadraten in den Farben Rot, Grün Blau und Weiß
>> geschrieben, wobei diese einmal über die lib und einmal direkt über das
>> Testprogramm generiert werden. Das Display wird hierbei aber nur einmal
>> über die Lib initialisiert. Interessanter Weise sind die Farben über die
>> Lib falsch und im Testcode korrekt.
>
> Ich hatte ähnliche Probleme mit den Farben, und habe dann eine Änderung
> an gemacht, die hauptsächlich bei Rechtecken zu tragen kommt. Ich glaube
> in der Demo wird immer glcdClearScreen verwendet (vorher das Clipping
> entsprechend gesetzt). Hier habe ich die folgenden ldi-Befehle ersetzt.
> Bin mir aber nicht 100%ig sicher, ob es das war.
>
//        ldi     D0, lo8(SCREEN_COLOR)
>         lds     D0, glcd_Colors
> #ifdef USE_HIGHCOLOR
> //        ldi     D1, hi8(SCREEN_COLOR)
>         lds     D1, glcd_Colors+1
> #endif
> Falls es das nicht ist, müsstest Du mal posten wie die Quadrate mit der
> Lib aufgerufen werden und wie es mit dem Testprogram erfolgt.
>
>> In der Funktion glcdSetAddr werden die 2 x- und die 2 y-Adressen für die
>> folgende Pixel-Ausgabe gesetzt. Es wird aber 2 Mal das Kommando
>> SET_X_ADDR an das Display gesendet (Zeilen 19 und 27). Wenn MEM_90 nicht
>> gesetzt ist, wird dies so beibehalten, ansonsten wird auf das Kommando
>> SET_X_ADDR+1 (SET_Y_ADDR) gewechselt. Sollte es hier nicht so sein, dass
>> einmal das X- und einmal das Y-Kommando ausgegeben wird?
>
> Das ist schon richtig so, was da abläuft, ist ziemlich tricky.

Wenn ich mir meine Fontausgaben ansehe, habe ich auch nur irgendwelche 
komischen Muster. Da ist noch einiges an Arbeit notwendig. Evtl. 
könntest Du den obigen Code nochmal genauer ansehen. Ich würde gerne 
verstehen, was da läuft.

Hier mein Verständnis:

glcdSetAddr:

// Hier wird in Abhängigkeit von glcd_MemCtrl
// der übergebene X-Bereich dem Display entweder als
// X-Bereich (keine 90°-Drehung) oder als Y-Bereich übergeben.
// glcd_MemCtrl enthält einen Spiegel des Display-Registers

        lds     T0, glcd_MemCtrl // Display-Ausrichtung nach r26 (T0)
        ldi     T1, SET_X_ADDR   // Kommando SET_X_ADDR nach r27 (T1)
        sbrc    T0, MEM_90       // Wenn Rotation um 90° gewählt, ...
        inc     T1               // ... Kommando auf SET_Y_ADDR wechseln
        fcall   glcdDispCommand  // Kommando über SPI ausgeben
        mov     T1, X1           // 1. X-Koordinate nach r27 ...
        fcall   glcdDispData     // ... und ausgeben. 9. Bit=0
        mov     T1, X2           // 2. X-Koordinate nach r27 ...
        fcall   glcdDispSend     // ... und ausgeben. 9. Bit bleibt.

// So, und jetzt geht's an die Y-Koordintenübertragung.
// Warum hier jetzt wieder SET_X_ADDR genommen wird, ist mit
// unklar!

        ldi     T1, SET_X_ADDR   // Kommando SET_X_ADDR nach r27
        sbrs    T0, MEM_90       // Wenn Rotation um 90° gewählt, ...
        inc     T1               // ... Kommando auf SET_Y_ADDR wechseln
        fcall   glcdDispCommand  // Kommando über SPI ausgeben
        mov     T1, Y1           // 1. Y-Koordinate hinterher
        fcall   glcdDispData
        mov     T1, Y2           // 2. Y-Koordinate hinterher
        fcall   glcdDispSend

// So, und da ab jetzt viele Pixel kommen, dies dem Display ebenfalls
// mitteilen. Somit werden ab jetzt alle Daten ohne weiteres Kommando
// als Pixel interpretiert.

        ldi     T1, MEM_WRITE    // Kommando MEM_WRITE nach r27...
        fjmp    glcdDispCommand  // ... und ans Display senden.

.end


>
> Hoffe das hilft erstmal.

Klar, vielen Dank! Toll, dass trotz den hohen alters des Threads noch 
immer Leute an den Themen dran sind.

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar,

noch eine Frage. Nutzt Du das Display mit oder ohne USE_HIGHCOLOR?

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

> So habe ich das auch zuerst gemacht. Vor allem in der ISR wird dann aber
> massiv zus. Code notwendig, da über die in und out-Befehle zusammen mit
> dem andi insgesamt 2 Register auf den Stack müssen. Alles in allem
> kommen 10 Instruktionen hinzu, und das bei jedem Byte das übertragen
> wird.

Bei mir sind es 6 Instruktionen plus RETI, aber wenn man ein paar Takte 
sparen kann.

> Wenn Du interessiert bist, mache ich das Debugging kurz raus.

Ne, keine Eile. Bei mir läuft es ja soweit ;) Ähnlich auch mit dem 
Reset, hat keine Eile, das Projekt ist noch nicht abgeschlossen und wird 
noch 'ne Weile aktiv sein.

> // So, und jetzt geht's an die Y-Koordintenübertragung.
> // Warum hier jetzt wieder SET_X_ADDR genommen wird, ist mit
> // unklar!

Ganz genau habe ich das auch nicht mehr im Kopf. Es werden aber die 
verschiedenen Möglichkeiten des Chips genutzt um in die verschiedenen 
Richtungen schreiben zu können. Es kann gespiegelt werden, um 90° 
gedreht etc. Durch diese tricky-Programmierung wird das passend gemacht. 
Die Frage ist, ob Du den richtigen Chip im 6100 hast, da gibt es ja 
verschiedene Varianten.

> noch eine Frage. Nutzt Du das Display mit oder ohne USE_HIGHCOLOR?
Derzeit ohne USE_HIGHCOLOR. Habe eben einfach mal den Wert geändert und 
kann optisch keinen Unterschied sehen (nur das Programm wächst in der 
Größe)

Volkmar

Autor: Ralph Scharpf (schwabe68)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar,

Volkmar schrieb:
> Hallo,
>
>> So habe ich das auch zuerst gemacht. Vor allem in der ISR wird dann aber
>> massiv zus. Code notwendig, da über die in und out-Befehle zusammen mit
>> dem andi insgesamt 2 Register auf den Stack müssen. Alles in allem
>> kommen 10 Instruktionen hinzu, und das bei jedem Byte das übertragen
>> wird.
>
> Bei mir sind es 6 Instruktionen plus RETI, aber wenn man ein paar Takte
> sparen kann.

6 Instruktionen sind wirklich spitze! Ich hatte T0 und T1 auf den Stack 
gelegt (2), dann das SREG gerettet (3), dann in+andi+out (6), dann das 
SREG wieder hergestellt (7), T1 und T0 zurück vom Stack (9). Das wäre 
dann der Ersatz für das "cbi LCD_SPCR, SPE" (1).

Könntest Du Deine Lösung mal posten? Evtl hast Du ja auch eine bessere 
Lösung für die Änderungen in glcdDispSend() (2 mal in+andi+out, push T0 
und pop T0)

Ansonsten rennt mein Display jetzt. Ich hatte in glcdDispSend() das 
Register T0 verwendet und das hat dann so einiges zerstört. Jetzt lege 
ich T0 einfach auf dem Stack ab. Kostet zwar 2 Zyklen, ich habe aber 
keine andere Möglichkeit dafür gefunden.

Interessanter Weise musste ich noch das RGB-Flag für das 
Memctrl-Kommando herausnehmen, sonst sind bei mir Blau und Rot 
vertauscht.

Ich habe meine Änderungen angehängt. In glcd.inc kann man jetzt über das 
Makro SPI_IN_LOWER_IO_REGS steuern, ob die SPI im unteren I/O-Bereich 
liegt oder nicht.

Ich denke es macht Sinn, mit den Änderungen ein neues Archiv zu 
erstellen (Version 2.3) und die Doku anzupassen. Evtl. möchte das ja 
auch Hagen machen, ich habe aber keine Ahnung ob er überhaupt noch aktiv 
ist bzw. noch Interesse hat.

Noch offen:

1. Da die in+andi+out-Kommandos nicht mehr atomar sind, müsste man 
eigentlich während der Ausführung die Interrupts sperren.

2. Da die SPI jetzt nach dem Interrupt aktiv bleibt, müsste man eine 
Funktion hinzufügen, die die SPI stoppt (SPE<-0) und dann ggf. noch 
wartet, bis die letzte Übertragung abgeschlossen ist. Irgendetwas wie 
void glcdReleaseSpi().

Ralph

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ralph,

> In glcd.inc kann man jetzt über das Makro SPI_IN_LOWER_IO_REGS steuern, ob
> die SPI im unteren I/O-Bereich liegt oder nicht.

Das habe ich über ein Makro gelöst (Anregung von Hagen). Zum Beispiel 
für das in-Kommando. Statt "in" verwende ich "in_". Dazu gibt es noch 
ein Makro "in_" wie folgt:
.macro in_ value port
  .if (_SFR_IO_ADDR(\port) > 63)
            lds     \value, \port
  .else
            in      \value, \port
  .endif
.endm
Damit geht das dann automatisch.

Ich habe an einigen Stellen gesehen, daß Du kein #else beim #if defined 
hast, ist das so korrekt?

Für das Vertauschen von Blau und Rot könnten die nachfolgenden 
Änderungen helfen (ich meine das hatte ich auch):
        ldi     T1, COLOR_INTERFACE     // initialize color format and color mapping
        rcall   glcdDispSend
Hier muß doch
        ldi     T1, COLOR_INTERFACE     // initialize color format and color mapping
        rcall   glcdDispCommand
stehen.

Den Block mit den Farben habe ich noch ins Flash verlegt:
    .section .progmem
#ifndef USE_HIGHCOLOR
  #ifdef USE_ORGINALCOLORS
COLOR_RED:                                              // original color table
        .byte   0x00, 0x02, 0x04, 0x06, 0x09, 0x0B, 0x0D, 0x0F
COLOR_BLUE:
        .byte   0x00, 0x04, 0x0B, 0x0F
  #else
COLOR_RED:                                              // modified color table
        .byte   0x00, 0x03, 0x05, 0x07, 0x09, 0x0B, 0x0D, 0x0F
COLOR_BLUE:
        .byte   0x00, 0x08, 0x0B, 0x0F
  #endif
#endif
        .section .text

Dazu muß dies aber auch noch beim Setzen der Farben angegeben werden:
    ldi    P3L, 1                   // Read from flash
    ldi    P3H, 0
    rcall   glcdDisplaySetColors


Für die ISR habe ich nur das was im Listing steht (da ich ja die Makros 
verwende):
00013966 <__vector_20>:
   13966:  a4 9a         sbi  0x14, 4  ; 20
   13968:  0f 93         push  r16
   1396a:  0c b5         in  r16, 0x2c  ; 44
   1396c:  0f 7b         andi  r16, 0xBF  ; 191
   1396e:  0c bd         out  0x2c, r16  ; 44
   13970:  0f 91         pop  r16
   13972:  18 95         reti

BTW: Ich gehe davon aus, das Hagen hier nichts mehr dran macht (hatte 
mal sowas gelesen). Dennoch noch mal Danke an ihn (auch für die Hilfe 
damals!).

Volkmar

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>BTW: Ich gehe davon aus, das Hagen hier nichts mehr dran macht (hatte
>mal sowas gelesen). Dennoch noch mal Danke an ihn (auch für die Hilfe
>damals!).

naja ist ja auch schon wieder par Jahre her und zudem gabs danach das 
bessere S65 Display.

Gruß Hagen

Autor: Sven T. (svent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
apropos S65......
Hat irgendjemand noch welche davon ?
Ich find nirgends ne Bezugsquelle und brauch etwa 5 Stück,

Sven

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> naja ist ja auch schon wieder par Jahre her und zudem gabs danach das
> bessere S65 Display.

Wie man sieht, gibt es aber dennoch weitere Verwendung für das betagte 
6100-Display ;)

> apropos S65......
> Hat irgendjemand noch welche davon ?
> Ich find nirgends ne Bezugsquelle und brauch etwa 5 Stück,

Das gehört nun wirklich nicht hierher! (Das 6100 gibt es noch...)

Volkmar

Autor: Sven T. (svent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volkmar
Man möge mir verzeihen hier eine Frage gestellt zu haben die sich auf 
etwas ähnliches bezieht.

Wobei ich nicht ganz nachvollziehen kann weshalb der Kommentar, dass das 
S65 das bessere Display sei hierher gehlrt, die Frage nach einer 
möglichen Bezugsquelle jedoch nicht.

Naja...

Sven

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar, hallo Hagen,

war ein paar Tage abgetaucht. Hatte eine Menge Zeugs um die Ohren :o. 
Jetzt habe ich hoffentlich wieder etwas mehr Zeit.

Ja, das 6100er Display gibt es noch. Z.B. hier für 8€:

http://www.centralshop24.com/nokia-6610-7210-display.html

Die Änderung an der ISR gehen so wie sie Volkmar gemacht hat leider 
nicht gut, da man auch noch das SFR retten muss wenn in einem Register 
ein "and" ausführt. Hierzu muss ein weiteres Register auf den Stack 
gerettet werden um dann das SFR in diesem Register zwischenzuspeichern. 
Das macht dann 4 Zyklen mehr für die ISR. Volkmar, du musst eigentlich 
ziemliche Schwierigkeiten mit seiner SW haben wenn Du diesen Fehler in 
Deinem Code drin hast.

Darum habe ich in meiner ISR ganz auf das Abschalten der SPI in der ISR 
verzichtet. Dies hat dann schließlich zu meinen etwas massiveren 
Änderungen geführt.

Wenn Hagen den Code übernimmt wie ich ihn gemacht habe, sollte dies auch 
in weiten Teilen für die "kleinen" Controller funktionieren. Dazu müsste 
man das Deaktivieren der SPI allerdings noch in die Funktion 
glcdDispSend() verlegen. (Würde ich machen, nur Hagen müsste dies dann 
eben prüfen). Damit sollten dann einige #if-Anweisungen verschwunden 
sein.

In glcdDispSend() musste ich noch das Register T0 retten, da ich dies 
benötige, um auf die SPI zuzugreifen. Bei Hagen war T0 in dieser 
Funktion unverändert und andere Funktionen gehen davon aus, dass dem 
auch tatsächlich so ist. Volkmar, dies dürfte Dir ebenfalls auch 
Schwierigkeiten bereiten.

Die Sache mit den Farben konnte sehr elegant in der Initialisierung 
lösen. Da wird nämlich explizit das Bit MEM_RGB gesetzt. Dieses schaltet 
von RGB auf BGR um. Und dieses Bit braucht mein Display einfach nicht.

Ich denke meine Lösungen sind nicht so schlecht. Wäre doch schön, wenn 
es nochmal eine neue Version der libglcd geben würde, zumal die Displays 
zur Zeit zum Schleuderpreis zu haben sind.

Ralph

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralph:

tut mir leid aber ich arbeite an diesem Projekt, wie gesagt, seit Jahren 
nicht mehr.

Gruß Hagen

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen,

schade. Ist es für Dich i.O. wenn ich mit meinen Änderungen eine Version 
2.3 zusammenstelle und hier anbiete?

@Andere

Gibt es sonst jemandem der gerade aktiv an dem Display dran ist und mit 
den "kleinen" Atmegas arbeitet?

Ralph

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>schade. Ist es für Dich i.O. wenn ich mit meinen Änderungen eine Version
>2.3 zusammenstelle und hier anbiete?

Natürlich ist das ok, bitte tue dir keinerlei Zwang an, davon lebt freie 
Software.

Gruß Hagen

Autor: Ralph Scharpf (schwabe68)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so, wie versprochen hier meine Version der libglcd. Hat noch ein 
bisschen gedauert, da ich meinen Octopus erst man auf 16MHz trimmen 
musste und nach wie vor ziemlich unter Last bin.

Ich habe an der Lib folgendes geändert:

- Optimized glcdDisplayInit(). I hope it works for everybody.
- Support for RGB and BGR memory color ordering.
- Changes to support controllers with SPI-Registers outside the lower 
I/O
  addresses (up to 0x1f).
- Renamed macro XTAL into F_CPU. F_CPU is commonly used inside avr-libc.
- Corrected bugs that cause compile errors with recent avr-gcc. (gcc-
  Version 4.3.)
- Corrected reading of display registers !CS was set inactive after 
sending
  a command. This aborted the read command at display and no data was 
sent.
  Now the command sequence is done manually without SPI use. In order
  to solve this I also had to change the glcdDisplayRead() function.

  WARNING: glcdDisplayRead() will now take the real amount of bits sent
  from display not the amount + 1.

- Added output of display ID in test program. Perhaps this enables the
  library to detect the display type in future.
- Optimized glcdDisplayOn(). A short wait before the request of status
  register helps my display to start.

ACHTUNG: Die Funktion glcdDisplayRead() akzeptiert jetzt 2 Parameter und
         die Anzahl an zu lesenden Bits wird exakt angegeben (Für 32 Bit
         wird jetzt 32 angegeben und NICHT mehr 33)

Ich hoffe diese Version hilft an einigen Stellen die Problemchen zu 
beheben. Bitte gebt mir Rückmeldungen zu der neuen Version! Ich konnte 
diese leider nicht mit der (neuen) Option SPI_IN_LOWER_IO_REGS prüfen.

Wenn die neue Version bei Euch so tut wie bei mir, dann würde ich diese 
Version gerne als 2.3 herausgeben.

Gruß

Ralph

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich kann gerne Deine Version testen, es wird aber noch einige Tage 
dauern. Aber ich denke, so eilig ist es mit einer Version 2.3 ja auch 
nicht. Desweiteren bin ich gerade dabei die Performance bei den 
Schriften zu erhöhen (auf Kosten von Speicher). Ich hatte mir dazu 
überlegt einen Compile-Switch einzubauen, mit dem man zwischen beiden 
Varianten umschalten kann. Sowas könnte doch auch noch mit rein (ist 
aber noch nicht fertig).

Gruß
Volkmar

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar,

klingt prima. Ich habe mich bisher noch nicht über die Font-Geschichten 
gekümmert. Wenn Du hier ein paar gute Ideen hast, kommt die lib 
tatsächlich deutlich voran.

Achte aber auf die Register, die Du zusätzlich verwendest. Man muss 
immer prüfen, welche Register von aufrufenden Funktionen noch genutzt 
sind.

Grüße

Ralph

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Volkmar:

wie gedenkst Du die Performance zu erhöhen ?

Die innerste Schleife sollte in durchschnittlich 16 takten das nächste 
Datenbyte an/für das SPI gesendet/berechnet haben. Das SPI benötigt bei 
vollem Datendurchsatz exakt 16 MCU Takte zum raussenden. Die SPI Routine 
wurde so programmiert das sie sofort zum "Aufrufer" zurückkehrt. Alles 
in Allem sollte also jetzt schon die innerste Schleife der 
Fontzeichenroutine, die übrigens mit ca. 90% die Hauptarbeit macht, 
optimal schnell sein. Eine weitere Beschleunigung dieser Schleife würde 
nur bedeuten das diese Schleife Waitstates beim Warten auf das SPI 
einlegen würde.

Optimiert man den äußersten Part der Fontroutine, also zb. die 
Berechungen zum ASCII->Bitmap wandeln dann beträfe das eben nur die 
letzten 10-20%.

Das ist übrigens der Grund warum ein komprimierter Font effizienter 
dargestellt werden kann als ein unkomprimierter, obwohl der 
Berechnungsaufwand durch die Dekomprimierung eigentlich höher ist.

In der ASM Version der Nokia Lib. sehe ich kein Optimierungspotential 
mehr da ich dort schon in meinen Augen das Optimum rausgeholt habe. 
Falls du also gedenkst den Font bei der Selektion vom FLASH in den SRAM 
zu entpacken dann wird das letzendlich nur Resourcenverschwendung sein 
und nichts an der jetzigen Performance verbessern. Deswegen meine Frage 
an Dich zum Wie.

Der Flaschenhals ist letzendlich die SPI Hardware. Es gilt immer die 
Regel 16 MCU Takte sind Zeit bis ein Byte rausgeschoben wurde. Somit 
verbleiben bei clevrer Programmierung, eg. im Hintergrund des SPI 
Tranfser läuft die Software weiter, ca. 14 Takte für Berechnungen. Die 
jetzige innerste Schleife benötigt nicht mehr als diese 14 Takte. Ergo: 
schneller als 8MByte bei 16MHz Takt ist nicht drinnen. Wenn die 
Fontroutine mit 8MBytes Pixel setzt ist das Limit erreicht. Und dieses 
Limit ist fast erreicht mit der aktuellen Version.


Gruß Hagen

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hagen,

dem kann ich nur bedingt zustimmen. Tatsächlich werden von den 16 zur 
Verfügung stehenden CPU-Zyklen bereits 9 für die Verarbeitung des 
Interrupts benötigt. Da bleiben dann nur noch 7. Selbst wenn man einen 
Controller hat, auf dem die SPI in den unteren I/O Registern gemappt 
ist, benötigt man fast das dreifache (20 Zyklen).

Ich habe darum auch bereits darüber nachgedacht, auf den Interrupt zu 
verzichten, da die ISR ohnehin nichts Bedeutendes macht. Auch das 
permanente  Setzen und wieder Löschen des !CS-Signals könnte man sich 
dann sparen, wodurch das ganze nochmals beschleunigt werden würde (und 
die Probleme beim Lesen vom Display wären ebenfalls weg). Das spart dann 
durchaus 10-Zyklen (ca. 600ns) pro gesendetem Byte. Zur Zeit werden in 
glcdDispData() 20 Zyklen pro Byte benötigt. Zusammen mit der ISR 29. 
Wenn man 10 spart ist das nicht unerheblich!

Um das zu machen, könnte man einfach das SPIF Flag direkt im SPI 
Register abfragen. Dieses wird nach einer Anfrage gelöscht, sobald das 
nächste Byte gesendet wird. Sollte also gehen. Man könnte allerdings 
einmalig in der Initialisierung ein Dummy-Byte senden, um das Flag 
initial gesetzt zu bekommen.

Alternativ könnte man die Zeit auch einfach als vergangen ansehen. 16 
Zyklen sind ruck zuck vorbei. Selbst wenn man auf die ISR verzichtet und 
das Warten auf die SPI in glcdDispData() herausnimmt, bleiben noch 17 
Zyklen übrig. Und das ist immerhin einer mehr als die SPI braucht, um 
das Byte zu senden!

Was hältst Du davon?

Grüße

Ralph

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

dann hätte ich gleich noch einen...

Ich habe mir 10 Nokia-Display auf Vorrat bestellt, beim selben 
Hersteller wie meine ersten beiden. Die Displays kamen heute an. 7 waren 
Baugleich (braune Folie, gehen), 3 hatten eine grüne Folie und gehen 
nicht :(

Ich denke mal da ist jetzt der Epson-Controller drin. Hat noch 
irgendeiner einen Testcode (am besten in C, geht schneller) für die 
Epson-Controller?

Gruß

Ralph

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Da ich unterwegs bin nur in wenigen Worten. Es gibt einen Teil bei dem 
die Position der eigentlichen Font-Daten bestimmt wird. Diese Routine 
addiert jedesmal alles vorherigen Zeichenbreiten. Dieser Teil kostet 
gerade bei hinteren Zeichen viel Zeit. Das würde ich einmalig beim 
Festlegen des Fonts im RAM ablegen, kostet halt 512 Byte. Flash wäre 
auch nicht schlecht, aber dafür müsste ich den Font-Editor ändern, was 
ich nicht kann.

Gruß Volkmar

Autor: Ralph Scharpf (schwabe68)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal @Hagen,

Von den 20 Zyklen für glcdDispData() sind 9 zwischen SPI disable und SPI 
start. Diese darf man also nicht zählen. Somit geht es ohne Warten auf 
die SPI doch nicht. Ich eine Version gemacht, in der ich auf die ISR 
verzichte. 6 NOPs in glcdDispSend() genügen, damit die Bibliothek wieder 
läuft.

Dabei ist mir aufgefallen, dass ich einen Fehler in der Initialisierung 
eingebaut hatte. Das SPI2X Flag wurde nicht korrekt gesetzt. Ich hatte 
zunächst 22 NOP benötigt.

Entfallen sind nun die ISR (9 Zyklen) und das Warten auf das löschen des 
CS-Signals (mind. 2 Zyklen, wenn Loop aktiv + 3 Zyklen/Loop). Es 
entfallen also mindestens 11 Zyklen. Also in diesem schnellen Hack sind 
bereits 5 Zyklen gespart.

Gruß

Ralph

Autor: Ralph Scharpf (schwabe68)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

jetzt habe ich noch ein bisschen experimentiert und mit dem Testprogramm 
Laufzeiten ermittelt:

Laufzeit Test mit ISR: ca. 70 Sekunden
Laufzeit ohne ISR, warten auf SPIF-Bit: 59s
Laufzeit ohne ISR, NOP-Warten: 54s

Jetzt könnte man noch das toggeln des CS-Signals einsparen, dann wäre 
man wohl unter 50s. Auf die Schnelle hat dies aber dann doch nicht 
funktioniert. Durch das Toggeln des CS-Signals wird eben die Adresslogik 
im Display immer wieder in den Ausgangszustand versetzt. Das schein wohl 
notwendig zu sein zu sein.

Interessant finde ich, dass die NOP-Lösung die schnellste ist. Ich 
erkläre dies damit, dass wenn die Wait-Loop einmal zurückspringt, mehr 
als die 4 noch übrigen NOPs benötigt werden. Und dies scheint wohl öfter 
der Fall zu sein.

Angehängt die dafür geänderten Dateien, auf Basis meiner Quellen vom 
27.01.11. Da ich jetzt ziemlich viele #ifdef Präprozessordirektiven drin 
habe, sollte man sich besser ganz für oder ganz gegen die ISRs 
entscheiden. Das mit dem NOP-Timing sollte optional bleiben, falls 
jemand die SPI mit einem kleineren Takt betreiben möchte.

Bitte gebt zu diesem Thema Eure Meinungen ab!

Gruß

Ralph

P.S.: Hat noch jemand den Code für die Epson-Controller?

Autor: Ralph Scharpf (schwabe68)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das CS-Toggeln habe ich jetzt auch noch herausoptimiert. Ohne das 
Toggeln bekommt aber die Adresslogik im Display keine Resets mehr. Wenn 
also einmal schief gelaufen ist dürfte diese dann für immer hängen. Nach 
einem Lesen muss in jedem Fall das CS getoggelt werden. Das war gestern 
noch die Schwiegigkeit.

Beim Benchmark konnten so nochmals 5s geholt werden. Das Testprogram 
benötigt für den ersten Durchlauf jetzt nur noch 49s. Pro Instruktion in 
glcdDispSend() werden also ca. 3s beim Benchmark eingespart. Bevoe ich 
gestartet habe hat das Testprogramm noch 70s benötigt.

Dafür gibt es jetzt ein weiters #define. Die Übersichtlichkeit ist damit 
völlig futsch. Da kommt #if nach dem anderen. Wenn man diesen Code in 6 
Wochen nochmals ansieht versteht man nichts mehr :o

Es muss also dringend aufgeräumt werden! Darum meine Frage: Welche der 
neuen Optionen sollten optional bleiben?

Gruß

Ralph

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ralph Scharpf schrieb:
> Interessant finde ich, dass die NOP-Lösung die schnellste ist. Ich
> erkläre dies damit, dass wenn die Wait-Loop einmal zurückspringt, mehr
> als die 4 noch übrigen NOPs benötigt werden. Und dies scheint wohl öfter
> der Fall zu sein.

Naja, das läßt sich wie folgt erklären: Abgesehen von Interrupts, die 
zwischendurch auftauchen können, gibt es ja immer eine festen Ablauf im 
µC. Und dann entsteht immer der gleiche Zeitversatz. Mit den NOPs kannst 
Du es Takt-Genau einstellen, mit der Schleife ist das Raster halt größer 
als 1.

Ralph Scharpf schrieb:
> Es muss also dringend aufgeräumt werden! Darum meine Frage: Welche der
> neuen Optionen sollten optional bleiben?

Im Moment (ohne in die Sourcen zu schauen) habe ich den Überblick etwas 
verloren ;) Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am 
SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines 
glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders 
verwendet werden kann.

Ralph Scharpf schrieb:
> Das mit dem NOP-Timing sollte optional bleiben, falls
> jemand die SPI mit einem kleineren Takt betreiben möchte.

Hier stimme ich auf jeden Fall zu. Eventuell könnte man überlegen noch 
eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option 
verwendet werden soll und der SPI-Takt nicht auf das Schnellste 
eingestellt ist.

Gruß
Volkmar

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Volkmar schrieb:

> Ralph Scharpf schrieb:
>> Es muss also dringend aufgeräumt werden! Darum meine Frage: Welche der
>> neuen Optionen sollten optional bleiben?
>
> Im Moment (ohne in die Sourcen zu schauen) habe ich den Überblick etwas
> verloren ;)

Ok, kurze Erklärung: Es gibt zurzeit 3 neue Makros in glcd.inc. Diese 
sind:

1. USE_ISR

Wenn das Makro gesetzt ist, wir die SPI-ISR wie ursprünglich von Hagen 
umgesetzt verwendet. Wenn diese Makro gesetzt ist, sind die anderen 
beiden folgenden ohne Funktion bzw. sollten nicht aktiviert werden. 
Laufzeit des Testprogramms mit ISR: 70s, ohne ISR: 59s

2. SPI_NOP_WAIT

Wartet nicht in einer Loop bis die SPI fertig ist, sondern verwendet ein 
paar NOPs um die überschüssige Zeit zu verbrauchen. Laufzeit des 
Testprogramms mit dieser Einstellung: 54s

3. TOGGLE_CS

Jetzt hat man noch die Möglichkeit, die CS-Leitung nicht nach jeder 
Übertragung zu deaktivieren und am Beginn wieder zu aktivieren, sondern 
das CS einfach stehen zu lassen. Das Spart dann nochmals 2 Zyklen. 
Laufzeit des Testprogramms mit dieser Einstellung: 49s

> Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am
> SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines
> glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders
> verwendet werden kann.

Wie wäre es hier mit einem separaten Aufruf. Wenn die SPI auf ein 
anderes Device wechseln soll, wird in dieser Funktion einfach das CS 
weggenommen. Hinterher kann man dann wieder durch einen weiteren Call 
das Display wieder ansprechen. Sollte ein Zweizeiler sein. Darin könnte 
man dann auch die SPI-Einstellungen wieder herstellen, falls das andere 
Device hier z.B. einen kleineren Takt verlangt.

Hast Du irgendwelche sonstigen Abhängigkeiten. Bisher wurde ja eine ISR 
verwendet. Hattest diese dann angepasst? Ansonsten sollte es doch ohne 
ISR eigentlich einfacher sein, noch ein weiteres Device anzuschließen.

>
> Ralph Scharpf schrieb:
>> Das mit dem NOP-Timing sollte optional bleiben, falls
>> jemand die SPI mit einem kleineren Takt betreiben möchte.
>
> Hier stimme ich auf jeden Fall zu. Eventuell könnte man überlegen noch
> eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option
> verwendet werden soll und der SPI-Takt nicht auf das Schnellste
> eingestellt ist.

So eine Prüfung Macht aber ziemliche Mühe. Dann lieber optional zum 
Aktivieren bei Bedarf und per Default die sicheren Einstellungen.

Wenn niemand an der ISR "hängt", würde ich vorschlagen auf diese zu 
verzichten. Dann sollte der Code wieder deutlich übersichtlicher werden. 
Die anderen Optionen würde ich drin lassen. Wenn man ein zickiges 
Display hat ist es gut, wenn CS toggelt und SPI_NOP_WAIT ist während 
einer Inbetriebnahme auch nicht das was man haben möchte.

Gruß

Ralph

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kurzes Update von mir.

Ralph Scharpf schrieb:
>> Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am
>> SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines
>> glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders
>> verwendet werden kann.
>
> Wie wäre es hier mit einem separaten Aufruf. Wenn die SPI auf ein
> anderes Device wechseln soll, wird in dieser Funktion einfach das CS
> weggenommen. Hinterher kann man dann wieder durch einen weiteren Call
> das Display wieder ansprechen. Sollte ein Zweizeiler sein. Darin könnte
> man dann auch die SPI-Einstellungen wieder herstellen, falls das andere
> Device hier z.B. einen kleineren Takt verlangt.

Ja, ich denke mit einem separaten Aufruf wäre das gut zu lösen. In 
meinem Projekt mußten die SPI-Einstellungen (z.B. die Taktlage) zwischen 
den beiden Devices gewechselt werden.

Ralph Scharpf schrieb:
>> Eventuell könnte man überlegen noch
>> eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option
>> verwendet werden soll und der SPI-Takt nicht auf das Schnellste
>> eingestellt ist.
>
> So eine Prüfung Macht aber ziemliche Mühe. Dann lieber optional zum
> Aktivieren bei Bedarf und per Default die sicheren Einstellungen.

Man könnte die SPI-Frequenz in ein #define packen und dann anhand der 
defines den Compiler-Fehler auswerfen. Sollte nicht aufwändig sein.

Ralph Scharpf schrieb:
> Wenn niemand an der ISR "hängt", würde ich vorschlagen auf diese zu
> verzichten. Dann sollte der Code wieder deutlich übersichtlicher werden.

Die ISR sehe ich auch nicht als notwendig an. Von mir aus kann sie raus.

Dann habe ich noch eine Frage zu Deinen Messungen. Für die Messungen 
hast Du 'cnt' auf 1 gesetzt, oder? Mit meiner Lib (Deine konnte ich noch 
nicht testen, siehe unten) komme ich sonst da überhaupt nicht hin, und 
das könnte ich mir nicht anders erklären.
Ich denke, es macht Sinn das Testprogramm etwas zu erweitern und eine 
kleine Zeitmessung einzubauen. Ebenso sollte man über die Gewichtung 
nachdenken, die Rechtecke haben im Moment einen ziemlich hohen Anteil, 
die Linien würde ich höher als jetzt gewichten, Ellipsen sind OK, die 
werden bestimmt nur selten benutzt. Texte sind total unterrepräsentiert.

Und nun noch zu dem Punkt, warum Deine Lib bei mir bisher nicht läuft: 
Aufgrund vorgegebener HW liegen Reset und CS nicht am selben Port wie 
SCL und SDA. D.h. ich muß hier noch die Routinen anpassen, damit diese 
Werte auf anderen Ports geschrieben werden können.
Damit leidet die Übersichtlichkeit noch mehr :(

Gruß Volkmar

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar,

Volkmar schrieb:
> Hallo,
>
> kurzes Update von mir.
>
> Ralph Scharpf schrieb:
>>> Wichtig wäre mir, daß in jedem Fall ein weiteres Gerät am
>>> SPI bedient werden kann. D.h. zumindest am Ende der Bearbeitung eines
>>> glcd-Befehls sollte alles so abgeschlossen sein, daß der SPI auch anders
>>> verwendet werden kann.
>>
>> Wie wäre es hier mit einem separaten Aufruf. Wenn die SPI auf ein
>> anderes Device wechseln soll, wird in dieser Funktion einfach das CS
>> weggenommen. Hinterher kann man dann wieder durch einen weiteren Call
>> das Display wieder ansprechen. Sollte ein Zweizeiler sein. Darin könnte
>> man dann auch die SPI-Einstellungen wieder herstellen, falls das andere
>> Device hier z.B. einen kleineren Takt verlangt.
>
> Ja, ich denke mit einem separaten Aufruf wäre das gut zu lösen. In
> meinem Projekt mußten die SPI-Einstellungen (z.B. die Taktlage) zwischen
> den beiden Devices gewechselt werden.

Ich mache hierzu einen Vorschlag!

>
> Ralph Scharpf schrieb:
>>> Eventuell könnte man überlegen noch
>>> eine Überprüfen einzubauen, die einen Fehler auswirft, wenn diese Option
>>> verwendet werden soll und der SPI-Takt nicht auf das Schnellste
>>> eingestellt ist.
>>
>> So eine Prüfung Macht aber ziemliche Mühe. Dann lieber optional zum
>> Aktivieren bei Bedarf und per Default die sicheren Einstellungen.
>
> Man könnte die SPI-Frequenz in ein #define packen und dann anhand der
> defines den Compiler-Fehler auswerfen. Sollte nicht aufwändig sein.

Man hat eben in der SPI mehrere Register die berücksichtigt werden 
müssen. Letztlich muss eben das SI2X gesetzt werden und der Clock auf 
Maximum stehen. Aber das sind Register-Werte. Die Frequenz selbst ist 
egal. Es kommt nur auf den Teiler an. Wenn hier jemand einfach mal 
andere Werte setzt um evtl. Probleme zu beheben geht es eben schief. 
Darum würde ich darauf verzichten.

>
> Ralph Scharpf schrieb:
>> Wenn niemand an der ISR "hängt", würde ich vorschlagen auf diese zu
>> verzichten. Dann sollte der Code wieder deutlich übersichtlicher werden.
>
> Die ISR sehe ich auch nicht als notwendig an. Von mir aus kann sie raus.

Ok, auch das werde ich machen...

>
> Dann habe ich noch eine Frage zu Deinen Messungen. Für die Messungen
> hast Du 'cnt' auf 1 gesetzt, oder?

Ich habe im Testprogramm noch eine Ausgabe der Display-ID drin. Danach 
geht der Test los. Ich messe ab dem Beginn mit den Rechtecken bis zum 
Ende der laufenden Steifen, also bevor das Display in die 4 Teile 
geteilt wird. Hinter diesem letzten Test scheint sich ein Delay zu 
befinden. Darum habe ich diesen Teil nicht mitgemessen.

>Mit meiner Lib (Deine konnte ich noch
> nicht testen, siehe unten) komme ich sonst da überhaupt nicht hin, und
> das könnte ich mir nicht anders erklären.
> Ich denke, es macht Sinn das Testprogramm etwas zu erweitern und eine
> kleine Zeitmessung einzubauen. Ebenso sollte man über die Gewichtung
> nachdenken, die Rechtecke haben im Moment einen ziemlich hohen Anteil,
> die Linien würde ich höher als jetzt gewichten, Ellipsen sind OK, die
> werden bestimmt nur selten benutzt. Texte sind total unterrepräsentiert.

Stimmt! Hinterher wäre eine Zusammenfassung auf dem Display auch spitze. 
10s anzeigen, dann weitermachen.

>
> Und nun noch zu dem Punkt, warum Deine Lib bei mir bisher nicht läuft:
> Aufgrund vorgegebener HW liegen Reset und CS nicht am selben Port wie
> SCL und SDA. D.h. ich muß hier noch die Routinen anpassen, damit diese
> Werte auf anderen Ports geschrieben werden können.
> Damit leidet die Übersichtlichkeit noch mehr :(

Da schlage ich vor, das eine Makro für LCD_PORT durch 3 zu ersetzten. 
Die SPI-Pins dürften ja immer am gleichen Port hängen. Wenn Du möchtest, 
kann ich dies auch gleich machen. Ich schlage die Makros vor 
LCD_SPI_PORT, LCD_CS_PORT und LCD_RES_PORT. Sollte an der 
Übersichtlichkeit nicht viel ändern. Kann man durch suchen und ersetzten 
machen. Suche "LCD_PORT, LCD_CS", ersetze durch "LCD_CS_PORT, LCD_CS".

Gruß Ralph

Autor: Volkmar (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ralph Scharpf schrieb:
>> Dann habe ich noch eine Frage zu Deinen Messungen. Für die Messungen
>> hast Du 'cnt' auf 1 gesetzt, oder?
>
> Ich habe im Testprogramm noch eine Ausgabe der Display-ID drin. Danach
> geht der Test los. Ich messe ab dem Beginn mit den Rechtecken bis zum
> Ende der laufenden Steifen, also bevor das Display in die 4 Teile
> geteilt wird. Hinter diesem letzten Test scheint sich ein Delay zu
> befinden. Darum habe ich diesen Teil nicht mitgemessen.

OK, ich habe zwischenzeitlich einen Fehler bei mir gefunden. Nun stimmen 
die Durchläufe.

Ralph Scharpf schrieb:
> Stimmt! Hinterher wäre eine Zusammenfassung auf dem Display auch spitze.
> 10s anzeigen, dann weitermachen.

Ich habe mal einen Benchmark erstellt (in test.c), die Zahlen am Ende 
werden pro Disziplin angezeigt. Es sind die Anzahl der Takte geteilt 
durch 64. Die Werte sind reproduzierbar.

Ralph Scharpf schrieb:
> kann man durch suchen und ersetzten
> machen. Suche "LCD_PORT, LCD_CS", ersetze durch "LCD_CS_PORT, LCD_CS".

Das Problem hierbei ist, daß die Ports nicht alle direkt 
bit-adressierbar sind und somit auch die in/out-Konstruktion benötigt 
wird. Habe ich ja soweit für mich schon umgesetzt.

Anbei ein Satz der Änderungen, ich hoffe ich habe alle drin ;) Bei der 
Test.c habe ich noch weiter Rücksicht auf die HW nehmen müssen (wie zB. 
Hintergrundbeleuchtung einschalten, Ausschalten des Gerätes nach Ablauf 
des Benchmarks). Insgesamt ist es sicherlich auch nicht optimal/schön 
programmiert (zu wenig Zeit).

Was mir auch dabei noch aufgefallen war, bei mir passte die Funktion für 
die Orientierung nicht. Die hatte ich angepaßt, scheinbar gibt es hier 
zwei verschiedene Typen (habe ein braunes Display). Habe die Änderungen 
in glcd03.S eingetragen.

Gruß
Volkmar

Autor: Ralph Scharpf (schwabe68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Volkmar,

ich hatte inzwischen einige Probleme mit meinen Änderungen. Zunächst 
hatte ich nur veruscht, die Änderungen an glcdDisplayOff() zu prüfen, 
was das ganze Display durcheinandergebracht hat. Dann habe ich weiter 
experimentiert und habe alle möglichen Störungen auch in anderen 
Routinen entdeckt. Mein Ergebnis: Das Toggeln der CS-Leitung wird 
einfach doch benötigt!

Volkmar schrieb:
> Ich habe mal einen Benchmark erstellt (in test.c), die Zahlen am Ende
> werden pro Disziplin angezeigt. Es sind die Anzahl der Takte geteilt
> durch 64. Die Werte sind reproduzierbar.

Ich kam noch nicht dazu, mir die Sache genau anzusehen. Aber die Ausgabe 
ist recht umstandlich. Ich hatte dies zuvor auch so gemacht, inzwischen 
bin ich aber auf itoa und ltoa gestoßen. Siehe 
http://www.nongnu.org/avr-libc/user-manual/group__...

>
> Ralph Scharpf schrieb:
>> kann man durch suchen und ersetzten
>> machen. Suche "LCD_PORT, LCD_CS", ersetze durch "LCD_CS_PORT, LCD_CS".
>
> Das Problem hierbei ist, daß die Ports nicht alle direkt
> bit-adressierbar sind und somit auch die in/out-Konstruktion benötigt
> wird. Habe ich ja soweit für mich schon umgesetzt.

Du liegst doch mit den Ports auf PortG. Dieser ist bein meinem 
Controller noch in den unteren Adressen (PING@0x12, DDRG@0x13, 
PORTG@0x14). Sind die Port-Register nicht immer in die unteren Adressen 
gemappt?

>
> Anbei ein Satz der Änderungen, ich hoffe ich habe alle drin ;) Bei der
> Test.c habe ich noch weiter Rücksicht auf die HW nehmen müssen (wie zB.
> Hintergrundbeleuchtung einschalten, Ausschalten des Gerätes nach Ablauf
> des Benchmarks). Insgesamt ist es sicherlich auch nicht optimal/schön
> programmiert (zu wenig Zeit).

Wie gesagt, bin noch am Zusammenführen mit meinen letzten Änderungen. 
Melde mich wenn ich fertig bin. Mache dann auch nochmal ein Archiv.

>
> Was mir auch dabei noch aufgefallen war, bei mir passte die Funktion für
> die Orientierung nicht. Die hatte ich angepaßt, scheinbar gibt es hier
> zwei verschiedene Typen (habe ein braunes Display). Habe die Änderungen
> in glcd03.S eingetragen.

Bei mit gingen nur die Orientierungen 90° und 270°. Mit deinen 
Eintstellungen in glcd.inc geht das jetzt! glcd03.S muss ich noch 
prüfen. Kommt auch morgen dran...

Gruß

Ralph

Autor: Volkmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph Scharpf schrieb:
> Ich kam noch nicht dazu, mir die Sache genau anzusehen. Aber die Ausgabe
> ist recht umstandlich. Ich hatte dies zuvor auch so gemacht,

Deswegen hatte ich ja vorher geschrieben: "Insgesamt ist es sicherlich 
auch nicht optimal/schön programmiert (zu wenig Zeit).". ;)
Hatte halt Deine Zeilen mit Copy/Paste übernommen. Eigentlich nutze ich 
dafür gerne dir printf-Varianten ...

Ralph Scharpf schrieb:
> Du liegst doch mit den Ports auf PortG. Dieser ist bein meinem
> Controller noch in den unteren Adressen (PING@0x12, DDRG@0x13,
> PORTG@0x14).

Hmmm, irgendwie hast Du recht. Frag mich nicht, warum ich das so 
gemacht/gedacht habe. Scheint doch zu gehen ;)

Da ich leider meinen (eher fliegenden) Aufbau erneuern muß, wird es nun 
einige Tage dauern, bis ich daran weitermachen kann.

Gruß
Volkmar

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.