The Siemens S65 132x176, 65536 color display with AVR

@Ralf:

wie gesagt steht oben meine EMail Adresse, ich kann dir meinen Source 
mailen.
Du benutzt 8Bit SPI und vor jeder "Aktion" mit dem Display sendet man

1.) Identifikations Byte mit Addresse des Displays + Kommando Bits die 
beschreiben ob man ein Daten/Command Register lesen/schreiben möchte.
2.) der Index des Registers das man ansprechen möchte
3.) die entsprechenden Daten die man schreiben möchte, beim Lesen sind 
es nur Dummybytes aber das ist eh überflüssig da beim SPI keine MOSI 
Leistung nach aussen geführt ist.

Das steht aber so auch im Datenblatt drinnen.

Gruß Hagen

Hallo Hagen

Hab mir 3 von diesen Displays bei Ebay gekauft.
Wärst Du bitte so nett und mailst mir den Quellcode?

LG
Michael

@Michael:

ja wäre ich, nur kann ich nicht verstehen warum nun schon 10 Leute ohne 
Probleme an meine obige Addresse eine EMail schicken konnten, und du 
nicht in der Lage bist das gleiche zu tuen oder zumindestens deine EMail 
Adresse kund zu tuen. Wie soll ich dir das mailen ? Also, schreib an 
obige Adresse eine Mail und ich antworte mit einem Attachment. Ich meine 
das ist nicht zu viel verlangt von mir.

Gruß Hagen

