Library für EA-DOGM Grafikdisplays inkl. Font-Generator

Danke für das Interesse an meiner Bibliothek! Hier kommt ein Update mit 
einigen neuen Funktionen. Einige davon stammen von Oliver Schwaneberg, 
bei dem ich mich herzlich bedanken möchte.

Neue Funktionen in dogm-graphic.c:
- "Chip Select" Pin des Displays wird unterstützt.
- Benutzung von Beleuchtung und Chip Select sind optional und können in 
dogm-graphic.h an- und abgewählt werden
- Funktion lcd_draw_image_P: Zeichnet ein Bild mit x*y Pixeln aus 
Rohdaten im Flash an die aktuelle Cursorposition
- Funktion lcd_draw_image_xy_P: Zeichnet ein Bild mit x*y Pixeln aus 
Rohdaten im Flash an die angegebenen Pixelkoordinaten. Verschiebung is 
pixelgenau möglich.
- Initialisierung von SPI wird von der lcd-init Routine übernommen. Eine 
eigene Funktion mit den nötigen Befehlen kann in dogm-graphic.h 
spezifiziert werden

Neue Funktionen in font.c:
- Text kann auch invertiert dargestellt werden
- Text wird (optional) in die nächste Zeile umgebrochen
- Funktionen zur direkten Ausgabe von int, long int und float 
hinzugefügt. Wegen des großen Platzbedarfs können diese einzeln in 
font.h an-/abgewählt werden
- put_string* und put_char* Funktionen geben die Breite des ausgegebenen 
Texts zurück

Die Funktionen, um einen Buchstaben oder einen String auszugeben sind:

1

uint16_t lcd_put_string       (FONT_P font, uint8_t style, char* str);

2

uint16_t lcd_put_string_P     (FONT_P font, uint8_t style, PGM_P str);

3

uint8_t  lcd_put_char         (FONT_P font, uint8_t style, unsigned char c);

Funktionen mit einem "_P" am Ende laden ihre Daten direkt aus dem Flash, 
die anderen aus dem RAM.

Das erste Argument ist immer die Schriftart. Zur Auswahl stehen 
FONT_FIXED_8, FONT_PROP_8, FONT_PROP_16, sowie zwei kleine Symbolsätze 
FONT_SYMBOL_8 und FONT_SYMBOL_16.
Welche davon eingebunden sind hängt davon ab, welche Zeilen in font.h 
unter "Select which of the available features will be included" nicht 
auskommentiert sind.

Das zweite Argument ist der Stil. Zur Auswahl stehen NORMAL, 
DOUBLE_WIDTH, DOUBLE_HEIGHT, INVERT (weiß auf schwarz) und WRAP (sorgt 
für Zeilenumbrüche in längerem Text). Diese Optionen können natürlich 
miteinander kombiniert werden. ("INVERT | WRAP" würde beispielsweise 
invertierten Text mit Zeilenumbrüchen erzeugen).

Das dritte Argument ist der auszugebende Text, also entweder ein Zeichen 
oder ein Pointer auf einen string im RAM oder Flash.


Ich hoffe, ich konnte dir damit helfen, ansonsten stell doch bitte 
deinen Code hier ein oder versuche genauer zu beschreiben wo du nicht 
weiter kommst.

Jan

Hallo GG,
für diese Anwendung würde ich dir vorschlagen, die Konfiguration über 
globale Variablen zu machen und einen wrapper die put_* Funktionen mit 
diesen globalen Variablen aufzurufen.

Also z.B. so

1

FONT_P global_font_select;

2

uint8_t global_font_style;

3

4

void font_set_config(FONT_P font, uint8_t style){

5

  global_font_select = font;

6

  global_font_style = style;

7

}

8

9

uint16_t putc_simple(char c) {

10

 return lcd_put_char(global_font_select,global_font_style,c);

11

}

Ja, das sehe ich auch gerade. Nimm in font.h einfach das "PROGMEM" aus 
der typedef von FONT_P raus:

>>typedef const struct font_info * FONT_P;

Wow, super! Läßt sich die Lib auch mit vertretbarem Aufwand an die DOGL 
und DOGXL Displays anpassen?

Grüße
Tom

Sollte sich aber wahrscheinlich auch anpassen lassen der DOGXL hat den 
Speicher halt dämlicherweise in 8-Pixel hohe spalten organisiert. wie 
die anderen DOGs das machen weiß ich nicht.
Tom

Hallo Thomas,
die DOGM haben auch diese Organisation. Die Beschreibung im Datenblatt 
der DOGL sieht identisch aus - von dieser Seite kein Problem, du musst 
nur die entsprechenden defines aendern.

Fuer die DOGXL sind mehr Aenderungen noetig, der Font-Generator wird 
aber sicher auch funktionieren.

@GG:
Kannst du mir deinen Code schicken? Dann wuerde ich ihn mit deiner 
Erlaubnis in die Library einbinden und hier demnaechst wieder hochladen.

Hallo Jürgen,
möchtest du eine proportionale oder eine monospaced Schrift?
Eine proportionale müsstest du dir mit Hagens Font-Generator selbst 
erstellen - das ist aber auch kein großer Aufwand.

Ich weiß nicht mehr, welche von Benedikts Font-Varianten die passende 
ist. Um das herauszufinden kannst du einfach die Daten in font_fixed_8px 
mit denen von Benedikts 5x8 Font vergleichen.

Die proportionale Schriftart würde dir einiges an Speicher sparen, 
insbesondere weil du einzelne unbenutzte Zeichen einfach aus dem Font 
entfernen kannst. Die 16x26 Font von Benedikt bräuchte ja schon ungefähr 
13kByte Speicher.

Eine kleine Beschränkung gibt es noch zu beachten: Die Höhe muss ein 
Vielfaches von 8 sein, da die Software immer komplette Bytes liest und 
ausgibt.

Außerdem wundert mich die Angabe "Font bits per pixel : 2" - die 
Schriftart muss in s/w sein, also mit einem Bit pro Pixel.


Wenn du den Font-Generator benutzt, ändere einfach die font.ini so, dass 
unter Export das template.h aus meinem zip-File angegeben ist, dann 
kuemmert sich die Software von alleine um alle nötigen Werte.

Dazu muss das Bild im selben Format vorliegen wie auch die Schriften, 
d.h. ein 8bit hoher Streifen von rechts nach links, und dann von oben 
nach unten.

In dogm-graphic.h muss  das define LCD_INCLUDE_GRAPHIC_FUNCTIONS gesetzt 
sein, damit lcd_draw_image_P() eingebunden ist.

Dort uebergibst du dann den Pointer auf das Bild im Flash, die Hoehe in 
pages, die Breite in Pixel. Style wirst du normalerweise auf NORMAL 
setzen (oder INVERTED). Das Bild hat die linke obere Ecke dann dort, wo 
der Cursor gerade steht, also dort, wo du vorher mit lcd_moveto_xy() 
hingegangen bist.

lcd_draw_image_xy_P() kannst du zusaetzlich noch die genaue Position auf 
dem Display in Pixeln uebergeben.

Ich habe die Funktion noch nie wirklich benutzt :-)

Beim Font-Generator ist ein Programm namens convert.exe dabei. Ich kann 
es hier gerade nicht testen, aber das koennte das sein was du suchst.

Hätte mich gewundert, wenn es hier im Forum keine passende Software 
dafür gäbe. "Laeubi" hat hier das richtige: 
Beitrag "Grafikkonverter Tool für AVR/Mikrocontroller (BMP2C, BMP2ASM, BMP2BASCOM)"
Die Version auf seiner Homepage hat auch direkt die Option um Dateien 
direkt für EA-DOG-Displays exportieren zu können.

Jürgen schrieb:
> gibt es ein programm das mir die bitmaps konvertiert oder ist hier
> handarbeit angesagt?
>
> hast du mir ein beispiel bitmap?

Hallöchen..

Hab das ganze etwas anders gelöst. Schau mal hier im CC2-Forum: 
http://www.cczwei-forum.de/cc2/thread.php?postid=50476#post50476

Gruß Rolf

Christian Sowada schrieb:
> Gibt es für dein Script sowas wie ein "Hallo Welt" Beispiel?

Das hast du schon fast komplett zusammen.

> Ich habe auch erstmal die Zeile geändert, richtig? Ist ja für UART ?!?!
>

1

//#define spi_wait_for_idle() while(! (UCSR1A & _BV(TXC1)));UCSR1A |=

2

> _BV(TXC1)

3

> #define spi_wait_for_idle() while(!(SPSR & (1<<SPIF)))

Ja, wenn das Display bei dir an der SPI-Schnittstelle hängt. Bei mir ist 
es die USART eines Atmega324, deswegen der andere Code

>
> Wie muß ich meiner main.c loslegen? So?
>
>

1

lcd_init();

2

> lcd_put_string(FONT_FIXED_8, NORMAL, "Hallo Welt");

Ja, das passt. ich würde aber empfehlen, den String in den Flash und 
nicht in den RAM zu packen:

1

lcd_put_string_P(FONT_FIXED_8, NORMAL, PSTR("Hallo Welt"));

>
> Was ich nicht ganz so durchschaue, ist die leere Funktion
> init_spi_lcd(). Die muss doch irgendwie mit Leben befüllt
> werden!?

