Hallo liebe µC-Gemeinde, seit längere Zeit nutze ich diese Plattform hier als Informationsquelle und konnte bisher die entstandenen Problem Dank euch lösen. Nun komme ich trotzdem nicht weiter, hier mal kurz mein Problemchen: Ich verwende ein Display von Electronic Assembly (DOGL128-6) (128*64 Pixel) und µC (ATMega32). Nun kann ich 8 Zeilen mit jeweils 21 Zeichen (bei Fonttyp 8*6) ausgeben, soweit so gut. Nun möchte ich gerne einen kleinen Rahmen um die Schrift ziehen so das nur noch 5 Zeilen möglich sind. Mein Problem besteht darin das ich nicht weiß wie ich das Progammtechnisch lösen kann. Das Display lässt sich nur in 8Bit breiten Pages ansprechen. Vielen Dank schon mal voraus ciao Paritybit
Peter M. schrieb:
> Das Display lässt sich nur in 8Bit breiten Pages ansprechen.
Zuallererst benötigst du eine Funktion, die sich darum kümmert.
Du gibst dieser Funktion die Koordinaten (x und y) des Pixels, das du
gesetzt oder gelöscht haben möchtest und die Funktion kümmert sich
darum, diese Koordinate in die Pages umzubrechen, in das Bit in dieser
Page und um die Bearbeitung des entsprechenden Bytes um dieses Pixel zu
setzen.
Das ist deine Grundroutine. Ab sofort ist für dich dein Display dann nur
noch eine 2D-Matrix von Pixeln und die Frage dreht sich dann nur noch
darum, welches Pixel gesetzt werden muss und welches gelöscht.
Deine Textausgabefunktionen wirst du dann umschreiben müssen. Du kannst
dann nicht mehr eine Zeichenspalte in einem Rutsch schreiben, sondern
musst das Zeichen Pixel für Pixel ausgeben. (Natürlich kann man da noch
ein wenig für die Zeichenausgabe optimieren. Ein Zeichen kann ja maximal
in 2 verchiedene Bytes fallen und man muss nur die Aufteilung der Bytes
finden. Aber probier erst mal aus, wie langsam Zeichenaufbau ist, wenn
du den tatsächlich pixelweise machst)
Hi, ich nutze im Moment 2 Funktionen 1. Goto_xy - damit wird Zeile (0 .. 7) und Spalte (0 .. 127) angesprochen 2. writechar - welches das Zeichen schreibt Hauptbestandteil der Funktion ist:
1 | for (i=0; i<6; i++) |
2 | {
|
3 | c=pgm_read_byte(&font[x][i]); |
4 | GLCD_Data_send(c); |
5 | }
|
mein Problem ist den Zeichensatz der im Flash liegt zuzerhacken und getrennt auszugeben. Dabei würden mir 2 Varianten einfallen. 1. Variante (Zeilenausgabe) - Zeichen/-kette virutell im SRAM ablegen - berechnen der Pixel der oberen hälfte - berechnen der Pixel der unteren hälft - Zeilenweise Ausgabe zuerst von Page und danach Page+1 2. Variante (Spaltenausgabe) - Zeichen/-kette virutell im SRAM ablegen, anstatt 8 Bit Zeichenhöhe wird ein 16 Bit breiter Speicher verwendet - verschiebung des 8Bit Zeichen innerhalb der 16Bit - Spaltenweiseausgabe (höherer Zeitaufwand durch springroutinen) für weitere Vorschläge bin ich jeder Zeit zu haben. ciao Paritybit
Schon diese Lib dafür gesehen? Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator" Vielleicht hilft die ja Gruß Tom
Hallo Tom, und an alle anderen, vielen Dank, habe mich mal durch den Quellcode (von dogm-graphic-091.zip) durchgeboxt und mir bleiben da so einige Fragen noch offen. Wäre nett wenn mir da mal jemand bitte helfen könnte, Danke. 1. In der Datei "dogm-graphic.c" gibt es die Funktion "void lcd_draw_image_xy_P(PGM_P progmem_image, uint8_t x, uint8_t y, uint8_t pages, uint8_t columns, uint8_t style)"
1 | void lcd_draw_image_xy_P(PGM_P progmem_image, uint8_t x, uint8_t y, uint8_t pages, uint8_t columns, uint8_t style) { |
2 | uint16_t i,j; |
3 | uint8_t data = 0; |
4 | uint8_t inv = style & INVERT_BIT; |
5 | uint8_t offset = y & 0x7; //Optimized modulo 8 |
6 | //If there is an offset, we must use an additional page
|
7 | if(offset) |
8 | pages++; |
9 | //If there is not enough vertical space -> cut image
|
10 | if(pages > LCD_RAM_PAGES - lcd_get_position_page()) |
11 | pages = LCD_RAM_PAGES - lcd_get_position_page(); |
12 | //Goto starting point and draw
|
13 | lcd_moveto_xy((y>>3), x); |
14 | for (j=0; j<pages; j++) { |
15 | for (i=0; i<columns && (lcd_get_position_column() < LCD_WIDTH); i++){ |
16 | data = 0; |
17 | if (!offset || j+1 != pages) |
18 | data = pgm_read_byte(&progmem_image[j*columns + i]) << offset; |
19 | if(j > 0 && offset) |
20 | data |= pgm_read_byte(&progmem_image[(j-1)*columns + i]) >> (8-offset); |
21 | if(inv) lcd_data(~data); |
22 | else lcd_data(data); |
23 | }
|
24 | if(j+1 != pages) |
25 | lcd_move_xy(1,-columns); |
26 | }
|
27 | }
|
-> lcd_moveto_xy((y>>3), x); hierbei wird der Wert (welcher max. 7 ist) um 3 Stellen nach Rechts geschoben so das y den Wert 0 hat, was macht das für einen Sinn? -> if(j > 0 && offset) j wird mit offset verglichen, wobei offset auf 0 und verknüpf wird ??? hätte man nicht gleich j > 0 schreiben können, ich mein ja nur. Nun bräuchte ich Nachhilfe in Zeichen- (Spuren-) lesen.
1 | /*
|
2 | created with FontEditor written by H. Reddmann HaReddmann at t-online dot de
|
3 | using template file by J. Michel jan at mueschelsoft.de
|
4 | |
5 | File Name : symbols_16px.c
|
6 | Date : 19.07.2009
|
7 | Font size in bytes : 0x0104, 260
|
8 | Font width : 20
|
9 | Font height : 16
|
10 | Font first char : 0x00
|
11 | Font last char : 0x09
|
12 | Font bits per pixel : 1
|
13 | */
|
14 | |
15 | #include "../font.h" |
16 | #ifdef FONTS_INCLUDE_symbols_16px
|
17 | |
18 | |
19 | |
20 | const char symbols_16px_data[] PROGMEM = { |
21 | 0x0F, 0x0F, 0x0D, 0x0D, 0x0D, 0x0D, 0x0D, 0x0E, 0x0F, 0x13, |
22 | 0x01, 0x03, 0x04, 0x0D, |
23 | 0x1A, 0x1B, 0x0F, 0x11, 0x0C, 0x0C, 0x1A, 0x14, 0x20, 0x29, |
24 | 0x4A, 0xD7, 0x75, 0x5D, 0x25, 0xAA, 0x62, 0xC8, 0x34, 0x64, 0x0A, 0x14, 0x68, 0x8C, 0xC2, 0xB2, |
25 | 0x2B, 0xC0, 0xA6, 0xE4, 0x4A, 0x80, 0x29, 0xA9, 0x03, 0x15, 0x12, 0x87, 0x4A, 0x32, 0x25, 0xC0, |
26 | 0x95, 0x6C, 0x0A, 0xB0, 0x2B, 0xA3, 0x70, 0x0A, 0x14, 0x68, 0xC8, 0x34, 0x64, 0xA8, 0x8A, 0x52, |
27 | 0xD7, 0x75, 0x5D, 0x05, 0x00, 0x92, 0xA5, 0x58, 0x8A, 0xA5, 0x58, 0x8A, 0xA5, 0x1C, 0x38, 0x73, |
28 | 0x79, 0x9E, 0xE7, 0x59, 0x02, 0x3C, 0xCF, 0xF3, 0xAC, 0xE7, 0x04, 0x2E, 0xC5, 0x52, 0x2C, 0xC5, |
29 | 0x52, 0x2C, 0xC5, 0x02, 0x00, 0x4A, 0xD7, 0x75, 0x5D, 0xA5, 0xE7, 0xB9, 0xD4, 0x75, 0x5D, 0x57, |
30 | 0x01, 0x4A, 0xD7, 0x75, 0x5D, 0xD7, 0x75, 0x5D, 0xD7, 0x75, 0x5D, 0x05, 0x00, 0x5B, 0x28, 0x80, |
31 | 0x14, 0x50, 0x59, 0x96, 0x09, 0x58, 0xB1, 0x25, 0xC0, 0x94, 0x62, 0x29, 0x26, 0x25, 0x14, 0x56, |
32 | 0x1A, 0x0B, 0x56, 0x05, 0x90, 0x02, 0x19, 0x12, 0xC0, 0xA1, 0x33, 0x67, 0x4A, 0xB1, 0x14, 0x4B, |
33 | 0xA9, 0x94, 0x4A, 0xAA, 0x24, 0x72, 0xE4, 0xC8, 0x91, 0xE3, 0x00, 0x82, 0x2B, 0xD9, 0x54, 0xA8, |
34 | 0x50, 0xA1, 0x42, 0x85, 0x0A, 0x15, 0x9B, 0x92, 0x3B, 0x29, 0x36, 0x15, 0x9B, 0x12, 0x50, 0x49, |
35 | 0x24, 0x48, 0x09, 0x20, 0x43, 0x4A, 0xA4, 0x40, 0x2A, 0x54, 0x18, 0xB2, 0xA9, 0xD8, 0x54, 0x18, |
36 | 0x86, 0x0A, 0xC3, 0x50, 0xA1, 0xC2, 0x49, 0x29, 0x40, 0x4A, 0x66, 0xA8, 0x30, 0x0C, 0x15, 0x86, |
37 | 0xA1, 0xC2, 0x98, 0x12, 0x09, 0x74, 0x92, 0x5C, 0xC9, 0xA6, 0x42, 0x85, 0x0A, 0x15, 0x2A, 0x54, |
38 | 0x28, 0x91, 0x21, 0x05, 0x00 |
39 | };
|
40 | |
41 | const struct font_info symbols_16px PROGMEM = {0x04+(0x01<<8),0x14,0x10,0x00,0x09,symbols_16px_data,(char*)symbols_16px_data+0x09-0x00+1}; |
42 | |
43 | #endif
|
Wenn ich nun die Programmzeile pgm_read_byte(&progmem_image[0]) //(Null ist von mir als Bsp eingetragen) nehme welcher Wert wird aus der List ausgelesen. Wie ich die Zahlen auch drehe die passen nicht zum Symbol / Symbolen. Wie kann ich die Liste lesen, damit ich verstehe was für ein Zeichen aus dem Speicher geladen wird. Vielen Dank Paritybit
Peter M. schrieb: > > -> lcd_moveto_xy((y>>3), x); > hierbei wird der Wert (welcher max. 7 ist) um 3 Stellen nach Rechts > geschoben so das y den Wert 0 hat, was macht das für einen Sinn? y ist in diesem Code offenbar die Pixelnummer in y Richtung, nicht die Pagenummer. > > -> if(j > 0 && offset) > j wird mit offset verglichen, Nein. Operator Precedence Table studieren if( ( j > 0 ) && ( offset != 0 ) )
Peter M. schrieb: > > Wenn ich nun die Programmzeile pgm_read_byte(&progmem_image[0]) > //(Null ist von mir als Bsp eingetragen) > nehme welcher Wert wird aus der List ausgelesen. Der, dessen Adresse in progmem_image übergeben wurde. Aber was haben die beiden Einzelteile miteinander zu tun? Das ist eine Funktion zum Zeichnen eines Bildes (einer Bitmap), das andere sind Fontdaten
Karl heinz Buchegger schrieb: > Das ist eine Funktion zum Zeichnen eines Bildes (einer Bitmap), das > andere sind Fontdaten meine Auffassung ist nun so, dass das Bild als Code in den Flash gespeichert wird und über die Funktion "pgm_read_byte()" aus diesem Byte für Byte ausgelesen wird. mal ein Beispiel: angefügte Grafik soll vom Flashspeicher auf das Display ausgegeben werden. Nun erhalte ich mit dem Convertierungsprogramm von H. Reddmann 2 Dateien, eine Binär- und eine Headerdatei. Headerdatei:
1 | /*
|
2 | created with S65 Image Converter written by H. Reddmann
|
3 | HaReddmann at t-online dot de
|
4 | |
5 | Filename : button_home_nor.h
|
6 | Bitmaptype : Monochrome, compressed
|
7 | Width : 16
|
8 | Height : 16
|
9 | Number of Colors : 2
|
10 | Bits Per Pixel : 1
|
11 | Colortable : none
|
12 | Size : 57 bytes
|
13 | Imagesize : 512 bytes
|
14 | */
|
15 | |
16 | #ifndef button_home_nor_H
|
17 | #define button_home_nor_H
|
18 | |
19 | #include <inttypes.h> |
20 | #include <avr/pgmspace.h> |
21 | |
22 | #define button_home_nor_WIDTH 16
|
23 | #define button_home_nor_HEIGHT 16
|
24 | |
25 | uint8_t button_home_nor_bmp[] PROGMEM = { |
26 | 0x10, 0x10, 0x01, 0xFF, 0xFF, 0x00, 0x00, |
27 | |
28 | 0x30, 0x01, 0x1F, 0x08, 0x02, 0x10, 0x14, 0x01, 0x08, 0x02, 0x04, 0x03, 0x0C, 0x02, 0x04, 0x07, |
29 | 0x0E, 0x02, 0x04, 0x1F, 0x02, 0x05, 0x08, 0x01, 0x0A, 0x04, 0x08, 0x01, 0x02, 0x04, 0x09, 0x0D, |
30 | 0x02, 0x04, 0x09, 0x0D, 0x02, 0x04, 0x09, 0x0D, 0x02, 0x04, 0x1F, 0x12, 0x10, 0x04, 0x01, 0x1F, |
31 | 0x08, 0x30}; |
32 | |
33 | #endif
|
soweit so gut nur habe ich bisher nur Fonts gespeichert und zwar im Format 8-Bit, Vertikal von links oben nach rechts unten: Die ersten Zahlen müssten nach meiner Meinung so aussehen: unsigned char button_home_nor_bmp[] PROGMEM = { 0x00, 0xF8, 0x04, 0x82, ... (erste Zeile) (die letzten Zeichen) ..., 0x40, 0x20, 0x1F, 0x00}; Somit werden bei einer 16*16 Grafik 32 Byte (16 Byte f. obere Zeile und 16 Byte f. d. untere) benötigt. Im oberen Ergebnis sind es jedoch 57 Byte. Wie kann die Daten für mich nutzbar machen? Könnt Ihr mir da bitte weiterhelfen. Vielen Dank Paritybit P.S.: habe schon versucht im Thread vom Autor dieses Programm was heraus zulesen, leider ohne Ergebnis.
Der Schlüssel wird wohl hier liegen Bitmaptype : Monochrome, compressed Entweder das Erzeugende Programm hat irgendwo einen Schalter, mit dem man die Kompression beim Erzeugen abschalten kann, oder du musst eine Dekompression einbauen. In deinem Fall ist letzteres wohl eher kontraproduktiv, weil die Kompression sich ins Gegenteil verkehrt hat. Die Daten sind nicht kleiner, sondern größer geworden. PS: Die Daten sehen mir dann doch stark nach einem Run Length Enocding aus. Genaueres weiß man aber nur, wenn man den Code vom Generierprogramm studiert.
Die Daten beginnen so uint8_t button_home_nor_bmp[] PROGMEM = { 0x10, 0x10, 0x01, 0xFF, 0xFF, 0x00, 0x00, Das ist dezimal 16 16 1 255 255 0 0 Was die 255/255/0/0 bedeuten weiß ich nicht, aber ich biete die Wette an, dass am Anfang steht: 16 Pixel Breite, 16 Pixel Höhe, 1 Bit pro Pixel. Der Rest werden wohl Kennungen für Kompression, Palette und wohl sonst noch irgendwas anderes sein.
Hi Mein Programm erzeugt die Daten im Anhang (für ASM). >Die ersten Zahlen müssten nach meiner Meinung so aussehen: >unsigned char button_home_nor_bmp[] PROGMEM = { > 0x00, 0xF8, 0x04, 0x82, ... (erste Zeile) > (die letzten Zeichen) ..., 0x40, 0x20, 0x1F, 0x00}; Nicht ganz. Schwarz->0, Weiss->1. Hängt allerdings vom Display. MfG Spess
Hallo spess53, danke für deine asm datei, allerdings ist bei diesem Display (DOGL128-6) High also 1 auch ein Pixel erzeugt, in meinem Fall wäre es schwarz. D.h. die Grafikdaten für mein Display sind genau invertiert. @all: Mein Problem welches ich gern hier lösen möchte ist, das ich noch nie mit Grafikausgaben auf ein Display zu tun hatte und ich gern dahinter steigen möchte wie nun genau das so funktioniert. Z.Bsp.: Grafikdaten in den Speicher legen intern oder extern vom Controller spielt dabei keine Rolle, jedoch die Verarbeitung und Ausgabe dieser. Mir scheint es als gebe es dafür nicht eine Variante sondern viele! Man müsste ebenfalls unterscheiden ob man, wie in meinem Falle mit einem Monochromen oder mit einem Farbdisplay gearbeitet wird. Viele hier im Forum knallen einen Programme oder sogar Funktionen zur Grafikausgabe um die Ohren, jedoch ohne Erklärung oder Beispiele. Somit haben die, wie ich, es sehr schwer in die Materie hinein zublicken. Wenn sich da einer angesprochen fühlt und mir helfen möchte, bin ich sehr Dankbar dafür Greenhorn Gruß Paritybit
Peter M. schrieb: > danke für deine asm datei, allerdings ist bei diesem Display (DOGL128-6) > High also 1 auch ein Pixel erzeugt, in meinem Fall wäre es schwarz. er hat doch beide Varianten angegeben > Mein Problem welches ich gern hier lösen möchte ist, das ich noch nie > mit Grafikausgaben auf ein Display zu tun hatte und ich gern dahinter > steigen möchte wie nun genau das so funktioniert. > Z.Bsp.: Grafikdaten in den Speicher legen intern oder extern vom > Controller spielt dabei keine Rolle, jedoch die Verarbeitung und Ausgabe > dieser. Ist im Grunde sehr, sehr simpel. Da gibt es einen Speicher. Jeweils ein Byte im Speicher korrespondiert mit einer 'Spalte' von 8 übereinander liegenden Bits. Ds ist das was du als 'Page' kennst. Eine 'Page' ist also nichts anderes als ein paar Bytes hhinteinander, wobei die Bits 0 aller Bytes mit der ersten Pixelzeile korrespondieren. Die Bits 1 aller Bytes sind die nächste Pixelzeile und so weiter. Setzt du ein Bit in diesem Byte auf 0 so bleibt das LCD an dieser Stelle durchsichtig. Setzt du es auf 1, dann verdunkelt sich das entsprechende Pixel. Und das ist dann im Grunde schon alles. > Mir scheint es als gebe es dafür nicht eine Variante sondern viele! Klar. Anstelle untereinander kann man die Bits in einem Byte auch nebeneinander in Pixel übersetzen. Oder anstelle der Bits 0 können die Bits 7 für die erste Zeile zuständig sein. Oder anstelle von 0 verdunkelt eine 1 das Pixel. Oder im Falle eines Farb-Displays: 3 Bytes hintereinander beeinflussen ein Pixel, oder die Farben kommen in Byteblöcken ins Spiel oder ... > Viele hier im Forum knallen einen Programme oder sogar Funktionen zur > Grafikausgabe um die Ohren, jedoch ohne Erklärung oder Beispiele. Eben weil es so viele Variationen gibt. Das Datenblatt sollte darüber Aufschluss geben. Aber im Grunde ist es 'prinzipmässig' immer gleiche. Die einzelnen Bits in einem Byte korrespondieren mit Pixeln am Display. > Somit haben die, wie ich, es sehr schwer in die Materie hinein > zublicken. Du denkst viel zu kompliziert. Das ist gaaaaaaanz simpel aufgebaut.
Hi >danke für deine asm datei, allerdings ist bei diesem Display (DOGL128-6) >High also 1 auch ein Pixel erzeugt, in meinem Fall wäre es schwarz. Deshalb ist dein Bild in der Datei auch zweimal drin. Das DOGL128-6 gibt es in 5 verschiedenen Ausführungen (W/E/B/S/L) teils normale, teils invertierte Darstellung. >Mir scheint es als gebe es dafür nicht eine Variante sondern viele! >Man müsste ebenfalls unterscheiden ob man, wie in meinem Falle mit einem >Monochromen oder mit einem Farbdisplay gearbeitet wird. Richtig. Allerdings werden dir allgemeine Fragen nicht weiterhelfen. Die Antworten werden nämlich genauso allgemein sein. Bei konkreten Fragen bin ich gern bereit dir zu helfen. MfG Spess
Hallo Peter, hast du es inzwischen geschafft, ein Bild für das Display zu konvertieren? Das Programm von Hagen Reddmann erzeugt Daten für ein S65-Display, das ist nicht kompatibel zum DOG-Format. Hier ist das richtige Tool: http://laeubi-soft.de/service/downloads/tools.html Dort kannst du die Daten direkt in einem DOGM-kompatiblen Format speichern lassen. Das c-Array das das Tool erstellt legst du dann im Flash deines uC ab und gibts der Funktion lcd_draw_image_P() aus meiner Library einen Pointer darauf plus die Höhe in pages und die Breite in Pixel. Btw.: Bitte auch die Beschreibungen der Funktionen in den .c-Dateien lesen - für die "komplizierteren" Funktionen sind alle Argumente beschrieben.
Hi >Das c-Array das das Tool erstellt legst du dann im Flash deines uC ab >und gibts der Funktion lcd_draw_image_P() aus meiner Library einen >Pointer darauf plus die Höhe in pages und die Breite in Pixel. Nützt nicht viel. Da seine Textzeilen über jeweils 2 Pages gehen und DOG-Displays nicht gelesen werden können ist es einfacher ein Display-Abbild im RAM zu erzeugen und dort zu manipulieren. Das RAM-Abbild wird dann zum Display übertragen. MfG Spess
Die Funktionen sind für Grafiken, und diese lassen sich damit pixelgenau platzieren. Für Fonts ist dieses Page-übergreifende Schreiben nicht vorgesehen, dafür müsste man ja auch zwei Textzeilen in einer page kombinieren, wofür man definitiv einen internen RAM braucht den man dann nachträglich auf das Display lädt. Ich würde aber definitiv überlegen, ob nicht vier Zeilen mit jeweils 16 Pixeln Höhe sinnvoller wären - den Programmieraufwand für Zeilen mit 12-13 Pixel Höhe würde ich nicht treiben wollen.
Jan M. schrieb: > Ich würde aber definitiv überlegen, ob nicht vier Zeilen mit jeweils 16 > Pixeln Höhe sinnvoller wären Er möchte auch noch Rahmen um die Einzelteile legen. Spätestens dann wirds ohne ein Duplikat im Speicher nicht mehr gehen. Ich wüsste nicht, wie man das sonst machen kann ohne vom Display lesen zu müssen. Letztenendes ist das auch die flexibelste Lösung, wenn dann auch irgendwann einmal graphische Anzeigen dazu kommen sollen.
Hi Das läuft das auf etwas Bitschubsen und wenige einfache logische Verknüpfungen hinaus. Was ist daran so komplizert? Bei mir klappt das in Assembler wunderbar. MfG Spess
spess53 schrieb: > Hi > > Das läuft das auf etwas Bitschubsen und wenige einfache logische > Verknüpfungen hinaus. Was ist daran so komplizert? Bei mir klappt das in > Assembler wunderbar. Das du eine Textausgabe brauchst, die speziell angepasst ist, und je nachdem an welcher Stelle ein 'A' ausgegeben werden soll, auch noch die Pixel für die Rahmen mit einrechnet. Oder reden wir jetzt aneinander vorbei?
Hi >Das du eine Textausgabe brauchst, die speziell angepasst ist, und je >nachdem an welcher Stelle ein 'A' ausgegeben werden soll, auch noch die >Pixel für die Rahmen mit einrechnet. Ja. Mit meiner Routine kann ich einen Buchstaben pixelgenau setzen ohne den Hintergrund zu ändern. RAM-Abbild vorrausgesetzt. >Oder reden wir jetzt aneinander vorbei? Ich denke nicht. MfG Spess
spess53 schrieb: > RAM-Abbild vorrausgesetzt. > >>Oder reden wir jetzt aneinander vorbei? > > Ich denke nicht. Doch :-) Mein Fehler
Hallo an alle nochmal, vielen Dank für eure Einbringungen zu diesem Thema. Mein Fazit welches ich hieraus schließe ist: - 4 Zeilenausgabe á 16 Bit Zeilenhöhe - Grafiken werden in einer Bytereihe seperat gespeichert - Grafiken werden je nach Bedarf ausgelesen und entsprechend im SRAM positioniert abgelegt - mit ODER Verknüpfung werden Strings (Fonts) im SRAM abgelegt - und zum Schluß wird der Inhalt auf das Display Zeilenweise ausgegeben Da ich den ATMega32 zu Testzwecken verwende welcher einen 2 KByte SRAM besitzt dürfte dieser mit dem 1 KByte "Schattendisplayspeicher" zurecht kommen. Vielen Dank Peter
Das klingt nach einem guten Konzept. Wenn du willst kannst du für all diese Funktionen meine Library verwenden - im Prinzip musst du nur die Ausgaberoutine die bei mir direkt aufs LCD schreibt durch eine eigene Funktion ersetzen, die deinen Grafikspeicher entweder ersetzt oder mit den neuen Daten "verodert".
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.