Hi to all!
Anybody knows where to find datasheet for the most popular LS020 display 
or its LR38826 controller?
It seems that all the displays (LPH and L2F50) is pretty documented now, 
except for LS020... :((

Dear H. Reddmann!
I`ve found your FontEditor (from the library package) very useful for 
me. It is simple and powerful enough.
Can you, please, help me to understand how to work with the .font files 
generated by the editor? Especially - how to decompress them?

Yes i can help you ;)

First use the newest version i've attached. It contains a checkbox to 
explicitely tell the program not to compress the data. In older versions 
this descision was made automaticaly by the program, now with user 
invention.

There exist two possible formats of the font data:

1.) not compressed fonts

1

    struct _FONT_ {

2

       uint16_t   font_Size_in_Bytes_over_all_included_Size_it_self;

3

       uint8_t    font_Width_in_Pixel_for_fixed_drawing;

4

       uint8_t    font_Height_in_Pixel_for_all_Characters;

5

       uint8_t    font_Bits_per_Pixels;

6

       uint8_t    font_First_Char;

7

       uint8_t    font_Last_Char;

8

       uint8_t    font_Char_Widths[font_Last_Char - font_First_Char +1];

9

       uint8_t    font_data[];

10

    }

now the members

1.) the size in bytes of this structure, you can sequientially store 
more fonts in memory. If you known the address of the first Font you can 
use this member to iterate over all Fonts, from first over the next upto 
last.

2.) the maximal Width of each Character in Font. Its used if we want to 
draw the chars as fixed Fonts. The Fonts supports like true types two 
font styles -> fixed pitch and proportional pitch

3.) Height of each character in font. Contrary to the Width in my fonts 
we use allways for each char the same height declared in the struct.

4.) Bits per Pixel means the Color Depth of this font. Fonts are 
multicolor if needed and thus need more as one bit per Pixel as in 
monochrome. This member contains the power of two of colors used, or in 
other words the Bits per Pixel used. If it contains as example 2 then we 
use 2^2=4 colors and require 2 bits per Pixel. The most significant bit 
have special purposes, because we do'nt need all 8 Bits of this member 
(my fonts can only use maximal 256 colors, thus 8 would be the highest 
value for bits per pixel). Thus we have some bits free in this member to 
use for other purposes. The highest bits show use iff the font use 
compressed data or not.

5.) the font stores only charachters in a certain range, we save memory 
this way. The member font_First_char contains the character ASCII code 
of the first declared char in the font.

6.) this member stores the last used ASCII code

Thus in your drawing function you have to be checked if your ASCII code 
to draw is in range of this two members.

7.) this array contains for each charachter in range font_First_char 
upto font_Last_char they width in pixels. If a array entry contains zero 
then there is no character defined.

Thus in a second check you read the width of your ASCII code from this 
array. Iff it is zero there is no character defined, exit your function.

With this array it is easy to calculate the width in pixels of a given 
string.

Please remember, this width is the real used width of each character 
without right space for characters in ASCII range #0 upto #127. This one 
Pixel space (normaly) is virtualy painted first in my GLCD lib. All 
ASCII above #127 are block characters and have no such a virtual right 
spacing. This logic save us again memory space, because now we dont have 
to store this right most empty pixel column.

8.) font_Data[] member is an array of our characters. A characters is 
seqiuentially encoded from left outer column to right column, from top 
to bottom pixel line in each column. This is done without any padding 
bits or bytes, means full sequiential. This save again memory space and 
we have to see our font data as simple bit stream, eg. bit chunks of 
font_Bits_Per_Pixel bits large pixels.

As example a 9*11 pixel (9 pixel width, 12 pixel height) font with 4 
colors:

- font_Height is 11
- font_Width is 9 pixel maximal
- font_Bits_Per_Pixel would be 2

we have stored a character in this font wich is 7 pixel large, eg. need 
7*11*2 Bits = 154 bits are sequientaly needed in memory

Now, font_Data[] contains this stream of characters. How you seek to the 
beginning of a certain character ?

Iterate from first entry in font_Char_Widths[] upto current ASCII code 
-1. Accumulate all the widths into a local variable, multiply this with 
font_Bits_Per_Pixel and font_Height and you get the Bit-Offset into the 
Data where the beginnung of our character data is.

That seems at first a little bit confusing but is not. In this way we 
avoid the use of padding bits/bytes and use the requiered memory space 
without compression maximal. The needed overhead in computation is not 
big compared.

After you have examined the Bit-Offset you can easily divide it by 8 to 
get the byte offset eg. index into font_Data[] array. The modular 
remainder of Bit-Offset contains the bit start position of our 
datastream of our first data byte.

Now you read sequientialy chunks of as example 2 bits for a 4 color 
font. The two bits are a index into a global initialised glcd_Colors[] 
Color Table. Read out from this Table the real color an paint your one 
pixel. Begin drawing on left top most Pixel, column by column each with 
font_Height pixels until you have painted char_Widths[ASCII_code] 
columns.

In proportional painting we paint one or myabe two columns at right more 
if our character is <= #128.
In fixed font drawing we center our character to font_Width and paint 
the half pixel columns left, the char_Widths[ASCII_code] count columns 
of character and the ramaining right space columns to get a font_Width 
large char.

Next post explains the compressed font.

Best Regards, Hagen

Compressed Fonts use

1

    struct _FONT_ {

2

       uint16_t   font_Size_in_Bytes_over_all_included_Size_it_self;

3

       uint8_t    font_Width_in_Pixel_for_fixed_drawing;

4

       uint8_t    font_Height_in_Pixel_for_all_Characters;

5

       uint8_t    font_Bits_per_Pixels;

6

       uint8_t    font_First_Char;

7

       uint8_t    font_Last_Char;

8

       uint8_t    font_Char_Widths[font_Last_Char - font_First_Char +1];

9

       uint8_t    font_Byte_Padding;

10

       uint8_t    font_RLE_Table[3];

11

       uint8_t    font_Char_Size_in_Bytes[font_Last_Char - font_First_Char +1];

12

       uint8_t    font_data[];

13

    }

1.) font_Bits_Per_Pixel must have set the MSB to true to identify a 
compressed font.

2.) font_Byte_Padding is a multiply of Bytes wich we have used to pad 
our character data in font_Data[], explanation follows.

3.) font_RLE_Table[] contains 3 entries, but in realty there a 4. The 
first one, not saved entry is always 1.

4.) font_Char_Sizes[] contains the count of bytes used for each 
character in font_Data[]. We need this array to find the right 
beginning.
Because this array[] can only save a byte for one character, eg. the 
maximal data bytes of one characters can 256 bytes we have a problem on 
large fonts. To solve this we use font_Byte_Padding. If as example 
Font_Byte_Padding is 2 the all charcaters in our font use data chunks of 
a multiply of 2 bytes in length. Now our font_Char_Sizes[] entry stores 
the real bytecount divided by 2. A character in this font that need 127 
real data bytes would be thus consume 128 bytes and the entry in 
font_Char_Sizes[] would be 64. Thus we can now save characters with upto 
512 bytes each instead of only 256 bytes.

Thus in the computation of our start index into font_Data[] we iterate 
now over font_Char_Sizes[] from font_First_Char upto ASCII_code -1 and 
accumulate all sizes. After we mulptiply it with font_Byte_Padding and 
we have our index computed.

5.) the font_Data[].

Load the font_RLE[] Table into an array with 4 entries, the first entry 
must be initialized with 1.

This Table contains now a Run Length of Pixels to be painted in one 
Color.

As example a 4 color Font. We need 2 Bits to indentify the color in our 
Datastream. After this 2 bits we store 2 Bits of RLE Code, that is a 
index into our RLE Table. Load from the color index the real color from 
glcd_Colors[]. Load from RLE Code from RLE_Table[] the count of pixels 
to be painted in this color. Paint again from left outer Columns to 
right outer from top line to bottom.


In our example one pixel need in worst case 4 Bits in our stream. 2 bits 
color index and 2 bits RLE Table index. In best case, depended on RLE 
Table[1..3] we need 2 Bits color index and 2 bits RLE index, but we 
paint as example 13 Pixels in this color sequientialy, because in RLE 
Table[2] was saved 13.

If our RLE Table would be {1,2,5,13} and we have sequientialy to paint 
20 pixels in same color then our stream contains exactly 12 Bits. 2 Bits 
color + 2 bits RLE index = 3 -> 13 Pixel, then 2 bits again same color 
index, 2 Bits RLE Index = 2 -> 5 Pixel, then 2 bits same colorindex and 
2 bits RLE Table Index = 1 -> 2 Pixel.

The compression function in my Font Editor tries out now all possible 
combinations of this 4 entray RLE Table compared to the existing font 
datas to find the one solution wich would be need the smallest count of 
these chunks.

It was a conceptionaly descision of me to use smalles memory 
requierements as possible wit compact design and not to many expensive 
computation overhead on small MCUs.

Best Regards, Hagen

sorry some errors ;)

On compressed font a chunk contains

2 Bits RLE Index
x Bits Color Index, where X == font_Bits_Per_Pixel.

The order is reversed to my last post ;)

1

      bitsmul = pgm_read_byte(&powerof2[bitscount & 0x07]);

2

      if (bitscount < 8) {

3

        bitscount += 8;

4

        bits |= pgm_read_byte_inc(data) * bitsmul;    // faster as shifting

5

      }

6

      pixelcount = 1;

7

      do {

8

        i = FontHeight;

9

        do {

10

          if (!(--pixelcount)) {

11

            pixelcount++;

12

            if (flags & 0x80) { // compresed Font ??

13

              pixelcount = rle[bits & 0x03];

14

              bits >>= 2;

15

              bitscount -= 2;

16

            }

17

            bitscount -= bitspixel;

18

            bitsmul = pgm_read_byte(&powerof2[bitscount & 0x07]);

19

            color = colors[bits & bitsmask];

20

            bits >>= bitspixel;

21

          }

22

          GLCD_WAIT();

23

          GLCD_OUT(H8(color));

24

          if (bitscount < 8) { // read in advance while we wait for SPI

25

            bitscount += 8;

26

            bits |= pgm_read_byte_inc(data) * bitsmul;   // faster as shifting

27

          }

28

          GLCD_WAIT();

29

          GLCD_OUT(L8(color));

30

        } while (--i);

31

      } while (--charwidth);

Here the inner most source cut of my S65 lib font routine (you can mail 
me iff you want to get the source).

Bits is our databuffer that is repeately filled from font_Data[]. We 
append these new datas read on most significant side and then right 
shift out these bits such as needed.

First we eaxtract on compressed fonts the lower most to bits to get the 
index in our Run Length Table. From this we load our PixelCount 
variable. On uncompressed fonts we do this not, instead set PixelCount 
to 1.

After this we shift right the Bits variable 2 bits. BitCount Variable 
stores the count of valid bits in Bits this we have to decrement it by 
2.

Then we load our color index into glcd_Colors[] array. Dependend on 
font_Bits_Per_Pixel we have to and mask Bits to get the index. After we 
shift right again variable Bits.

Now we have Color and the PixelCount to be set in this color examined, 
we paint it.

Variable BitsMul is a special thing for MCU that supports fast 
multiplication. On ATMega MCU as example we can shift left (one byte 
shifted into a word) faster by a multiplication as with ordinary shift
opcodes.

Logical, above source can be only used on compressed fonts with maximal 
2^6 colors, otherwise our 16bit Bits databuffer can be underflow. It can 
be easily rewritten when we expand variable Bits to 24 or 32 Bits width 
and if we check that always more as 2 + font_Bits_per_Pixel Bits are 
valid. One 256 colors fonts that are 2 + 8 + 8 = 18 bits maximal width 
for variable Bits.

Best Regards, Hagen

Hagen Re wrote:

> Yes i can help you ;)

Thank you very much for an explanation!
I`ve got it :)

I`am just interesting, is there is a way to stop LCD controller from 
screen refreshing while data write is in progress?
It is better to see the whole picture at once, than observe appearance 
of each pixel...
There must be some synchronization between the data transfer and actual 
picture change, because the screen updates momentarily when LCD is in 
the phone.
Any ideas?

Not to my knownledge. You cant stop the refreshing of the LCD, thats 
transparently done in background without affecting our communication 
trough SPI with it. Thus phone MCU done only one thing better as our 
lame small MCU,  they SPI works most realy faster.

On my S65 Library i worked with 8 Mhz SPI and my bitmap drawing 
functions get mostly the full troughput on decoding/decompression while 
SPI sends data. I get about 16 frames per second. But as example the S65 
LCD could be driven with 27 Mhz SPI instead of lame 8 Mhz. Of course 
with hardware SPI and not with some bit banging soft SPI ;) Thus i 
have'nt any problems to see "apperance of each pixel", even'nt with 
slower functions as with my font drawing functions (they are even more 
complex stuff in software, you known;). Currently i have the feeling 
that my lame 16 Mhz ATMega128 is on drawing a complex menu system faster 
as some commercial phones.

And we must strongly differentiate between the phone displays. Newer one 
use far more faster communications.

Best Regards Hagen

The mobile phone uses a copy of the display ram (shadow). The phone-µC 
itself writes only (very fast) to the shadow that is connected the µC 
bus. The shadow is copied after µC request (or automatically for video 
and camera) to the display by hardware. Therefor you can not see the 
display content build up pixel by pixel. The SPI clock frequency is 
13MHz -> 29ms is the shortest  screen refresh period (>30 frames/sec).

The copy-hardware and shadow function is part of the grafik controller 
chip in the phone. The grafik controller chip also takes care about 
camera functions.

If you think about the 46kByte you need for display shadow that is not 
suitable for small µC systems....

Thanks for the answers :)

I did not mean really that I see how each pixel is changing during data 
write.
I`am talking about Vertical Synchronization.

I communicate with the display (LS020) through 12 MHz SPI of my AT91SAM7 
ARM controller. The whole screen transfer takes about 31,6 ms. Almost as 
in the phone.

>The SPI clock frequency is 13MHz -> 29ms is the shortest  screen refresh period 
(>30 frames/sec).
Yes, but the screen refresh (most likely) is twice as high. And display 
contents will be scanned and updated twice while data is fully 
transferred.
And this is the cause of so called "tearings" (I do`nt know how to name 
it exactly in english...).

>Therefor you can not see the display content build up pixel by pixel.
But, without vertical sync, its easy to see (during full screen data 
write - 31,6 ms) that the screen updates not at once.

In order to avoid this "tearings", the only high speed SPI is not 
enough.
There must be such a synchronization, and the phone does it somehow. But 
how?

At least, 12 MHz did not helps. I can try higher - up to 24 MHz with my 
controller. If the LCD can operate at that frequency, of course...

Ok i understand now.

First on LCD there exists no Vertical Synchronization, there exists no 
vertical retrace like in CRT monitors ;)

But the LPHxxxx Display as Example supports a interlaced frame cycle 
control -> interlaced drive and high speed Burst RAM Write.

1.) HWM mode: we send 4 pixel and first after this the display put it 
into GRAM. This avoid jitter.

2.) interlaced drive: prevent flicker and is what you want. Read the 
HD66733R Datensheet on page 103.

On my experiments with my S65 library on LPHxxx displays i played around 
this interlaced drive control. Yes it avoid flicker but reduce 
remarkable the display quality if we display as example a large gray 
background and in the middle a sharp square. Then we see shaddow effects 
on the remaining gray area. Thats why i don't use it. I think it's only 
usefull when we display fast animations but never usefull for static 
displaying on menu sytems, graphics etc.pp.

Best Regards Hagen

>First on LCD there exists no Vertical Synchronization, there exists no
>vertical retrace like in CRT monitors ;)

Maybe, but image building mechanisms are the same: 60 frames per second, 
"beam" goes from topmost row down to bottom. 176 rows each of 132 
pixels.

I`ve attached the image with explanations of these "tearings" (or 
flicker) I`am trying to avoid: 
http://www.sonycman.newmail.ru/LCD_Image_building.zip
LCD display refresh frequency is 60 Hz and the SPI speed is 12 MHz (30 
frames per second).

Does my LS020 (LR38826) is in any way compatible with HD66733 
controller?

Best regards,
Vladimir

not compatible but very probable supports the controller same mechanism 
as the HD66733. But we don't know because we have'nt the original 
datasheet. Thats why i choose only the LPHxxxx displays.

I will try on my LPHxxxx display your example.

>Maybe, but image building mechanisms are the same: 60 frames per second,
>"beam" goes from topmost row down to bottom. 176 rows each of 132
>pixels.

Even not. Dependend on the LCD and the mounting the AC Drive of the 
scanlines can be any order. Mybe topdown or bottomup, mybe first top 
half in topdown and second half bottomup or even interlaced, lines by 
lines interleaved with upto 4 frames needed to display the full image 
one times or even pixel chunks interleaved. There exists many different 
drive controls compared to a common CRT monitor wich have a vertical 
retrace cycle, very long time to put in  hidden the next image.

Best regards, Hagen

Found some datasheet for LS020 LCD module.
It seems (see attachment) that two its interface pins - CS and RS - are 
bidirectional (input/output).
Interesting, what kind of data they can provide?

Hello, Hagen Reddmann.
I`ve just finished writing basic routines for the text printing...
Thanks again :)
My next step will be into displaying the images converted by your 
S65-bitmap converter.
Would you be so kind to reveal to me structure of its output files?
RLE compression is used, I presume?

PS: What do you think about using GIF or PNG compressors? 256 colors 
will be enough for most cases...

Yes i give you ;)