Genau, diese Funktion habe ich nicht in der Library, sie hängt ja von 
der Hardware ab. Im wesentlichen sind die Einstellungen: SPI Mode 3 
(Setup (Falling) Sample (Rising)) und Frequenz ~ 1 MHz. Damit die 
Abfrage spi_wait_for_idle() richtig funktioniert, muss man meist zuerst 
eine "dummy"-Übertragung machen, also das Datenregister mit LCD_NOP 
laden.

> Nur ist alles horizontal gespiegelt!?!?!

Der Vollständigkeit halber hier der Link zur Fehlersuche
Beitrag "DOGM132 - Text horizontal gespiegelt."

Lösung: Bei der Initialisierung der seriellen Schnittstelle darf nicht 
eine 0 über SPI übertragen werden - als Dummywert immer LCD_NOP 
verwenden!

So, es ist Zeit für die nächste Version. Die Änderungen sind:

- Schriftart und -stil können global gesetzt werden, so dass die 
Funktionen lcd_putc, lcd_putstr u.a. nur mit dem auszugebenden Text als 
Parameter aufgerufen werden können.
- Neue Schriftart: 24px hohe / 16px breite Ziffern und Zahlensymbole
- Neuer Schriftstil: Unterstreichung

- Die Library sollte jetzt in der Lage sein, alle DOGS, DOGM und 
DOGL-Module zu initialisieren und anzusprechen. Die Initialisierung des 
DOGS102 konnte ich aber nicht testen mangels Display.

Falls jemand die Ausgabefunktionen für die DOGXL-Displays umzuschreiben 
möchte - ich bin gerne bereit zu helfen.

Hallo,

Dieses Code habe ich sozusagen "zu spät" gefunden, bereits was eigenes 
am Laufen. Auf einem (positiven) DOGM132W, soweit keine Probleme.

Dann hatte mich mit einem (negativen) DOGM128S "abgeplagt", der Kontrast 
war notorisch schlecht. Frustriert habe ich das erstmal beiseite gelegt, 
dem invertierten Display die Schuld gegeben, später ein positves 
DOGM128W gekauft, war aber auch flau.

Dann habe ich für eine zweite Meinung diesen Code ausprobiert. 
Funktionierte auch nicht, aber ich habe mich zumindest mal genauer damit 
beschäftigt, jetzt gehts!

Ich glaube, die Initialisierung ist doch noch typabhängiger als bisher 
codiert. Der originale Code liefert für ein DOGM132 ein gutes Bild, auf 
einem DOGM128 sieht man aber nichts.

Die Initialisierung habe ich jetzt beim DOGM128 sinngemäß so:
  LCD_SET_BIAS_RATIO_1_7();       //bias 1/7
  LCD_SET_POWER_CONTROL(7);       //power control mode: all features on
  LCD_SET_BIAS_VOLTAGE(7);        //set voltage regulator R/R
  LCD_SET_VOLUME_MODE(0x06);      //volume mode set


Dank und Gruß
Jörg

Ich habe kein DOGS-Display, konnte es also noch nicht ausprobieren.
Laut Datenblatt sind die beiden Controller aber fast identisch. Mit 
kleinen Anpassungen in der Init-Sequenz sollte der Code laufen.

Wenn du es zum Laufen bringst: Ich würde mich über eine Rückmeldung 
freuen, welche Anpassungen notwendig waren. Dann kann ich sie mit in die 
Library aufnehmen. Die Änderungen von Jörg für das DOGM128 werde ich 
auch demnächst mit einpflegen.

Jan

Hallo

Ich habe nun mal ein DOG S angeschlossen.
Als Controller haben ich ein ATMEGA 168

Was sofort auffällt ist das bei lcd_moveto_xy(0,2);

x und y vertauscht sind.

Ich denke das sollte so sein

x für Horizontal
y für Vertikal


lcd_moveto_xy(0,2);
lcd_putc('X');

macht gibt nich definierte Zeichen auf das Display

Ich habe bislang mit den 8051 programmiert und frage mich wie der 168er 
die Fonts Tabellen anspricht,.
Oder müssen die vorher im EEprom bereich geladen werden.


Gruß Juppo

Hallo an alle

Habe jetzt fast alles am laufen.
Wunderbar.

Probleme gibt es bei FONT_SYMBOL_16

lcd_put_char(FONT_SYMBOL_16,DOUBLE_SIZE,2);

Da zeigt das Display nur Mull an.




FONT_SYMBOL_8 Zeichen kommen wunderbar.

Gruß Juppo

Juppo Nini schrieb:
> lcd_moveto_xy(0,2);
> lcd_putc('X');
>
> macht gibt nich definierte Zeichen auf das Display

Du hast es wohl schon geloest, aber: Hast du vorher mit lcd_set_font() 
die richtigen Einstellungen gemacht?

Juppo Nini schrieb:
> lcd_put_char(FONT_SYMBOL_16,DOUBLE_SIZE,2);
> Da zeigt das Display nur Mull an.

Da muss ich heute abend mal genauer schauen.

Hallo
Bin immere noch am testen mit dem DOG S

Läuft alles super und wunderbar schnell.

Nur bei FONT_PROB_16 werden die Leerzeichen nicht auf das Display 
dargestellt.

zB."HALLO WORLD"

hinter HALLO steht nur noch Müll

??
Gruß Juppo

Hallo,
hier ist die neuste Version der Library:
- Initialisierung angepasst für DOGM128 (Dank an Jörg H.!)
- Fehler in symbol_16px und font_proportional_16px korrigiert (Dank an 
Juppo!)
- Funktionen zur Ausgabe von long, int und float angepasst - sie 
verwenden nun die globalen Schriftart-Einstellungen und haben somit 2 
Parameter weniger

@Juppo: Ich würde mich freuen, wenn du mir noch deine 
Initialisierungssequenz für das DOGS102 zukommen lassen würdest falls 
sie von der Sequenz in der Library abweicht.

Danke für den Hinweis!
Im Anhang die korrigierte Version.

Danke für den Test!
Da ich kein DOGS102 habe, konnte ich die Initialisierung auch noch nicht 
testen. Deswegen waren dort bis jetzt auch nur Dummy-Werte vorhanden.
Ich habe deine Einstellungen jetzt übernommen, in der nächsten Version 
sind sie dann auch enthalten.

Btw, bei LCD_SET_POWER_CONTROL() ist deine Einstellung 0x2F identisch zu 
meiner 0x7 - nur die unteren drei Bits sind der Wert, die oberen sind 
der Befehl.

Ein kleiner Tipp noch:

Beim DOGM132 sind im Controller nicht nur die pages 0 bis 3 vorhanden, 
sondern auch die normalerweise nicht sichtbaren 4 bis 7. Hier kann man 
z.B. im Hintergrund einen neuen Bildschirminhalt laden, und dann mit 
LCD_SET_FIRST_LINE(32); dorthin wechseln.

Oder mit LCD_SET_FIRST_LINE(4); kann man drei Zeilen Text vertikal 
zentrieren und hat oben und unten noch jeweils 4 Pixel Platz für einen 
schmalen Rahmen.

Hallo Leute,

ich versuche auch gerade ein dogm128 display mit einem atmega32 zum 
laufen zu bringen. Dazu muß ich sagen, daß ich mir erst heute ein 
Programmierkabel mit 10-Pol Wannenstecker gebaut habe, damit ich den 
atmega32 über mein mysmartUSB programmieren kann. das Kabel scheint zu 
funktionieren.

Den atmega32 hab ich auf einer anderen Platine als das Display.

Leider hab ich keine Ahnung, ob ich das Display richtig angeschlossen 
habe, bzw ob ich überhaupt die isp des m32 zur datenübertragung auf das 
display benutzen kann ?!?!?

bisher angeschlossen wie folgt:

am spi des atmega32:

1: mosd
2: vcc
3: port C1 ( soll am dogm cs1 sein)
4: gnd
5: reset
6: gnd
7: sck
8: gnd
9: miso
10: gnd

am dogm128:

wannenstecker 10-pol:
1: A0 ( pin 38 am dogm)
2: --- (nicht belegt, da display-platine eigene spannungsversorgung mit 
3,3V hat.)
3: cs1 ( pin 40)
4: gnd
5: reset (pin 39)
6: gnd
7: scl ( pin 37)
8: gnd
9: sdi(si) (pin 36)
10: gnd

Es sind für mich noch viele Fragen offen, wie z.B.

ist das überhaupt machbar ..so ???

was passiert mit dem display, wenn die signale vom uC mit 5V kommen ?

Danke im vorraus

Hallo zusammen,

ich bin am überlegen für mei nächstes Projekt mit ATMEGA32 ein DOGM128-6 
Display zu benutzen. Ich wollte mir daher schon einmal vorab die Library 
anschauen die ihr hier erstellt und ergänzt habt. Bei mir im AVR-Studio 
kann ich Sie aber nicht kompilieren. Ich bekommen nur Compilerfehler und 
ich kann diese nicht so ganz verstehen. Muss die Version 0.92 der 
Library, wenn ich die files in ein AVR-Studio-Projekt einbinde ohne 
Fehler compilierbar sein?

Es kommt z.B. folgene Fehlermeldung:

../lcd/dogm-graphic.c:105: error: 'UCSR1A' undeclared (first use in this 
function)

in der Runktion: void lcd_data(uint8_t data)

oder

