Forum: Mikrocontroller und Digitale Elektronik Zeichenausgabe auf dem DOGL128-6 von Electronic Assembly


von Peter E. (paritybit)


Angehängte Dateien:

Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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)

von Peter E. (paritybit)


Lesenswert?

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

von Thomas B. (escamoteur)


Lesenswert?

Schon diese Lib dafür gesehen?

Beitrag "Re: Library für EA-DOGM Grafikdisplays inkl. Font-Generator"

Vielleicht hilft die ja

Gruß
Tom

von Peter E. (paritybit)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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

von Peter E. (paritybit)


Angehängte Dateien:

Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von spess53 (Gast)


Angehängte Dateien:

Lesenswert?

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

von Peter E. (paritybit)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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.

von spess53 (Gast)


Lesenswert?

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

von Jan M. (mueschel)


Lesenswert?

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.

von spess53 (Gast)


Lesenswert?

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

von Jan M. (mueschel)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von spess53 (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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?

von spess53 (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

spess53 schrieb:

> RAM-Abbild vorrausgesetzt.
>
>>Oder reden wir jetzt aneinander vorbei?
>
> Ich denke nicht.

Doch :-)
Mein Fehler

von Peter E. (paritybit)


Lesenswert?

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

von Jan M. (mueschel)


Lesenswert?

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