Last thing as first:

My compression is better as PNG !? ;) Yes, i thought it can't never so 
good as PNG or GIF but i compared the resulting filesizes, and get this 
result. Maybe, my assumption is that we use relatively small images 
compared to common use in GIF and/or PNG. The overhead for such small 
files in headers are bigger in ratio to the complete image in these 
formats. My headers are very small and my compression is realy primitve 
and straightforward.
And thats the more important thing, then we need a easy dataformat, 
instead of a complex LZW/LZH compressed GIF or much more complex PNG 
dataformat. PNG especialy supports much more different encoding 
schematas with larger need on memory or processor resources. Both are 
good for big PCs or fast ARMs but for my tiny ATMega i'am faster to my 
goal with a own format. I considered it at first but i was much faster 
with my own solution. As Example the Delphi program to convert, mirror, 
scale down, import and compress the images was done in about five hours. 
One hour later i finished my glcdDrawBitmap() (without optimization). I 
think in this shirt time i could'nt understand the PNG dataformat alone. 
That i get as side effect a better compression had me let wonder.

The argument "we need most times only 256 color images" was a "no no" 
for me. No, i need most times even images with far more colors, 
otherwise i could pay a lame monochrome LCD with fixed 2 lines in one 
font charset. Instead i payed for a 2^16 smart color display and even 
want to display colorfull images ;)