../lcd/dogm-graphic.c:105: error: (Each undeclared identifier is 
reported only once

Ich weiß solche Ferndiagnosen sind schwer zu beantworten. Ich muss dazu 
sagen mit Displays und SPI habe ich noch nicht viel bisher gemacht. Was 
könnte das sein? Fehlen da Dateien? Wie gesagt soll alles bei einem 
ATMEGA 32 später eventuell laufen.

Martin

Hallo Martin,
dein Fehler kommt daher, dass die Library für einen Atmega324 und dessen 
USART-Schnittstelle geschrieben ist und bei deinem Atmega32 die Register 
anders heißen. Du musst einfach diese Zeilen in dogm-graphic.h an deinen 
Controller anpassen:

1

//Define a function that waits until SPI interface is idle

2

#define spi_wait_for_idle() while(! (UCSR1A & _BV(TXC1)));UCSR1A |= _BV(TXC1)

3

4

//Define how to write to SPI data register

5

#define spi_write(i) UDR1 = i

Christian Sowada hat weiter oben schon seine Variante gepostet, die 
sollte es bei dir auch tun, wenn du die SPI-Schnittstelle benutzt:

1

#define spi_wait_for_idle() while(!(SPSR & (1<<SPIF)))

2

#define spi_write(i) SPDR = i

Vielen Dank!

Ich hatte mir inzwischen soetwas gedacht. Das heißt im Klartext ich muss 
den ganzen Treiber durchgehen und an den SP1-Stellen abändern. Falls ich 
Probleme dabei bekomme melde ich mich wieder. Ich versuche mal so die 
Compilermeldungen loszuwerden.

Martin

Alle Stellen die du ändern musst, sind im "Config Block" in 
dogm-graphic.h zusammengefasst.

Außerdem musst du noch die Funktion spi_init() schreiben, die dafür 
sorgt, dass die SPI-Schnittstelle richtig eingestellt ist.
Das Beispiel aus dogm-graphic.h ab Zeile 65 wirst du für den Atmega32 
gerade übernehmen können.

Btw: Es gibt auch noch Version 0.93 mit einigen kleinen Änderungen:
Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator"

So jetzt habe ich meiner Meinung nach eigentlich alle Dinge angepasst, 
aber jetzt mekert er über eine Referenz zur main. Was ist das nun schon 
wieder? ich komme nich dahinter. Muss ich alles neu anlegen, ich meine 
in einem neuen Prjekt?

Fehlermeldung:

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/crt 
m32.o:(.init9+0x0):  undefined reference to `main'
make: *** [Temperaturdatenlogger.elf] Error 1


Mar

Hi,

ich habe nun den referenc fehler beseitigt, aber jetzt kommt ständig ein 
weiterer Fehler, dass ich die init_spi_lcd mehrfach definiert habe. Hast 
du einen Tipp für mich als noch unerfahrenen Programmierer?

Martin

Compilerauszug!

D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
dogm-graphic.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font_fixed_8px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font_proportional_8px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
font_proportional_16px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
symbols_8px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
symbols_16px.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
template_simplefont.o: In function `init_spi_lcd':
D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../L 
CD/dogm-graphic.h:70:  multiple definition of `init_spi_lcd'
logger.o:D:\Martin\Eignene 
Dokumente\Techniker\elektronik\Temperaturdatenlogger\Source\default/../l 
cd\dogm-graphic.h:70:  first defined here
make: *** [logger.elf] Error 1

Hi ,

ich möchte eigentlich nur einen funktionierenden Treiber für den Atmega 
32 und das Display. Kann ich dir mein Projekt mal mailen und du schaust 
mal darüber? Es ist bis jetzt nur eine unsinnige main und halt der 
Treiber, den ich für den Atmega 32 veruscht habe anzupassen, was mir 
irgendwie nicht gelingt, weil ich wohl Tomaten auf den Augen habe.


martin

Hallo,
das klingt so, als hättest du die Funktion init_spi_lcd() in 
dogm_graphic.h definiert. In header-Dateien steht aber üblicherweise nur 
die Deklaration, nicht die Definition (die gehört in eine .c).

Btw.: Hierbei handelt es sich um ein spezifisches Problem mit deinem 
Projekt, nicht um ein generelles mit der Library. Daher würde ich 
vorschlagen, du machst zur Fehlersuche einen eigenen Thread auf. Dort 
ist dann auch die Wahrscheinlichkeit auf Antworten deutlich höher, da 
ich auch nicht jeden Tag hier ins Forum schaue.

Hallo Ralph,
diesen Fehler kenne ich noch nicht - das mag aber vor allem daran 
liegen, dass ich bis jetzt noch keine so großen Schriften benutzt habe.

Spontan tippe ich auf einen Überlauf bei irgendeinem int8_t, ab 21 Pixel 
Breite bist du ja bei mehr als 128 Byte pro Zeichen. Ich werde mir den 
Code heute abend mal genauer anschauen.

Kannst du mir deinen Zeichensatz schicken, dann kann ich es direkt damit 
ausprobieren?


Gruß, Jan

Hallo Ralph,
ich habe leider gerade keine Zeit für einen ausführlichen Test, aber 
schau mal bitte in font.c (ungefähr Zeile 180):

1

/******************************************************************************

2

 * Outputs a character on the display, using the given font and style

3

 */

4

uint8_t lcd_put_char(FONT_P font, uint8_t style, char character) {

5

  int8_t  i;

i ist der relative Pointer auf die einzelnen Bytes eines Characters. 
Ändere mal die Definition von i in uint16_t, dann sollte das auch mit 
sehr großen Schriften passen.

Hallo Markus,
ich habe hier ein DOGM132 und kann gerade keinen Fehler feststellen, bei 
mir wird über die gesamte Breite gelöscht. Für dich sollte die richtige 
Einstellung definitiv diese sein:
lcd_clear_area(8,102,NORMAL)


Irgendwie war ich mir sicher, ich hätte hier vor kurzem noch einen Post 
geschrieben - sorry für die späte Antwort an die vorherigen Poster:

@Ralph: Ist in der nächsten Version korrigiert.

@Duke:
>Nette Bibliothek, etwas unübersichtlich zu lesen...
Kannst du das etwas erläutern? Ich bin für Verbesserungsvorschläge 
offen.

Markus schrieb:
> Hatte ich probiert, geht wie gesagt nicht. Ich mach mal ein Foto und lad
> das hoch, es ist schwer zu beschreiben was passiert (sieht komisch aus).
> Evtl. hat das auch was mit dem Wrap Around für Text zu tun.

Ein Bild wäre gut, dann kann ich das bei mir nochmal mit verschiedenen 
Einstellungen testen. Wie hast du den wrap-around eingestellt im 
header-file?


> Mal was Anderes, hast Du noch das Template File für den Fonteditor für
> GLCD? Ich hab mir da aus dem anderen Thread die neueste Version besorgt,
> aber da fällt das falsche Headerfile raus weil das Template anders ist.
>
> Idealerweise hast Du noch die Kombination aus Fonteditor mit
> Templatefile?

Das template müsste im Archiv mit enthalten sein, template*.h. Dann 
musst du nur noch die *.ini vom Fonteditor anpassen damit er dieses 
template benutzt. Wenn das nicht geht, kann ich dir morgen auch noch mal 
das komplette Paket schicken.
Wenn du neue Schriften generierst, vielleicht kannst du mir diese 
schicken, dann kann ich sie in die Library mit aufnehmen.


@XMEGA:
Grafikfunktionen sind mit dieser Library leider etwas schwer umsetzbar. 
Dafür müsste man zuerst einen Grafik-RAM im uC anlegen, da das Display 
ja keine pixelweisen Zugriffe erlaubt.

Hallo an alle da draußen,

wer kann mir mit Grafikfehler helfen???

Die Lib ist echt klasse. Nach 3 Tagen (SS-PIN der SPI-Schnittstelle war 
nicht HIGH bzw. Output) probieren klimperte mein DOG-L schon einmal paar 
Zeichen auf das Display. Allerdings mit komischer Pixel-Leiste am 
rechten Rand des Displays. Dabei ist es egal, welche Funktion zur 
Textausgabe verwendet wird.

Ich benutze ein Mega644 mit 20MHz auf selbst erstelltem Testboard. 
Programmierumgebung AVR-Studio 4 (aktuellste Ver.). Hardwarefehler kann 
ich ausschließen, da die Lib von U. Radig diese Fehler nicht produziert.

Schaut euch bitte mal das Bild an, vll. hat jemand eine Idee dazu.

Dank schon mal im voraus...

lg

Hallo Alexander,
spontan weiß ich keinen Grund warum das passiert. Das Display hat 128x64 
Auflösung?
Ich nehme an, du benutzt die Init-Routine aus der Library die am Anfang 
das gesamte Display löscht?
Wenn du keinen Text ausgibst, sind die vier Pixelspalten dann auch zu 
sehen?
Was passiert, wenn dein Text um ein paar Pixel breiter ist und bis in 
diese Spalte hineinreicht?
Und mit einer anderen Schriftart (nicht, das an dem Zeichensatz etwas 
kaputt ist)?

@Guest: Gegen einen grundsätzlichen Timinfehler spricht aber, dass der 
Text ohne Fehler ausgegeben ist.

Hallo,

sry, dass ich mich erst jetzt mit meinem Problem zurück melde.

Ich denke dass eine komplette Verschiebung um 4 Pixel in x-Richtung 
statt findet.
@ Jan: Ich benutze deine Lib 093 hier aus dem Forum und ich muss 
unabhängig der Fonts bei

1

lcd_moveto_xy(0,x)

für das x mindestens 4 angeben, damit ich in der ersten Pixelspalte 
meinen ersten Buchstaben setzen kann.
P.S. ist das Absicht, dass hier x und y vertauscht sind???

Probiert habe ich jeweils ein EA-DOGM und DOGL. Beide 128 x 64 Pixel.

Schreibe ich über die Zeile hinaus (WRAP=0) überschreibt er auch das 
Pixelmuster in der jeweiligen Zeile. Lösche ich das komplette LCD 
bleiben die letzten vier Pixelspalten mit dem letzten Inhalt über. Rest 
wird sauber gelöscht. Setze ich in der "Löschroutine" das max. x auf 132 
anstatt auf "LCD_WIDTH" löscht er auch alles.

Also meiner Meinung nach keine Probleme mit der Initialisierung des LCDs 
oder Probleme mit der SPI-Schnittstelle.

Ach klar, jetzt sehe ich es auf dem Foto. Du benutzt das Display ja im 
Top-View Modus. Dort gehen die Adressen von 4 bis 131 (siehe Datenblatt 
Seite 7 oben links). Das berücksichtigt meine Library im Augenblick 
nicht.

Ich versuche das in der nächsten Version einzubauen, kann dir aber nicht 
sagen, wann es soweit ist. Bis dahin musst du dir leider einen 
Work-Around basteln. Sorry!

Ahh, ok danke!

Ich hab aber leider noch ein viel bescheideneres Problem...
Ich betreibe den µC mit 5V. Zum LCD hin ein 74HC5040 Pegelwandler um auf 
die 3,3V für das LCD zu kommen.
Nun das Problem: näher ich mich mit meiner Hand dem Pegelwandler, 
"stürzt" das Display ab. Erst durch µC-reset wieder OK. Hab schon vers. 
SPI-Geschwindigkeiten getestet (prescaler min bis max), ohne Erfolg. 
Dabei ist es egal, ob ich den Programmer gesteckt lasse oder nicht. 
Anderes Phänomen ist, wenn ich das Experimentierboard über eine gewisse 
Zeit nicht mit Spannung versorge und dann wieder Spannung anschalte, das 
Lcd auch nichts anzeigt, sondern erst noch µC-reset.
Was könnte dafür die Ursache sein?

Ich benutze für die Ansteuerung des LCD ausschließlich den PORTB den ich 
vor der Display-Init auf Ausgang setze.

Hi Zusammen,

ich setze mich gerade mit dem EA-DOG XL Display auseinander und bin 
dabei auf deine Software gestoßen. Ich versuche diese jetzt gerade an 
das Display anzupassen. Die Displayinitialisierung klappt jetzt soweit 
und ich wollte jetzt versuchen ein paar Buchstaben auf das Display zu 
bringen.Einzelne Pixel  kann ich schon mit lcd_data() setzen.
Wenn ich nun Versuche die Funktion:
lcd_put_string_P(FONT_FIXED_8,NORMAL,PSTR("hello"));
aufzurufen, bekomme ich die folgende Fehlermeldung:
Error  2  undefined reference to `font_fixed_8px'

Die Definition ist ok, nachdem &font_fixed_8px den selben Fehler 
liefert. Ich habe an der Font.h und font.c nichts geändert, außer die 
auskommentierten Funktionen wieder einzufügen(z.94-101) (Nachdem ich 
sonst mit Fehlern überhäuft werde).
Außerdem habe ich noch die Zeile 215 in font.c auskommentiert, da die 
funtion     double_bits((row&1),tmp); diese Fehlermeldung hervorruft:
Error  2  undefined reference to `double_bits'

Ich benutze AVR Studio 5 und einen At90CAN (Was aber dafür wohl nichts 
zur Sache tun sollte).
Mein C ist eher rudimentär, weswegen ich mitt:
#ifdef FONTS_INCLUDE_font_fixed_8px
  extern const struct font_info font_fixed_8px PROGMEM ;
  #define FONT_FIXED_8 &font_fixed_8px
#endif
nicht viel anfangen kann. Wird hier die Datei mit den Fonts aufgerufen? 
Wieso kann ich nirgendwo einen Pfad finden?
Im Anhang ist das ganze Projekt.

Gruß, Olm

Hallo,
das Problem scheint einfach nur zu sein, dass du vergessen hast, alle .c 
und .h Dateien aus meinem Archiv in dein Projekt mit aufzunehmen (Die 
font*.c müssen im Unterverzeichnis Fonts liegen bleiben, da dort das 
#include relative Pfade benutzt).


Zu deiner zweiten Frage:

>#ifdef FONTS_INCLUDE_font_fixed_8px
Wenn oben FONTS_INCLUDE_font... definiert wurde, du dich also 
entschieden hast, diesen Font zu benutzen...
>  extern const struct font_info font_fixed_8px PROGMEM ;
... dann existiert irgendwo (= in einem anderen File in deinem Projekt) 
ein struct mit den Definitionen.
>  #define FONT_FIXED_8 &font_fixed_8px
... und dann definieren wir uns noch einen Namen um uns das &xyz 
Konstrukt sparen zu können.
>#endif
Feierabend.
Automatisch eingebunden wird damit nichts, der Compiler bekommt nur 
mitgeteilt, dass diese Variablen außerhalb der momentanen Datei 
existieren und der Linker sie später finden wird.

Cool, danke für die schnelle Antwort. Das einbinden der Dateien wars was 
gefehlt hat. Hab dann auch gleich mal ein paar versuche gemacht, kriege 
aber etwas merkwürdige Schriftbilder. Bei den Zahlen kann man es am 
besten sehen (Bild). Scheinbar verrutscht jede neue Zeile um eine 
Font-Breite (Eingentlich steht da "4444").
Die Diagonale und den Quader hab ich da mit lcd_data() hingeschrieben. 
Offenbar inkrementiert das Dispaly von Links nach Rechts, was auch 
logisch erscheint. Die 4er sehen aber irgendwie aus, als würde es zu 
weit zählen, bzw. in der neuen Zeile nicht bei 0 anfangen. Irgendwelche 
Ideen was dahintersteckt?

Auszug aus Programm:
init_spi_lcd();
  lcd_init();
  lcd_moveto_xy(0,0);
  lcd_data(0b11000000);
  lcd_data(0b00110000);
  lcd_data(0b00001100);
  lcd_data(0b00000011);
  lcd_data(0b00000000);  //Diagonale Line
  lcd_data(0xFF);
  lcd_data(0xFF);
  lcd_data(0xFF);
  lcd_data(0xFF);    //4x4Block

  lcd_moveto_xy(2,20);
  lcd_put_int (FONT_DIGITS_24,NORMAL,4444);

Interessant... auf meinem DOGM habe ich dieses Problem noch nicht 
gesehen, ein DOGXL hatte ich aber auch noch nicht in den Händen.

Auf jeden Fall musst du den Text mit DOUBLE_HEIGHT ausgeben - damit 
berücksichtigst du dass das XL zwei Bits pro Pixel verwendet (bei dir 
fehlt jedes zweite vertikale Pixel und die Höhe sind nur 12px). Meine 
Library hat dafür noch keine automatische Funktion.

Die Verschiebung von Zeile zu Zeile (und das auch noch nach links) kann 
ich im Augenblick nicht verstehen, da werde ich morgen nochmal drüber 
nachdenken müssen.

Aber trotzdem schön zu sehen, dass das auch mit dem DOGXL auf Anhieb 
zumindest halbwegs läuft. Spricht auch für die Qualität des Datenblatts, 
dass man sich blind auf die Beispiel-Initialisierungen verlassen kann.

Hi,
ich hab mal noch mit der Autoincrement-Richtung rumgespielt, was aber 
nichts geändert hat.
Im bild noch mal ein besseres Beispiel. Die Striche oben sind je im 
Abstand von 10 Pixel.
Die "7" sollte in auf (2,0) sein(Stimmt wohl). Jede weitere Zeile ist um 
eine Font-Breite nach links verschoben, auch wenn Line-wrapping des 
Displays aus ist.
Von da würde ich mal vermuten, dass etwas mit der Wrap-funktion in 
kombination mit der neuen Displaygröße nicht stimmt (Z.B. hat die 
Page-adressierung nun 5 bits(26 Pages/Zeilen).

Der Display Controller ist hier der UC1610. Das Display hat 
160Pixelx26Zeilen á 4 Pixel(104).

Hier der relevante Code für das Bild:
  uint8_t gap;
  while(gap<=16){
    lcd_data(0b11111111);
    lcd_move_xy(0,10);
    gap++;
  }
  lcd_data(0b11111111);
  lcd_moveto_xy(2,0);
  lcd_put_int (FONT_DIGITS_24,DOUBLE_HEIGHT,7);

Ich habe gerade noch einmal in deinen Code geschaut - du scheinst an 
einigen Stelle die Kommandos umdefiniert zu haben um den Code an den 
Controller des DOGXL anzupassen. Das macht es für mich jetzt natürlich 
sehr schwierig den Grund für die falsche Darstellung zu finden.

Meine Vorgehensweise wäre, zunächst die Library so zu erweitern, dass 
das DOGXL direkt unterstützt wird und zu schauen ob der Fehler dann 
immer noch auftritt. Leider sind dazu einige größere Änderungen nötig, 
für die ich alleine im Augenblick keine Zeit finde. Wenn du willst, 
können wir das aber auch gemeinsam angehen.

Die Änderungen beschänken sich weitgehend auf die Initialisierung, 
nachdem diese für das XL anders abläuft, und auch teilweise andere 
Befehle hat. Alle meine Änderungen erkannt man aber eigenltich daran, 
dass ich Befehle in Binärform schreibe(Hex ist mir ein Graus).
Wie man dem Bild entnehmen kann, habe ich auch beim Schriftbild 
Fortschritte gemacht. Nachdem ich den Fehler auf die Put_char-Funktion 
eingegrenzt habe, hab ich einfach willkürlich Variablen verändert um zu 
schaun was sich ändert (Nachdem ich die Funktion nicht 100% 
durchsteige). Als ich an LCD_MOVE rumgefingert habe(Setzt den cursor um 
die Breite des Fonts zurück und eine Zeile tiefer oder?) fiel mir auf, 
dass das Problem an "-char_final_width" liegen muss. Mit den Parametern 
LCD_MOVE(1,0) klappts. Dann blieb noch das Problem, dass die Zahlen von 
Rechts nach links geschrieben wurden(Offenbar benutzt dieses Display ein 
gegenüber den kleineren Hunden ein inverses Koordinatensystem.
LCD_MOVE(-char_final_height,+char_final_width); statt
LCD_MOVE(-char_final_height,-char_final_width);
löste auch diesen Problem.

Was noch bleibt sind die obstrusen Leerzeichen und die Tatsache, dass
lcd_put_string_P() nicht funktioniert
lcd_put_string() aber schon. Was ist denn da der Unterschied?

Hast du auch eine Mail(PM)? Dann kann ic dir den veränderten Code mal 
schicken.

> lcd_put_string_P()
Diese Funktion holt sich den string aus dem ROM.

Das Problem mit den Leerzeichen war ein Bug in Version 0.92. 0.93 vom 
06.09.2010 ist korrigiert.

> Offenbar benutzt dieses Display ein
>gegenüber den kleineren Hunden ein inverses Koordinatensystem

Das schreiben von rechts nach links ist konsistent mit dem Phänomen der 
zerhackten Buchstaben.
Gegen ein invertiertes Koordinatensystem spricht, dass die Buchstaben ja 
nicht spiegelverkehrt erscheinen. Allerdings hat dieser Kontroller ja 
auch einige Funktionen um das auto-inkrement der Adressen an die eigenen 
Bedürfnisse anzupassen. Vielleicht ist bei diesen Einstellungen etwas 
durcheinandergekommen?

Die Buchstaben werden Zeile für Zeile jeweils von links nach rechts 
geschrieben. In den Zeilen verlasse ich mich auf das auto-inkrement der 
Spaltenadresse, das weiterschalten um eine Zeile und zurückgehen an den 
linken Rand des Buchstabens mache ich manuell.

Ansonsten widerspricht das irgendwie jeder Logik, dass man einfach Pixel 
für Pixel von links nach rechts schreibt und bei einem Zeilenwechsel 
nicht wieder nach links zurückgehen muss... Vielleicht ist es aber auch 
nur ein Feature a la "wenn die page Adresse geändert wird, wird die 
column wieder auf den Wert zurückgesetzt der zuletzt geschrieben wurde" 
- das habe ich im Controller-Datenblatt aber noch nicht gesehen.

Wie ich schonmal schrieb verwende ich diese Lib leider nicht, weil ich 
sie zu spät "gefunden" habe, da hatte ich schon was Eigenes, ist im 
Prinzip ähnlich.

Ich hatte just am Wochenende das "Problem" das mir noch gute, große 
Zeichensätze fehlten. Als alter Rockbox-Mitentwickler erinnerte ich 
mich, das dort die Pixel dem LCD-Layout folgend auch in 8er-Reihen 
senkrecht geschrieben werden, bzw. mittlerweile wurden. Und das es dort 
ein Konverter-Tool gibt, was den Zeichensatz als C-Arrays ausgiebt. Das 
konnte ich zweckentfremden. Für den Fall das hier auch Bedarf besteht 
verrate ich gern wie:

Eine schöne Übersicht über die Fonts gibt es hier (wenn auch nicht 
alle):
http://rasher.dk/rockbox/fonts/
Wir brauchen als Ausgangspunkt eine .bdf-Datei, die sind dort leider 
nicht.

Falls man sich einen X.Org-Font ausgesucht hat findet man die zugehörige 
.bdf-Datei hier:
http://webcvs.freedesktop.org/xorg/xc/fonts/bdf/

Das Tool für die Konvertierung von .bdf in C-Code Arrays ist hier:
http://svn.rockbox.org/viewvc.cgi/trunk/tools/convbdf.c?view=log
Das muß man selbst kompilieren, für die senkrechten Spalten #define 
ROTATE auskommentieren um das alte Format zu erzwingen.
Beim Aufruf gibt es nützliche Kommandozeilenparameter um nur einen 
Ausschnitt des Zeichensatzes rauszuschreiben (z.B. von ASCII 32 bis 127) 
und um oben und unten was abzuschneiden. Die Standardzeichen passen 
häufig in einen kleineren Bereich.

Auf welchem Display?

Hallo Orko,
ja, das c-file muss mit ins Projekt. Am einfachsten kopierst du den 
generierten Code direkt in deinen Quellcode hinein.
Oder du bindest die neu erstellte Datei zusätzlich ein, dann musst du 
die Variable aber mittels "extern" deinem Code bekannt machen.

Dann kannst du einfach
> lcd_draw_image_P(data_demo_image,(Höhe/8),Breite,NORMAL);
aufrufen.




@Fabian: Ich bin noch dabei die Library für das DOGXL vorzubereiten, 
nächste Woche sollte es soweit sein. Es wäre schön, wenn du das dann 
testen könntest.

@orko

in headerdatei z.b.: "bitmap.h"

1

static uint8_t PFEIL_LINKS[] PROGMEM = {

2

// 2 pages x 8 columns

3

0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0xAA,

4

0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xAA

5

};

aufruf dann mit:

1

lcd_moveto_xy(0,0);

2

lcd_draw_image_P(PFEIL_LINKS,2,8,NORMAL);

Bild wird hier an die obere, linke Bildschirmecke gezeichnet (0,0) und 
es muss die Größe des Bildes mit an die Funktion übergeben werden (8 
Pixel breit und 2 pages hoch, was 2*8 Pixel entspricht)

Bilder müssen leider eine Höhe von einem vielfachen von 8 haben (8px, 
16px,...) und was auch schade ist, dass diese in y-Richtung nicht 
Pixelgenau gesetzt werden können (nur in x-Richtung)

AleX

AleX A. schrieb:
> Bilder müssen leider eine Höhe von einem vielfachen von 8 haben (8px,
> 16px,...) und was auch schade ist, dass diese in y-Richtung nicht
> Pixelgenau gesetzt werden können (nur in x-Richtung)

Zumindest zweiteres stimmt nicht:
Mit lcd_draw_image_xy_P kannst du das Bild pixelgenau plazieren, musst 
allerdings beachten, dass die "restlichen" Pixel einer Page dann 
gelöscht werden.
Ohne lesbaren Grafik-Speicher ist halt leider nicht mehr drin.

Hallo Jan,

könnte man nicht einen temporären Zwischenspeicher im µC realisieren, in 
dem geschrieben und gelesen werden kann? Änderungen im Zwischenspeicher 
natürlich an das Display schreiben. Ich würde mir als Zwischenspeicher 
ein unsigned char Array mit 128x8 Zellen vorstellen. Würde dann 
natürlich 1024 Bytes vom Speicher (SRAM???) dafür flöten gehen.

Das als Grundlage. Damit würden dann auch keine Pixel einer Page 
gelöscht werden, die schon vorhanden waren. Wenn das dann für Bilder 
funktioniert, sollte es doch auch für die Fonts funktionieren!?

Wird wahrscheinlich eine abartige Bit-Schieberei und zulasten der 
Geschwindigkeit gehen.

Ja klar, das geht. Der Aufwand dürfte sich in Grenzen halten. Im 
wesentlichen muss nur die Ausgaberoutine geändert werden, so dass sie 
neben den Daten auch eine Maske der zu ändernden Bits bekommt und vor 
dem Schreiben zum Display mit den Daten im RAM überlagert. Dazu dann 
(später) noch die Anpassung aller schreibenden Funktionen um 
pixelgenaues Verschieben zu ermöglichen.


Allerdings sind 1 kB ja doch eine ganze Menge Speicher für einen kleinen 
atmega. Aber zumindest in der 64* Serie mit 4kB kann man sicher darüber 
nachdenken - oder eben gleich einen externen RAM benutzen.

Dann kann man sicher auch über Grafik-Funktionen nachdenken, also z.B. 
Kreise zeichnen. Das ist dann aber am Ende schon sehr viel mehr als das 
für das diese Library ursprünglich gedacht war.

Zur Performance - das müsste man mal nachmessen, wie lange 
lcd_draw_image_P und lcd_draw_image_xy_P im Vergleich brauchen. Dabei 
muss man aber einrechnen, dass durch das Verschieben eine Page mehr 
geschrieben werden muss.

Hallo Andreas,
Bis jetzt habe ich auch nur angefangen mit der Portierung, bin aber noch 
nicht fertig. Wenn nichts dazwischenkommt werde ich am nächsten Montag 
die grundlegenden Dinge  fertig machen,  dann kann ich dir den Code 
schicken.

Jan

Hallo zusammen,
ich glaube bei euch bin ich genau richtig. Ich versuche auch ein
EA-DOGM128-6 zum laufen zu bekommen. Also, das ist jetzt etwas
übertrieben, ich habe ehrlich gesagt im Moment nicht die Zeit mich
richtig damit zu befassen wie ich es gerne möchte. Ich brauche
eigentlich Hilfe dabei das Teil zu testen. Es soll irgend etwas anzeigen
das ich weis, es geht. Wenn ich damit warte bis ich so weit bin,
und das Ding ist kaputt, kann ich es nicht mehr zurück schicken.
Mein Problem ist weiter, ich kann kein C, Assembler wäre echt
toll. Ich hoffe nicht, das sich durch meine Anfrage jemand auf den
Schlipps getreten fühlt, von wegen, "der lässt sich hier im Forum
bedienen". Vieles kann ich einfach noch nicht, da ich mich noch im
Selbststudium mit der ganzen Materie befinde. In Hardware kann ich
richtig helfen wenn es benötigt wird, aber hierbei, blutiger
Anfänger. Also auf meinem Testbord sitzt ein Mega88 und wie gesagt
Assembler ist das meine.

Gruß an alle

Hallo,
hier ist die aktuelle Version (0.94) meiner DOG-Library. Aktuelle 
Änderungen:

- Reihenfolge der Argumente von lcd_clear_area_xy() korrigiert
- Befehle für DOGXL160 hinzugefügt (siehe unten)

- Einzelne Zeichen dürfen jetzt größer sein als 128 Byte
- 32 Pixel hohe Ziffern hinzugefügt, Breite so, dass 4 Ziffern plus 
Doppelpunkt in 128 Pixel Breite passen.


Zur Unterstützung des DOGXL habe ich alle Befehle aus dem Datenblatt 
eingebunden, die Initialisierung nach Datenblatt eingebaut. Testen kann 
ich das leider mangels Display nicht, ich kann nur soviel sagen: Es 
kompiliert...
Ich hoffe, dass sich einer der Interessenten von vorher findet, der ein 
XL hat und das ganze testen kann.

Hallo Jan M.,


Jan M. schrieb:
> der ein XL hat und das ganze testen kann

ich habe deinen Code mit einem DOGXL160 getestet.

Das Display zeigt bis gut über die Hälfte des Displays alles ordentlich 
an. Der Rest ist Pixelsalt.

Habe das Ganze auch auf einen Xmega32a4 getestet und da trat der selbe 
Fehler auf.

Habe den Code kurz überflogen, aber keinen Fehler gefunden.




Gruß xmega

Hallo,
vielen Dank für deinen Test - da scheint ja schon einmal einiges zu 
funktionieren.

Zeile 238 in dogm_graphic.h ist das Problem:

1

#define LCD_SET_PAGE_ADDR(i)          lcd_command(LCD_PAGE_ADDRESS | ((i) & 0x1F))

Die Maske stand auf 0x0F, muss aber natürlich 0x1F sein um alle 26 Pages 
addressieren zu können.

Hallo,

alles klar, funktioniert bestens.



Danke!!!


Gruß xmega

Hallo Jan M.,

musste noch folgende Zeile ändern:


#define LCD_GOTO_ADDRESS(page,col)    lcd_command(LCD_PAGE_ADDRESS | 
((page) & 0x1F)); \

Erst dann war alles ok!

Gruß xmega

Hallo Jan M.,

ich habe mal die neueste Version für Atxmega und Amega644 hier 
eingestellt:


http://www.basteln-mit-avr.de/


Gruß xmega

Hallo,

an alle die mit einem DOGXL160 und der Lib von Jan M. experimentieren!

EA DOGXL160 im I2C/TWI Betrieb mit einem Atxmega32A4.

I2C/TWI Takt: 4 Mhz

Geht richtig flott!

Näheres: http://www.basteln-mit-avr.de/atxmega32a4.html


Gruß Xmega

Hat irgendjemand ein Funktionierendes Beispiel für DOGM/DOGL da über SPI 
mit einem Atmega?

Habe einige Probleme die ich mir nicht erklären kann. Kann ohne Fehler 
Kompilieren aber bekomme NICHTS auf dem Display angezeigt. Habe die 
Ports richtig angepasst und die SPI initialisiert wie es hier schon 
gezeigt wurde.

Bei:

  lcd_init();
  lcd_moveto_xy(2,20);
  lcd_put_string(FONT_FIXED_8, NORMAL, "Hallo Welt");

Passiert einfach garnichts auf dem Display.

Bei:
        lcd_moveto_xy(2,0);
  lcd_put_int (FONT_DIGITS_32,NORMAL,4444);

Kann ich nicht Kompilieren und er beschwert sich:


Error  3  expected 'int16_t' but argument is of type 'const struct 
font_info *'

Error  4  too many arguments to function 'lcd_put_int'

Warning  2  passing argument 1 of 'lcd_put_int' makes integer from 
pointer without a cast


Ich musste auch tmp = double_bits((row&1),tmp);  ausklammern da er immer 
gemeckert hat über undefined reference zu double_bits.

Hat jemand eine Idee oder kann mir jemand bitte sein funktionierendes 
Programm hochladen? (Mit SPI bei einem DOGM/DOGL und Atmega)

Mit der Bibliothek von Ulrich Radig funktioniert es aber die Lib ist bei 
weitem nicht so umfangreich und toll geschrieben wie diese hier.

Vielen Dank

Hallo,

schau ma hier:

http://www.basteln-mit-avr.de/

Gruß Xmega

Danke für den Link.

Ist leider mit dem Xmega und das dann abzuändern ist ja relativ 
aufwendig oder? Habe davon keinerlei Ahnung.

du hast eine datei spic eingebunden. Brauch ich die auch? Ich habe nur 3 
Pins angeschlossen. CS ist an PortB4, Reset an PortB3, A0 an PortB2 
mehr habe ich nicht angeschlossen.

Nutze einen Atmega16. Mit der Lib vom Radig reichen die Anschlüsse auch 
da lass ich sogar noch den CS weg da brauch ich nur 2 Pins anschliessen 
und es läuft.

Was hast du gemacht mit SPI_MOSI, SPI_MISO, SPI_SCK ? Wo soll ich die 
anschliessen? PIN 24/25 wie du sie benutzt hast sind bei mir mit 
Kondensatoren belegt.

Danke ^^

Hallo


Hier gibt es auch eienen Code füt Atmega644, der ist kompatible zu fast 
allen Atmegas.

SPI musst du natürlich komplett einbinden.

Schau dir das mal in Ruhe an, und melde dich dann nochmals!

Gruß Xmega

Ich habe jetzt exakt das was du auf dem Mega644 gemacht hast auf meinen 
Mega16 gepresst. Habe alle Anschlüsse gleich auch die MOSI und SCK 
anschlüsse. Hab im AVR STudio den Mega 16 eingestellt und kompiliert und 
geflasht.. resultat ist ein leeres Display. ?!?!?

Hallo,

- Wichtig -> Die Geschichte funktioniert mit 3,3 Volt, Datenblatt lesen


- Wichtig -> LCD_CS 10K Widerstand nach 3,3V!!


In der  dogm.graphic.h

Select the display type: DOGS102: 102, DOGM128/DOGL128: 128, DOGM132: 
132

#define DISPLAY_TYPE  160

- dein Display-Typ einstellen

Gruß Xmega

Habe ich alles gemacht Display trotzdem leer. Target Voltage auf dem 
stk500 ist auf 3,3V eingestellt. Der 10k Widerstand ist vom CS auf 3.3V. 
Das Richtige Display habe ich ausgewählt habe 128 für das DOGL 
ausgewählt.

Kriege mit AVR Studio 4 ne Warnung:

gcc plug-in: No AVR Toolchain installation found. The AVR GCC plug-in 
can still be used if you set up your own build tools.


Im AVR Studio 5 kann ich obwohl ich alles eingebunden habe nichteinmal 
kompilieren. da zeigt er mir viele Fehler in der font.c an und dazu halt 
immernoch der Fehler mit den double_bits.

Woran kann das liegen das 1. das Display komplett leer bleibt. Und 
wodran kann es liegen, dass ich in AVR Studio 4 Kompilieren kann und im 
5er nicht? Obwohl die gleichen Dateien eingebunden sind.

Hab im makefile mcu name auf atmega16 geändert. Nun kriege ich keine 
Fehlermeldung mehr im AVR Studio 4 aber auch keinerlei Ausgabe.

Display läuft nun mit deinem Beispiel. Warum verstehe ich nicht. Aber 
egal es läuft nun ohne das ich etwas gemacht habe.

Wie kann ich mit lcd_moveto_xy(x,y) die x position auf den Pixel genau 
festlegen? Die ist ja jetzt Zeilenweise gemacht will aber an eine ganz 
genaue Position einen Text oder Zahl ausgeben.

>Und wodran kann es liegen, dass ich in AVR Studio 4 Kompilieren kann und im
>5er nicht? Obwohl die gleichen Dateien eingebunden sind.
Vorsicht beim Einbinden im AVRStudio 5. Dateien werden standardmäßig 
alle in ein Verzeichnis kopiert und damit stimmen dann natürlich alle 
relativen Links zu header-files nicht mehr. Also beim Einbinden immer 
nur verlinken und nicht kopieren!

>Wie kann ich mit lcd_moveto_xy(x,y) die x position auf den Pixel genau
>festlegen? Die ist ja jetzt Zeilenweise gemacht will aber an eine ganz
>genaue Position einen Text oder Zahl ausgeben.

Das unterstützt das Display nicht. Der Speicher lässt sich nur 
page-weise ansprechen. Um Text genauer zu platzieren ohne umgebende 
Teile zu überschreiben müsste man im uC einen internen Bildspeicher 
implementieren, aber das braucht natürlich sehr viel RAM.

Hallo,

André R. schrieb:
> Wie kann ich mit lcd_moveto_xy(x,y) die x position auf den Pixel genau
>
> festlegen? Die ist ja jetzt Zeilenweise gemacht will aber an eine ganz
> > genaue Position einen Text oder Zahl ausgeben.

Dann solltest du diese Version nehmen. Siehe Dateianhang!

Gruß Xmega

Habe mit dem Font Editor neue Zeichen zu der datei symbols_8px 
hinzugefügt. Einmal nur zum testen bei 0x23 (#) ein ausgefülltes 
Rechteck 5x8 Pixel.

Habe danach abgespeichert/exportiert und den ganzen Block an Hexwerten 
in die bestehende Datei kopiert.

Wenn ich jetzt hingehe und folgendes mache:
 lcd_set_font(FONT_SYMBOL_8, NORMAL);
  lcd_moveto_xy(1,0);
  printf("####");

Dann erwarte ich ja eigtl. das dort abgespeicherte Rechteck aber es 
kommt nen verkrüppeltes Zeichen bei raus ?!?. Was habe ich falsch 
gemacht?

Hallo zusammen!

Erstmal vielen Dank für die schöne Lib! Ich bin gerade dabei, mein 
DOGM128 in Betrieb zu nehmen und komme nicht weiter.
Ich wollte ein Bild anzeigen und habe versucht, es so zu machen wie Alex 
A. es oben beschrieben hatte:

in headerdatei z.b.: "bitmap.h"

static uint8_t PFEIL_LINKS[] PROGMEM = {
// 2 pages x 8 columns
0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0xAA,
0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xAA
};

aufruf dann mit:

lcd_moveto_xy(0,0);
lcd_draw_image_P(PFEIL_LINKS,2,8,NORMAL);

Beim Kompilieren bringt AVR Studio 4 mir eine Warnung:

../Lib94.c:42:3: warning: pointer targets in passing argument 1 of 
'lcd_draw_image_P' differ in signedness
../dogm-graphic.h:100:8: note: expected 'const prog_char *' but argument 
is of type 'uint8_t *'

Das Display zeigt nichts an. Mit dem Testprogramm von Gerhard G. kann 
ich zumindest Text anzeigen. Das Display selber arbeitet also. Daher 
vermute ich,dass es mit der Warnung zusammenhängt.
Was mache ich falsch?
Ich verwende übrigens einen Atmega 8 mit 16MHz.

Gruß,

Jochen

Hallo Jochen,

Jochen H. schrieb:
> in headerdatei z.b.: "bitmap.h"
> static uint8_t PFEIL_LINKS[] PROGMEM = {
> // 2 pages x 8 columns
> 0xFF,0x00,0xFF,0x00,0xFF,0x00,0xFF,0xAA,
> 0x00,0xFF,0x00,0xFF,0x00,0xFF,0x00,0xAA
> };
Variablendefinitionen gehören üblicherweise in .c, nicht in .h Dateien. 
Das ist so kein echter Fehler aber zumindest Konvention.

> Beim Kompilieren bringt AVR Studio 4 mir eine Warnung:
> ../Lib94.c:42:3: warning: pointer targets in passing argument 1 of
> 'lcd_draw_image_P' differ in signedness
> ../dogm-graphic.h:100:8: note: expected 'const prog_char *' but argument
> is of type 'uint8_t *'
Ja, das ist richtig. Wenn du das erste Argument von lcd_draw_image_P von 
PGM_P auf PGM_VOID_P änderst, bist du diese Warnungen los.


> Das Display zeigt nichts an. Mit dem Testprogramm von Gerhard G. kann
> ich zumindest Text anzeigen. Das Display selber arbeitet also. Daher
> vermute ich,dass es mit der Warnung zusammenhängt.
> Was mache ich falsch?

Deine geposteten Zeilen Code funktionieren bei mir ohne Probleme (auch 
wenn "PFEIL_LINKS" nicht der passende Name für das Bild ist).
Hast du schon probiert einfach einen Text mit meiner Library auszugeben?
Die SPI-Routine und Pin-Definitionen sind an deinen µC / dein Board 
angepasst?

Hallo André,
ich habe deinen Beitrag wohl übersehen... sorry.
Hast du das Problem inzwischen gelöst?
Wenn nein, funktionieren die anderen Symbole aus deiner neu generierten 
font*.c noch? Wenn nicht, ist wahrscheinlich eine Einstellung im 
Font-Editor falsch. Schau mal nach, ob die Zeichenhöhe noch 8 Pixel ist 
und Kompression abgeschaltet ist.

Hallo Jan,

vielen Dank für deine Hilfe!
Habe eben nochmal mein Testprogramm durchgeschaut und den Fehler 
gefunden. Nun wird die Grafik dargestellt.
Habe das PGM_P auf PGM_VOID_P geändert; die eine Warnung ist nun weg, 
dafür kommen zwei andere :-):

../dogm-graphic.c:187:16: warning: dereferencing 'void *' pointer
../dogm-graphic.c:189:13: warning: dereferencing 'void *' pointer

Bekomme ich die auch weg?

Kein Problem: Einfach die Array-Schreibweise ("warum hatte ich das 
damals so geschrieben???") in den beiden angekreideten Zeilen ersetzen 
durch normale Pointerarithmetik:

1

data = pgm_read_byte(progmem_image+j*columns + i) << offset;

2

data |= pgm_read_byte(progmem_image+(j-1)*columns + i) >> (8-offset);

Hat jemand ein Schaltungsbeispiel oder ähnliches, damit ich das Display 
auch an 5V betreiben kann?

Habe mit Pegelwandlern noch nicht gearbeitet sollte damit aber gehen 
oder gibt es da eine einfachere Variante?

Hallo

Wie Verdrehe ich das Display um 180 GraD
SET SEG direction auf 0xA0
SET COM direction auf 0xC8

geht ,aber die zeichen sind nich t auf x,y 0,0

Da muss noch was bei den Set Column Adresse "+30" gesetzt werden.

Das will nicht klappen.
Ich benutze die LCD-Library von Jan.

hat da jemand ne Idee ?

Das kommt auf das Display an, das du benutzt. Wenn es ein DOGM oder -L 
mit 128 Pixel sind, musst du alle column-Adressen um 4 erhöhen.

PS: In der nächsten Version (auf meinem Rechner, bin nur noch nicht dazu 
gekommen sie zu finalisieren & hochzuladen), kannst du die Drehung über 
ein #define einstellen, dann brauchst du dir um die Adressen und 
Registereinstellungen keine Gedanken mehr zu machen.

DOG S 102

In dem Fall dann wie du schon geschrieben hast die Spaltenadresse um 30 
erhöhen. Das musst du im Augenblick noch von Hand machen, der 
automatische Zeilenumbruch bei längeren Texten geht mit v0.94 auch noch 
nicht.

Ich kann die neue Version heute Abend hochladen, dann kannst du das 
ausprobieren wenn du willst.

Ja das wäre nett.

Gruss Juppo

Hallo,

versuche schon den halben Tag mein 132x32 blau neg. ans laufen 
zubekommen.

Atmega644 int. 8Mhz

Laut Oszi werden auch keine SPI Daten gesendet.
Meine SPI Init schaut so aus:

1

#define SPI_MOSI   PB5

2

#define SPI_SCK    PB7

3

#define  SPI_MISO  PB6

4

5

DDRB  = (1 << SPI_MOSI) | (1 << SPI_SCK); 

6

PORTB &=~(1<<SPI_MISO);

Im Anhang auch mal das ganze Projekt.

Ich hoffe ihr könnt mir helfen.

Danke, Markus

Sorry,

falsche Anhang. jetzt koriegiert.

1

#define SPI_MOSI   PB5

2

#define SPI_SCK    PB7

3

#define  SPI_MISO  PB6

4

5

DDRB  = (1 << SPI_MOSI) | (1 << SPI_SCK); 

6

PORTB &=~(1<<SPI_MISO);

7

8

SPCR = (1 << SPE) | (1 << MSTR) | (0 << SPR1) | (0 << SPR0);   

9

SPSR = 0;

10

11

_delay_ms(2);

lg, markus

Hallo Markus,
schau dir mal das Beispiel aus dogm_graphic.h an:

1

  SPCR = 0 << SPIE | 1 << SPE | 0 << DORD | 1 << MSTR | 1 << CPOL | 1 << CPHA | 0 << SPR1 | 0 << SPR0;

2

  SPSR = 1 << SPI2X;

3

  SPDR = LCD_NOP; //Do not use 0 here, only LCD_NOP is allowed!

SPI-Mode ist 3, also müssen CPOL und CPHA gesetzt sein.
Das letzte Schreiben auf SPDR ist notwendig, damit das TX-ready Signal 
initalisiert wird.

Hallo Jan,

dann bekomme ich dieses:
dogm-graphic.c:61: error: 'LCD_NOP' undeclared (first use in this 
function)

lg, markus

Stimmt, da ist das Beispiel nicht mehr up-to-date. Es muss LCD_NO_OP 
heißen.

Ok.

nun she ich aufm Oszi auch das was geht. Nur leider Streikt das Display, 
ich passiert nix.

Hallo Jan,

so jetzt geht es..

Nur das Hallo Welt wird so dargestellt:
- fängt rechts an
- Spiegelschrift

lg, markus

So,

- fängt rechts an
- Spiegelschrift

habe ich rausgefunden.

Nur was ich ned hinbekomme ist ein Bild von 132x32

wenn ich

1

lcd_moveto_xy(0,0);

2

lcd_draw_image_P(data_DOG132_bmp,4,132,NORMAL);

dann habe ich in Zeile 2 und 4 nix stehen.

Als Bild verwende ich das DOG132.

lg, markus

Hallo vaid,
der unterschied zwischen mit/ohne zusätzlichen zeichensätzen ist 
reinzufällig: Es wird einfach der Inhalt an irgendeiner Stelle im RAM 
angezeigt. Damit Leerzeichen funktionieren muss die Schriftart  das 
Zeichen 0x20 enthalten, sonst kommt der Zeichengenerator durcheinander - 
das muss ich auch bei Gelegenheit mal korigieren.

Gruß, Jan

Hallo Markus,
danke für den Hinweis. Wenn das Bild bis an den rechten Rand geht 
pfuscht mir der Zeilenumbruch in die Cursor-Bewegung rein. Probier bitte 
mal folgendes:
Ersetze in lcd_draw_image_P() (dogm_graphic.c) ungefähr Zeile 156:

1

    if(++j != pages)

2

      lcd_move_xy(1,-columns);

durch

1

    if(++j != pages && lcd_get_position_column != 0)

2

      lcd_move_xy(1,-columns);

Hallo

Ich Habe einen uC ATMEGA644 und ein EA-DOGL 128

Für ein Projekt gebe ich Temperaturwerte aufs Display aus, habe mir die 
Datei von Jan geladen, habe jedoch keine Ahnung wie ich die einbinden 
soll und was ich mit den x.font Dateien machen muss.

Arbeite mit AVR Studio 5

Hätte jemand eventuel ne kleine Anleitung parrat fürs programmieren 
eines Displays?

Hallo,


http://www.basteln-mit-avr.de/

AVR Studio 5 Vers: Atmega 644 SPI

In der dogm.graphic.h ist das Display bereits definiert!

G.G.

Hallo,

das wird mit dieser Version nicht funktionieren, das hier arbeitet mit
einem 4-line SPI Interface. Dein Board arbeitet mit dem 6800 
Interfaceals (8 Bit parallel)


Siehe Datenblatt: http://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf

Das Ganze auf parallel umzuschreiben ist sicherlich kein Problem, aber 
du solltes dir mal deine Schaltung anschauen, da befinden sich einige 
Logik-Bausteine am Eingang deines Displays. Also Adressen- und Datenbus 
beachten.


Gruß G.G.

Hi zusammen,

Dieser Treiber ist absolut klasse!
Habe mir das Beispiel von http://www.basteln-mit-avr.de Beispiel: 
"Atmega 644 SPI" genommen, angepasst auf meinen Atmega128 und fertig -> 
läuft super, so soll es sein!

Das einzige ist, die Hintergrundbeleuchtung tut bei mir nicht, ich habe 
alles angepasst (bei mir PD7) und die Einstellungen von 1 und 2 
ausprobiert (low-active und high-active), gehen leider beide nicht.
Wenn ich den Port "per Hand" einschalte geht es.

Hat einer eine Idee?

Und DANKE nochmals für den super Treiber, so macht LCD spass.

PS: Ist die Version 0.94 die in dem Bsp. verwendet wird.

Hallo Anton,
wenn du die vier defines in dogm_graphic.h richtig gesetzt hast:

1

  #define LCD_USE_BACKLIGHT   1

2

...

3

  #define PORT_LED PORTD

4

  #define DDR_LED  DDRD

5

  #define PIN_LED  7

kannst du nach dem lcd_init() die Makros BACKLIGHT_ON() und 
BACKLIGHT_OFF() benutzen. high_active und low_active vertauschen nur die 
beiden Makros. Zusammen passiert da nichts anderes als das, was du von 
Hand machst. Schau doch nochmal die Einstellungen durch, vielleicht hast 
du ja etwas übersehen.

Jan

ja passt, hatte das falsch verstanden, dachte das geht irgendwie an wenn 
man Text aus gibt.. aber das geht ja gar nicht wie blöd von mir :(

Hallo,

erstmal vielen Dank für diese super library an Jan M. und  Gerhard G. 
für die Portierung auf Xmega.

Habe sie heute auf meinem Xmega 256 und einem dog XL getestet. 
Funktioniert wirklich sehr gut :)

Ich habe nur eine Frage was die delay routinen in der library betrifft.
Wenn ich zum Beispiel nach dem ausgeben von dem Text ein paar LED's 
blinken lassen will (1 Sekunde an 1 Sekunde aus) ist mir aufgefallen das 
die LED's ca 30 mal so schnell blinken (bei _delay_ms(1000)).Musste den 
Wert von _delay_ms auf 30000 setzen um ca 1 Sekunde zu haben. Habe ich 
mit dem Oszi getestet. Beim Compilieren habe ich bei der optimization Os 
eigestellt wie es in der delay routine gefordert ist.

Hab ich da was übersehen bei der Definition von CPU clock oder so ?
Mein System läuft mit 32 Mhz.

Hoffe Ihr könnt mir helfen, ansonsten nochmals vielen Dank für diese 
tolle library.

Gruß
Stefan

Hallo,

arbeitest du im Debug oder im Release Modus?


Im Toolchain muss dann für beide Modi folgendes eingetragen werden:

Symbols-> F_CPU=32000000UL, oder halt deine F_CPU= "Geschwindigkeit"

#define F_CPU 32000000 braucht dann in deiner Anwendung nicht mehr 
erscheinen.

Ansonsten stimmt das bei mir mit dem Takt haargenau.


Gruß G.G.

Vielen Dank für die Antwort.
Das war das Problem, ich war im Debug Modus und da war das Symbol gesezt 
im Release aber nicht.

Funktioniert nun einwandtfrei.

Grüße Stefan

Hallo,

was für eine Software verwendest du?

AVR Studio 4 oder 5.

Generell würde ich dir vorschlagen, das lauffähige Programm 
runterzuladen und in ein Verzeichnis auf deinem Lfw zu entpacken. 
Projekt öffnen und testen. Hardware mitinbegriffen!! Sollte alles OK 
sein kannst du Stück für Stück in dein Programm einfließen lassen.


Zwei Projekte mischen ist nicht! Die Grundlagen um ein solches Projekt 
zu starten sollten schon vorhanden sein.

Gruß G.G.

Hallo,


> was für eine Software verwendest du?
> AVR Studio 4 oder 5.

Aus  Kompatibilitätsgründen  habe ich noch eine neue Version
(AVR Studio 6) hochgeladen.

http://www.basteln-mit-avr.de/atxmega32a4.html#dogxl160



Gruß G.G.

Hallo,

die SPI- und Port-Zuweisungen findest du in der dogm-graphic.c
Leider ist die Umsetzung in Richtung ARM etwas schwierig, da die 
ARM-IDE's
keine pgm_read_byte(..) Anweisungen kennen.

Vielleicht gibt es hier im Forum ein paar Leute, die das schon gemacht 
haben.
Die Hardware, sprich SPI/PORT ist dagegen leicht anzupassen.

Ich verwende darum für meine LPC1769 Anwendung folgende Software:

http://www.basteln-mit-avr.de/LPCXpresso_1769.html

Das Anpassen an das Display DOGS102 ist auch nicht so kompliziert.
Man braucht nur die Init. ändern.

Gruß G.G.

Erst mal auch von mir ein riesen dankeschön an Jan für die Hammer Lib! 
hat bis jetzt top funktioniert.

Bilder bekomme ich mittlerweile auch dargestellt, nur eine frage hätte 
ich noch zu bildern:

wenn ich ein bild darstellen möchte, das genau so groß wie das display 
ist, also 128*32 pixel, wie viele bytes habe ich dann pro reihe? 
zufällig 16?
oder sind das immer 8 bytes pro reihe.
ich benutze den konverter von laeubi-soft, hab das DOGM128 display.

vielen dank schon mal

Jan

...außerdem habe ich festgestellt, dass wenn ich zwei 64x64 pixel bilder 
direkt nebeneinander darstellen will, dass das zweite, also das rechte 
bild, nciht richtig dargestellt wird. Es fehlen zeilen und es flackert 
viel.

Kann mir da vielleicht einer helfen?

vielen dank schon mal

Jan

...ncoh was rausgefunden:

das problem mit den beiden bildern liegt darin, dass das zweite bild bis 
zum rechten rand gezeichnet wird, das gleich Problem dass Markus auch 
hat mit den Zeilen 2,4,... die fehlen.

JanM, Deine Lösung, die Zeile 165 zu ändern hat leider nciht geholfen.

Hättest du noch eine weitere Lösung für uns?

(Sorry für so viele Postings...)

Jan

Hallo Klong,

vielen dank für deine antwort und den code, nur leider benutze ich das 
DOGM128. man könnte den code ja bestimmt umändern für dieses glcd.

ich bräuchte aber eher einen code, um ein bild von 64x64 pixel ganz nach 
rechts an den rand zu zeichnen.

kann mir da jemand helfen?

Jan

Hallo,


Klong schrieb:
> Code für eine Ganzseiten Bitmap 160X104 - DOGXL160-7:

habe mal deinen Code eingebunden und das Ergebnis als Anhang


Benutzt du auch  den Konverter von Laeubi-soft?

Meine Versuche sind erstmal gescheitert.


Gruß G.G.