Hallo G.G.,
Der Fehler war in der Verschaltung eines Kondensators.
Jetzt scheint es perfekt zu funktionieren :-)
Danke für die Hilfe und die Super- Lib.
Durch was muss ich denn diese "pgm_read_byte" und "pgm_read_word"
ersetzen, damit das auch auf meinem PIC läuft?
Habe mal versucht es einfach wegzulassen, aber damit bekomme ich nicht
die gewünschte Anzeige. =(
Hallo,
EGS_TI schrieb:> Durch was muss ich denn diese "pgm_read_byte" und "pgm_read_word"> ersetzen, damit das auch auf meinem PIC läuft?>> Habe mal versucht es einfach wegzulassen, aber damit bekomme ich nicht> die gewünschte Anzeige. =(
du musst bei den Fonts das PROGMEM entfernen
mit:
const uint8_t font_proportional_8px_data[] PROGMEM = {
0x02, 0x01, 0x03, 0x05, 0x05, 0x07, 0x05, 0x01, 0x03....
ohne:
const uint8_t font_proportional_8px_data[] = {
0x02, 0x01, 0x03, 0x05, 0x05, 0x07, 0x05, 0x01, 0x03....
dann pgm_read_byte und das "&" Zeichen entfernen.
Ob es dann funktioniert ist zweifelhaft, da manche Programmroutinen halt
auf das PROGMEM-Verfahren abgestützt sind. Das aber auf den ersten Blick
zu erkennbar, ist für einen Einsteiger schwierig.
Danke für deine Antwort. Das hab ich schon alles erkannt und gemacht.
Schließlich habe ich es ja zum Laufen gebracht. :)
Möchte mich aber eigentlich nicht so sehr mit AVR typischen
Angelegenheiten herumschlagen.
Vermutlich liegt es an den "pgm_read_word" Makros in den folgenden
beiden Funktionen aus der "font.c"-Datei:
Mein Compiler speichert Variablen automatisch im Flash, wenn diese mit
"const" deklariert/definiert werden. Auslesen kann man sie dann auch
wieder ganz normal, als ob sie im RAM stünden.
Ich hab aus den Funktionen einfach mal auf gut Glück folgendes draus
gemacht:
Ich möchte immer noch das 'A' auf Position Page 1 und Column 1 ausgeben
und es erscheint jetzt diese Anzeige.
Die Nullen und Doppelpunkte werden durch meine eigenen Funkionen
dargestellt.
Steht jetzt in tmp eine Adresse drin oder die Daten? oO
Wieso können die Displayhersteller denn nicht einfach ihre eigenen
plattformunabhängigen Bibliotheken erstellen?? :(
Hallo,
>Wieso wird hier auf "sizeof(tmp)" verglichen?
Das ist nur eine Auswahl um den Programmcode zu optimieren. Ist der
Pointer genau 2 Byte groß, kann pgm_read_word verwendet werden,
ansonsten muss das deutlich aufwendigere memcpy_P herhalten.
Das gleiche gilt für font_width(), gleich unterhalb im Code.
>Steht jetzt in tmp eine Adresse drin oder die Daten?
Wie der Kommentar über der Funktion sagt: Es ist der Pointer auf die
Daten. Schau dir auch mal die Definition von struct font_info ganz am
Ende von font.h an. FONT_P ist nämlich genau ein Pointer auf solch eine
Struktur.
Falls mal jemand mal Zeit und Lust hat mir zu helfen, hier mal die
Dateien die ich verwende.
Die Daten werden einfach durch ein "const" im Flash abgelegt.
Meine main:
Hallo,
ich habe mir Jans Lib auch gesaugt und implementiert. Nachdem es
nirgendwo dokumentiert ist wollte ich fragen, wie denn die Befehlsfolge
abläuft.
Ich habe eine init_spi_lcd() erstellt, wie es im Beispiel steht
allerdings frage ich mich, was das
1
SPDR=LCD_NOP;
sein soll. Da wirfts bei mir immer einen Fehler.
Durch etwas Suchen bin ich dann draufgekommen, dass
1
#define LCD_NOP() lcd_command(LCD_NO_OP)
allerdings, wenn ich es in meiner SPI Init ausbessere, die übrigens so
aussieht:
1
voidinit_spi_lcd(){
2
SPCR=1<<SPE|1<<MSTR|1<<CPOL|1<<CPHA;
3
SPDR=LCD_NOP();//Do not use 0 here, only LCD_NOP is allowed!
4
}
kommt folgender error: "void value not ignored as it ought to be"
Kann jemand bitte die minimale Befehlsfolge posten, sodass mit dieser
Lib überhaupt irgendwas einmal am DOGM dargestellt wird?
Danke.
Hallo,
eine Beschreibung im weitersten Sinne gibt es nicht.
Zuerst zu deinem Problem:
Floxx schrieb:> LCD_NOP;
Du musst in die dogm-graphic.h schauen!
#define LCD_NOP() lcd_command(LCD_NO_OP)
#if DISPLAY_TYPE == 128 || DISPLAY_TYPE == 132 || DISPLAY_TYPE == 102
#define LCD_NO_OP 0xE3 //22: NOP command
Der Fehler entsteht dadurch, dass dieser Befehl nur bei einem DOGM128
gültig ist. Du musst in der dogm-graphic.h das Display definieren.
#define DISPLAY_TYPE 128
Verwendest du ein anderes Display, so führt der Befehl unweigerlich zu
einem Fehler.
SPDR = LCD_NOP;
kannst du getrost weglassen, der Befehl bewirkt sowie so nichts.
Hallo G. G.!
Danke, aber das habe ich bereits alles schon durchprobiert. Ich habe
auch SPDR = 0xE3 gesendet, sowie alle nötigen Einstellungen gemacht,
jedoch bleibt der Bildschirm schwarz.
Ich werde mich am Dienstag nochmals dahinter klemmen.
Danke so far!
Hallo,
Das schreiben in SPDR bewirkt zwar nichts am Display, aber es setzt das
TX-ready Bit, ohne das die Routine, die die Daten ans Display sendet,
nicht arbeiten kann.
Es müsste reichen LCD_NOP durch LCD_NO_OP bzw. Den entsprechenden
no-operation Befehl für das Display zu ersetzen.
Hallo Jan,
Jan M. schrieb:> Das schreiben in SPDR bewirkt zwar nichts am Display, aber es setzt das> TX-ready Bit, ohne das die Routine, die die Daten ans Display sendet,
da hast du schon recht, aber SPDR = 0 hat sich bei meinen SPI-Routinen
stets bewährt.
Jan M. schrieb:> 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!
Hallo,
erstmal Kompliment für die Lib - somit konnte ich schon mal schnell ein
paar Zeichen auf's Display zaubern.
Aber nun noch ein paar Anmerkungen:
Zitat siehe oben: ich arbeite mit V.94 - da ist der Offset von 4 Pixeln
noch nich implementiert - gibt es bereits eine neuere Version?
Bei Schriftart: FONT_FIXED_8 bekomme ich die Fehlermeldung "FONT_FIXED_8
undeclared..."
eine kleine main.c mit der Inititalisierung als "ready-to-use"-Lib würde
den Einstieg vereinfachen und sicher einige Fragen überflüssig machen.
Wie hier schon erwähnt wurde, wären Funktionen um Linien oder sogar
Kreise zu zeichnen ganz nett. Gibt es da etwas kompatibles?
Gruß Dirk
Hallo,
die lib funktioniert wirklich super, jetzt habe ich nur ein Problem bei
der Nutzung des Displays im 12 o'clock mode bei "lcd_clear_area".
Den Offset in den für die Columns ist korrekt, nur beim löschen bleiben
die letzten columns stehen.
Gibt es dafür Abhilfe?
Danke schonmal.
Hallo G. G.,
das war leider nicht das Problem :-(
Es hängt vermutlich mit dem Offset bei der 12Uhr Darstellung zusammen...
Wenn einer noch Ideen hat, immer her damit :-)
>bei der Nutzung des Displays im 12 o'clock mode bei "lcd_clear_area".>Den Offset in den für die Columns ist korrekt, nur beim löschen bleiben>die letzten columns stehen.
Hallo Daniel,
um welches Display geht es denn? Hast du den Offset "von Hand"
eingefügt?
Ich habe hier auch noch eine neue Lib, die das automatisch macht, muss
sie nur noch fertig testen.
Das habe ich vorerst nur "händisch" eingebaut, z.B.: so
1
lcd_moveto_xy(0,LCD_COL_OFFSET+0);
Im Moment will ich das in Deine Funktionen integrieren, aber scheitere
schon beim Löschen des Displays :-(
Ich denke beim Line Wrap sollte das so funktionieren?
Hier ist die neuste Version der Library. Die einzige wesentliche
Änderung ist die Unterstützung des topview-Modus (siehe Definition in
dogm-graphic.h Zeile 18) inklusive automatischer Berücksichtigung der
verschobenen Column-Adressen. Ich konnte diese Änderung nicht selbst
testen mangels Displays, habe aber gehört, dass sie funktioniert.
Hallo Jan,
ich habe die neue Version auf einem DOGM128-6 getestet und was soll ich
sagen - es ist perfekt.
Super Lib und vielen Dank für die Hilfe hier.
VG Daniel
Hallo,
ich nutze zur Zeit das DOG-M 3x16 Textdisplay und wollte jetzt auf ein
Grafikdisplay umsteigen, da ich gerne auch später Grafiken/Logos
darstellen möchte.
Beim Textdisplay gebe ich ja Text im Arduino so aus:
....
lcd.setCursor(0, 0);
lcd.print("Text:");
....
....
wie sieht das bei einem Grafikdisplay wie dem EA DOGS102N-6 aus. Hat da
jemand einen kurzen Beispielcode?
VG
Florian
Hi, ich nochmal...
Habe mir mal den Programmspeicher in der IDE angeguckt siehe mein Bild.
Könnte es sein, dass der RETLW Befehl dort irgendwelche Probleme macht?
Vielen Dank für Eure Hilfe!!
Hallo EGS_TI,
das ist kein Problem, das sind ja einfach nur Daten und kein
Programmcode der jemals augeführt wird. Dass der Disassembler dort meint
einen Befehl zu erkennen liegt nur daran, dass er keine Möglichkeit hat,
Code und Daten zu unterscheiden.
Ja, is ja klar, dass das nicht ausgeführt wird, aber ich schreibe doch
eigentlich an die jeweilige Adresse nur das was im Font-Array drin
steht. Und da steht doch nicht überall eine 34 davor.
Ohjeee, der Programmspeicher des PIC ist 14 Bit breit.. Das könnte
eventuell das Problem sein. :(
Hallo liebe Freunde,
ich komme mit der Library einfach nicht weiter. Irgendetwas scheint
nicht zu stimmen (ach nee...).
Hat vielleicht jemand einen Tipp für mich, wie ich das ganze etwas
systematischer angehen kann?
Diese scheiß Microchip IDEs kann man ja auch alle getrost in der Pfeiffe
rauchen. Der Kacksimulator tut auch nicht was er soll und... ach zum
Verzweifeln...
Gute Nacht
Hallo LCD Freunde,
endlich habe ich es geschafft, dass Display mit dieser Library etwas
sinnvolles anzeigen zu lassen.
Als ich vorhin begann das hier zu schreiben, hat das Display nur einen
einzigen Buchstaben eines Strings angezeigt. Und zwar immer nur den
letzten.
Ich vermutete, dass irgendetwas in der "lcd_put_char"-Routine nicht
stimmte. Bevor ich hier also irgendwelche oberflächlichen Vermutungen
anstellen wollte und ich nicht wusste wo ich ansetzen sollte habe ich
mein Projekt nochmal geöffnet und mit den original Library Daten
verglichen.
Dabei ist mir dann aufgefallen, dass ich in meiner eigenen
lcd_data-Routine das "lcd_inc_column(1);" am Ende vergessen hatte.
Siehe original Routine:
1
voidlcd_data(uint8_tdata){
2
LCD_SELECT();
3
LCD_DRAM();
4
spi_write(data);
5
LCD_UNSELECT();
6
7
lcd_inc_column(1);
8
}
Nachdem ich meine Routine ergänzte zeigte mein Display nun alle bis auf
das Erste Zeichen an. Die Position an dem das erste Zeichen erscheinen
müsste ist "weiß".
Hat vielleicht jemand eine Idee woran das liegen kann?
Moin zusammen, ich habe gestern für ein neues Projekt ein Dog128-L an
einen XMega128A3 angebunden. War durch die Lib total einfach. Danke für
die tolle Arbeit. Mir ist dabei aber aufgefallen, dass das Löschen des
ganzen Displays (was ja auch in der lcd-init() mit durchlaufen wird)
nicht sauber funktioniert. Es wird nur die erste der acht Pages des
Displays gelöscht. Bemerkt hab ich das, weil das Display aufgrund meiner
falschen Power_Control Einstellung kurzfristig nur Müll angezeigt hat
und dieser nur in den ersten acht Zeilen (1. Page) gelöscht wurde. Das
Problem steckt m.E. hier:
Ich denke hier soll abgefangen werden, dass nach einem Wraparound
(Column==0) schon automatisch auf die nächste Page hochgezählt wurde.
Der Columns-Wert wird durch diesen Aufruf dann aber negativ und daher
automatisch die Page wieder zurückgezählt. Daher bleibt der Löschbereich
immer in der ersten Page, wenn die letze Column das Ende des angegebenen
Löschbereichs ist
Könnt ihr das Problem nachvollziehen?
Viele Grüße aus Hamburg
Hallo Jens,
wenn ich mir diese Zeile gerade anschauen weiß ich gar nicht mehr, warum
diese Abfrage da drin ist - ich komme gerade auf keinen Fall wo "0"
richtig wäre, aber vielleicht übersehe ich auch nur etwas. Irgendeinen
Grund muss es gehabt haben.
Im Augenblick würde ich sagen: Schmeiß die Abfrage raus und schreibe fix
eine 1 hin.
Moin Jan, danke für die superschnelle Antwort nach ein paar Minuten. So
schnell hatte ich gar nicht damit gerechnet. Habs schon genauso gemacht.
In älteren Versionen deiner Lib steht auch nur die 1 drin.
Thx, Jens
Hallo,
ich hatte die lib an einen xmega 128A3 angebunden und was soll ich sagen
- funktioniert super.
Jetzt habe ich nur ein Problem mit den Umlauten, mit lcd_putstr() wird
mir bei den Umlauten nur Mist angezeigt. Komischerweise ist das aber
erst seitdem ich auf das AS6 umgestellt habe, auch mit lcd_putc(252) "ü"
funktioniert das nicht.
Hat da einer eine Idee? Vielleicht wurde nur ein Header der toolchain
nicht richtig eingebunden?
Danke schon mal.
Hallo Jan,
danke für die Info, aber das Ergebnis ist das gleiche :-(
Selbst wenn ich z.B. lcd_putstr("Übung") benutze, bekomme ich "Mist"
gefolgt von "bung" angezeigt.
Hast Du noch eine Idee?
ich habe mir die Sache nochmal im Debugger angeschaut:
Aufruf:
lcd_putc(129);
in der Funktion:
uint8_t lcd_putc(char c) {
return lcd_put_char(global_font_select, global_font_style, c);
}
hat "c" einen Wert von -127
Ich bin ratlos...
-127 (signed) ist ja 129 (unsigned), soweit stimmt das. Ich arbeite
üblicherweise mit unsigned char, und du (zumindest im Debugger) mit
signed char als Standard. Stell deinen Compiler mal auf unsigned um - es
kann gut sein, dass irgendeine Rechnung schiefläuft wenn mit Vorzeichen
gerechnet wird. Zum Umstellen gibt's irgendwo einen Button bzw. die
compiler Option -funsigned_char.
Hallo Jan,
danke für den Tipp :-)
Ich hatte bisher auch alle Projekte mit unsigned als Standard, das war
hier leider nicht so.
Jetzt läuft es auf jeden Fall - Super Support kann ich da nur sagen.
Noch eine Frage hätte ich aber:
Ist es möglich einzelne Zeichen des Font umzugestalten, z.B. in Symbole?
Das geht doch bestimmt nicht mit dem Fontcreator, oder?
Daniel Held schrieb:> Ist es möglich einzelne Zeichen des Font umzugestalten, z.B. in Symbole?> Das geht doch bestimmt nicht mit dem Fontcreator, oder?
Doch, das ist kein (großes) Problem. Die *.font kannst du im Fontcreator
öffnen und beliebig editieren. Du musst nur darauf achten, dass sich die
Höhe nicht ändert und unkomprimiert gespeichert wird. Vorher noch die
.ini anpassen und das template aus dem Archiv eintragen damit das Format
beim exportieren stimmt.
Ich würde aber empfehlen, einen der schon existierenden Symbol-Fonts zu
erweitern oder einen neuen zu erstellen. Und wenn du fertig bist darfst
du das Ergebnis natürlich auch gerne hier hochladen :-)
OK, gute Idee.
Als Template meinst Du die "template_simplefont.c" nehme ich an.
Muss ich damit in der *.ini die "template.c" unter export_unused
ersetzen?
Danke! Kannst du noch die .font hochladen, damit man die Symbole weiter
editieren kann? Und darf ich sie in meinen Quellcode hinzufügen und mit
der nächsten Version hochladen?
Hallo zusammen
Eigentlich will ich hier im Trade nicht über die Entwicklung an meinem
AVR-Synthesizer schreiben. Das kann man ausführlich im CC2-Forum tun
wenn man Lust verspürt und Interesse an Musikelektronik hat :).
Link zu meinem Synthesizer-Projekt im CC2-Forum:
http://www.cczwei-forum.de/cc2/thread.php?postid=81924#post81924
Aber weshalb ich hier poste ist die Tatsache, das ich für die
Menüsteuerung in meinem Synthesizer ein DOGXL160W-7 Display verwende und
einen Teil der EADOGM-Library 0.94 hier aus dem Forum. Besten Dank an
die Entwickler :=)
Ich habe davor ein anderes Grafik Display eDIP160W-7 verwendet, das ich
wegen der schlechten Performance gegen ein neues Display vom Typ
DOGXL160W-7 ausgewechselt habe. Den Neukauf hätte ich mir allerdings
sparen können. Denn bei genauer Betrachtung des alten Displays (siehe
Bild 1) ist mir aufgefallen, das im Inneren das gleiche Display
verwendet wird, nur mit einer Platine davor, auf der ein ATMega128 mit
12MHz für die Displayansteuerung sitzt. Da ich das neue Display direkt
über die SPI-Schnittstelle meines Xmega-Controller mit 8MHz ansteuern
kann, ist die Darstellung von Text und Grafik wesentlich schneller als
beim alten Display.
Im Vergleich zum alten eDIP160W-7 Display (weises LED-Backlight), ist
die Ansteuerung des neuen Displays (günes LED-Backlight) etwas
aufwendiger. Aber das ganze ist kein Hexenwerk und im Internet gibts
eine Menge freie AVR-Library's für die DOG-Displays. Mein nächster
Schritt ist jetzt die Implementierung von einfachen Grafikfunktionen um
Wellenformen und Linien dazustellen. Mal schaun wie ich das wieder
hinbekomme.
Im Anhang ein paar Pics vom alten und neuen Display. Zusätzlich eine
Plot-Funktion die einen Punkt setzt (nur für DOGXL160 geeignet). Die
Routine ist noch nicht optimiert. Reicht aber aus um eine Wellenform aus
dem Programmspeicher dazustellen.
Gruß Rolf
Anhang: Plot-Funktion
---------------------
Hallo..
Hab gerade noch von einem guten Freund aus dem CC2-Forum einen Link
bezüglich Grafikfunktionen für ein Display bekommen. Möchte ich euch
nicht vorenthalten. Werde es die Tage mal versuchen auf meinem Display
umzusetzen.
Link Bresenham-Algorithmus:
http://de.wikipedia.org/wiki/Bresenham-Algorithmus
Gruß Rolf
Hallo,
ich habe ein Problem mit der Display Orientation. 1 zeigt Blickwinkel 12
Uhr, soweit alles OK. Setzte ich ORIENTATION_UPSIDEDOWN 0 wird alles
gespiegelt angezeigt. Woran kann das liegen?
Library v0.95
Display: EA-DOGL128
Vielen Dank für Eure Hilfe!
*) Bitte beachten Sie, dass für die 6:00 Darstellung ADC auf „reverse“
gesetzt werden muss (gespiegeltes Layout) !
(bottom view 6:00)
ADC set = $A1
Common output mode select = $C0
(Top View 12:00)
ADC set = $A0
Common output mode select = $C8
Gruß Rolf
Hallo Mathias,
das kann ich dir nicht erklären - wie du in der init-Routine siehst,
werden zwei Register leicht anders beschrieben (spiegeln in x-Richtung
und spiegeln in y-Richtung werden getrennt gesetzt und ergeben zusammen
die 180°-Drehung). Spiel doch mal mit diesen Befehlen beim init etwas
herum, vielleicht erkennst du ein Muster und findest so heraus, was
genau schiefläuft.
Hallo Rolf,
einige Vektorgrafik-Routinen für Linien, Kreise und so weiter sind
einfach zu programmieren - der Grund warum sie in meiner Library fehlen
ist nicht der Aufwand, sondern der Umstand, dass man bei den
DOG-Displays nur ganze Bytes schreiben aber nicht wieder lesen kann. So
lassen sich immer nur 8 Pixel gleichzeitig setzen und kann keine Objekte
übereinander / direkt nebeneinander zeichnen. Man bräuchte dafür einen
eigenen Video-RAM im Controller, aber damit sind die meisten kleinen
Atmega ja überfordert - Deswegen gibt's bei mir keine Grafikfunktionen,
aber ich freue mich, dass das mit deinem Display so schön funktioniert.
Hallo Jan,
Bei der Programmierung der Grafik-Routinen für das DOGXL160W-7 Display
tue ich mich etwas schwer.Ich benötige eigentlich nur eine Punkt- und
Linien-Funktion. Ich habe es jetzt irgendwie hinbekommen, einfache
Linien mit dem Bresenham-Algorithmus zu zeichnen. Aber das ganze läuft
noch nicht so rund. Beim zeichenen treten noch Pixel-Fehler auf. Ich
benutze für das setzen der einzelnen Punkte ein 160*13 Byte großen
Speicherbereich im Xmega128A1. Da ich für die Wellenform-Darstellung von
links nach rechts zeichne, müsste es möglich sein, den Speicherbedarf
auf maximal 13+1 Byte zu reduzieren. Die Idee: Wird für einen Pixel eine
neue X-Position berechnet, lösche ich die 13 Bytes für die alten
Y-Positionen (104 Zeilen/8),speicher den neuen Y-Wert in das 1.Byte und
übertrage es zum Display. So spare ich Zeit und komme ohne großen
Speicherbedarf aus. Soweit die Theorie.. Mal schaun obs klappt :=).
Gruß Rolf
Nachtrag: Hier zwei Funktionen fürs zeichnen einer Linie mit
implementierter Bresenham-Algorithmus. Nur fürs DOGXL160W-7 geeignet.
Diese Funktion verwendet für die Pixel-Darstellung auf dem DOGXL160W-7
einen 2080 Byte großen Speicherbereich im XMega. Wie im letzten Beitrag
schon erwähnt, versuche den Speicherbedarf noch zu reduzieren.
Hallo
Hier noch ein paar Pics. Gut zu erkennen die Pixel-Fehler. Im Anhang die
kompletten C-Funktionen fürs zeichnen einer Wellenform auf dem
DOGXL160W-7.
Gruß Rolf
Hallo
Der Fehler in der Pixeldarstellung habe ich zwar noch nicht gefunden,
aber ich konnte die C-Funktion fürs Zeichnen einer Linie jetzt so
abändern, das sie nur noch 13 Byte im Ram benötigt (siehe Anhang).
Gruß Rolf
Hallo zusammen..
Ich habe den Fehler gefunden. Die Pixelfehler wurden durch die
Zeichenrichtung von Unten nach Oben verursacht wenn x1 > x2 war.
Jetzt habe ich eine if-Abfrage implementiert, die die Zeichenrichtung in
Y-Richtung ändert, wenn x1 > x2 ist.
Funktion zum zeichnen einer Wellenform auf dem Display.
1
wave_adr=wave_index*256;
2
for(uint8_ti=0;i<128;i++)
3
{
4
yplot=pgm_read_byte(&(avrx_bank00[wave_adr]));
5
yplot=255-yplot;
6
yplot=(yplot/6)+22;
7
x1=i+15;y1=yplot;
8
if(x1<x2)// if x1 < X2 draw from up to down
9
{
10
LCD_Plot_Line(x1,y1,x2,y2);
11
}
12
elseLCD_Plot_Line(x2,y2,x1,y1);// else draw form down to up
13
14
// next sample_adr.
15
xplot++;
16
wave_adr=wave_adr+adr_offset;
17
x2=x1;y2=y1;
18
}
Die Buffergröße für die Zeichenfunktion konnte ich stark reduzieren.
Jetzt werden für das zeichnen einer Wellenform nur noch 13 Bytes im Ram
benötigt. Darin werden die Y-Pixel für einen Samplewert gespeichert und
wieder gelöscht, wenn x1 um eins erhöht wird. Die kompletten Routinen im
Anhang.
Gruß Rolf
Hallo.. ich schon wieder :)
Wer gerne mit der 2080 Byte großen Buffer-Version für das Zeichenen von
Linien und Punkten arbeiten möchte, Vorteil Objekte können direkt neben-
und überanander gezeichnet werden, für den habe ich im Anhang die
gleichen Routinen nur mit großem Display-Buffer hinterlegt.
Info: In der Funktion "void LCD_Plot_Wave(uint8_t wave_index)" habe ich
für Testzwecke einen Timer mitlaufen, der mir die benötigte Zeit für das
Zeichnen einer Wellenform-Line anzeigt.
Gruß Rolf
Hallo
Im Anhang noch drei weitere Funktionen zum zeichnen eines Rechtecks
(Rahmen oder gefüllt), einer vertikalen und horizontalen Linie. Die
Funktion zum Zeichnen eines gefüllten Rechtecks ist hier allerdings noch
sehr langsam, da jeder Pixel einzeln gesetzt wird. Ich denke das man
dies noch optimieren kann, indem man direkt 4 Pixel in eine
Speicheradresse schreibt bzw ausliest. Momentan wird jeder Pixel einzeln
mit dem Inhalt einer Speicheradresse (4 Pixel) maskiert und
abgespeichert. Eine Speicheradresse beinhaltet 4 Pixel (Y-Richtung) und
4Bit für die Grauwerte.
Gruß Rolf
Hallo zusammen..
Da ich gerade an einer Scope-Funktion für den AVR-Synth "bastle" habe
ich mal schnell ein Video davon gemacht.
http://www.youtube.com/watch?v=_IJ8TA7NLr0
Die Scope-Funktion bekommt später eine eigene Menü-Seite im AVR-Synth.
Im Moment funktioniert sie sobald eine Taste auf dem Keyboard gedrückt
wird. Meine Idee ist es, im Osc-Menü oben rechts ein kleines
Mini-Fenster anzuordnen, in dem das Audiosignal vom Ausgang angezeigt
wird. So kann man direkt sehen welchen Einfluss die ausgewählte
Oszilator-Wellenform auf das Ausgangssignal hat.
Gruß Rolf
main.c:174: error: incompatible type for argument 1 of 'lcd_put_string'
3
make.exe: *** [main.o] Error 1
Ist bite jemand so nett und stellt nochmal einen dreizeiler rein, wie
man das mit den Schriften nun macht?
Ich sehe nicht durch: der Ordner "Fonts" wird im Makefile mit angegeben?
wenn ja - wie und wo?
Ziel sollte es sein, kleine und große Schriften verwenden zu können...
In der Font.h habe ich ersteinmal nur den einen fixen font "eingestellt"
im Makefile habe ich die entsprechende Fontdatei mit hinzugefügt und un
der font.h die passende Zeile einkommentiert.
Aber muss das so?? Habe ich da etwas überlesen oder ist das alles
richitg jetzt? Ich sehe es mir einfach nocheinmal an... ( Vorerst geht's
ja ;) )
Axelr.
Axel R. schrieb:> Aber muss das so?? Habe ich da etwas überlesen oder ist das alles> richitg jetzt?
Das ist so richtig, gedacht ist es etwas anders. In font.h gibt es ein
define, das "schönere" Namen definiert:
Vielen Dank für den Hinweis!
Wie blind muss man sein? ;)
Beim Beispiel war der 8ter fixed Font ausgewählt. Da fiehl das, der
84komma615%tigen Namensgleichheit zum define geschuldet, nicht auf.
Anfangs hatte es funktioniert, bis ich dann (irgentwann) nicht mehr
"FONT_FIXED_8" angab, sondern aus Unachtsamkeit "font_fixed_8px"...
Nochmals vielen Dank für die Erklärung.
Axelr.
BTW: wer hier nur Hobbyprogrammierer ist, hat es mit den ...zig
verschachtelten #defines sehr schwer, durchzublicken.
Trotz alledem bzw. gerade daher: Großen Respekt und vielen Dank für die
geleistete Arbeit Dir und allen Beteiligten.
Hallo,
kurzes Update:
Die aktuelle Code-Version gibt es ab sofort auf github:
https://github.com/mueschel/lcdlib
Neu dabei sind:
- 16 Pixel hoher Font mit fixer Breite
- eine kleine Library für ein 240x320 Farb-LCD mit SPI inklusive der
Anbindung an den vorhandenen Font-Generator. Grafik-Funktionen gibt es
noch nicht, aber das kann sich ja auch noch ändern.
@Rolf: Schickes Design!
Hallo,
erstmal möchte ich ein ganz großes Dankeschön vorausschicken an Jan und
alle anderen, die zu der Bibliothek beigetragen haben.
Ich habe ein kleines Problem.
Kurzform:
Ich nutze die Bibliothek zum Ansteuern eines DOGS102 und habe heute nach
langer Pause das Projekt wieder aufgenommen.
1
lcd_clear_area_xy(8,102,NORMAL,0,0)
hat nicht mehr richtig funktioniert (vorher ohne Probleme) und ich
musste
1
#define LCD_WIDTH
von 102 auf 103 setzen. Nun scheint alles wieder zu funktionieren. Was
ist da los?
Langform:
Ich wollte gestern, nach ca. 1,5 Jahren Pause, endlich mal an einem
Projekt weiterarbeiten. Es nutzt diese Bibliothek um ein DOGS102
anzusteuern.
Ich war damals bereits so weit gekommen, dass ich eine einfache
Menüstruktur umgesetzt hatte.
Also Projekt mit make kompiliert und übertragen - nichts ging!
Nach einigem herumprobieren habe ich ein anderes Projekt genommen,
nicht neu kompiliert und übertragen - und siehe da, es funktionierte.
Dann habe ich es neu kompiliert und den gleichen Fehler bekommen.
Ich konnte den Fehler dann auf die Funktion lcd_clear_area_xy()
eingrenzen.
Mit
1
lcd_clear_area_xy(8,102,NORMAL,0,0)
wurde nur die erste Zeile gelöscht. Mit
1
lcd_clear_area_xy(8,101,NORMAL,0,0)
wurde dann das ganze Display außer die letzte Spalte gelöscht. Ich
vermutete ein Problem mit dem Zeilenumbruch und habe
1
#define LCD_WIDTH
auf 103 gesetzt und seitdem scheint alles zu funktionieren...
Alles schön und gut aber jetzt wüsste ich doch gerne warum?
Ich bin, was das Programmieren angeht nicht besonders bewandert, aber
ich vermute mal das ist ein Problem mit dem Kompiler, oder? Nun ist die
Frage, ob es große Änderungen im gcc-Kompiler gab (hab mir gestern den
neuen heruntergeladen), oder ich irgendeine Einstellung ändern muss.
Wie gesagt, die Programme haben alle schon einmal funktioniert.
Viele Grüße
Christoph
Hallo Jan M.
habe dein Library für ein 240x320 Farb-LCD getestet.
Hintergrund und Vordergrund kann ich einstellen und funktioniert
bestens.
Ebenso die Cursor-Steuerung lcd_set_pixel_xy()
Aber die eigentliche Ausgabe für Text:
void lcd_write_font_byte(uint8_t b)
{
usw..
}
funktioniert nicht!
Hier fehlt mir irgendwie der Zusammenhang mit der Font-Geschichte!
Vielleicht kannst du mir da weiterhelfen.
Danke
G.G.
Hallo Gerhard,
lcd_write_font_byte() ist eine Hilfsfunktion für die Font-Library.
Diese nutzt ein #define in font.h, das eine Funktion festlegt, die die
Daten ans LCD schickt:
https://github.com/mueschel/lcdlib/blob/master/font.h#L115
1
#define LCD_WRITE(x) lcd_data((x))
Dort muss dann lcd_write_font_byte() angegeben werden anstelle von
lcd_data().
Hallo Jan,
funktioniert bestens!!
Habe ein TFT-1.8" (ST7735) Display genommen. Das Display hat die selbe
Adressierung und die Register stimmen auch.
Noch ein Vorteil: die ganze Sache funktioniert auch mit printf(),
was bei den meisten TFT-Lib's nicht der Fall ist. Das komplette
Überschreiben von Text ist auch möglich.
Werde die nächsten Tage mal den Code (Atxmega..) hier einstellen!
Vielen Dank nochmals
G.G.
Hallo,
ich möchte mir ein DOGXL240W-7 zulegen und habe folgenden Text in einem
Onlineshop gelesen:
Diese neue Displayserie wurde speziell für low-power Handheld
Applikationen entwickelt. Erstmals ist der Betrieb eines
Standard-Displays direkt an 3,3V möglich! Ein 5V Betrieb ist bei den
Textdisplays ebenso möglich. Auch die optional erhältlichen
LED-Beleuchtungen laufen in der Regel mit 3,3V oder 5V.
Habe hier aber etwas von Pegelwandler mit 5V Controller gelesen und im
Datenblatt steht ebenfalls Supply 3.3V. Das Display soll bei mir an
einen PIC18 mit 5V Versorgungsspannung. Funktioniert das Display da
direkt an 5V?
LG
Hallo,
das entscheidende Wort im Werbetext ist "*Text*display" - die reinen
Text-LCD können mit 5V betrieben werden, die Grafikdisplays nicht. Diese
brauchen in jedem Fall eine 3.3V Versorgungsspannung und entsprechende
Pegel an den Logikeingängen.
Gruß, Jan
Hallo Zusammen,
ich dachte mir ich schreibe hier mal direkt weiter, nachdem auf dieses
doch etwas längere Thema gestoßen bin.
Ich selbst verbaue gerade in einem Projekt ein DOGXL240-7
(http://www.reichelt.de/EA-DOGXL240S-7/3/index.html?&ACTION=3&LA=446&ARTICLE=140444&artnr=EA+DOGXL240S-7&SEARCH=dogxl240).
Ich selbst befasse mich jetzt schon etwas länger mit Mikrocontroller und
benutze aktuell den Atmega1284P, welchen ich in C programmiere.
Vorgesehen ist die Ansteuerung des Displays in I²C, da ich dann ja auch
Daten lesen kann und das einige Vorteile zu bringen scheint ?
Ich bin dabei auf dieses Thema hier gestoßen, welches mir beim ersten
Kontakt mit grafischen Displays wohl ziehmlich helfen wird. Vielen Dank
hier schonmal an die Autoren. Meine Frage ist nun, ob ich die aktuellste
Version einfach auf ein 240er anpassen kann oder ob ich auf etwas mehr
achten muss ? Mir scheint es so, dass ich lediglich die Tabellen des
Datenblatt mit dem bereits programmierten vergleichen und abändern muss
!?!? Wäre dann ja ziemlich "einfach" (so die Theorie).
Liebe Grüße
André
Hallo André,
viele Änderungen werden nicht nötig sein. Anscheinend ist ein anderer
Controller verbaut als bei den restlichen LCDs, d.h. du musst die
Befehlsliste in dogm-graphic.h anpassen. Die Initialisierungssequenz
muss natürlich auch angepasst werden, aber dann sollte alles zunächst
einmal laufen.
Wenn du I2C verwenden willst, dann musst du auch nur die Ausgaberoutine
entsprechend anpassen. Das Lesen von Displayinhalten wird dann zwar noch
nicht unterstützt. Das ist eigentlich auch nur bei der Darstellung von
kleinen Grafiken (Linien, Kreisen...) nötig, und diese sind bei meiner
Lib ja auch noch nicht enthalten.
Die aktuelle Version liegt wie gehabt auf github:
https://github.com/mueschel/lcdlib .
Ich würde mich freuen, wenn wir deine Erweiterungen dann später mit in
das Repository aufnehmen könnten.
Gruß, Jan
Hallo Jan,
wie du richtig erkannt hast ist hier der UC1611s verbaut, ist jedoch
ähnlich zu den anderen. Ich werde mal schauen, dass ich die Tage alles
anpasse und anschließe und melde mich dann entweder mit Erfolg oder
Problemen erneut.
Vielen Dank schonmal für die schnelle Antwort und die Erweiterungen
dürfen dann natürlich gern ins Repository aufgenommen werden.
Gruß André
Hallo Jan,
vorerst vielen Dank für die lib.
Ich habe jetzt aber doch ein Problem - seit der Umstellung auf Atmel
Studio 6.2 werden die Umlaute nicht mehr korrekt dargestellt, es wird
dann immer anstelle des Umlautes ein relativ langer String angezeigt.
Ich habe 2 Projekte und nutze bei beiden eine ATXmega das mit dem AS6
kompilierte läuft perfekt und bei dem mit AS6.2 tritt der Fehler auf.
Hast Du evtl. eine Idee an was das liegen könnte?
Vielen Dank
Daniel
Mittlerweile bin ich etwas weiter gekommen, konnte das Problem aber noch
nicht lösen :-(
Die Funktion "font_get_char_width(font,character);" gibt eine falsche
Länge zurück - im Beispiel von"ü" -> 57 normal wäre da 7
Ich stehe voll auf dem Schlauch...
Hallo Daniel,
das klingt nach einem encoding Problem. Wenn du literale Umlaute hast,
muss der String im Quellcode als ASCII gespeichert werden, nicht als
UTF-8. Wie man AVR Studio das beibringt weiß ich nicht.
Probiere einfach mal statt dem 'ü' ein \x81 in den String zu packen,
dann steht wirkliche ein ü im String im uC.
Hallo Jan,
Danke für die Unterstützung :-)
Leider bringt "\x81" ein ähnliches Ergebnis. Im Debugger wird in der
Fkt. lcd_put_char der korrekte Wert für den Character angezeigt (0x81),
aber die Länge aus der Fkt. font_get_char_width ergibt immer noch 57
(0x39). Ich vermute evtl. ein Problem bei den pgm_read_.. Funktionen?
VG Daniel
Hallo Jan,
es handelt sich wohl nur um ein Vorzeichenproblem. Ich habe das jetzt
vorerst durch einige casts gelöst.
Vielen Dank für die Hilfe
VG
Daniel
/***********************************************************************
*******
* Get the number of the character in the given font
*/
inline int16_t font_get_char_number(FONT_P font, char character) {
FONT_P tmp = font;
if ((unsigned char)character > pgm_read_byte(&tmp->lastchar))
return -1;
uint8_t first = pgm_read_byte(&tmp->firstchar);
if ((unsigned char)character < first)
return -1;
return (unsigned char)character - first;
}
Hallo Forum,
ich wollte mal von BASCOM weg und AVR Studio verwenden. Ich möchte mir
einem ATmega8 das DOGm132 ansteuern. Da ich sehr lange nicht mehr
richtig Programmiert habe stehe ich gerade vor einem riesen
Fragezeichen.
Ich benötige eine Kurze Einweisung.
Ich habe die Library Heruntergelden.
in mein Programm eingepflegt. Und wollte folgendes Kompilieren
#include "C:\Users\tci\Desktop\Includes\dogm-graphic.c"
#include "C:\Users\tci\Desktop\Includes\font.c"
#include <avr/io.h>
#define F_CPU 1000000UL
int main(void)
{
while(1)
{
init_spi_lcd();
lcd_init() ;
lcd_put_string_P(FONT_PROP_16,NORMAL, PSTR("Hallo Welt"));
}
}
Ich bekomme einige Fehlermeldungen
TXC1 undeclared(first use in this function)
UDR1 " " " " " "
UCSR1A " " " " " "
Ich mache anscheindend Grundsätzlich einige dinge Falsch. Ein hinweis
oder Links wie es richtig geht wären nett.
Hallo Hive_Live,
binde mal nicht die *.c Dateien ein sondern die *.h Dateien.
In den so genannten Header-Files (*.h) werden dann auch die
entsprechenden Defines zugewiesen. Die musst Du dann natürlich noch an
Deine Hardware anpassen.
...und der richtige Befehl um einen String zu "drucken" wäre
lcd_putstr("Hier der String");
Im Datenblatt (Stand 1.2009, Seite 6) und in den Source Code Beispielen
zum DOGM132-5 LCD wird der Static Indicator Off mit einem 2 Byte Befehl
initialisiert:
0xAC Static Indicator Command mit Indicator Off
0x00 Static Indicator Register Set Command mit Flashing Mode Off
Und genau so wird es zur Zeit auch in dieser Lib gemacht. Ich vermute,
dass das falsch ist. Im Datenblatt (V1.5, 2006/03/10) des für das EA
DOGM132-5 verwendeten LCD Drivers ST7565R, steht nämlich auf Seite 46,
dass der Static Indicator Off Befehl im Gegensatz zum On Befehl ein
'single byte command' ist und demnach nur aus einem
0xAC Static Indicator Command mit Indicator Off
besteht.
Die 0x00 aus obiger Initialisierung wird deswegen als neuer Befehl
interpretiert und, da es diesen nicht gibt, hoffentlich ohne
Nebenwirkungen verworfen.
Wenn man im Netz sucht, finden sich sowohl Beispiele mit falscher 2 Byte
Initialisierung, als auch richtiger 1 Byte Initialisierung für den
Static Indicator Off Zustand. In dem Projekt, für das ich seit längerem
diverse Updates mache (OBD2-Analyser NG aus Elektor 09/2009), war es
auch falsch. Deswegen ist es mir überhaupt aufgefallen.
Um zu zeigen, dass der Static Indicator Off Befehl tatsächlich ein 1
Byte Befehl ist, ohne auf die FR und FRS Pins des ST7565R, auf die
dieser Befehl Auswirkungen hat, zuzugreifen, habe ich mir folgende
Sequenz überlegt und erfolgreich mit einem EA DOGM132-5 LCD getestet:
Ausgangszustand: Display ist On.
0xAE Display Off Befehl
Pause 1s
0xAC Static Indicator Off Befehl (1 Byte Befehl)
0xAF Display On Befehl -> Display geht an
Erwartet: Display geht aus und nach einer Sekunde wieder an
Getestet: OK, das ist so
Wäre es ein 2 Byte Befehl, würde sich der ST7565R nach dem ersten Byte
vom Static Indicator Off Befehl im Zustand 'Warte auf Static Indicator
Register Set' befinden. Und im nächsten gesendeten Byte nur auf die
Flashing Mode Werte 00, 01, 10 oder 11 in Bit 0..1 achten.
Der Display On Befehl 0xAF würde dann als Flashing Mode 11 für Bit 0..1
für den Static Indicator Register Set Befehl interpretiert und das
Display bliebe dunkel. Das Display geht aber wieder an, wie erwartet.
Gegenprobe:
Ausgangszustand: Display ist On.
0xAE Display Off Befehl
0xAD Static Indicator On Befehl (2 Byte Befehl)
0xAF Display On Befehl -> Display bleibt aus, trotz On Befehl
Warte auf Taste
0xAF Display On Befehl -> Display geht an, wie erwartet
Erwartet: Display bleibt bis zum Tastendruck aus, da 0xAF als Flashing
Mode 11 in Bit 0..1 für Static Indicator Register Set interpretiert wird
und geht erst nach Tastendruck nach dem nächsten 0xAF wieder an
Getestet: OK, das ist so
Fragt mich jetzt aber nicht, was beim 2 Byte Befehl 0xAD Static
Indicator On + 0x00 Static Indicator Register Set = Off, rauskommt. Ich
vermute mal, dass das identisch ist zum 1 Byte Befehl 0xAC Static
Indicator Off.
Eine andere Variante, die ich im Netz gesehen habe, ist, den Static
Indicator gar nicht explizit zu initialisieren, sondern auf den über
/RES ausgelösten Resetzustand (Static Indicator Off) zu vertrauen ;-)
Ich habe zu dem Thema auch den Hersteller EA des LC Displays
angeschrieben. Sollte er antworten, stelle ich hier das Ergebnis rein.
Hallo Forum,
Danke ich hatte die includes nicht im Program aktiviert.
Ich habe jetzt keine Fehler mehr und kann den µC Programmieren.
Trozdem bleibt das Display tot. Das Display ist richtig angeschlossen
das hab ich mehrfach Kontolliert.
Ich verwende einen ATmega8
Mein Oszi zeigt mir
B0 => Signal
B1 => H
B2 => Signal
B3 => GND
B4 => GND
B5 => GND
Setzte ich in der dogm-graphic.h LCD_USR_CHIPSELECT 0 liegt bis auf an
B1 => H GND an?
Meine Konfig in spi.c ist
#define LCD_A0 2
#define LCD_RST 1
#define LCD_CS 0
#define SPI_MOSI 3
#define SPI_MISO 4
#define SPI_SCK 5
Meine Konfig in dogm-graphic.h ist
//A0 Port (CD on DOGS & DOGXL)
#define PORT_A0 PORTB
#define DDR_A0 DDRB
#define PIN_A0 2
//Reset Port
#define PORT_RST PORTB
#define DDR_RST DDRB
#define PIN_RST 1
//Backlight Port
#if LCD_USE_BACKLIGHT != 0
#define PORT_LED PORTD
#define DDR_LED DDRD
#define PIN_LED 2
#endif
//Chip select
#if LCD_USE_CHIPSELECT == 1
#define PORT_CS PORTB
#define DDR_CS DDRB
#define PIN_CS 0
#endif
Ich weiss das solche Fragen nerven. Trozdem würde ich mich um eine
Antwort freuen.
Hallo,
ich versuche seit mehreren Stunden eine Grafik auf dem Display
auszugeben. Leider ohne Erfolg!
Jetzt möchte ich einfach nur eine Linie Anzeigen.
µC: Atmega8
Display: Dogm 132
int8_t Balken[] PROGMEM = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};
lcd_moveto_xy(0,0);
lcd_draw_image_P(Balken,1,8,NORMAL);
bei diesem code sehe ich folgendes:
X0-
Y0 oooooooo
| oooooooo
oooooooo
oxoooooo
oxooxoox
oxooxoox
ooooxoox
Hallo zusammen,
danke für die Library. Ich habe sie erfolgreich mit meinem DOGM128
getestet.
Allerdings musste ich LCD_WIDTH auf 129 ändern. Sonst kann ich Pixel 128
nicht löschen. Komisch...
Gruss
Inzwischen habe ich mir das Problem mit dem lcd_clear_area angeschaut.
Mit einer kleinen Änderung funktioniert es jetzt wie gewünscht. Mir ist
kein Fall aufgefallen, bei dem es nach dieser Änderung jetzt Probleme
geben sollte - falls doch, bitte einfach melden.
Die aktuelle Version liegt wie gehabt auf
https://github.com/mueschel/lcdlib
Hallo
die Ausgabe auf dem Display bleibt die gleiche. Ich weis nicht was ich
noch probieren kann. Ich habe das Display von DOGM132 auf DOGM128
gewechselt. Ich habe auf die neuste Version der Lib gewechselt. Ich weis
nicht mehr wie oft ich den ganzen Verlauf hier gelesen habe um das
Problem zu beheben.
Ich habe unterschiedlichste Bilder Konvertiert aber die Ausgabe war fast
immer dieses Streifenmuster oder ein vielfaches davon. Ich habe jetzt
~20Std in dieses Problem investiert. Ich bin für jede Hilfe oder
hinweise dankbar.
Die Ausgabe von Buchstaben funktioniert aber Tadellos.
Hallo,
in der Lib werden die Fonts mit "PROGMEM" im Flash-Speicher abgelegt!
Das ist nicht kompatible mit dem ARM Cortex-M3.
Die Lesebefehle dazu pgm_read_byte() müssten alle angepasst werden.
Genau wie Gerhard schreibt: Einige Befehle sind recht spezifisch und
werden deinem Compiler nicht gefallen. Aber außer diesen Lesebefehlen
aus dem Flash sowie der Initialisierung von Ports und SPI sollte nicht
viel zu machen sein, der eigentliche Programmcode hat da keine
Abhängigkeiten.
Hallo,
EGS_TI (guest) hatte mal wegen der Ansteuerung des LCDs mit einem PIC
angefragt.
Wollte fragen, ob nun er oder wer anderes eine Lib für einen PIC hat?
Gruß,
Marten
Hallo Forum
die Library fkt super. Nur eigene Fonts erstellen bekomme ich nicht hin.
Ich bekomme nur Zeichensalat.
Wenn ich eine font wie Digit_24px oder font_proportional_8px im font
Editor öffne nichts verändere und die font wieder Speicher bekomme ich
nur Zeichensalat. Die compress fkt ist ausgeschaltet adjust font height
ein und ausgeschaltet versucht. Immer Zeichensalat.
Mein Vorgehen.
- ich lade eine *.font in den Editor.
- ich verändere nichts und speichere die *.font in einem Extra
Verzeichnis/oder wieder im includierten font Ordner(kein unterschied)
- ich exportiere die *.h Datei
- Ich öffne die *.h Datei kopiere alle HEX werte und speichere Sie in
die includierte *.c Datei
Das habe ich mit der prop_8 und Digit_24 getan.
Was mache ich falsch. Ich beiß gleich in einen Bleistift
Hallo Ben,
Hast du das template in die .ini-Datei vom Editor eingetragen?
Ansonsten lade einfach mal eine deiner generierten Dateien hoch, damit
wir vergleich können.
Hallo Jan,
ich habe das template nicht in die .ini Datei eingetragen.
Ich werde das morgen früh mal probieren. Damit ich nicht zig mal
nachharken muss.
[export]
0=template_simplefont.c //wie oben erwähnt
Ich habe aber im Tool Ordner nur template.asm-.c-.h.. Trotzdem?
Ist das vorgehen das ich oben beschrieben habe denn richtig?
Vielen dank das du dich noch immer um den thread kümmerst!!
Das template_simplefont.c musst du dann noch in den Ordner vom Tool
kopieren damit es gefunden wird.
>Vielen dank das du dich noch immer um den thread kümmerst!!
Ich bastel ja auch immer noch an der Lib rum ;-)
Hi Jan,
ich habe mir gerade die neusten Dateien von deinem git runter geladen.
Und habe jetzt das Problem wenn die Funktion
lcd_draw_image_xy_P((char*)Image_xxx_BMP, 0, 0, 8, 128,0 );
so aufrufe das das Bild nicht auf Position 0,0 startet sondern auf der x
= 1
und somit ein 128x64 Bild um 1 nach rechts verschoben ist.
Liegt der Fehler bei mir oder ist ein Fehler im Code.?
Mit der Lib 094 von Gerhard und der
draw_partialpic_dogm128((char*)Image_xxx_BMP,0,0);
Funktion hatte das alles ohne Probleme funktioniert.
Danke im voraus.
Floh
Hallo Florian,
ein Überlauf über die Größe des Displays wird nicht so behandelt wie es
für Bilder notwendig wäre - dann geht es je nach Einstellung am Anfang
der nächsten oder derselben Zeile weiter. Im Prinzip muss in die
draw_image Funktion nur noch eine Abfrage rein, die überprüft, ob er am
Ende des Displays angekommen ist und dann richtig auf die nächste Zeile
schaltet.
Jan
Habe auch ein DOGM128 am laufen. zur Zeit mit der Lib von Ulrich Radig,
da sie etwas übersichtlicher ist.
Problem: egal was ich ausgebe, ich bekomm den Cursor nicht wieder an den
Anfang gestellt (sollte ja mit display_clear() gehen). Jeder
display_write() Befehl schiebt den Cursor weiter nach rechts, und dann
irgendwann aus dem Bild raus.
Jemand eine idee wie ich ihn wieder an den Anfang setze?
OK, es ist kein Text Display, deswegen wird es so eine Funktion nicht
geben. Man übergibt ja den kompletten Bildschirm-Inhalt. Also müsste man
eher bei dem Daten-Feld den man übergibt, den Cursor zurücksetzen.
Ich übergebe einen string an eine Funktion mittels Pointer.
zB
display_write("test1");
display_write("test2");
Was rauskommt ist
test1test2
Dabei soll der letzte Textr den vorhergehenden überschreiben.
Mehr als den String neu zu übergeben kann ich doch nicht machen oder wie
versteht man das? Man müsste den Pointer zurückstellen, was anscheinend
nicht gemacht wird.
Hallo zusammen,
ich versuche jetzt seit mehreren Wochen dieses Display zum laufen zu
bringen, leider ohne Erfolg.
- Atmega328p
- Dogm128-6
- 3.3V Betriebsspannung
bei mir wird das Display beim flashen kurz schwarz und geht dann aus.
ich bin mir nicht sicher ob das mit der Init bei mir richtig ist, vor
allem mit dem CS / SS PIN
Ich habe den SS PIN (PB2) einfach als Ausgang definiert.
in dogm-grpahic.h folgende config:
//Should chip select (CS) be used?
#define LCD_USE_CHIPSELECT 1
//Chip select
#if LCD_USE_CHIPSELECT == 1
#define PORT_CS PORTC
#define DDR_CS DDRC
#define PIN_CS PORTC1
#endif
auf PC1 ist CS von dem Display aufgelegt.
hier ist die init von der SPI:
#define SPI_SS PB2
#define SPI_MOSI PB3
#define SPI_MISO PB4
#define SPI_SCK PB5
void init_spi_lcd() {
DDRB = (1 << SPI_MOSI) | (1 << SPI_SCK) | (1 << SPI_SS);
PORTB &=~(1<<SPI_MISO);
SPCR = 0 << SPIE | 1 << SPE | 0 << DORD | 1 << MSTR | 1 << CPOL
| 1 << CPHA | 0 << SPR1 | 0 << SPR0;
SPSR = 1 << SPI2X;
SPDR = LCD_NO_OP; //Do not use 0 here, only LCD_NOP is allowed!
}
und hier noch die main:
int main(void)
{
init_spi_lcd();
lcd_init();
while(1)
{
lcd_move_xy(0,0);
lcd_put_string_P(FONT_FIXED_8, NORMAL, PSTR("Hallo
Welt"));
}
}
eigentlich gibt es da nicht all zu viel zum falsch machen oder?
Hallo zusammen,
ich versuche jetzt seit mehreren Wochen dieses Display zum laufen zu
bringen, leider ohne Erfolg.
- Atmega328p
- Dogm128-6
- 3.3V Betriebsspannung
bei mir wird das Display beim flashen kurz schwarz und geht dann aus.
ich bin mir nicht sicher ob das mit der Init bei mir richtig ist, vor
allem mit dem CS / SS PIN
Ich habe den SS PIN (PB2) einfach als Ausgang definiert.
in dogm-grpahic.h folgende config:
//Should chip select (CS) be used?
#define LCD_USE_CHIPSELECT 1
//Chip select
#if LCD_USE_CHIPSELECT == 1
#define PORT_CS PORTC
#define DDR_CS DDRC
#define PIN_CS PORTC1
#endif
auf PC1 ist CS von dem Display aufgelegt.
hier ist die init von der SPI:
#define SPI_SS PB2
#define SPI_MOSI PB3
#define SPI_MISO PB4
#define SPI_SCK PB5
void init_spi_lcd() {
DDRB = (1 << SPI_MOSI) | (1 << SPI_SCK) | (1 << SPI_SS);
PORTB &=~(1<<SPI_MISO);
SPCR = 0 << SPIE | 1 << SPE | 0 << DORD | 1 << MSTR | 1 << CPOL | 1 <<
CPHA | 0 << SPR1 | 0 << SPR0;
SPSR = 1 << SPI2X;
SPDR = LCD_NO_OP; //Do not use 0 here, only LCD_NOP is allowed!
}
und hier noch die main:
int main(void)
{
init_spi_lcd();
lcd_init();
while(1)
{
lcd_move_xy(0,0);
lcd_put_string_P(FONT_FIXED_8, NORMAL, PSTR("Hallo Welt"));
}
}
eigentlich gibt es da nicht all zu viel zum falsch machen oder?
Danke für eure Hilfe
Hallo Jch,
ich habe im Moment keine Pläne mit diesem großen Display.
Es sollte aber kein großes Problem sein: Aus dem Datenblatt des
Controllers müssen die wesentlichen Befehle in die dogm-graphic.h
übertragen werden - nach Möglichkeit mit den gleichen Namen wie bei den
anderen Displays.
Dann muss in dogm-graphic.c noch die init-Sequenz geschrieben werden und
schon sollte es funktionieren.
Hallo zusammen,
ich habe vor längerer Zeit das DOGM132-5 in Betrieb genommen und habe
immer wieder das Problem, dass die Anzeige um mehrere Zeilen verschoben
ist (im angehängten Bild um etwa 15 Zeilen nach oben).
Teilweise verschiebt sich die Anzeige auch während des Betriebs, mal
nach oben, mal nach unten. Teilweise ist auch gar nichts mehr zu
erkennen.
Und das obwohl die Startzeile bei der Initialisierung auf 0 festgelegt
wird und anschließend nur doch die Pages entsprechend beschrieben
werden. Rein vom Code sollte es eigentlich keine Verschiebung geben, sie
tritt aber immer mal wieder auf. Teilweise läuft das Display tagelang
ohne Probleme, teilweise ist die fehlerhafte Anzeige auch schon nach ein
paar Stunden da.
Hatte irgendjemand von euch schon mal ähnliche Probleme?
Viele Grüße
Jürgen
Nach langer Zeit ein kleines Update:
Es gibt jetzt auch eine Variante der Lib, die mit Arduino verwendet
werden kann, hier im Foto ein ILI9341 TFT (240x320px), angesteuert mit
einem ESP8266 Modul.
Zu finden wie immer auf github:
https://github.com/mueschel/lcdlib (EA DOG LCD & ILI9341 für AVR)
https://github.com/mueschel/lcdlib-arduino (ILI9341 mit Arduino)
Hallo,
ist hier jemand noch aktiv und könnte mir helfen?
Ich versuche mit der Bib ein EA-DOG-XL 204-7 zum laufen zu kriegen.
Das ganze soll über 4-Bit-SPI laufen.
Ich habe vorher noch nie mit einem Graphicdisplay gearbeitet, sondern
nur mit einem Charackter Display.
Die Initalisierungen sowieso SPI-PORT Konfigurationen habe ich
verstanden.
Jedoch verstehe ich nicht wie ich eine Ausgabefunktion verwenden kann.
Mir würde es reichen wenn mir jemand kurz erklären kann wie man einfach
nur irgendeinen Buchstaben irgendwo auf dem Display darstellen kann.
Gruß
Thomas
Hallo Thomas,
klar schaue ich hier noch rein, aber nicht jeden Tag.
So ungefähr sieht ein Minimalbeispiel aus, um zwei unterschiedliche
Texte auszugeben:
1
lcd_init();
2
lcd_clear_area(0,240,0,320);
3
4
lcd_moveto_xy(6,0);
5
lcd_set_font(FONT_PROP_16,NORMAL | WRAP);
6
lcd_putstr("A long text that might warp around to the next line");
7
8
lcd_moveto_xy(15,80);
9
lcd_set_font(FONT_DIGITS_32,NORMAL);
10
lcd_putstr("1:0");
Wegen der verschiedenen Schriftarten: Hast du auch alle Schriftarten
eingebunden? In font.h kann man die jeweiligen #define (ab etwa Zeile
20) ein- und auskommentieren um Speicher zu sparen.
Hallo Jan,
ich habe schon vieles geschafft in der Zeit, jedoch wird mir sobald ich
eine der großen Schriftarten auswähle immernoch Murx angezeigt.
Ich habe bemerkt dass in der lcd_put_char Funktion ein paar Sachen
auskommentiert wurden. Ich schätze mal es liegt daran. Ich verstehe die
Funktion leider nicht komplett. Sie ist schon etwas komplexer für meine
Erfahrung.
/***********************************************************************
*******
* Outputs a character on the display, using the given font and style
*/
uint8_t lcd_put_char(FONT_P font, uint8_t style, char character) {
uint16_t i;
uint8_t row = 0; //current row of char
#ifdef LCD_DOUBLE_PIXEL
uint8_t hc = 1; //height forced
#else
uint8_t hc = (style & DOUBLE_HEIGHT)?1:0; //height changed
#endif
uint8_t wc = (style & DOUBLE_WIDTH)?1:0; //width changed
uint8_t ul = (style & UNDERLINE)?0x80:0x00; //underline
uint8_t inv = (style & INVERT)?0xFF:0; //inverted
uint8_t spc = (style & SPACING)?3:1; //spacing
uint8_t tmp;
//load information about character
uint8_t char_width = font_get_char_width(font,character);
uint8_t font_height = font_get_height_bytes(font);
uint8_t free_space = font_get_add_space(font,character)*spc;
PGM_P tableposition = font_get_char_position(font,character);
//final size of character
uint8_t char_final_width = (uint8_t)(char_width+free_space) << wc;
uint8_t char_final_height = (uint8_t)font_height << hc;
/*//check for avail. space on display
if ((style & WRAP) && (LCD_CURRENT_COL() + char_final_width >
LCD_WIDTH)) {
LCD_MOVE_TO(LCD_CURRENT_PAGE()+char_final_height,0);
if (character == ' ') return 0;
}
*/
//write chracter
do {
for(i=(row>>hc); i<char_width*font_height; i+=font_height) {
tmp = pgm_read_byte(tableposition+i);
if(row == char_final_height-1)
tmp |= ul;
if(hc)
tmp = double_bits((row&1),tmp);
if(inv)
tmp = ~tmp;
lcd_dat(tmp);
if(wc)
lcd_dat(tmp);
}
if (free_space) {
uint8_t c = inv;
if(row == char_final_height-1) {
c ^= ul;
if(hc)
c ^= ul>>1;
}
for(uint8_t x = free_space; x>0;x--) {
lcd_dat(c);
}
}
// move_yx(1,-char_final_width);
} while (++row < char_final_height);
//move cursor to upper right corner of character
//move_yx(-char_final_height,char_final_width);
return char_final_width;
}
Hallo Jan
bist du noch mit dem DOG XL160 aktiv dran?
Versuche ebenfalls das Display zum laufen zu bekommen. Habe die oben
angegeben Datein geladen und versuch es in den Griff zu bekommen. Klappt
leider nicht. Du hast 2 Datein mit fonts drin stehen und 2 Datein mit
dogm-graphig (c) und (h). Ist die main schon dabei oder muss man die
selber schreiben? Wo steht bei deinen Datein die init für das Display?
LG Klaus
Hallo Klaus,
das XL160 habe ich nie selbst benutzt, es ist in der Library enthalten,
weil die Unterschiede zu den anderen Displays doch eher gering sind.
ein main-Funktion musst du dir selbst schreiben, ich weiß ja nicht, was
du auf deinem Display anzeigen willst.
Die init-Funktion findest du recht weit unten in dogm-graphic.c
(lcd_init).
Hallo Jan
Ich möchte das Display XL160 mit dem I2C Bus verwenden. Der Hersteller
EA erlaubt ja beide Versionen für das Display. Deine Dateien arbeiten
mit SPI. a kein Anbindung zum Bus besteht funktioniert es nicht. Was
muss genau dazu geändert werden? Hat es schon mal jemand gemacht?
achim
Habe ein kleines Stück zum testen geschrieben. Damit erfolgt bereits das
init (teilweise). Eine Schrift oder ähnliches konnte ich nicht ausgeben.
1
#include<stdbool.h>
2
#include<avr/pgmspace.h>
3
#include"main.h"
4
#include"i2cmaster.h"
5
#include"avr/io.h"
6
#include"util/delay.h"
7
#include"avr/interrupt.h"
8
#include<stdlib.h>
9
#include"string.h"
10
11
// Adressen für XL160 0x7a
12
#define Write_Command 0x78
13
#define Read_Status 0x79
14
#define Write_Data 0x7A
15
#define Read_Data 0x7B
16
/*
17
// Adressen für XL160 0x7e
18
#define Write_Command 0x7C
19
#define Read_Status 0x7D
20
#define Write_Data 0x7E
21
#define Read_Data 0x7F
22
*/
23
24
intmain(void)
25
{
26
i2c_init();
27
i2c_start(Write_Command);// set device address and write mode
28
i2c_write(0xF1);// Set last COM electrode to 103 (number of COM electrodes - 1)
29
i2c_write(0x67);//
30
i2c_write(0xC0);// SEG (column) and COM (row) normal
31
i2c_write(0x40);// Set Display Startline to 0
32
i2c_write(0x50);//
33
i2c_write(0x2B);// Set Panelloading to 28..38nF
34
i2c_write(0xEB);// Set Bias to 1/12
35
i2c_write(0x81);// Set Contrast
36
i2c_write(0x5F);//
37
i2c_write(0x89);// Set Auto-Increment
38
i2c_write(0xAF);// Display on
39
i2c_stop();// set stop conditon = release bus
40
41
while
42
{
43
44
//i2c_start_wait(Write_Data); // set device address and write mode
45
//i2c_write(0xFF); // Set last COM electrode to 103 (number of COM electrodes - 1)
46
//i2c_stop(); // set stop conditon = release bus
47
48
}while(1);
49
50
return0;
51
}
Mit diesem Code erfolgt die korrekte Angabe der Adresse und der
Parameter. Das Teil innerhalb der while Schleife hat nichts zu sagen.
Sind noch überreste eines anderen Programmes.
Das Display wird damit angesprochen und es erscheint bereits eine
sinnlose Angabe von Punkten.
Wie kann ich dein Programm anpsaasem um die ganzen voids zu nutzen?
achim
Achim S. schrieb:> #define LCD_DISPLAY_ENABLE 0xAE //18: Display enable> müsste es nicht 0xAF sein?
Nein, der Befehl ist 0xAE, wobei das untere Bit dann auswählt, ob man
an- oder abschalten will. Weiter unten findest du die zugehörigen
Befehle:
Habe weiter gemacht mit dem I2C Bus. Wahrscheinlich kann ich die Befehle
von Jan kaum nutzen. Da ich jedes Pixel über den Bus einstellen muss,
ist der Ablauf auch anders.
Hat keiner Idee oder so was schon mal gemacht?
achim
Hallo,
habe mal vor ein paar Jahren folgende Dateien verfasst.
Atmega644 und DOGXL160/I2C
//LCD_RST PC2 Display RST PIN 29
//SDA PC1 Display SSA PIN 31 4,7K an 3,3V
//SCL PC0 Display SCK PIN 32 4,7K an 3,3V
// Display D6 PIN 26 an 3,3V
// Display BM0 PIN 30 an 3,3V
// Display CD PIN 27 an GND
// Display A2 PIN 28 an GND
Siehe Anhang ZIP
Gruß G.G.
Ich habe das für Atxmega.. programmiert.
Anschließend nach Atmega644 umgesetzt.
Mußte auch die I2C Lib wechseln.
Stelle heute Abend mal ein Bild mit der Displaydarstellung ein.
Hallo
habe die ersten Pixel auf dem Display zum Leben erweckt. Bin gerade an
den Parametern dran, halt was wie geht.
Habe wieder was gefunden was ich so nicht verstehe.
- wie bekommst du die Uhr auf den Schirm?
- wie kann ich Text einstellen?
- kann ich einen Strich von A nach B ziehen?
- kann ich z.B. ein Quadrat zeichen oder andere Figur?
achim
Servus Achim,
lcd_set_font(FONT_PROP_16, NORMAL); // FONT_PROP_16
lcd_moveto_xy(0,0); printf("Atmega644 11059200 Mhz");
while (1)
{
lcd_set_font(FONT_PROP_16, NORMAL);// FONT_PROP_16
lcd_moveto_xy(0,0); printf("Atmega644 11059200 Mhz");
lcd_moveto_xy(4,0); printf("DOGXL160 mit I2C");
lcd_set_font(FONT_PROP_8, NORMAL);// FONT_PROP_8
lcd_moveto_xy(10,0); printf("I2C/TWI Takt: 400 KHz");
lcd_moveto_xy(12,0); printf("Lib von Jan Michel");
lcd_moveto_xy(14,0); printf("Atmel AVR Studio 6");
lcd_moveto_xy(16,0); printf("Version 6.1");
draw_partialpic_dogxl160((char*)uhr_bmp,10, 76);
// UHR-Bmp ELECTRONIC ASSEMBLY LCD-Tools (grafik.c)
}
in der ATMEGA644_DOG_160.c findest du alle Befehle die am Display
angezeigt werden.
z.B. schreiben: printf("Atmega644 11059200 Mhz");
Sollte das nicht funktionieren, ist die Pixeldarstellung von der du
immer schreibst fehlerhaft.
Habe das Projekt ebenfalls auf einem DOG XL160 umgesetzt. Beim Probelauf
sind mir ein paar Sachen aufgefallen.
- die Graphik für Uhr und Sanduhr sind gleich
- die Einstelleung der I2C Bus Adresse ist doch recht versteckt
- Angabe der Quarzfrequenz muss 2 mal erfolgen sonst util nicht warum?
Kennt jemand noch andere Graphik Zeichen?
LG Hans
Hallo,
ich habe Probleme, die Library einzubinden, bzw. das Beispielprogramm
von der Arduino-Library auf meinen Arduino Micro zu programmieren.
Ich bekomme immer beim Programmiervorgang folgende Fehlermeldung, mit
der ich nicht wirklich etwas anfangen kann:
In file included from
C:\Users\Stefan\Documents\Arduino\libraries\lcdlib-arduino-master\lcdlib
-arduino\lcdlib-arduino.ino:7:0:
C:\Users\Stefan\Documents\Arduino\libraries\lcdlib-arduino-master/font.h
:4:10: fatal error: pgmspace.h: No such file or directory
#include <pgmspace.h>
^~~~~~~~~~~~
compilation terminated.
exit status 1
Fehler beim Kompilieren für das Board Arduino Micro.
Bitte zerreißt mich nicht in der Luft, da meine Kenntnisse nicht
sonderlich groß sind.
Ich möchte die Schrift auf meinem DOGL128 gerne invertiert darstellen
und bin auf diese Library gestoßen, da die Standard-Library von EA das
ja scheinbar nicht kann(?)
Ich würde mich freuen, evtl. einen Tipp zu bekommen, wo ich ansetzen
kann.
Ein Bespiel-Sketch wäre evtl. auch sehr schön.
Liebe Grüße
Stefan
Hallo,
ich habe da auch ein Problem mit dem Umgang mit der Library bzw. als
Umsteiger ein Verständnisproblem.
Ich habe ein EA DOGM128 an einem ATMega324P und vor Jahren noch mit
Bascom und einer Software SPI ans laufen gebracht.
Nun habe ich das Display an einem ATMega1284P per Hardware SPI
angeschaltet. Natürlich mit Pegelwandler usw....
Da ich eine vorhandene Hardware für die ersten Tests nutzen möchte und
nun auch schon ein paar Versuche ohne Ergebnis habe abbrechen müssen,
die alles bewegende Frage.
Am ATMega1284p liegt die SPI an PortB. Kann man die drei anderen
steuernden Pins an einen anderen Port legen z.B. an PortC ?
Probiert habe ich das schon bekomme es allerdings nicht zum laufen, es
bricht immer bei der LCD Initialisierung ab und der ATMEga startet
einfach neu durch den Watchdog.
PS: Ach ja die Library ist die von Gerhard, die von Jan lässt sich bei
mir nur mit Fehlern compilieren bzw. bricht mit einer Fehlermeldung ab.
Ich weiß, ich wühle hier ne Leiche raus, ist aber aus gegebenem Anlass.
Ich beziehe mich auf die Version, die ich auf github gefunden habe.
In der Datei "dogm-graphic.c" in Zeile 282 heißt es:
1
#if ORIENTATION_UPSIDEDOWN = 0
Das wirft natürlich einen Fehler. Es sollte wohl lauten:
Hallo Lötlackl,
das steht da tatsächlich seit 8 Jahren drin. Ist mir nie aufgefallen,
weil ich nie ein 160-px-Display hatte und diesen Teil somit nie
kompiliert habe.
Möchtest du das im git ändern oder soll ich das gerade machen?
Jan M. schrieb:> Möchtest du das im git ändern oder soll ich das gerade machen?
Mache Du das mal, ich habe bezüglich Github keine Ahnung (sollte ich
vielleicht mal ändern).