Ok the file format:

There exists 4 different formats:

1.) unichrome images, thats nothing others as a rectangle filled in one 
color. The header looks like

1

struct bitmap {

2

  uint8_t Width;

3

  uint8_t Height;

4

  uint8_t Bits_Per_Pixel;

5

  uint16_t BkColor; 

6

}

- Width in Pixels
- Height in Pixels
- Bits per Pixel, color depth == 0
- backgroundcolor

Paint a rectangle in given Width and Height relative to the coordinates 
X,Y filled with BkColor.

2.) full color images, each pixel is 16 Bit

1

struct bitmap {

2

  uint8_t Width;

3

  uint8_t Height;

4

  uint8_t Bits_Per_Pixel;

5

  uint16_t BkColor;

6

  uint16_t Pixels[Width*Height -1];

7

}

- width, height see above
- Bits per Pixel == 16
- Color, first left top Pixel color, most used as transparency color. If 
my glcdDrawBitmap() routine should paint this bitmap transparent then 
this color, eg. the top left pixel, marks this transparent color. In the 
LPHxxxx Display we can setup a special graphics raster operation that 
filter out all data sends with this color. Thus would'nt paint this 
pixels.
- Pixels[] the remaining pixel

Ah, i forgot, the Pixel data is line by line from left to right, eg. the 
natural order.

Calculate PixelCount = Width * Height, setup the first Pixel in BkColor 
the remaining  PixelCount -1 Pixel read as 16Bit from Data[].

3.) monochrome image, eg. 2 colors. This image format use real RLE 
compression but in a litte differnt format, especialy optimized for AVR 
processors.

1

struct bitmap {

2

  uint8_t Width;

3

  uint8_t Height;

4

  unit8_t Bits_Per_Pixel;

5

  uint16_t BkColor;

6

  uint16_t FgColor; 

7

  uint8_t Data[];

8

}

- Width, Height hm se above ;)
- Bits per Pixel == 1
- BkColor left top most pixel
- FgColor the second color used in monochrome images

Because BkColor contains the first top left Pixel our compressed Data[] 
have already one information that we do'nt need to encode at first.

Read 1 Byte from Data[] ->

Buffer = *Data++;
PixelBits = ((Buffer >> 4) +1) << 2;
Buffer &= 0x0F;
Buffer |= Buffer << 4;

We have read one RLE Code Byte. In the Low Nibble we have encoded a 4 
Bit Pixel Mask. As Example 0011b means: set 2 Pixel in BkColor and set 2 
Pixel in FgColor. In the High Nibble we have encoded the repeat count of 
such a 4 Pixel sequence. Iff we have 0000b in High Nibble then we must 
repeat one times the 4 Bit encoded sequence. Because my loop decrement 
the PixelBits on every pixel we have thus to compute PixelBits = 
((Buffer >> 4) +1) * 4; to get the real pixel count to setup. Now we 
fillup Buffer in the high nibble with its context form low nibble, eg. 
we ecpand our sequence from 4 Bit to 8 bit. Thats easy on AVR because 
they have a SWAP Instruction for nibbles. In our inner loop we set now 
Width*Height pixels, rotate Buffer one Bit left -> ROL(), check if 
lowest Bit is TRUE and select FgColor as Pixelcolor otehrwise FgColor. 
After we have setup PixelBits Pixel we must read the next RLE Code Byte. 
Decode it such as above and repeat.

4.) 3 upto 2^15 Color Bitmaps. Thats the most complex format, not realy 
;)

1

struct bitmap {

2

   uint8_t  Width;

3

   uint8_t  Height;

4

   uint8_t  Bits_Per_Pixel;

5

   uint16_t BkColor;

6

   uint16_t Color_Table_Size;

7

   uint16_t Color_Table[Color_Table_Size / 2];

8

   uint8_t  Data[];

9

}

- Bits_Per_Pixel between 2 upto 15
- BkColor see above
- Color_Table_Size, size in BYTES of following Color Table, with this 
member we could easy skip to member Data[] (our pointers).
- Color Table, contains sorted all used colors in the image, the next 
higher power of 2 of they count defines Bits_Per_Pixel.

Now Data[] contains a Bit Stream. So far as we read a 0 Bit we paint a 
Pixel in the current active Color. That is on startup logical BkColor. 
When we read a 1 Bit we get a new color. Then read Bits_Per_Pixel Bits 
from Data[] as Index into our Color_Table[]. Load the new Color from it, 
and paint one Pixel in this new color. Then again read from Data[] all 0 
Bits and set a pixel in this color until we have Width*Height Pixels set 
or we read a 1 Bit from Data[], the next color index into Color Table.

The Bits in Data[] are right justified, thus you load one Byte from 
Data[] and right shift out Bit by Bit.

Best Regards, Hagen

1

uint16_t colormasks[14] PROGMEM = {0x0006, 0x000E, 0x001E, 0x003E, 0x007E, 0x00FE, 0x01FE, 0x03FE, 0x07FE, 0x0FFE, 0x1FFE, 0x3FFE, 0x7FFE, 0xFFFE};

2

3

void glcdDrawBitmap(glcdCoord_t x, glcdCoord_t y, const prog_char* bitmap, uint8_t flags) {

4

5

6

#define GLCD_LOAD_BITS(data0, data2, databits, addr, bitsmul) \

7

   asm volatile(                            \

8

    "cpi   %2, lo8(16)"         "\n\t"  \

9

        "brsh  .%=2"                "\n\t"  \

10

        "movw  r30, %A3"            "\n\t"  \

11

        "lpm   r0, Z+"              "\n\t"  \

12

        "mul   r0, %4"              "\n\t"  \

13

        "cpi   %2, lo8(8)"          "\n\t"  \

14

        "brsh  .%=1"                "\n\t"  \

15

        "or    %A0, r0"             "\n\t"  \

16

        "or    %B0, r1"             "\n\t"  \

17

        "subi  %2, lo8(-(8))"       "\n\t"  \

18

        "lpm   r0, Z+"              "\n\t"  \

19

        "mul   r0, %4"              "\n\t"  \

20

".%=1:"                             "\n\t"  \

21

        "or    %B0, r0"             "\n\t"  \

22

        "or    %1, r1"              "\n\t"  \

23

        "subi  %2, lo8(-(8))"       "\n\t"  \

24

        "movw  %A3, r30"            "\n\t"  \

25

        "clr   r1"                  "\n\t"  \

26

".%=2:"                             "\n\t"  \

27

      : "=r" (data0),                     \

28

        "=r" (data2),                     \

29

        "=a" (databits),                  \

30

        "=r" (addr),                      \

31

        "=r" (bitsmul)                    \

32

      : "r" (data0),                      \

33

        "r" (data2),                      \

34

        "a" (databits),                   \

35

        "r" (addr),                       \

36

        "r" (bitsmul)                     \

37

        : "r0", "r1", "r30", "r31"          \

38

     );

39

40

#define GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor) \

41

   asm volatile(                            \

42

        "movw  r30, %A0"            "\n\t"  \

43

        "lsr   %1"                  "\n\t"  \

44

        "ror   %B0"                 "\n\t"  \

45

        "ror   %A0"                 "\n\t"  \

46

        "brcs  .%=0"                "\n\t"  \

47

        "dec   %2"                  "\n\t"  \

48

        "lsr   %6"                  "\n\t"  \

49

        "brne  .%=3"                "\n\t"  \

50

        "ori   %6, lo8(0x80)"       "\n\t"  \

51

        "rjmp  .%=3"                "\n\t"  \

52

".%=0:"                             "\n\t"  \

53

        "and   r30, %A4"            "\n\t"  \

54

        "and   r31, %B4"            "\n\t"  \

55

        "add   r30, %A3"            "\n\t"  \

56

        "adc   r31, %B3"            "\n\t"  \

57

        "lpm   %A7, Z+"             "\n\t"  \

58

        "lpm   %B7, Z"              "\n\t"  \

59

        "mov   r30, %5"             "\n\t"  \

60

        "cpi   r30, lo8(8)"         "\n\t"  \

61

        "brlo  .%=1"                "\n\t"  \

62

        "mov   %A0, %B0"            "\n\t"  \

63

        "mov   %B0, %1"             "\n\t"  \

64

        "clr   %1"                  "\n\t"  \

65

        "andi  r30, lo8(0x07)"      "\n\t"  \

66

        "breq  .%=2"                "\n\t"  \

67

".%=1:"                             "\n\t"  \

68

        "lsr   %1"                  "\n\t"  \

69

        "ror   %B0"                 "\n\t"  \

70

        "ror   %A0"                 "\n\t"  \

71

        "dec   r30"                 "\n\t"  \

72

        "brne  .%=1"                "\n\t"  \

73

".%=2:"                             "\n\t"  \

74

        "sub   %2, %5"              "\n\t"  \

75

        "dec   %2"                  "\n\t"  \

76

        "mov   r30, %2"             "\n\t"  \

77

        "andi  r30, lo8(0x07)"      "\n\t"  \

78

        "clr   r31"                 "\n\t"  \

79

        "subi  r30, lo8(-(powerof2))"   "\n\t"  \

80

        "sbci  r31, hi8(-(powerof2))"   "\n\t"  \

81

        "lpm   %6, Z"               "\n\t"  \

82

".%=3:"                             "\n\t"  \

83

      : "=r" (data0),                     \

84

        "=r" (data2),                     \

85

        "=a" (databits),                  \

86

        "=r" (colortable),                \

87

        "=r" (colormask),                 \

88

        "=r" (bpp),                       \

89

        "=r" (bitsmul),                   \

90

        "=r" (bkcolor)                    \

91

      : "r" (data0),                      \

92

        "r" (data2),                      \

93

        "a" (databits),                   \

94

        "r" (colortable),                 \

95

        "r" (colormask),                  \

96

        "r" (bpp),                        \

97

        "r" (bitsmul),                    \

98

        "r" (bkcolor)                     \

99

        : "r30", "r31"                      \

100

     );

101

102

103

    if (!(bitmap)) return;

104

    uint8_t w = pgm_read_byte_inc(bitmap);

105

    if (!(w)) return;

106

    uint8_t h = pgm_read_byte_inc(bitmap);

107

    if (!(h)) return;

108

    uint8_t bpp = pgm_read_byte_inc(bitmap);

109

    uint16_t bkcolor = pgm_read_word_inc(bitmap);

110

    if (flags & GLCD_BMP_USECOLORS) bkcolor = glcd.Colors[0];

111

    if (bpp == 0) {

112

      glcdFillRect(x, y, x + w -1, y + h -1, bkcolor);

113

      return;

114

    }

115

    GLCD_CS_ON();

116

    GLCD_SETADDR(x, y);

117

    GLCD_WINDOW(x, y, x + w -1, y + h -1);

118

    if (flags & GLCD_BMP_TRANSPARENT) {

119

      GLCD_SETMODE(0x38 | GLCD_ROP_WNE);

120

      GLCD_SETCOMPARE(bkcolor);

121

    } else {

122

      GLCD_SETMODE(0x38);

123

    }

124

    GLCD_STARTDATA();

125

    if (bpp == 1) {// monochrome

126

      uint16_t pixelcount = w * h;

127

      uint16_t fgcolor = pgm_read_word_inc(bitmap);

128

      if (flags & GLCD_BMP_USECOLORS) fgcolor = glcd.Colors[1];

129

      uint16_t color = bkcolor;

130

      if (flags & GLCD_BMP_SWAPCOLORS) {

131

        bkcolor = fgcolor;

132

        fgcolor = color;

133

        color   = bkcolor;

134

      }

135

      uint8_t data = pgm_read_byte_inc(bitmap);

136

      uint8_t pixelbits = ((data >> 4) +1) << 2;

137

      data &= 0x0F;

138

      uint8_t temp = data << 4;

139

      data |= temp;

140

      do {

141

        GLCD_WAIT();

142

        GLCD_OUT(H8(color));

143

        if (!(--pixelbits)) {

144

          data = pgm_read_byte_inc(bitmap);

145

          pixelbits = ((data >> 4) +1) << 2;

146

          data &= 0x0F;

147

          uint8_t temp = data << 4;

148

          data |= temp;

149

        }

150

        GLCD_WAIT();

151

        GLCD_OUT(L8(color));

152

        ROL(data);                                // rotate data, data = (data << 1) | (data >> 7);

153

        color = bkcolor;

154

        if (data & 0x01) color = fgcolor;

155

      } while (--pixelcount);

156

    } else if (bpp == 16) { // full color

157

      uint16_t pixelcount = w * h;

158

      while (pixelcount) {

159

        GLCD_WAIT();

160

        GLCD_OUT(H8(bkcolor));

161

        pixelcount--;

162

        GLCD_WAIT();

163

        GLCD_OUT(L8(bkcolor));

164

        bkcolor = pgm_read_word_inc(bitmap);

165

      }

166

    } else {// color, 2 upto 15 BPP

167

      uint16_t colortablesize = pgm_read_word_inc(bitmap);

168

      uint8_t* colortable = (uint8_t*)bitmap;

169

      bitmap += colortablesize;

170

      uint16_t colormask = pgm_read_word(&colormasks[bpp -2]);

171

      uint8_t databits = 0, data2 = 0, bitsmul = 1;

172

      uint16_t data0 = 0;

173

//      uint32_t data = 0;

174

      uint16_t pixelcount = w * h;

175

      do {

176

        GLCD_WAIT();

177

        GLCD_OUT(H8(bkcolor));

178

        pixelcount--;

179

        GLCD_LOAD_BITS(data0, data2, databits, bitmap, bitsmul);

180

181

//        while (databits < 16) {

182

//          uint16_t t = pgm_read_byte_inc(bitmap) * bitsmul;

183

//          if (databits >= 8) data |= (uint32_t)t << 8;

184

//            else data |= t;

185

//          databits += 8;

186

//        }

187

188

        GLCD_WAIT();

189

        GLCD_OUT(L8(bkcolor));

190

191

        GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor);

192

193

//        if (LL8(data) & 0x01) {

194

//          bkcolor = pgm_read_word(colortable + (L16(data) & colormask));

195

//          data >>= bpp;

196

//          databits -= bpp;

197

//          bitsmul = pgm_read_byte(&powerof2[databits & 0x07]);

198

//        }

199

//        bitsmul >>= 1;

200

//        if (!(bitsmul)) bitsmul |= 0x80;

201

//        data >>= 1;

202

//        databits--;

203

      } while (pixelcount);

204

    }

205

    GLCD_WAIT();

206

    GLCD_CS_PULSE();

207

    GLCD_SETMODE(0x30);

208

    GLCD_CS_OFF();

209

}

Aber warum muss man nur "pure" LCD-Module nehmen, Schnitstelle basteln 
und Driver schreben? Ist nich einfacher S65 "As is" nehmen, und mit die 
ganze J2ME power bequem und einfach über RS232 oder USB arbeiteiten? Und 
dazu Handy Tastatur für Eingabe benutzen?

Weil ich kein Telefon an einem Schlagzeug brauche ?

Gruß Hagen

abbo

Hagen Re wrote:
> Weil ich kein Telefon an einem Schlagzeug brauche ?
>
> Gruß Hagen

ja, aber:
- für Lösung mit raw Display braucht man viel mehr Arbeit investieren, 
als mit Java Handy
- S65 sind letzte Handys mit serieller Schnittstelle zwischen Display 
und main Prozessor, folgende Generation kommt mit 8 Bit parallel.
- muss man für jede Displaytype eigene Driver schreiben
und mit Java kann man attached screenshot sofort kriegen

Hagen Re wrote:
> Yes i give you ;)

Thanks!
You`re the best :)

Best regards
Vladimir

ist das Bitmap als PROGMEM_UPPER deklariert und hast du die Section im 
MakeFile ? Schau dir mal mein Drum Projekt Source + MakeFile an.

Falls du die Bitmaps nicht in einer eigenen FLASH Section speichern 
möchtest, dann gehe in glcdDrawBitmap() und entferne das Makro 
SET_RAMZ(1) oder setze es auf 0.

Ich habe das gemacht weil ich in meinem ATMega128-Drum-Projekt mit den 
großen Bitmaps auf Probleme mit dem Compiler stieß, er wollte es nicht 
mehr kompilieren. Zudem spare ich mir so die ständige Berechnung einer 
24 Bit Adresse ins FLASH -> RAMPZ:ZH:ZL -> bei jedem Zugriff um nur 1 
Byte aus dem FLASH zu laden. Also: Section textupper ins Makefile die 
zb. an Addresse 0x11000 beginnt. Alle Bitmaps als PROGMEM_UPPER -> 
textupper -> deklarieren, und fertig. Vorteil: andere FLASH Konstanten, 
wie aufwändiges Menusystem, Fonts usw. liegen gemeinsam mit dem Code am 
Anfang des FLASHs. Am Ende liegen nur die großen Bitmaps.

Gruß Hagen

beim Text hast du vorher

1.) einen Font eingebunden ?
2.) glcdSelectFont(dein_font) aufgerufen ?
3.) in glcd.Colors[0..3] die Farben gesetzt ?

Gruß Hagen

Hallo,

ich versuche nun seit 5 Stunden das LCD ans Laufen zu brinngen, leider 
vergebens.

Wie wichtig sind die Timings?
Zu viel warten kein Thema oder doch ein Thema?

Wie sieht es mit den SPI Settings aus?
Ich nutze inen SAM7..

Hier das CS Register
  s_pSpi->SPI_CSR[0] = AT91C_SPI_NCPHA         // (SPI) Display
                        //AT91C_SPI_CSAAT
                       | AT91C_SPI_BITS_16
                       | 55<< 8 //AT91C_SPI_SCB  // (SPI) Serial Clock 
Baud Rate
                       | 55<<16   //AT91C_SPI_DLYBS
                       | 55<<24;   //AT91C_SPI_DLYBCT;  // (SPI) Delay 
Between Consecutive Transfers
Da habe ich schon unterschiedliche Werte ausgetestet leider ohne Erfolg.

Jens

Danke,
könnte sein, dass es das bei mir ist.

Die Befehle kann ich die in 16Bit rueber schieben, oder ist das 
Interface nur 8Bit Breit?

Die funktionieren (LS020) auf dem AVR ohne Probleme ;)

Hallo,

ich habe heute mal mich etwas mehr mit dem LCD auseinander gesetzt, und 
mus sagen WOW.
Ich habs hinbekommen mit knapp 50MHz SPI Clock anzusprechen.

Controller ist der SAM7.
Nun setz ich mich ersteinmal an das Thema FONTs etc mal sehn, was raus 
kommt.

Das Programm von Mike Bird befindet sich hier und heisst 
BMPConvert16.zip
da der Link oben tot ist findet man es hier:

http://home.arcor.de/dirk.milewski/seite72.html

für unsere BASCOM und Assembler Freunde.

ich habe mal eine frage: das datenblatt des controllers ist doch 
inzwischen bekannt oder?
Dann müsste die powerdown sequenz doch auch bekannt sein oder?

Weil ich verwende das LS020xxx Display und zu diesem steht in dem PDF 
bei powerdown nix dabei außer halt de reset methode...

Es wurden ja 2 Datenblatter reingestellt, beide von Hitachi, sind das 
überhaupt die Controller für die LS020xxx Displays oder gilt das nur für 
die anderen Typen?

MFG
luxx

hallo an alle,

ich schliesse mich mal fragend an luxx beitrag an: wie steht es um das 
LS020- gibt es eine spec dafuer? koennte die mal jemand posten oder per 
mail verteilen?

gruss dudu

Hallo,

diese Register kannst du nur über den SRAM ansprehen, wenn diese zu hoch 
liegen.

Ich mein das war mit ST - Store Indirect From Register to data space 
using Index X

Gruss Jens

Hallo,
kaum hat man das LS20.... zum laufen gekriegt,
fangen die Probleme schon an.
Ich will meine Hintergrundfarbe prog.
Leider habe ich vergeblich versucht eine 16 Bit Farbtabelle
zu finden. 24 Bit ist an jeder "Ecke" zu haben.
Oder anders: der Hintergrund soll zum Display meines Yaesu Tranceiver
passen.Wäre Rotbraun oder so.
Mit probieren habe ich es schon stundenlang versucht.
Hat jemand da was parat?
Dank für Eure Hilfe.


Wigbert

Hallo Jens,

kapier ich nicht.

ff für Rot wäre binär 11111111 also 8 Bit.
ich hab doch aber nur 11111 also 5 Bit Rot , 6 Bit grün , 5 Bit blau
oder wandelst Du das mit der #define um?
Bin Bascom Fan und da declariere ich zB. rot
Const Rot = &B1111100000000000
aber das müsste egal sein.


Wigbert

Das Display wird digital mittels entsprechender Display-Befehle 
angesteuert. Du aber möchtest einen analogen AV-Eingang. Der damit 
verbundene Aufwand käme  mit Sicherheit deutlich höher, als wenn Du in 
den nächsten Geiz-ist-Geil-Markt gehst und Dir dort ein LC-Display mit 
analogem AV-Eingang kaufst. Oder schau mal bei iBlöd unter dem Stichwort 
"Auto DVD Player Sonnenblende" nach. Dort bekommst Du ein 7 Zoll Farb 
LC-Display mit AV-Eingang und DVD-Player für ca 80 Teuro.

Da ist es doch viel einfacher so ein 7" Monitor zu kaufen und dort
die Designeffekte anzuzeigen als auf so einem kleinen Display.
130x130px sind nichts im Vergleich zu 640x480 oder so.
Gib mal in Paint die beiden Pixelmaße ein und vergleiche mal.

Ein guter Anfang ist das AVR-Tutorial...

Außerdem wäre ein neuer Post auch kein Schaden, denn
dieser hier bezieht sich auf das S65 Display und wird
durch solche Anfängerfragen nur (entschuldigung) zugemüllt.

Hallo Mirco,
geh mal zu http://www.comwebnet.de/
Dort haben wir die ersten "Gehversuche" mit s65 in Bascom hinterlegt.
Vielleicht werden dann einige Fragen beantwortet sein.
und wenn du die Grundlagen beherrschst, kannst Du hier ruhig 
weiterfragen.


Wigbert

Hallo everyone

Hopefully you don't mind that this post is in English (can't write 
German just a little understanding because I speak Dutch and English).

I tried the last getting a Siemens S65 display to work... After one 
week, I finally get 'random noise (all pixels light up in a different 
color'.

Can someone help me with that? Or does someone has the correct init 
codes, maybe a simple example program wich turns on some pixel(s) or 
draw a char?

I'm using the Arduino NG Board (http://www.arduino.cc) en the 
environment (Arduino-0008) which is basically AVR-GCC with a bootloader.

I do also have a blog at http://www.arduinoprojects.blogspot.com where 
you can read mij 'experience' ;-)

I hope someone of you can help me or get this project running.

Thanks a lot in advance!

Andy

Hallo,
ich hatte schon vor längerer Zeit ein LS020 mit den Routinen von 
Christian zum Laufen gebracht. Als einzige Änderung hatte ich auf 
Soft-SPI umgestellt und alles lief auf Anhieb auf einem mega8 
(mittlerweile: mega168).
Danach hatte ich vom gleichen ebay-Handler zwei L2F50 Displays bekommen,
die ich im Moment versuche, zum Laufen zu bringen. Ich verwende einen 
mega168.

Meine Versuche:
1. simple-code von Christian, Pins angepaßt und mein Soft-SPI (der beim 
LS020 funktionierte)
Ergebnis: nix!

2. simple-code von Christian, Pins angepaßt mit original Hard-SPI
Ergebnis: nix!

3. Version 1. aber RS-Signal gedreht (wie bei LS020)
Ergebnis: Wenn in der init-sequenz lcd_wrcmd(DISON); kommt, dann 
schaltet das Display ein und man sieht Zufallswerte/Rauschen, aber 
danach funktionieren keine weiteren Kommandos, wie DISOFF,DISINVERT etc.
Wenn ich dann ein fill_screen() mit allen möglichen Farben durchtickere, 
dann wird das Display zwischendurch mal ganz oder teilweise weiß.

Hat jemand eine Idee?

Ich werde meinen Test-Code mal entrümpeln und anhängen. Ist im Moment 
für Außenstehende unlesbar (wie üblich bei mir, wenn ich zu lange an 
etwas rumteste...)!

Gruß,

Matthias

Hallo,

ich habe das LS020 mit 48MHz am laufen (AT91SAM7S)
Kann mir jemand sagen, ob und wie ich den Kontrast / helligkeit 
veraendert bekomme? bzw wie ich den Pointer nur eins weiter stellen 
kann?

> RS ist der R/W - Selektor. Data und Clock sind auch klar. Aaaber was
> meint CS?
> Der Hintergrund ist, dass ich gern versuchen möchte- ähnlich NDS 2
> Displays anzusteuern..

Wer solche Fragen stellt sollte nochmal bei den Basics anfangen....


CS ist Chipselect wie schon oben gesagt, es dient dazu wenn mehrere 
Teilnehmer am selben Bus hängen, demjenigen für den die Daten bestimmt 
sind zu sagen, pass auf, das hier ist für dich, die die nicht angewählt 
sind ignorieren die Daten.

uLuxx

achso ja dann, nix für ungut...

Hallo LS020 Nutzer,

Nutzt hier jemand die "More advanced RAM addressing modes" wie auf 
http://www.superkranz.de/christian/S65_Display/DisplayRamAccess.html 
beschrieben ??

Folgendes Problem, ich definiere 3 mal im "mirror image, -90 degree " 
Mode einen schmalen Bildschirmausschnitt, immer mit der selbe Funktion 
bei mir daher eigentlich auch keine x y Vertauschung möglich. Zwei mal 
davon macht er es richtig und erzeugt die Zeichenkette, das 3.Mal 
definiert er einen Block als wäre x y vertauscht was natürlich dann die 
Zeichendarstellung unmöglich macht. Setzte ich vor dem 3.Mal einfach 
mittels 0xEF90, 0x0504 einen Windows resize auf Maximum und danach wie 
üblich die alte Windowdefinition funktioniert das prima. Siehe auch das 
Bild im Anhang fuer den Schlechtfall. Mit Workaround ist das 3.Fenster 
wirklich als neue Zeile unten drunter zu sehen.

Ich habe daher den Verdacht das die advance Modies irgendwelche 
Einschränkungen haben oder mit relativen Adressen arbeiten. Wäre schon 
wenn da jemand seine Erfahrungen mit beitragen kann und etwas Licht ins 
Dunkle bringt.


Danke Alex

Kann jemand kurz sagen welche Displayversion sich am geeignetesten 
erwiesen hat?

LS020

Nur leider gibt es dazu kaum Befehle, die man nutzen kann.
Oder hat jemand ein paar Möglichkeiten gefunden den Pointer zB. nur eins 
weiter zu setzen OHNE ein pixel zu setzen?

Leider nicht, musst halt das Fenster komplett neusetzen und dann dort 
weitermachen.

Alex

Hallo zusammen,

ist die Seite vom "SUPERKRANZ" down??

Was nun ?

MfG,

balze

P.S.: Jetzt wollte ich mich mal mit dem S65 Display befassen und der 
"God of S65 LCD programing" ist mit seiner Seite vom Netz :(

P.P.S.: Gibt es einen Mirror vonder Seite? Waere ueber jeden Hinweis 
dankbar.

In meinem PDF steht alles was man dazu braucht(nur kein code)
...hoffe du kannst was damit anfangen bis die Seite wieder
online ist.

Gruß Lightning

Danke fuer Eure schnelle Hilfe !!!


MfG,

balze

Nope, and chances are near to zero to get some as this display is nearly 
not manufactured new anymore. So the companies don´t want to spread 
the datasheet, they wanna sell the new stuff. The LS020 displays will 
anyhow be available for the next years as there are more than enough 
reserves for hobbyists.

hi,
ich wollt mir auch mal ein paar zulegen. Welche Typ ist denn zu 
empfehlen?

LS020...

http://www.comwebnet.de

Das GLCD sollte auch 3,3V ab können, hatte das mal diesbezüglich nach 
gefragt.

Wenn du das nur n paar mal privat (also nicht in serie) bauen willst 
kannst du einfach mal deine controller durchtesten, mein mega16 macht 
bei 2,9V noch volle 16MHz. Wenn man in Serie baut, kann man sich dadrauf 
natürlich nicht mehr so verlassen ;)

Hallo,

ich habe das S65 vor einigen Tagen mit der einfachen Testsoftware auf 
von CK zum laufen gebracht. Läuft alles prima und problemlos, bisher tut 
es das was ich will. Da das Display nacher einmal mehr ausgeben soll als 
nur ein bisschen Text und nen bunten Hintergrund und ich keine Zeit habe 
eigene Routinen zu entwickeln wollte ich nun die
GLCD-Lib einbinden um auch komplexere Dinge auf den Bildschirm zu 
bringen.

Mit der Installation von Bibliotheken habe ich keine große Erfahrung, 
und so erschließt sich mir auch nach mehrmaligem lesen der 
Installationsanleitung nicht, wie genau ich die Bibliothek installieren 
soll. Vor allem finde ich bei mir keine compile.bat. Ausserdem entstehen 
bei mir beim Entzippen andere Ordner als in der Installation angegeben. 
Könnte mir jemand kurz erlären wie genau ich die Bibliothek einbinde ?

Ich nutze AvrStudio 4.13 SP2 in Verbindung mit Winavr-20070525.

Netten Gruß,

Marc

Hallo

Ich hab mir gerade das Display bestellt und werde in den nächsten Tagen 
versuchen das ganze zum laufen zu bringen.

Ich hab noch ein paar Fragen:

Mein Board/AVR läuft mit 3.3 Volt. Kann ich nun damit direkt ins display 
rein oder brauch ich noch einen Spannunsteiler.

Auf dem Board habe ich eben nur 3.3 Volt zu Verfügung. Die 
Hintergrundbeleuchtung benötigt ja laut Schaltplan 15V.
Kann ich mir irgendwie aus den 3.3V die 15V auf "relativ" einfache Art 
erzeugen ?

http://comwebnet.co.funpic.de/seite47.php
Forum: http://comwebnet.weimars.net/forum/

Bloß musst du noch ein Kondi und Diode vielleicht dazu bauen, ist 
eigentlich für 5 V. das Display sollte auch auf 3,3V laufen

Hallo zusammen,

seit einiger Zeit spiele ich schon mit dem S65 Display herum. Immer ein
kleiner Dron im Auge war für mich der ASM part. Einen
Geschwindigkeitsvorteil sollte diese Teil nicht sonderlich bringen, da
der Controller in den SPI Funktionen zu 99% warten muss und die C und
ASM Funktionen in dieser Beziehung dann ähnlich lang sind.
Zudem kommt noch hinzu das die ASM Funktionen nicht für einen Atmega644
funktionieren, da dort u.a. das SPCR Register > Adresse 31 ist.

Der Rewrite braucht eigentlich genauso viel Speicher, da ich einige
unnötige Sachen weg gelassen habe. Zudem habe ich die Init-Sequenzen in
das Flash verschoben.

Auch die obere Schichte der Lbr habe ich (im vergleich zum HelloWorld
Programm) erweitert. Nach der klareren Trennung (lcd.h muss nicht mehr
inkludiert werden) wird nun auch die Font nicht mehr in den RAM geladen.
Neben Chars, Strings, Punkten, Linien und gefüllten Rechtecken kann man
nun auch Bilder darstellen. Letztere können verschiedene Farbtiefen und
RAW- oder das bekannte RLE-Format besitzen. Durch den Header werden
automatisch die passenden Funktionen ausgewählt. Ein passender Converter
ist auch mit dabei. Zugegeben er wurde etwas badhack mässig
geschrieben. Mit dem strcut alligment des Headers bin ich mir nicht ganz
sicher ob er für 64bit Maschinen funktionerit. Genauso das 32-bit
alligment der BMP Datei selbst wurde etwas sträflich behandelt. Seht es
euch einfach mal an. Bei mit funktionierts ;)

Vielleicht noch kurz was zur Aufruf weise des Konverters:

1

./convert inputfile picturename 16|15|12|10|8 >> includefile

Auf stderr werden Informationen ausgegeben und auf stdout wird das
umgewandelte Bild ausgegeben, dass in die Code (include file) bepipt
werden kann.


Hier noch ein mini Demoprogramm:

1

#include "s65.h"

2

3

[...]

4

5

    S65_Init();

6

7

    S65_Fillscreen(S65_RGB(0,255,0));

8

    S65_Dawpic(10, 40, (void *) pic, 0);

Vielleicht kann es ja wer gebrauchen...
So Far
Jürgen