The Siemens S65 132x176, 65536 color display with AVR

[Hagen R. (hagen)]

@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

[SuperUser (Gast)]

Hallo Martin,

wenn du die libraray benutzt, musst du die auch neu kompilieren. 
Ansonsten durchsuch doch mal den Quellcode, ob irgendwo noch direkt PB7 
steht...

[TeraByte (Gast)]

@SuperUser

Danke für deine Antwort, aber das versteht sich von selbst, dass man 
Änderungen neu kompiliert!

Das einzigste was mir aufgefallen ist, die .hex hat sich nicht erneuert, 
wenn ich in der .inc was ändere. Habe es schon versucht, die .hex zu 
löschen - kompilieren, aber änderungen trotzdem nicht drin.

Werd das problem beim Compiler noch erforschen: Denke irgenwo dort liegt 
das Prob.

[Michael R. (rubi)]

Hallo Hagen

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

LG
Michael

[Hagen R. (hagen)]

@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

[SuperUser (Gast)]

@Martin
ich wollte nur darauf hinweisen, dass die library ein eigenes makefile 
hat. Ein make im programm folder kompiliert die nicht automatisch mit... 
Aber ich denke das war auch klar oder?

[TeraByte (Gast)]

Hey Proggers,

mal ne Umfrage!

Hab ihr auch das problem, dass ihr das Display (PB1/CLK reicht auch) 
abnehmen müsst um euer Atmega per ISP zu programmieren?
Falls nicht, was ist bei euch anders?

Habe Das ET-BASE AVR Board mit Atmega128 und Display wie Superkranz 
beschrieben hat angeschlossen.

[dudu (Gast)]

hallo aethr,

can post your c-source for LPC2148?

[MichiB (Gast)]

Hallo zusammen,

habe interessiert diesen Thread gelesen!

Dickes Lob an alle!

Habe das Display gerade bestellt und möchte es mit
nem MSP benutzten.

Deshalb die Frage:

Gibt es schon eine Lib für den MSP?

Danke

[aethr (Gast)]

@dudu

currently the ARM LPC code is tied into my project. I was planning to 
factor it out and post it here, but am working with Hagen to port his 
GLCD lib to the LPC.

Have basic graphic primitives working, but needs more work on the bitmap 
and menu functions.

Have you tried to compile the LPC version posted by Lupin on this 
thread?

Encountered any problems?

aethr

[dudu (Gast)]

hallo aethr,

thanks for your reply. the only code what lupin has posted was display.c 
for an avr-controller and a lph-display.
maybe i have overlooked but nothing found.
i am looking for any easy routines for ARM7TDMI-LPC2148 and SHARP-LS020 
display like simple_display3.zip. but the include file inside is 
assembler for AVR. has anyone converted that into C ?
so my first try will be to convert that files into gnu-c for LPC21
48.

dudu

[aethr (Gast)]

Hi dudu,

please find attached my display routines adapted from different sources. 
No cleanup has been made, so bear any rough edges ;)

You need to provide your own SPI initialization and send byte functions; 
nothing special, all pretty standard. If you need info, mail me 
privately.

BTW, initialization is for the LPH variant, but you should have no 
problem changing this.

Have fun.

aethr

[Vladimir R. (sonycman)]

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... :((

[Vladimir R. (sonycman)]

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?

[Hagen R. (hagen)]

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

    struct _FONT_ {
       uint16_t   font_Size_in_Bytes_over_all_included_Size_it_self;
       uint8_t    font_Width_in_Pixel_for_fixed_drawing;
       uint8_t    font_Height_in_Pixel_for_all_Characters;
       uint8_t    font_Bits_per_Pixels;
       uint8_t    font_First_Char;
       uint8_t    font_Last_Char;
       uint8_t    font_Char_Widths[font_Last_Char - font_First_Char +1];
       uint8_t    font_data[];
    }

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

[Hagen R. (hagen)]

Compressed Fonts use

    struct _FONT_ {
       uint16_t   font_Size_in_Bytes_over_all_included_Size_it_self;
       uint8_t    font_Width_in_Pixel_for_fixed_drawing;
       uint8_t    font_Height_in_Pixel_for_all_Characters;
       uint8_t    font_Bits_per_Pixels;
       uint8_t    font_First_Char;
       uint8_t    font_Last_Char;
       uint8_t    font_Char_Widths[font_Last_Char - font_First_Char +1];
       uint8_t    font_Byte_Padding;
       uint8_t    font_RLE_Table[3];
       uint8_t    font_Char_Size_in_Bytes[font_Last_Char - font_First_Char +1];
       uint8_t    font_data[];
    }

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

[Hagen R. (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 ;)

      bitsmul = pgm_read_byte(&powerof2[bitscount & 0x07]);
      if (bitscount < 8) {
        bitscount += 8;
        bits |= pgm_read_byte_inc(data) * bitsmul;    // faster as shifting
      }
      pixelcount = 1;
      do {
        i = FontHeight;
        do {
          if (!(--pixelcount)) {
            pixelcount++;
            if (flags & 0x80) { // compresed Font ??
              pixelcount = rle[bits & 0x03];
              bits >>= 2;
              bitscount -= 2;
            }
            bitscount -= bitspixel;
            bitsmul = pgm_read_byte(&powerof2[bitscount & 0x07]);
            color = colors[bits & bitsmask];
            bits >>= bitspixel;
          }
          GLCD_WAIT();
          GLCD_OUT(H8(color));
          if (bitscount < 8) { // read in advance while we wait for SPI
            bitscount += 8;
            bits |= pgm_read_byte_inc(data) * bitsmul;   // faster as shifting
          }
          GLCD_WAIT();
          GLCD_OUT(L8(color));
        } while (--i);
      } 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

[Vladimir R. (sonycman)]

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?

[Hagen R. (hagen)]

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

[Christian K. (christiank)]

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

[Vladimir R. (sonycman)]

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

[Hagen R. (hagen)]

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

[Vladimir R. (sonycman)]

>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

[Hagen R. (hagen)]

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

[Thomas (Gast)]

Hallo Hagen,

habe auch interesse an dem Quellcode. Könntest Du mir diesen bitte 
mailen ?

danke
Gruß
Thomas

[Thomas (Gast)]

oops, E-Mailadresse: toastin ätt gmx punkt de

[MichiB (Gast)]

Hallo zusammen,

habe ein LS020 bei Ebay ersteigert.
Der Controller (MSP) läuft auf 2.9V.

Ich habe das Simple-Beispiel vom Superkranz umgesetzt.

Leider bekomme ich das Display nicht initialisiert,
scheint so, das Display bleibt weiss.

Aufruf:
  - LCD_Init
  - LCD_Test

Bin ein wengig verwirrt, da die Initialisierung im
Simple-Beispiel nicht dem PDF entspricht.

Bin für jeden Tipp dankvar.

[Vladimir R. (sonycman)]

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?

[Vladimir R. (sonycman)]

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

[Hagen R. (hagen)]

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

struct bitmap {
  uint8_t Width;
  uint8_t Height;
  uint8_t Bits_Per_Pixel;
  uint16_t BkColor; 
}

- 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

struct bitmap {
  uint8_t Width;
  uint8_t Height;
  uint8_t Bits_Per_Pixel;
  uint16_t BkColor;
  uint16_t Pixels[Width*Height -1];
}

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

struct bitmap {
  uint8_t Width;
  uint8_t Height;
  unit8_t Bits_Per_Pixel;
  uint16_t BkColor;
  uint16_t FgColor; 
  uint8_t Data[];
}

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

struct bitmap {
   uint8_t  Width;
   uint8_t  Height;
   uint8_t  Bits_Per_Pixel;
   uint16_t BkColor;
   uint16_t Color_Table_Size;
   uint16_t Color_Table[Color_Table_Size / 2];
   uint8_t  Data[];
}

- 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

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

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


#define GLCD_LOAD_BITS(data0, data2, databits, addr, bitsmul) \
   asm volatile(                            \
    "cpi   %2, lo8(16)"         "\n\t"  \
        "brsh  .%=2"                "\n\t"  \
        "movw  r30, %A3"            "\n\t"  \
        "lpm   r0, Z+"              "\n\t"  \
        "mul   r0, %4"              "\n\t"  \
        "cpi   %2, lo8(8)"          "\n\t"  \
        "brsh  .%=1"                "\n\t"  \
        "or    %A0, r0"             "\n\t"  \
        "or    %B0, r1"             "\n\t"  \
        "subi  %2, lo8(-(8))"       "\n\t"  \
        "lpm   r0, Z+"              "\n\t"  \
        "mul   r0, %4"              "\n\t"  \
".%=1:"                             "\n\t"  \
        "or    %B0, r0"             "\n\t"  \
        "or    %1, r1"              "\n\t"  \
        "subi  %2, lo8(-(8))"       "\n\t"  \
        "movw  %A3, r30"            "\n\t"  \
        "clr   r1"                  "\n\t"  \
".%=2:"                             "\n\t"  \
      : "=r" (data0),                     \
        "=r" (data2),                     \
        "=a" (databits),                  \
        "=r" (addr),                      \
        "=r" (bitsmul)                    \
      : "r" (data0),                      \
        "r" (data2),                      \
        "a" (databits),                   \
        "r" (addr),                       \
        "r" (bitsmul)                     \
        : "r0", "r1", "r30", "r31"          \
     );

#define GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor) \
   asm volatile(                            \
        "movw  r30, %A0"            "\n\t"  \
        "lsr   %1"                  "\n\t"  \
        "ror   %B0"                 "\n\t"  \
        "ror   %A0"                 "\n\t"  \
        "brcs  .%=0"                "\n\t"  \
        "dec   %2"                  "\n\t"  \
        "lsr   %6"                  "\n\t"  \
        "brne  .%=3"                "\n\t"  \
        "ori   %6, lo8(0x80)"       "\n\t"  \
        "rjmp  .%=3"                "\n\t"  \
".%=0:"                             "\n\t"  \
        "and   r30, %A4"            "\n\t"  \
        "and   r31, %B4"            "\n\t"  \
        "add   r30, %A3"            "\n\t"  \
        "adc   r31, %B3"            "\n\t"  \
        "lpm   %A7, Z+"             "\n\t"  \
        "lpm   %B7, Z"              "\n\t"  \
        "mov   r30, %5"             "\n\t"  \
        "cpi   r30, lo8(8)"         "\n\t"  \
        "brlo  .%=1"                "\n\t"  \
        "mov   %A0, %B0"            "\n\t"  \
        "mov   %B0, %1"             "\n\t"  \
        "clr   %1"                  "\n\t"  \
        "andi  r30, lo8(0x07)"      "\n\t"  \
        "breq  .%=2"                "\n\t"  \
".%=1:"                             "\n\t"  \
        "lsr   %1"                  "\n\t"  \
        "ror   %B0"                 "\n\t"  \
        "ror   %A0"                 "\n\t"  \
        "dec   r30"                 "\n\t"  \
        "brne  .%=1"                "\n\t"  \
".%=2:"                             "\n\t"  \
        "sub   %2, %5"              "\n\t"  \
        "dec   %2"                  "\n\t"  \
        "mov   r30, %2"             "\n\t"  \
        "andi  r30, lo8(0x07)"      "\n\t"  \
        "clr   r31"                 "\n\t"  \
        "subi  r30, lo8(-(powerof2))"   "\n\t"  \
        "sbci  r31, hi8(-(powerof2))"   "\n\t"  \
        "lpm   %6, Z"               "\n\t"  \
".%=3:"                             "\n\t"  \
      : "=r" (data0),                     \
        "=r" (data2),                     \
        "=a" (databits),                  \
        "=r" (colortable),                \
        "=r" (colormask),                 \
        "=r" (bpp),                       \
        "=r" (bitsmul),                   \
        "=r" (bkcolor)                    \
      : "r" (data0),                      \
        "r" (data2),                      \
        "a" (databits),                   \
        "r" (colortable),                 \
        "r" (colormask),                  \
        "r" (bpp),                        \
        "r" (bitsmul),                    \
        "r" (bkcolor)                     \
        : "r30", "r31"                      \
     );


    if (!(bitmap)) return;
    uint8_t w = pgm_read_byte_inc(bitmap);
    if (!(w)) return;
    uint8_t h = pgm_read_byte_inc(bitmap);
    if (!(h)) return;
    uint8_t bpp = pgm_read_byte_inc(bitmap);
    uint16_t bkcolor = pgm_read_word_inc(bitmap);
    if (flags & GLCD_BMP_USECOLORS) bkcolor = glcd.Colors[0];
    if (bpp == 0) {
      glcdFillRect(x, y, x + w -1, y + h -1, bkcolor);
      return;
    }
    GLCD_CS_ON();
    GLCD_SETADDR(x, y);
    GLCD_WINDOW(x, y, x + w -1, y + h -1);
    if (flags & GLCD_BMP_TRANSPARENT) {
      GLCD_SETMODE(0x38 | GLCD_ROP_WNE);
      GLCD_SETCOMPARE(bkcolor);
    } else {
      GLCD_SETMODE(0x38);
    }
    GLCD_STARTDATA();
    if (bpp == 1) {// monochrome
      uint16_t pixelcount = w * h;
      uint16_t fgcolor = pgm_read_word_inc(bitmap);
      if (flags & GLCD_BMP_USECOLORS) fgcolor = glcd.Colors[1];
      uint16_t color = bkcolor;
      if (flags & GLCD_BMP_SWAPCOLORS) {
        bkcolor = fgcolor;
        fgcolor = color;
        color   = bkcolor;
      }
      uint8_t data = pgm_read_byte_inc(bitmap);
      uint8_t pixelbits = ((data >> 4) +1) << 2;
      data &= 0x0F;
      uint8_t temp = data << 4;
      data |= temp;
      do {
        GLCD_WAIT();
        GLCD_OUT(H8(color));
        if (!(--pixelbits)) {
          data = pgm_read_byte_inc(bitmap);
          pixelbits = ((data >> 4) +1) << 2;
          data &= 0x0F;
          uint8_t temp = data << 4;
          data |= temp;
        }
        GLCD_WAIT();
        GLCD_OUT(L8(color));
        ROL(data);                                // rotate data, data = (data << 1) | (data >> 7);
        color = bkcolor;
        if (data & 0x01) color = fgcolor;
      } while (--pixelcount);
    } else if (bpp == 16) { // full color
      uint16_t pixelcount = w * h;
      while (pixelcount) {
        GLCD_WAIT();
        GLCD_OUT(H8(bkcolor));
        pixelcount--;
        GLCD_WAIT();
        GLCD_OUT(L8(bkcolor));
        bkcolor = pgm_read_word_inc(bitmap);
      }
    } else {// color, 2 upto 15 BPP
      uint16_t colortablesize = pgm_read_word_inc(bitmap);
      uint8_t* colortable = (uint8_t*)bitmap;
      bitmap += colortablesize;
      uint16_t colormask = pgm_read_word(&colormasks[bpp -2]);
      uint8_t databits = 0, data2 = 0, bitsmul = 1;
      uint16_t data0 = 0;
//      uint32_t data = 0;
      uint16_t pixelcount = w * h;
      do {
        GLCD_WAIT();
        GLCD_OUT(H8(bkcolor));
        pixelcount--;
        GLCD_LOAD_BITS(data0, data2, databits, bitmap, bitsmul);

//        while (databits < 16) {
//          uint16_t t = pgm_read_byte_inc(bitmap) * bitsmul;
//          if (databits >= 8) data |= (uint32_t)t << 8;
//            else data |= t;
//          databits += 8;
//        }

        GLCD_WAIT();
        GLCD_OUT(L8(bkcolor));

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

//        if (LL8(data) & 0x01) {
//          bkcolor = pgm_read_word(colortable + (L16(data) & colormask));
//          data >>= bpp;
//          databits -= bpp;
//          bitsmul = pgm_read_byte(&powerof2[databits & 0x07]);
//        }
//        bitsmul >>= 1;
//        if (!(bitsmul)) bitsmul |= 0x80;
//        data >>= 1;
//        databits--;
      } while (pixelcount);
    }
    GLCD_WAIT();
    GLCD_CS_PULSE();
    GLCD_SETMODE(0x30);
    GLCD_CS_OFF();
}

[Ippolit V. (ellar)]

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?

[Hagen R. (hagen)]

Weil ich kein Telefon an einem Schlagzeug brauche ?

Gruß Hagen

[Holger H. (holger-h-hennef)]

abbo

[MichiB (Gast)]

Hallo zusammen,

versuche seit Tagen ein LS020 zu initialisieren.

Controller: MSP430F169
SPI: 4MHz

Habe viel mit den Timings und co. herumgespielt.

Es hat sich nie auch nur ein Pixel verändert.

Ist das Display defekt?

Ich sollte doch eigentlich nach dem Reset schon bunte Pixel sehen oder?

Besten Dank

[Ippolit V. (ellar)]

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

[Vladimir R. (sonycman)]

Hagen Re wrote:
> Yes i give you ;)

Thanks!
You`re the best :)

Best regards
Vladimir

[james (Gast)]

Hallo

Ich habe ein Problem mit der ausgabe von Bitmaps und TEXT auf dem 
Display. Die Ausgabe von Rechtecken Kreisen und s.w. funktioniert aber 
wenn ich ein bitmap augeben will kommt nur ein schwarzes rechteck 
genauso wenn ich ein TEXT ausgeben will.
Folgenden Code habe ich z.B. benutzt:

    glcdFillRect(110,110,130,130,WHITE);     // ! funzt
    glcdSelectFont(menufont);
    glcdDrawText("TEST", 12, 0);             // ! funzt nicht
    glcdDrawBitmap(20, 20, logo_bmp, 0);     // ! funzt nicht

Mus ich vorher noch irgendetwas beachten?
 #include "menufnt.h" und #include "logo.h" ist vorhanden.

Noch etwas wenn ich ein bitmap mit swarz weiß sende dann klappt es!

Danke für die Hilfe!

[Hagen R. (hagen)]

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

[Hagen R. (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

[james (Gast)]

@ Hagen

Vielen Dank!

Ich arbeite mit dem Atmega32 und da hat das SET_RAMZ(0)geholfen.

Gruß Ewert

[ratatatata (Gast)]

Hallo Leute.

Hab auch gerade das Display aus meinem alten S65 ausgebaut, nach nen 
paar mal probieren und dem richtigen timing hab ich ihn auch prima 
initialisieren können.

jetz hab ich aber ein problem.. er scheint mir keine cmds 
entgegenzunehmen! ich kann ihm schön daten schicken, er inkrementiert 
den pointer und zeigt alles perfekt an aber ich kann den pointer eben 
nicht verändern :/

das ist meine init sequenz:

    WORD init1[] = {0xFDFD, 0xFDFD};
    lcd_sendCmd(init1, arraysize(init1));
    _delay_ms(50);      
    WORD init2[] = {0xEF00, 0xEE04, 0x1B04, 0xFEFE, 0xFEFE, 0xEF90, 0x4A04, 0x7F3F, 0xEE04, 0x4306};
    lcd_sendCmd(init2, arraysize(init2));
    _delay_ms(7);      
    WORD init3[] = {0xEF90, 0x0983, 0x0800, 0x0BAF, 0x0A00, 0x0500, 0x0600, 0x0700, 0xEF00, 0xEE0C, 0xEF90, 0x0080, 0xEFB0, 0x4902, 0xEF00, 0x7F01, 0xE181, 0xE202, 0xE276, 0xE183};
    lcd_sendCmd(init3, arraysize(init3));    
    _delay_ms(50);      
    WORD init4[] = {0x8001};//, 0xEF90, 0x0000};
    lcd_sendCmd(init4, arraysize(init4));

(habe es mit und ohne dem abschließenden 0xEF900000 probiert)

und hier mein versuch den pixel bei 50|50 zu weissen:

    WORD cmd[] = {0xEF80, 0x1800, (0x1200+50), (0x1500+50), (0x1300+50), (0x1600+50)};
    lcd_sendCmd(cmd, arraysize(cmd));
    cbi(PORTLCD, PLCD_RS);
    spi_send((WORD)0xFFFF);

hat jemand vlt ein tip für mich? es ist egal welches cmd ich zum 
verändern des pointers nehme, es funktioniert keins :/

[Jens D. (jens)]

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

[ratatatata (Gast)]

ok habs grad mal für dich getestet, die zeit nach init1 is seehr 
unkritisch, funktioniert alles zw. 1 und 200 ms (mehr habe ich nicht 
versucht ;))
nach der zweiten sequenz solltest du dir aber nicht zuviel zeit lassen, 
von 1-7ms klappts perfekt, darüber hats bei mir nicht mehr funktioniert.
zw. sequenz 3 und 4 ists wieder dasselbe wie nach 1

also nochmal zusammengefasst:
  --------
   init1
      1-200ms (ich nehme 50)
   init2
      1-7ms   (ich nehme 7)
   init3
      1-200ms (ich nehme 50)
   init4
  --------

[Jens D. (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?

[ratatatata (Gast)]

die befehle an sichn solln 16bit sein, wies mit deinem µc aussieht weis 
ich aber nich.
falls du aber 2 byte auf einma rüberkriegen solltest pass auf dass das 
msb(yte) zuerst übertragen wird.

und kannst du mal kuggn ob die graphic-memory-zeiger-veränderten cmds 
bei dir gehn wenn alles klappt?

[Jens D. (jens)]

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

[ratatatata (Gast)]

verdammt.. kannst mir mal dein code geben?

der nimmt meine befehle irgendwie nciht entgegen ://
aber er unterscheidet zwischen daten und befehls-byte des hab ich 
festgestellt.

ich kann den grafik speicher nur inkrementel beschreiben, nix verändern 
und das neeeervt :D

[Jens D. (jens)]

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.

[Avr N. (avrnix)]

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.

[Alex (Gast)]

Hallo, wie befestigt bzw. kontaktiert Ihr eigentlich das Display auf 
einer Platine. Heissklebepistole und freiverdrahtes ist sicherlicher 
moeglich. Gibt es da noch bessere Varianten ?? Das momentan meist 
verfügbare LS020.. hat ja scheinbar keine richtigen Lötpunkte oder ?


Zweite Frage: Hagen verweist auf eine GLCD fuer das LS020..., Christian 
hat mal eine angepasste GLCD lib fuer das LPH gepostet. Welches Display 
ist hinsichtlich der Nutzung der GLCD lib besser geeignet. Lohnt es sich 
nach der doch mittlerweile schlecht zu bekommenen LPH Version zu suchen. 
Soweit ich gelesen habe unterstuetz das LS020 "More advanced RAM 
addressing modes".


Achso zum Hintergrund, bin auf der Suche nach einer mittelgrossen 
Anzeige fuer eine Steuerung, soll nix professionelles werden allerdings 
auch nicht gleich nach einem halben Jahr alles auseinanderfallen. 
Momentan nehme ich noch ein Standart 2x16 per SPI.

Danke und Gruss Alex

[Fasti (Gast)]

Hi!

Also die Lib von Christian ist für das LS020. Von Hagen gibts die fürs 
LPH und fürs L2F50 gibts leider keine Lib. Also LS020 oder LPH kaufen.

ciao

Fasti

[Michele B. (luxx)]

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

[M. S. (dudu)]

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

[Dirk Schlage (Gast)]

Hallo,
ich versuche das LS020xxx an einem AT90USB1287 bzw. einem Mega48 mit der 
kleinen Testsoftware bzw. der Lib von Christian Kranz zum Laufen zu 
bringen.
Leider sind da manche Register im Registerfile an Adressen höher 31, was 
sich in der Fehlermeldung
Error: number must be less than 32 winavr
beim Übersetzen von LCD.asm zeigt.

Ich habe daraufhin

SPI_SEND:   
    sbi SPCR,SPE        ;enable SPI
    out SPDR,r24        ;load byte in SPI data register
SPI_SEND_0: 
    sbis    SPSR,SPIF

zu

SPI_SEND:   
    push    r30      ;!!! 
    in     r30, SPCR
    sbr     r30, SPE
    out     SPCR, r30
  
    out SPDR,r24        ;load byte in SPI data register
SPI_SEND_0: 
    in     r30, SPSR
    sbrs     r30,SPIF
..
    pop r30        ;!!!
    ret

geändert.
Leider tut sich auf dem Display momentan noch nichts.

Da es hier ja noch jede Menge andere Unwägbarkeiten gibt.
Spannung, Taktrate, Displayverkabelung...
hier meine Fragen:

Hat jemand schon den Code an einen derartigen Prozessor angepasst?
Gibt es sonst irgendwelche Erfahrungen über Fallstricke?
Gibt es Testcodes für AVR in C, die ohne Assembler, evtl auch ohne 
Hardware-SPI das Display erfolgreich ansteuern?

Gruß
Dirk Schlage

[Jens D. (jens)]

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

[MichiB (Gast)]

Hallo,

es geht um das LPH.

Ich benötige die Konfiguration der Pixel Position.

Ich lade das Bitmap von einer SD Karten, die sich am
selben SPI-Bus befindet.

Danach muss ich die aktuelle Pixel Position setzen.

Kennt jemand die Befehle?

[Wigbert P. (wigbert)]

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

[Jens (Gast)]

Hallo,

wieso Probleme?

#define RGB_16(col) ((col& 0xf80000)>>8) | ((col& 0x00FC00)>>5) | ((col& 
0x0000F8)>>3)


und dann fillscreen(RGB_16(0xff0000)) fuer Rot

Tabellen kannst du nun die 24Bit aus HTML etc nehmen..

[Wigbert P. (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

[Jens (Gast)]

Ja,

Ich wandel das in dem Makro nur um (etwas einfacher zu lesen)
es reicht, wenn du die letzten 2 bzw. 3 stellen wegschneidest und dann 
schiebst.

[James (Gast)]

Hallo!

Wie schaff ich es mit einem ATmega32 auch zwei Displays unabhängig 
voneinander anzusteuern. Oder ist es grundsätzlich nicht möglich?
Theoretisch brauche ich nur zwei unabhängige CS (Chip Select) welches 
zurzeit an der SPI Schnittstelle am Pin SS hängt. Oder mach ich da ein 
Denkfehler?

Danke für eure Hilfe

[SuperUser (Gast)]

Kein Denkfehler. Zwei unabhängige Chipselect und den SPI Bus parallel 
anschliessen sollte funktionieren. Ich habe z.B. am SPI Bus auch noch 
die SD-Karte parallel zum Display hängen (mit eigenem Chip Select)

[James (Gast)]

Danke für die schnelle Antwort. Werde es am WE ausprobieren.

[Mircro=>DIsP_chix (Gast)]

Hi,

Weis jemand zufällig ob es irgendwie geht ein AV Eingang an das Display 
zu bringen. Also ein Videosignal das über 2 Drähte kommt Irgendwie auf 
dem Display anzeigen zu lassen.

Wenn es jemand weiß, soll er es mir bitte sagen(is sehr extrem wichtig 
für mein nächstes projekt.)Kann auch ein Schaltplan für ne 
Vorschaltplatine oder sowas in der Art sein.

Ich bedanke mich schonmal sehr im vorraus bei dem, der mir sagt ob bzw. 
wie mann es macht.

Grüße von Micro=>DIsP_chix

[Gast (Gast)]

Wird wohl nicht so einfach gehen. Das Videosignal ist Analog
und das Display möchte Digitale Daten.
Du müsstest das Videosignal Digitalisieren , Zwischenspeichern,
Skalieren und danach an das Display per SPI schicken.
Z.b. mit einem SAA7111 als AD Wandler ,
großes CPLD mit viel SRAM dran , AVR o.ä. um den SAA7111
per I2C zu konfigurieren, etc etc ....
Da ist es einfacher und billiger ein TFT mit AV Eingang in
ähnlicher Größe zu kaufen (Liliput).

[Klaus R. (ruebi)]

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.

[Mircro=>DIsP_chix (Gast)]

Danke für deine Antwort

ABER:
Ich wollte einen AV-Eingang an das Display bringen, weil ich auf dem 
Display Design-Effekte anzeigen wollte.
Also PowerPoint Präsentation über einen Computer=>AV Adapter anschließen

Fals doch noch jemand weiß wie man es macht, BITTE SAGT ES MIR!!!

Yours Micro=>DIsP_chix

[Ben (lightning)]

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.

[Mircro=>DIsP_chix (Gast)]

Ja Recht hast du ja aber ich brauche AV auf dem S65 Display weil ich auf 
der Oberfläche, auf der das Dislay hinsoll, nicht genug platz für einen 
7" Monitor
habe.Und ausserdem brauche wie gesagt für einen Designeffekt.Groß 
angemerkt für einen KLEINEN Designeffekt. Darum brauche ich irgendwas 
womit ich ein AV-Signal auf das Handy-Display Kriege.

Wie gesagt wenn jemand weiß wie man es machen kann, bitte sagt ees 
mir!!!!!

[Mircro=>DIsP_chix (Gast)]

OK
bevor ich die AV Sache mache,probier ich lieber mal diese andre sache 
aus.
Hab aber keinen wirklichen plan wie ichs machen soll,
Ok,also

Ich baue diese Controllerr-Platine vom Schlatplan auf Superkranz.de und 
verbinde sie mit mit dem Display soweit sogut, aber wass dann, wie macht 
man dann weiter?

Grüße,Micro=>DIsP_chix

[Gast (Gast)]

Dann Programmierst du den Controller auf der Controller Platine , 
versuchst den Sourcecode zu verstehen, versuchst das Display zu 
verstehen und wenn Du das alles durch hast wirst Du erkennen das es 
nicht geht ein AV Signal ohne großen Hard und Software Aufwand an das 
Display zu bringen.
Schau doch mal nach den sog. Lilliput TFTs , sind 1,8 Zoll und haben 
schon eine AV Eingang. Such einfach mal in der Halsabschneider und 
Sofort Abzock Bucht nach "1,8" Lilliput"

[Mircro=>DIsP_chix (Gast)]

Wie Programmier ich den denn und kann vieleicht jemand den passenden 
code als txt datei im Anhang mitsenden.

[Mircro=>DIsP_chix (Gast)]

Ok, aslo keinen AV.
Dann mach ich eben die sache, die hier die ganze Zeit beschrieben wird. 
Zumbeispiel dieses Hello World Testprogramm, oder noch besser, ich hab 
gehört das man auch n' Kleines Multimeter auf dem Display anzeigen 
lassen kann, denn der ATmega128 hat ja auch einen Messeingang. Also 
nochmal vonvorne.
Ich baue diese Steuerplatine samt display zusammen...
dann muss ich diese Platine warscheinlich mit dem Coputer programmieren 
schätz ich mal...
warscheinlich muss man einen code auf die Platine überspielen, den der 
ATmega beim Einschalten erkennt und der dann ein Bild auf dem Display 
anzeigen lässt.

Welches Programm muss ich nehmen???
Wie verbinde ich die Platine überhaupt mit meinenm Rechner???
Und wie lautet der Code???

Alles sachen die ich dafür warscheinlich wissen muss aber nicht weiß!
Deshalb bitte ich darum mir die sachen zu erklären und am besten wäre 
noch der Code als txt Datei beigefügt.

Ich bedanke mich schonmal im vorraus für die Person die es mir sagt!

Grüße, Micro=>DIsP_chix

[Mike (Gast)]

Ich würde dir erstmal raten dich in die Programmierung von µC´s 
einzuarbeiten bevor du dich gleich an sowas traust !

Bring erstmal ein paar LED´s zum leuchten, frag Tasten ab und so 
weiter...

[Ben (lightning)]

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.

[Mircro=>DIsP_chix (Gast)]

sehr sehr nett :-(

Ach ne, weiß ich auch.
Led's hab ich schon zum leuchten gebracht, und wieviele das wahren.
Ich wollte einfach mal einen neuen anfang in andre schaltungen wagen, 
aber es ist ja sehr shcwirig wie es scheint, wenn einem ja sowieso 
keiner helfen möchte :-(

Wers mir trotzdem noch erklären will nur zu.

[Mike (Gast)]

Also wenn man dein Posting oben ließt kann ich mir nicht vorstellen das 
du
LED´s mit nem µC zum leuchten gebracht hast!
Oder wie soll man diese Aussage

Zitat "Welches Programm muss ich nehmen???
Wie verbinde ich die Platine überhaupt mit meinenm Rechner???
Und wie lautet der Code???"

deuten?

Kann man eigentlich nur so deuten das du noch nicht in diesem Bereich 
gemacht hast.
Acker erst mal das Tutorial durch, denn dort werden dir auch diese 3 
Fragen beantwortet.

Geholfen wird dir in dem Forum hier auf alle Fälle aber sollte auch 
schon etwas Wissen vorhanden sein.

[Mircro=>DIsP_chix (Gast)]

Ich habe doch schon wissen in Elektronik.

Einige meiner Abgeschossenen Projekte:

30 Sekunden Sprachrekorder basirend auf IC 1416
9 Kanal LED Lauflicht basirend auf Dezimalzähler-IC 4017
Nano Leucht Ei mit Zeitsteuerung
u.v.m.

Ich möchte einfach in eine Andre Richtung Elektronik setzten und 
ungefähr vorstellen wie dass geht kann ichs mir ja auch.

O.k. dann les ich mir das Tutorial mal durch, zum Zweiten mal.

Danach kann ich doch wieder Fragen?

[Wigbert P. (wigbert)]

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

[Stefan_Z (Gast)]

Ich hab jetzt auch so ein Display (LS020) und auch die ganze Listings 
für Bascom.
Allerdings würde ich gerne noch mehr über das Display wissen. Die 
Init-Sequenzen erschließen sich mir z.B. nicht wirklich...
Gibt es vielleicht ein Datenblatt zu dem Teil?

[MisterNix (Gast)]

Stefan_Z

Lies mal den Thread hier, da wirst du es finden //oder auch nicht ;)

Da das LCD von den Japsen kommt wirst du kaum ein Datenblatt bekommen.
Es sei du nimmst mal eben 10k ab.

[Martin Heintze (Gast)]

hallo erstmal...ich bin zufällig auf diesen thrat gestoßen, da ich die 
möglichkeit hatte besagtes handy auszuschlachten..... nun bin ich also 
im besitz des lsh20xxx displays, eines atmnega16(16mhz) und den avr 
stk500 dev board. die frage ist, ob es eine möglichkeit gibt, 
umrauszubekommen ob das display kaputt ist, da es bis jetzt außer das 
leuchten der hintergrundbeleuchung noch nichts von sich gegeben hat. die 
stromversorgeung wird über ein netzteil mit einstellbaren 2.9V 
realisiert und der ausgagspegel das stk500 habe ich auf auf 3.8V 
eingestellt(ausgäge laufen exakt auf 2,9V). ich habe alles durchgemessen 
und keine fehler festgestellt
wenn ich das richtig verstanden hab müsste das dsp wenigstens rot 
werden, wenn ich den simple_display3 code auf dem mega16 ausführ...hab 
aber auch schon diverse andere versionen dies hier gibt ausprobiert.

hat jemand ne idee?, wär nett wenn sich jeamdn bei mir im forum hier, 
per icq(340245493) oder per mail meldet([e-mail]).
bin grad echt etwas frustriert.... viele dank schon mal...und geniale 
arbeit soweit !!

[Der Hubert (Gast)]

Welches der 3 verfügbaren Displays ist denn nun am geeignetsten ??

[Moien (Gast)]

Kommt ganz drauf an. Eigentlich gibt es nicht das beste Display für ALLE 
Personen. Es gibt manche die findes das besser, und dann welche die 
finden dieses besser und andre die findes jenes am besten. Ich Jedoch 
würde dir dass mit der Braunen Platine emfehlen. Aber is deine 
entscheidung.
-----------------------------------------
Ein Mini hasser sagte mal:
"Gott schütze uns vor Sturm und Wind, und vor den Autos die aus England 
sind."
Soweit ich weiß is der Mini aber von BMW und somit aus Bayern. Fazit=
SEHR SEHR SEHR DUMMER AUTOSCHRAUBER DER DAZU NOCH AUS MÜNCHEN IST

[Moien (Gast)]

Meldet sich mal jemand, mein Beitrag is immer hin schon 68 Minuten alt. 
Kleiner Scherz :-)

[Moien (Gast)]

Als ich abgeschikt hab, stand auf meinem Funkwecker 00:12

[Kevin D. (Firma: none) (thunderbirdje)]

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

[M. B. (mbode001)]

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

[Alex (Gast)]

Hi,

wo ist eigentlich auf ebay das P30... einzuordnen. Hier wird bisher 
immer nur vom

L2F50..
LPH...
LS020...

geschrieben ? Gibt leider nicht mal allzu viel neu zu kaufen.

Alex

[pay.c (Gast)]

Also den LS020 findet man immer wieder mal. Kostenpunkt derzeit sogar 
unter 10 Euronen (Versand blöderweise fast 5 Euro). Der LS020 wird 
übrigens bei ein paar Händlern fälschlicherweise als LS02B... 
bezeichnet. Stimmt nicht, schaut man sich das Bild an, ist es immer ein 
LS020B... also beruhigt kaufen. Hier mal ein Verkäufer, der die öfters 
hat (notfalls anschreiben): numan02003 (für 7,90 + 4,90 Versand)

Grüße!

[Jens D. (jens)]

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?

[Alex (Gast)]

numan02003 bietet zwar laut Ueberschrift
"Original Siemens LCD DISPLAY S65 M65 CX65 S M CX 65 NEU" das neu an 
aber im Text steht dann:
" - Das Display ist leicht gebraucht. (teils mit Display Schurtfolio)"

Keine Ahnung was man davon halten soll, zumal er auch welche neu mit 
Torx für 20 Euro hat, wo eben der bewusste Satz fehlt. Schutzfolie ist 
mir egal aber Kratzer etc wäre mir nicht egal.

@ pay.c   Wie sah den dein Display aus ??


Danke Alex

[pay.c (Gast)]

Sorry erstmal für die späte AW. Habe erst vor ein paar Tagen zum ersten 
Mal bei dem Typen bestellt, Display ist aber schon unterwegs (im 
Versand). Sobald er hier ist, lasse ich Dich wissen, wie das Display 
ausschaut und ob alles iO ist. Von den Bewertungen her schaut er ja an 
und für sich ganz gut aus. Wenn er zerkratzte Displays verchecken würde, 
hätte er, denke ich, deutlich schlechtere Meinungen im Profil. Aber mal 
guggen, ich geb Bescheid! :)

[tecdroid (Gast)]

Hi!

Ich schau mir das ganze gerade an und frage mich, für was das CS-Signal 
gut ist.
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..

[Alex (Gast)]

CS = Chip Select :)

Alex

[µluxx .. (uluxx)]

> 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

[pay.c (Gast)]

@Alex: Also leider IST das Display gebraucht und hat einen kleinen 
Kratzer. Mich störts jetzt nicht weiter, da das Display sowieso mein 
"Auprobierdisplay" wird und keine dermaßene Funktion übernehmen wird. 
Aber man sieh halt, daß der Display gebraucht ist.

[tecdroid (Gast)]

ich hatt's mir zwar gedacht, aber ich geh lieber auf nummer sicher.. hab 
schon zu viele mehrdeutige Abkürzungen gesehen. sry, wenn ich euch damit 
nerve.
Bin auch eigentlich Programmierer, kein Elektroniker.

[µluxx .. (uluxx)]

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

[Manfred (Gast)]

Hi, ich habe schon viele der gebrauchten LS020 Displays gekauft 
(mittlerweile nicht mehr - warum: s.u.). Durchgängig, d.h. bei mind. 65% 
ist zu bemerken: Kleine Kratzer und Macken auf der Displayfläche, die 
leider bei eingeschalteter Beleuchtung meist deutlich zu sehen sind 
(sehen dann teilweise wie defekte Pixel aus, also Sch....).
Ausserdem ist die Helligkeit dermaßen unterschiedlich bei den Displays 
(fällt natürlich erst dann auf, wenn man mehrere davon hat), was darauf 
hin deutet, dass beim Großteil der Gebrauchtdisplays die LEDs der 
Hintergrundbeleuchtung bereits am Ende ihrer Lebensdauer angelangt sind. 
Daher wurden sie vermutlich auch ausgemustert - was sollte es sonst für 
einen Grund dafür geben? So jedes 10. bis 20. Display ist auch defekt 
(intern gebrochen). Die werden immer schön als "geprüft" verkauft 
-stimmt im Leben nicht. Dann wären nicht gesplitterte und total 
versiffte dabei gewesen.
Fazit: Finger weg davon! Ich gebe mittlerweile lieber das doppelte aus 
und bekomme ein sauberes, neues ungebrauchtes Display mit Schutzfolie. 
Das hält dann auch entsprechend lange.

Manfred

[pay.c (Gast)]

Blöde Frage, Manfred: Wo bekommst Du die her? :)

[Alex F. (alexf)]

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

[Läubi .. (laeubi)]

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

[Avr N. (avrnix)]

LS020

[Jens D. (jens)]

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?

[Alex F. (alexf)]

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

Alex

[pay.c (Gast)]

@Jens: Naja, es gäbe die Möglichkeit, den Screen Section passend zu 
setzen. Kommt darauf an, was Du machen willst, für einen einzelnen Pixel 
ist das zwar übelst Aufwand (2 Befehle für Position und dann den Pixel 
schreiben), aber funzen könnte es. Ich bin mir nur nicht sicher, ob man 
die Befehle 0x06YS und 0x07XS verwenden kann, ohne das 0xEF90 und 0x05OR 
davor stehen, einfach mal ausprobieren. Code siehe hier: 
http://www.superkranz.de/christian/S65_Display/DisplayProgramming.html 
(unter Screen Sections)

[Hans-Christian (Gast)]

Ich habe gestern mein L2F50xx von Ebay bekommen, angeschlossen und es 
funktionierte sofort mit der "Simple Test Software" von Christian Ks 
Homepage. Ich verwende einen ATmega32 bei 16MHz und konnte ihn an meinem 
Labornetzteil bei 2.9V betreiben, womit ich mir dieses Levelgeshifte 
erspare. Vielen 1ooo Dank für diese tolle Arbeit von Christian.

[Marc (Gast)]

Interessiert mich auch..

[Avr N. (balze)]

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.

[Martin (Gast)]

http://web.archive.org/web/*/http://www.superkranz.de/christian/S65_Display/DisplayIndex.html

[Ben (lightning)]

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

[Avr N. (balze)]

Danke fuer Eure schnelle Hilfe !!!


MfG,

balze

[Christian K. (Gast)]

Nach Provider-Umzug (von 1&1 nach strato) ist die Seite jetzt wieder 
online.

[eugen (Gast)]

Hello!
Have anybody library for LS020 written for CodeVision?

[Dmitry (Gast)]

Hi !

Does anybody have datasheet for LS020 display (LR38826 controller)?

[Peter B. (payce)]

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.

[Flo S. (tuxianer)]

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

[Avr N. (avrnix)]

LS020...

http://www.comwebnet.de

[gast (Gast)]

ich hab vor einen mega644 an das LCD zu hängen

habe 2 möglichkeiten :

A: den controller + LCD bei 2,9V betrieben und hoffen das der 644 bei 
2,9V noch die 8MHz packt

b: den controller bei 3,3V laufen lassen
    und spannungsteiler ( geht das net auch mit schnellen dioden ) 
einsetzen ...

irgendwo muss ich ja anpassen

weil der controller ja wieder andere sachen ansteuern soll

[Avr N. (avrnix)]

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

[Hauke R. (lafkaschar)]

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

[Marc S. (eurofighter)]

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

[SuperUser (Gast)]

Hi,

ich schreibe das hier aus der Ferne, habe gerade keine Installation bei 
der ich nachschauen kann....

Im Grunde geht das mit der Library so:
- Nachdem du das zip-file ausgepackt hast, gibt es ein Verzeichnis mit 
den entsprechenden sourcen der library.
- Dort gibt es auch ein makefile. Das must du mit make in diesem 
Verzeichnis ausführen. Theoretisch sollte es auch mit deiner neueren AVR 
software version funktionieren. Entwickelt wurde das natürlich mit einer 
älteren Version.
- als Ergebnis gibt es ein lib file. Das lib file musst du später zu 
deinem binary dazulinken. Einfach als Objekt beim linken mit angeben.
- Bei deinem Quelltext musst du die benötigten header files der library 
(im include Verzeichnis) "includieren".
- Mit der library wird aber auch ein testprogram mitgeliefert. Dort 
findest du ein makefile das du als Beispiel für den build process nutzen 
kannst. Das Testprogram muss extra compiliert werden (wieder mit make im 
Directory des Testprogramms. (u.U. musst du deine Hardware anpassen!)
- Das Testprogram kannst du auch als Anleitung benutzen, wie die 
verschiedenen Library Funktionen benutzt werden können.

Es kann sein, dass die Installations-Anweisung auf die du dich beziehst 
noch von der Original-Library stammt und dann nicht exakt passt.

[Dmitry (Gast)]

I use LS020 display with ALTERA FPGA to display video received from
cell-phone camera.

original
http://www.o-d-v.nm.ru
google translation ;-)
http://translate.google.com/translate?u=http%3A%2F%2Fo-d-v.nm.ru&langpair=ru%7Cen&hl=en&ie=UTF8
one more "COTTON VELVET" means FPGA ;-)
http://www.translate.ru/url/tran_url.asp?lang=ru&direction=re&template=General&transliterate=&autotranslate=on&url=http://o-d-v.nm.ru/tel_cam/capture/FPGA.htm

[Manuel G. (manuelg)]

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 ?

[Avr N. (avrnix)]

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

[Jürgen E. (sid)]

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:

./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:

#include "s65.h"

[...]

    S65_Init();

    S65_Fillscreen(S65_RGB(0,255,0));
    S65_Dawpic(10, 40, (void *) pic, 0);

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

[Michi Müller (Gast)]

>Vielleicht kann es ja wer gebrauchen...

Ja, danke. Ich kann es gebrauchen.

[Marc S. (eurofighter)]

Manuel Geishauser wrote:
> 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 ?^

das display direkt an 3,3V hängen ist sone sache. Es läuft halt 
ausserhalb der Spezifikationen. Ich arbeite im moment an einem Projekt, 
welches ebenfalls überall mit 3,3V läuft. hab ein LS020 direkt an 3,3V 
schon seit Wochen am laufen. Nur garantieren kann ich dir da nix ^^

ja, kannst du, schau einfach mal in die Anleitung von christian k, dort 
ist alles beschrieben ! Dafür wid einfach ein timer des megas zur 
PWM-erzeugung genutzt. Eigentlich ist es für 5V, aber es geht auch mit 
3,3V, ich benutze dafür einen IRF7103 als mosfet und eine 1mH/0,16A 
Spule von reichelt (in SMD). Musst dann nur die Pulsweite etwas erhöhen 
um auf die benötigte spannung zu kommen. Und mal davon ab brauch die 
HG-Bel keine 15 V, sondern ca 10,4V um 20mA zu produzieren. Du kannst 
den Step-Up direkt dran hängen, brauchst keine angst um die leds zu 
haben, durch die Belastung regelst du eher den Strom als die Spannung! 
(wg. nicht linearer UI-Kennlinie der Leds)



@ SuperUser

Danke für die Anleitung ! habs gerade eben damit zum laufen gebracht :) 
Die Anleitung die bei der Lib dabei war war völlig falsch. Das Dumme an 
der ganzen sache ist, das ich es genau wie du beschrieben hast schonmal 
gemacht habe. Allerdings hatte ich einen Port falsch definiert, und 
deswegen lief es nciht, ich nam an, ich hätte was bei der verwendung der 
lib selber falsch gemacht ^^

[Marc S. (eurofighter)]

mir fällt grad auf, das ich in der glcd-lib die Schrift nicht drehen 
kann, sondern immer nur in einer Richtung ausgebe, obwohl die Option 
angegeben ist. Ich nutze ein LS020 Display, das sollte das doch 
eigentlich unterstützen ?

Wenns nicht möglich ist, wie kann ich dann die Fonts um 90° gedreht, 
also so wie im LS020-Beispielprogramm von C.K., ausgeben? Nutzen würde 
ich gerne die 8x8, 8x11, 15x22 Fonts.

Netten Gruß, Marc


P.S.: Ich hab mir mal die c-implementation von Jürgen Eckert angesehen. 
Und ich frage mich ernsthaft, warum man zum Zeichnen einer einfachen 
Linie Float-Variablen benötigt ? Und vor allem ob das in der asm-lib 
auch so ist, da wäre dann noch viel optimierungsspielraum. ich selber 
habe einmal vor ca 2 jahren eine bibliothek für ein GLCD geschrieben und 
im Rahmen dessen eine Routine zum Zeichnen von Linien entwickelt, welche 
nur mit einfachen integer-Zahlen auskommt, und die Genauigkeit einfach 
durch erweitern des Wertebereiches erhällt. Soweit ich weis gibts aber 
Routinen die komplett ohne mul/div auskommen..hab ich mich aber noch 
nicht näher mit beschäftigt...versuche grad Fonts in die richtige 
Richtung zu bringen :D

[SuperUser (Gast)]

Hallo Marc.

Das drehen der Fonts wird von der GLCD derzeit nicht unterstützt, weil 
zu der Zeit als der Port gemacht wurde die Addressierungs-Modi des 
Display-RAM's nicht bekannt waren.

Das hat sich mittlerweile geändert:
http://www.superkranz.de/christian/S65_Display/DisplayRamAccess.html

Wenn du Lust hast, kannst du ja die Drehung der Font's nachrüsten und 
hoffentlich hier veröffentlichen :-)

[Marc S. (eurofighter)]

SuperUser wrote:
> Hallo Marc.
>
> Das drehen der Fonts wird von der GLCD derzeit nicht unterstützt, weil
> zu der Zeit als der Port gemacht wurde die Addressierungs-Modi des
> Display-RAM's nicht bekannt waren.
>
> Das hat sich mittlerweile geändert:
> http://www.superkranz.de/christian/S65_Display/DisplayRamAccess.html
>
> Wenn du Lust hast, kannst du ja die Drehung der Font's nachrüsten und
> hoffentlich hier veröffentlichen :-)

da ich nicht so wirklich viel plan von assembler habe und leider auch 
keine zeit um mich in dne code einzuarbeiten werde ich das ganze in die 
o.g. C-version implementieren. Im endeffekt entsteht dann eine "lib" (es 
ist dann keine echte lib mehr), welche folgendes können wird:

- Punkte (fertig)
- Rechtecke gefüllt (probleme)
- Rechtecke ungefüllt (fertig)
- Linien (nach einem algo von mir, ohne float) (fertig)
- Belibigen Buchstaben aus einer Font ausgeben. Unterstützung erstmal 
nur für einfarbige fonts (bei denen man die Farbe zur laufzeit angeben 
kann) die fonts werden dabei punktgenau gesetzt, es wird also ohne 
hintergrund gearbeitet (ist etwas laufzeitintensiver, dafür kann ich die 
Schrift aber auch z.B. auf ein bild setzen), keine komprimierten Fonts 
(unfertig)
- Beliebigen Text aus Buchstaben ausgeben (unfertig)
- 16-Bit-Bitmaps ausgeben (unfertig)

Das Ganze dann halt für den "quer"-modus des Displays...Kreise und so 
kommen vielleicht noch später, aber erst muss das grundgerüst stehen, 
dann kann ich schonmal an einem Projekt weiterarbeiten.

Hab im moment aber ncoh probleme mit der erweiterten ansteuerung des 
Displays, der definiert mir meine rechtecke nicht so wie ich es gerne 
hätte ^^

[Harry S. (littlegonzo)]

Hallo Leute,
erstmal ein frohes Neues Jahr Euch allen.

Ich habe inzwischen auch ein S65 Display mit der Library in Verbindung 
mit einem M32 zum laufen bekommen. Nun würde ich gern die Lib mit dem 
M644 umschreiben doch meine Assembler Kenntnisse reiche dafür leider 
nicht.

Wie muß/müßte ich das umschreiben damit es universeler auf beiden Proz. 
Typen läuft?

SPI_SEND:
  sbi  SPCR,SPE    ;enable SPI
  out  SPDR,r24    ;load byte in SPI data register
SPI_SEND_0:
  sbis  SPSR,SPIF
  rjmp  SPI_SEND_0    ;transmitt byte to LCD
  in  r0,SPDR
  sbi  PORTB,LCD_CS    ;deselect Display
  ret

Das Problem mit dem M644 die SPCR, SPDR Register liegen über Adresse 
31...

Könnte mir da jemand bitte helfen?

Liebe Grüße
Harry

ps: Ich weiß das es mehrere Stellen in der Library betrifft...
und es geht um die ASM-Lib von Christian K.

Als Gegenleistung habe ich eine Circle Routine für die C-Lib;-)

void S65_Circle(uint8_t x0, uint8_t y0, uint8_t radius, unsigned int 
color)
 {
   int f = 1 - radius;
   int ddF_x = 0;
   int ddF_y = -2 * radius;
   int x = 0;
   int y = radius;

   S65_Pixel(x0, y0 + radius,color);
   S65_Pixel(x0, y0 - radius,color);
   S65_Pixel(x0 + radius, y0,color);
   S65_Pixel(x0 - radius, y0,color);

   while(x < y)
   {
     if(f >= 0)
     {
       y--;
       ddF_y += 2;
       f += ddF_y;
     }
     x++;
     ddF_x += 2;
     f += ddF_x + 1;

     S65_Pixel(x0 + x, y0 + y,color);
     S65_Pixel(x0 - x, y0 + y,color);
     S65_Pixel(x0 + x, y0 - y,color);
     S65_Pixel(x0 - x, y0 - y,color);
     S65_Pixel(x0 + y, y0 + x,color);
     S65_Pixel(x0 - y, y0 + x,color);
     S65_Pixel(x0 + y, y0 - x,color);
     S65_Pixel(x0 - y, y0 - x,color);
   }
}

Funktioniert Prima, wenn auch sicher nicht optimal...

[Hauke R. (lafkaschar)]

die oberen register können per sts und lds (als ersatz für out und in) 
angesprochen werden

[Harry S. (littlegonzo)]

Hallo,
habe es eben mal probiert aber es funktioniert leider nicht.
Wollte erstmal nur die simple-display.asm Routine ändern, aber war nix 
:-(

SPI_SEND:
  lds R0, (1<<SPE)
  sts  SPCR,R0
;   sbi  SPCR,SPE    ;enable SPI
  sts SPDR,R24
;  out  SPDR,R24    ;load byte in SPI data register
SPI_SEND_0:
  lds R24,SPSR
  sbrs  R24,SPIF
  rjmp  SPI_SEND_0    ;transmitt byte to LCD
;  in  r0,SPDR
  lds R0,SPDR
  sbi  PORTB,LCD_CS    ;deselect Display
  ret

Also der AVR Assembler ist irgendwie sehr eigenartig mit ihren oberen 31 
Bytes etc. Was war das noch mit 6510 und Z80 einfach ;-)


Grüße
Harry

ps: Frage/Bitte... könnte nicht mal schnell ein ASM-Profi das Ding 
"umbauen" für mich. Wäre echt super

[Harry S. (littlegonzo)]

Hallo ich schon wieder:

Jetzt habe ich es doch hinbekommen....
Hier für alle die evtl. auch die Probleme haben. Bisher läuft zumindest 
die Simple-ASM Library schon mal mit dem M644 zusammen :-) (ein klein 
wenig stolz bin)

SPI_SEND:
  in R25,SPCR
  ori R25, (1<<SPE)
  out  SPCR,R25        ;enable SPI
  out  SPDR,R24    ;load byte in SPI data register
SPI_SEND_0:
  in R0,SPSR
  sbrs  R0,SPIF
  rjmp  SPI_SEND_0    ;transmitt byte to LCD
  in R0,SPDR
  sbi  PORTB,LCD_CS    ;deselect Display
  ret

Grüße
Harry

[Jürgen E. (sid)]

Hallo,
ich hatte das selbe Problem wie du mit dem Mega644, deshalb habe ich sie 
nach C portiert. (siehe oben).

Universeller geht es nicht G
Jürgen

[Harry S. (littlegonzo)]

Guten Morgen Jürgen und auch die anderen natürlich,
ja sicher auch eine Möglichkeit, aber die Lib gefällt mir ja.
Inzwischen laufen alle Libs mit dem Display und dem M644 ;-)

So kann ich einfach auswählen was ich nehmen möchte^^

Grüße und noch einen schönen Tag,
Harry

[Marc S. (eurofighter)]

Hallo, Harry!

Die Kreisroutine schaut doch optimal aus, was hast du ^^ Schaut auf den 
ersten blick auch überhaupt nciht rechenintensiv aus o.ä. :)

danke dafür <*direktaufgenommenhat*>

möchtest nicht noch ne Routine für Ellipsen schreiben ? :) ^^
oder teilweise Kreise  halbkreise  viertelkreise .... ^^

ich beschäftige mich grad mit den Fonts, sollte recht bald fertig 
werden, dann stell ich meinen quellcode rein und ihr dürft ihn in der 
Luft zerreissen ;) (aber bitte Stückchen übriglassen die ich in besserer 
Form wieder zusammenfügen kann :D)

[Marc S. (eurofighter)]

So, hier wie versprochen meine erweiterte und überarbeitete C-Lib.

Die Lib benötigt im moment 3488 byte auf einem M128, ohne Fonts 
natürlich.

Es können beliebige Fonts benutzt werden, allerdings müssen sie 
unkomprimiret und einfarbig sein (Die Textfarbe kann nat. Variiert 
werden)

Ebenfalls habe ich einen 0°/90°-Modus hinzugefügt, welcher auf jedem 
Displaytyp funktionieren sollte (da die Fonts aus Einzelpixeln gesetzt 
werden --> Transparanz). Die Transparenz der Fonts ist noch nicht 
ausschaltbar, wred ich aber in den nächsten Tagen noch hinzufügen.

Was im Moment noch fehlt ist die ausgabe von Bitmaps.

Da ich die Lib nicht nur für mich schreiben möchte, könnt ihr mir gerne 
sagen, welche Module ich noch hinzufügen soll. Wenn sie nicht zu 
aufwendig und abwegig sind nehm ich Sie gern auf :)

Wäre über ein wenig Feedback & Kritik sehr erfreut,

Gruß, Marc

[Harry S. (littlegonzo)]

Hallo Marc,
sehr schöne Lib, vor allem in C.

Wenn Du dieses Define in die S65.h noch reinsetzt kann man die Farben 
etwas einfacher einstellen...sie ist aus der ASM Lib entnommen.
Übrigens die Circle Routine war leider nicht von mir sondern irgendwann 
mal im Netz gefunden. Leider weiß ich den Herrausgeber nicht mehr, aber 
ich möchte keine Lorbeeren für Dinge die ich nicht gemacht habe....

Liebe Grüße
Harry

Das Define:
#define RGB(r,g,b) (((r & 0xF8) << 8) | ((g & 0xFC) << 3) | ((b & 0xF8) 
>> 3))

[Tobias W. (despeyer)]

hi!
hätte einer von euch die güte, mal nen funktionierenden Quellcode (und 
optimalerweise noch das hex-file) für das S65-Display und nen 
Atmega8/16/32 zu posten?
Ich hab mehrmals simple_display3 kompiliert und auf meine pin-belegungen 
angepasst, ohne Ergebnis, gleiches Verfahren mit dem Bilderrahmen-Prog 
aus dem anderen Thread, der ja einen Atmega8 als Basis 
benutzt..Verdrahtung mehrmals überprüft, hintergrundbeleuchtung 
funktioniert..

[Marc S. (eurofighter)]

vielleicht wäre es gut, wenn du mal einen exacten schaltplan posten 
würdest, klingt eher nach nem fehler der beschaltung als nach nem fehler 
der software !

[Marc S. (eurofighter)]

hier mal die neueste Version 0.2 der Lib in C.

Neu hinzugekommen ist ein Modul für die HG-Bel nach dem step-up-Schema 
sowie eine Routine für 16-Bit-RAW-Bitmaps, als auch für 16Bit-Bitmaps 
die der Converter von Hagen erzeugt (Hier gefällt mir der Converter 
besser ;) vor allem dank GUI :) ). Die Bitmaps können auch transparent 
gezeichnet werden, indem man eine globale Farbe definiert, welche 
transparent sein soll, und den Transparenzmodus aktiviert. Allerdings 
wird bei Transparenten Bitmaps nur ein Bild pro Sekunde dargestellt, bei 
nonTransparenten sind 7 Bilder Pro sekunde möglich (nat. immer auf 
Vollbilder bezogen !)

Das HG-Bel-modul kann nach Bedarf nat. auch einfach rausgenommen werden, 
spart allerdings nur 18 Byte...die aktuelle größe der Lib im 
Kompilierten zustand beträgt bei mir 4222 Byte.

Bilder mit 2^1-2^15 Farben sind ebenfalls implementiert, allerdings ist 
in der Funktion noch irgendwo ein Bug, den es noch zu finden gilt. 
Vielleicht fällts ja jemandem auf, ich brauche die Funktion im moment 
nicht (Die Bilder werden eh von SD-Karte Gelesen, und auf der ist Platz 
ohne ende) und arbeite deshalb lieber an einem anderen Teil meines 
Projektes weiter (Eben der SD-Einheit)...wenn nat. jemand die 
Grafikfunktionen komplettieren will, immer her mit dem Code, ich baue 
ihn sofort ein.

Gruß, Marc

[Manuel G. (manuelg)]

Hallo

Ich hab gerade die neue Lib von Eurofighter probiert.Ich will nun einen 
Text ausgeben und hab nocht nicht ganz verstanden wie ich das ganze 
initialisieren muss.
Ich muss ja die Schriftfabe und die Font setzen.
Aber wie bekommen ich eine font in den AVR rein ?

[Gunni (Gast)]

Hallo.
Hat es mittlerweile jemand geschafft, die GLCD so umzubauen, das man 
Text auch um 90° gedreht ausgeben kann, bzw. es zu Spiegeln, das es 
lesbar ist?

[Marc S. (eurofighter)]

@ Manuel

Sry, das ich das nciht erwähnt habe. Du brauchst einfach eine der Fonts 
aus dem Packet der originalen GLCD-Lib, welche du ganz unten auf dieser 
seite downloaden kannst:
http://www.superkranz.de/christian/S65_Display/DisplaySoftware.html
du brauchst auch nur die Header-Dateien, also z.B. f8x8.h. Darin ist die 
komplette Font enthalten.

Dazu empfehle ich noch dieses Packet:
http://www.mikrocontroller.net/attachment/20837/FontEditor_BitmapConverter.zip
Welches 2 Geniale Programme für die Konvertierung enthällt

Beides nat. nicht von mir, aber mit meiner Lib zumindest zum Teil (siehe 
beschriebung) kompatibel

@ Gunni

Die originale Lib habe ich nicht umgebaut, bin nicht wirklich bewandert 
in asembler, aber meine "lib" ist speziell auf den 90°-Betrieb ausgelegt 
(habe sie ja nur geschrieben weil ich genau diesen Betriebsmodi brauche)



Gruß, Marc

[Gunni (Gast)]

@ Marc Seiffert
Achso.
Leider habe ich das Problem, das ich deine Lib (S65_LibMS-0-2.rar) nicht 
zum laufen bekomme.
Zeichen tut er, aber Text stellt er nicht da.
Ich habe nur Gelbe blöcke mit löchern drin.
Danke.

[Marc S. (eurofighter)]

sehr merkwürdig....kannst du mir mal nähere infos zum controller, der 
umgebung, etc geben ?

ajo, und die Schriftart muss UNKOMPRIMIERT sein ! ist ganz wichtig ! 
sowie zweifarbig (also nur Punkt gesetzt/nicht gesetzt) Die 
Komprimierung bringt bei den unterstützten zweifarbigen Schriftarten eh 
nicht viel wenn man nicht gerade Mega-Zeichen verwendet

Wenn du möchtest kann ich dir gerne ein Komplettpaket mit allem schicken 
was du für ein einfaches Testprogramm brauchst, bei ausreichend genauen 
infos auch schon gebuildet ;)



aktuell arbeite ich nimmer an der lib weiter, vielleicht werd ich in den 
nächsten semesterferien mal nen großes update schieben. bis dahin 
arbeite ich an einem projekt und an sonstigen unisache.


Gruß, Marc

[Gunni (Gast)]

@ Marc Seiffert:
Habe einen Atmega32. Programmiere in WinAvr, und schiebe es mit 
AVRStudio rüber.
Die Schriften habe ich auf der Glcd kopiert.
Ich habe auch probiert BMPs anzuzeigen, das haut jedoch auch nicht hin.
Habe das Bild mit Bin2c und mit dem Konverter aus dem Paket 
"FontEditor_BitmapConverter" Konvertiert mit und ohne Komprimierung.
Komischerweise habe ich mit dem Bild das gleiche Problem bei der 
Glcd-lib.
Jedoch wird dort die Schrift richtig angezeigt.
Ich vermute, das ich die Funktion "S65_PutBmp" falsch aufrufe.
Habe auch schon probiert, jeden Pixel einzeln zu lesen aus dem bmp, und 
dann zu setzten (S65_Pixel), aber auch ohne erfolg.
Dabei ist mir jedoch aufgefallen, das die Funktion "S65_Pixel" einen 
16bit Wert erwartet, und die Konverter Programme alle einen 8bit 
erzeugen. Habe also kurzerhand aus der 8 eine 16 gemacht, und unter GLCD 
funktionierte es gerstern mal kurz, kann es aber leider nicht mehr 
reproduzieren.
Wenn ich die Pixel direkt setze, sehe ich sie auf dem Display.
Ich habe mal mein Test Programm angehängt.
Vielleicht findet jemand den Fehler.

Gruß Gunni

[Marc S. (eurofighter)]

Mir fällt grad auf, eine ganz wichtge Frage habe ich hier noch 
vergessen:

Wasfür ein Displaytyp nutzt du ?

Ich habe die Lib auf nem L02 entwickelt, da ich hier die "more advanced 
addressing modes" nutzen kann. Wenn du ein anderes Display nutzt ist es 
klar, das es nicht funtzt, weil es diese Modes nicht kennt ! Du müsstest 
hier die funktion allocatearea umschreiben, und könntest dann 
transparente Fonts ohne Probleme direkt ausgeben ! (ebenso Transparente 
bitmaps)

[Gunni (Gast)]

Ich nutze den Typ LS020.
Ich denke den meintest du auch, oder?
Ist die schrift immer transparent?
Um die Transparenz geht es mir im moment gar nicht so.
Wichtig ist mir die Darstellung von Text (90°) und Bildern.
Mehr brauch ich (noch) nicht.

Gruß
Gunni

[Marc S. (eurofighter)]

hmm...ok, dannn nutzt du den gleichen typ wie ich, das sollte 100% 
funktionieren, auf den andeen controller kommts meies wissens nach nicht 
an.

ich hab dir mal die Version in den Anhang getan die ich nutze, incl. der 
von mir genutzten fonts.

[Harry S. (littlegonzo)]

Hallo,
habe der C-Lib von Marc mal wieder eine kleine Funktion hinzugefügt.
Gefüllte Kreise....

Vielleicht nützlich für den einen oder anderen...

ps: Bei der Circle Routine können alle ints, als char deklariert 
werden..

void FillCircle(unsigned char x0, unsigned char y0, unsigned char 
radius, unsigned int color)
{
   char f = 1 - radius;
   char ddF_x = 0;
   char ddF_y = -2 * radius;
   char x = 0;
   char y = radius;
     S65_DrawLine(x0,y0 - radius,x0,y0 + radius, color);
     S65_DrawLine(x0 - radius, y0, x0 + radius, y0, color);
   while(x < y)
   {
     if(f >= 0)
     {
       y--;
       ddF_y += 2;
       f += ddF_y;
     }
     x++;
     ddF_x += 2;
     f += ddF_x + 1;
     S65_DrawLine(x0 + x, y0 - y, x0 + x, y0 + y,color);
     S65_DrawLine(x0 + y, y0 - x, x0 + y, y0 +x,color);
     S65_DrawLine(x0 - x, y0 -y, x0 - x, y0 + y,color);
     S65_DrawLine(x0 - y, y0 -x, x0 - y, y0 + x,color);
   }
}

[Marc S. (eurofighter)]

n'abend

thx für das Modul, Harry,  hab ich mittlerweile aufgenommen. nimmt 
206byte Speicher ein :)

Habe nun mal alle int16 der circle-routine auf uint8_t-Typen geändert, 
hat 130 byte eingebracht :)

Allerdings können nun nur noch Kreise mit einem Radius < 128 gezeichnet 
werden! Bei Kreisen >= Raduis 128 funktioniert es nicht mehr. Solche 
Kreise treten aber nur so selten auf, das ich den Speichervorteil von 
immerhin 5,7% der kleinen Einschränkung vorziehe :) Ich selber arbeite 
hier zwar auf einem Mega128, da hab ich Platz ohne Ende, aber ich denke 
nicht, das jeder soein Monster will und in aktueller Form wären auch 
Applikationen auf einem Mega8 denkbar !

Ansonnsten hab ich noch ein paar Veränderungen vorgenommen, und die 
codesize von 4468 auf 3642 byte gesenkt, sind 18,5% :) Das ganze geschah 
einerseits durch die Änderung von int16 nach int8, andererseits wurden 
einige Funktionen in Schleifen untergebracht (bei der Zahlenausgabe), 
was enorm viel einbrachte.
Ausserdem hab ich die verbuggte Routine zur ausgabe komprimierter fonts 
entfernt. Sie ist in der Anlage in der datei "Outsourcing" zu finden, es 
wäre schön, wenn sich mal jemand ihr annehmen würde, um die Lib etwas zu 
komplettieren!
Ansonsten gab nur ein paar Miniänderungen, ein wenig 
Quellcodeformatierung und so...

Die Ramauslastung hab ich um 10 bytes gesenkt, also von 33 auf 23, ein 
Puffer war etwas zu großzügig dimensioniert...

Wie immer kann die lib nat. auf eigene Bedürfnisse angepasst werden, 
indem man einfach nicht benötigte Funktionen ausklammert (im .c-File, 
das .h-File muss nciht verändert werden, ein Ausklammern hier bringt 
nichts, trägt höchstens der Übersichtlichkeit bei ;) ) (wollts nur mal 
gesagt haben^^)

Gruß, €

[Gunni (Gast)]

@ Marc Seiffert:
Die Schrift kann ich jetzt darstellen.
Mit der aus deinem Paket funktionier es.
Aber Bilder werden immer noch nicht angezeigt.
Kann es sein, das ich noch irgendwelche regidster umstellen muss, damit 
es auf einem Atmega32 läuft?
Er zeigt mir nur ein Blaues Bild mit vielen Schwarzen Streifen an.
(Gleiches erbebnis bei der S65_LibMS-0-3.rar)

gruß
Gunni

[Marc S. (eurofighter)]

@ Gunni

in welchem Format speicherst du die Bilder denn ? Poste bitte mal die .h 
dateien der Bilder die du darstellen willst !

Gruß, Marc

[sadat (rus) (Gast)]

To Harry Sk. (littlegonzo)

First, i am one time initialize SPI:

; SPI_SS DDR must be ON!
ldi R16, 1<<SPE | 1<<MSTR   ;
OUT SPCR, R16;
ldi R16,  1<<SPI2X; max speed SPI
OUT SPSR, R16;

and to transmit word to SPI next asm:
SPI_OUT_S65_DATA_WORD:
    cbi     S65_CS (PORT)    ;select Display
    cbi     S65_RS (PORT)    ; clear RS line
SPI_OUT_S65_WORD:
  out SPDR, XH; high data byte
  sbis SPSR, SPIF;
    rjmp PC-1;
  out SPDR, XL; low data byte
  sbis SPSR, SPIF;
    rjmp PC-1;
   sbi S65_CS (PORT)        ;deselect Display
RET;

This get maximum speed to AVR microcontroller.

[Harry S. (littlegonzo)]

Kein Problem,
das Forum sollte ja aus einem nehmen und geben sein ;-)
Zum Anderen war die ableitung aus Circle ja nicht allzu schwer...

Momentan bastel ich eigentlich mehr mit meinem neuen Display (240x128 
T6963) es ist endlich aus Taiwan oder so angekommen ;-)
Die Dinger sind dort einfach zu einem unschlagbaren Preis zu bekommen, 
inkl. Touch für 46,- €.

Grüße
Harry

[Gunni (Gast)]

@ Marc Seiffert
Alles klar.
Ich habe es gestern hinbekommen.
Allerdings nutze ich dazu die Funktione "S65_PutRawBmp16" und speicher 
das Bild auch als "Raw Data".
Du hast geschrieben, das in der Lib noch ein Bug ist, was die 
Komprimierten Bilder angeht.
Ich versuche es mit der "S65_LibMS-0-3.rar".
Im Anhang ein Bild, welches ich mit der Oben beschrieben Funktion 
aufrufe.

Wie sieht es aus mit einem Externen Speicher?
Da ja der Atmega32 doch sehr begrenzt ist, ist bei 16Bit Farbtiefe 
schnell Datenmengen zusammen kommen.
Ich habe da MMC/SD gedacht. Kann ich den an den Gleichen Bus hängen wie 
das Display (Klar CS muss an einen anderen Pin), oder würdet ihr eher 
davon abraten, und nen Software SPI nehmen?
Ich lade nicht jede Sekunde ein Bild aus dem Speicher, aber es sollte 
auch nicht zu lange dauern ein Bild anzuzeigen.

Gruß
Gunni

[Marc S. (eurofighter)]

@ Gunni
Jop, ein Bug, der bei mir zu merkwürdigen blau-schwarzen bildern geführt 
hat ;) Aber nun ist der Teil ja eh rausgenommen, daher wreden 
komprimierte bilder einfach gar nciht mehr beachtet ^^

Wenn der converter 16bit-Bitmaps erzeugt sollten die aber auch ohne 
probleme funktinieren, dann aber mit der anderen Routine.

Ich arbeite im Moment daran SD-Karten anzubinden, ich habe ähnliches 
vor. Nutzen werde ich def. Hardware-SPI.

@ Harry
Ich brauchte ein halbwegs kleines display, ist für ein handgerät....wir 
groß ist denn das display mit dem du arbeitest ?

Gruß, Marc

[Gunni (Gast)]

@ Marc Seiffert:
Wie erzeugt der Konverter denn 16Bit Bitmaps?
Mit dem Haken bei "Raw Data", oder ohne?
Wie sieht den die Komprimierung aus?
Beschreibt diese eine Folge von gleichen Pixeln, oder weniger Farben, 
oder wie muss ich mir das vorstellen?
Gruß Gunni

[Hagen (Gast)]

Der BitmapConverter wandelt ein Bild erstmal vom ürsprünglichen Format 
in eine Bitmap um, also JPEG,PCX,TIFF usw. in Windows-BMP. Dann auf die 
Größe des Displays verkleinter falls das Bild zu groß ist. Danach kann 
man di Farbanzahl reduzieren falls gewünscht oder man kann es drehen und 
spiegeln.

Speichert/Exportiert man das so angepasste Bild dann können 5 
verschiedene Bildformate entstehen.

1.) RAW Data: wird erzeugt wenn die Checkbox angehackt ist. RAW Data 
bedeutet das pro Pixel 16 Bit Farbinformation gespeichert werden. Ohne 
Header usw.
Dieses Format ist zwar das einfachste, benötigt aber auch am meisten 
Speicherplatz und ist unter Umständen sogar langsammer darzustellen als 
die nachfolgenden Formate.

2.) Komprimierungsmodus, das verwendete Format wird automatisch 
ausgewählt.

2.1.) 1 Farb Modus :) Das wäre ein Bitmap das komplett nur eine Farbe 
enthält. Intern kann die Zeichenroutine also einfach mit 
glcdFillRect(Farbe) arbeiten. Der Header in den Daten besteht aus 
Breite,Höhe,BPP=0,Farbe.

2.2.) Monochrome 2 Farben Bilder. Hier wird eine RLE-artige 
Komprimierung verwendet. Der Header besteht aus 
Breite,Höhe,BPP=1,Hintergrundfarbe = 1. Pixel in der linken oberen Ecke. 
Die linke obere Ecke wird immer als Hintergrundfarbe interpretiert und 
kann in den Zeichenroutinen für das LPHxxxx Display als Transparenzfarbe 
eingestellt werden.
Die RLE Codierung sieht so aus das ein Byte in seine 2 Nibble geteilt 
wird. Das untere Nibble bestimmt ein 4 Pixelmuster aus Vordergrund und 
Hintergrundfarbe. Das obere Nibble bestimmt einen Wiederholungzähler, 
also wie oft dieses 4 Pixelmuster wiederholt werden soll. Dabei geht 
dieser Zähler von 1 bis 16 -> 0..15.

2.3.) Bilder mit 3 bis 2^15 Farben. Dieses Format besteht im Header 
wieder aus Breite,Höhe,BPP=x wobei 2^x die Anzahl der Farben darstellt, 
danach kommt ein Word mit der Größe der nachfolgenden Farbtabelle, 
anschließend die Farbtabelle bestehen aus Word Werten und danach die 
codierten Bilddaten.

Die Bilddaten sehen nun so aus: Wenn ein 1'er Bit gelesen wird dann 
folgt diesem BPP-Anzahl Bits. Zb. bei einer 10 Bit Farbbitmap = 1024 
Farben in der Farbtabelle folgt nach einem 1'er Bit im Datenstrom 10 Bit 
als Integer Zahl der Index in die Farbtabelle. Von dort wird der reale 
16 Bit Farbwert geladen und ein Pixel in dieser Farbe gezeichnet. Danach 
werden aus dem Bitstrom solange alle 0'er Bits entfernt und jedesmal ein 
Pixel in der aktuellen Farbe gezeichnet bis man auf ein 1'er Bit trifft. 
Danach würden wieder 10 Bit Index in die Farbtabelle folgen.

Man zeichnet die Bitmap immer von Links Oben nach Recht unten, 
zeilenweise. Dabei werden Header.Breite Pixel pro Zeile gezeichnet und 
das mal Header.Höhe Zeilen.

Bitmaps mit 2^16 Farben werden in den Komprimeirungsfunktionen nicht 
unterstützt da diese garnicht Sinn machen auf dem S65 Display. Man kann 
nicht mehr als 2^15 Pixel auf dem Display gleichzeitig darstellen ergo 
kann man auch nicht mehr als 2^15 verschiedene Farben gleichzeitig 
darstellen und somit ist ein Format für 2^16 Farbbitmaps im Grunde 
absolut überflüssig. Anderst ausgerückt: Das RAW Format mit 16 Bit 
Farbtiefe pro Pixel lässt sich beweisbar immer komprimieren wenn man nur 
eine einfache Farbtabelle und als Daten die Indizes der Realfarbe 
abspeichern würde. Das RAW Format ist also in jedem Falle 
Speicherineffizient.

Das LPHxxxx Display hat einen wichtigen Operationsmodus den ich in 
meiner S65-GLCD-Library auch intensiv in den Bitmap und Font Routinen 
benutzen. Man kann bei diesem Display eine Farbe als "Transparenzfarbe" 
definieren. Wird unn ein kontinuierlicher Pixelstrom an das Display 
gesendet so werden nur Pixel in das interne RAM gespeichert die NICHT 
dieser Transparenzfarbe entsprechen. Man sendet also ohne irgendwelche 
Sofwtarefilterungen alle Farbpixel ans Display, stellt aber vorher diese 
Transparenzfarbe ein und schwups kann man transparente Fonts und Bitmaps 
zeichnen.

Bei meiner glcdDrawBitmap() Funktion wird der linke-obere, also der 1. 
Pixel in den Daten, als Transparenzfarbe interpretiert, wenn man das 
entsprechnede Flag der glcdrawBitmap() Funktion übergibt.

Gruß Hagen

[Littlegonzo (Gast)]

Hallo Marc,
ich habe mir 2 bestellt, einmal ein 240x128 und ein 128x64, werde die 
beiden mal ausmessen. Das 240er ist Dir aber sicher zu groß. Als 
Handgerät würde ich das ganz bestimmt nicht bezeichnen wollen ;-)

Das 128x64 ist wohl mit KS108 als Controller, hab ich aber noch nichts 
mit gemacht, wollte erstmal das große testen ^^


Gruß Harry

[Marc S. (eurofighter)]

hehe, ok...die sache ist simpel, ich baue im moment ein 
GPS-Empfangsgerät mit enigen funktionen zum Loggen, routen, etc, aber 
auch als "mobile Steuerung" für einige Dinge. Das S65-Display ist mir 
eig. sogar zu klein, ich bräuchte ein display, das ca 30% größer ist (je 
seite). Farbe ist nat. auch schon sehr von Vorteil ^^
Hab mich früher auch mal mit 6963 Displays beschäftigt: 
http://eurofighter.eu.funpic.de/HP/Artikel/GPU1.htm
Aus dem Projekt ist aber nix geworden, wurde zu aufwendig und ich hatte 
Privat viel zu tun.


@ Hagen, thx für die auflistung...so ähnlich hattest du sie ja oben 
schonmal gepostet. Die verbuggte Routine basiert ja auh auf deinen 
komprimierten Fonts. Nur habe ich im moment nciht die zeit mich damit 
auseinanderzusetzen...Aktuell implementiere ich nen USART mit 
Datenauswertung, danach kommt eine einfache GUI, danach SD-Karten....

[Harry S. (littlegonzo)]

Hallo Marc,
ich war eben mal auf deiner Seite, aber bei den Videos konnte ich leider 
nix sehen, mehr schwarz als irgend etwas erkennbares ;-)

Sag mal hast Du die unterlagen noch dazu (Source, Platinenlayout) zu dem 
Display vielleicht???
Wäre echt klasse weil die Platine gefällt mir echt echt gut ;-)

Hm, die Displays sind beide Blau/Weiss also nix mit bunt(d)...
Soll ich trotzdem mal messen?

Gruß Harry

[Marc S. (eurofighter)]

n'abend Harry!

Ich hab grad gesucht, und die schlaltpläne/Layouts/Quelltexte zu GPU1.0 
nicht mehr gefunden. Die Quelltexte hätten dir aber auch nciht 
sonderlich viel gebracht, da die alle in Pascal geschrieben waren (AVRco 
Mega8-Version als Compiler). Der Code war dermaßen ineffizient, das ich 
nach kurzer Zeit auf C umgestiegen bin.

Ich habe allerdings das Projekt ein weiteres mal aufgegriffen, auch 
zuende geführt, allerdings einige Funktionen nie getestet und es dann 
ebenfalls zur Seite gelegt ^^ Dazu habe ich noch alle Files, also 
Quellcode, .sch , .brd, und das kannst dir im Anhang runterladen.

Das neue Layout nutzt einen Mega32 als Controller im TQFP Format, hat im 
gegensatz zum alten 64 KB Flash onboard, diesmal gesockelt, und kann 
zudem die HG-Bel in ihrer Helligkeit über PWM mit externem Mosfet 
regeln. Auch wurde das layout selber verbessert. ich habe auf SMD-Elkos 
zugunsten von normalen verzichtet, sodass die bauhöhe um einige 
milimeter gesunken ist (Auf der Rückseite waren nur die SMD-Elkos, und 
daher dort ausschlaggebend für die Bauhöhe).

Wie das alte Layout auch ist dies aber eine rein I²C-Gesteuerte Platine. 
also nix mit GPIO (auch nciht am ISP, das ist am GLCD dran)...gut, 
könnte man alles über I2C realisieren, das ist klar...es ist halt nur 
eigentlich ein Slave-Board ^^)

Schaus dir an, wenn du willst kannst es gerne nachbauen und den code für 
eigene Zwecke nutzen :)

Und messen wäre schön :) es ist immer gut alternativen im Kopf zu haben 
wenn man ein neues Projekt startet.

Gruß, Marc

[Manuel G. (manuelg)]

Ich hab noch ein Problem mit der RAW- Bildausgabe.
Ich arbeite mit dem AVR und dem ATMega128  - 128k Flash

Bei kleinen Bildern gibts kein Problem.
Jetzt wollt ich mal ein mit Vollbild probieren (132x176).
Allerdings schreit dann AVR Studio ".... to large".
Obwohl ein Vollbild ja nur ca 40 kb hat ... Drum rum hab ich nicht viel 
laufen - nur die Lib eben.
Im AVR Studio - Configuration - Memory Settings steht auch 
seltsamerweise bei Flash size 0x10000 - was ja 65k wären.

Kann mir wer weiterhelfen ?
(Ja BIld wurde mit PROGMEM gespeichert)

[Hagen (Gast)]

ich bin mir nicht ganz sicher, aber WinAVR GCC kann nur Datenstrukturen 
< 32Kb am Stück verarbeiten. Irgendein Problem gabs da mit dem GCC, ich 
denke hier im GCC Forum sollte man darüber ein Thread finden.

Du kannst aber die daten im *.h File einfach in 2 Arrays aufteilen, so 
das sie im FLASH nacheinander eingelinkt werden. Du übergibst dann der 
glcdDrawbitmap() Funktion einfach das 1. dieser beiden arrays. 
Allerdings soltest du im *.MAP oder *.LST File überprüfen das beide 
teile der Bitmap auch wirklich nacheinander am Stück eingelinkt wurden.

Gruß Hagen

[Manuel G. (manuelg)]

Da könntest du recht haben .... 32k ist so ca. die magische Grenze
von Map oder List Files hab ich aber noch nie was gehört.
Werd die Foren mal durchstöbern.

Danke erstmal

[Harry S. (littlegonzo)]

Hallo Marc,
erstmal vielen Dank für die Dateien. Schaue ich mir gleich mal an...

Die Werte der LCDs:

240x128 = 144,3 mm x 104,00 mm
128x64  = 78,0 mm x 70,35 mm

Beide sind mit Blauer Hintergrund Beleuchtung und weißer Schrift.

Momentan spiele ich nur mit dem großen noch rum ;-)

Gruß Harry

[Marc S. (eurofighter)]

das aufteilen der arrays wie von hagen beschrieben kann ich bestätigen, 
hat bisher mehrmals bei mir geklappt....hab atm ein anders problem, und 
zwar gibts bei mir massig errors, wenn ich 64kb codegrenze überschreite 
:/




das 128x64 könte glatt passen :) nur isses halt nicht so wirklich 
geeignet ^^

[Gunni (Gast)]

Wie Teile ich denn das Array?
Ich muss doch dann im vorheriegen Array immer den namen des neuen 
irgendwie mitgeben, oder nicht?
vieleicht könnte jemand mal nen beispiel posten.
gruß
Gunni

[Marc S. (eurofighter)]

gsnz einfach, geh irgendwo in die mitte des arrays und deklarier da 
irgendeine variable mit belibigem namen im progmem

die namen werden ja eh nicht mitgespeichert, sodern nur die daten. und 
die halt nun einmal linear hintereinander im flash ^^

nimm einfach die deklaration des hauptgerichets und für ne 0 hinter den 
namen oder so ^^

[Hagen (Gast)]

@Manuel,
das MAP und LST File wird normalerweise vom Compiler eg. Linker erzeugt 
wenn du neu compilierst. Im MAP File, MAP kommt von Map=Karte, wird dann 
ersichtlich welche Variablen,Konstanten,Funktionen an welcher Adresse im 
FLASH oder SRAM zur Laufzeit liegen. Es ist also eine Karte mit 
Koordinaten=Speicheradressen der wichtigen Teile des fertigen 
Programmes.
Das LST File oder List/Listing-File enthält je nach Konfiguration den 
aus dem C Source erzeugten Assembler Source. Quasi eine lesbare Form des 
HEX Files. Je nach Einstellungen im MakeFile kann dieses LST File sogar 
Teile des C Sources als Remarks enthalten und da drunter den erzeugten 
Assemblercode.
Beide Files sind wichtig für einen erfahrenen C Programmierer, einfach 
um zu verifizieren was der Compiler/Linker aus dem Source erzeugt haben 
oder eben bei der Fehlersuche. Denn auch Compiler machen manchmal dumme 
Fehler ;)

Gruß Hagen

[Hagen (Gast)]

uint8_t logo_bmp[] PROGMEM = {
  0xB0, 0x84, 0x0C, 0x00, 0x00, 0x12, 0x1E, 

  0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x20, 0x00, 0x21, 0x00, 0x22, 0x00, 0x23, 0x00, 0x24, 0x00, 
  0x26, 0x00, 0x40, 0x00, 0x41, 0x00, 0x42, 0x00, 0x43, 0x00, 0x44, 0x00, 0x60, 0x00, 0x61, 0x00, 
  0x62, 0x00, 0x63, 0x00, 0x64, 0x00, 0x65, 0x00, 0x66, 0x00, 0x67, 0x00, 0x68, 0x00, 0x69, 0x00, 
  0x6A, 0x00, 0x6B, 0x00, 0x6F, 0x00, 0x80, 0x00, 0x81, 0x00, 0x82, 0x00};

uint8_t logo_bmp0[] PROGMEM = {
0x84, 0x00, 0x85, 0x00, 
  0x86, 0x00, 0x87, 0x00, 0x8E, 0x00, 0xA0, 0x00, 0xA1, 0x00, 0xA2, 0x00, 0xA6, 0x00, 0xA7, 0x00, 
  0xA8, 0x00, 0xA9, 0x00, 0xAD, 0x00, 0xAE, 0x00, 0xB0, 0x00, 0xB1, 0x00, 0xC0, 0x00, 0xC1, 0x00, 
  0xC2, 0x00, 0xC3, 0x00, 0xC7, 0x00, 0xC8, 0x00, 0xC9, 0x00, 0xCA, 0x00, 0xCD, 0x00, 0xD1, 0x00, 
  0xE0, 0x00, 0xE1, 0x00, 0xE2, 0x00, 0xE7, 0x00, 0xE8, 0x00, 0xE9, 0x00, 0xEA, 0x00, 0xEB, 0x00, 
  0xEC, 0x00, 0x00, 0x01, 0x02, 0x01, 0x03, 0x01, 0x08, 0x01, 0x0A, 0x01, 0x0B, 0x01, 0x0C, 0x01};

So müsste es bei dir aussehen. Das Array logo_bmp[] wurde in der Mitte 
geteilt und logo_bmp0[] als zweites Array gleich hintendran deklariert. 
Im MAP/LST File sollte nun logo_bmp[] und danach ohne Lücke logo_bmp0[] 
drinnen stehen. Achte darauf das das erste Array[] eine durch 2 teilbare 
Bytesgröße besitzt, d.h. die Anzahl der HEX Bytes ist gerade (einfach um 
dumme Fehler zu vermeiden)

Gruß Hagen

[Manuel G. (manuelg)]

Funktioniert ohne Probleme das mit dem teilen.
Hab gerade das AVR Studio durchstöbert und festgestellt dass die option 
map file generieren nicht aktiviert ist .. daher ist di bei mir auch 
nicht aufgetaucht. Aber danke für den Hinweis !
Ich bin noch auf der Suche nach einer relativ großen Schriftart.
So ca. 32x32 Pixel
Bekomm ich die irgendwo her ? Gehst das ohne Probleme ?

[Hagen (Gast)]

Also mit meinem FontEditor kannst du eine beliebige Windows-Schriftart 
importieren. Also suche dir einen schönen TTF->True Type Font, öffne 
meinen FontEditor, drücke den Button "Import Font", wähle dort deinen 
Font aus, stelle die Größe des Fonts im Dialog ein und drücke Ok.
Danach wird der Font in einem Bitmapfont umgeandelt und angezeigt. Es 
kann dann je nach Font sein das du diesen Prozess mehrmals machen musst 
und dich an die beste Größe herantasten musst. Auch wirst du ein par der 
importierten Zeichen löschen oder nachbearbeiten müssen. Einfacher gehst 
nicht ;)

Gruß Hagen

[Dominic B. (Gast)]

Hi zusammen,
ich mus zugeben das ich nicht die ganzen, sind ja über 900, Beiträge 
durchgelesen habe. Ich will mir nun auch ein solches Display kaufen. Es 
soll letzendlich zum mobilen Einsatz kommen. ALs Spannungsversorgung für 
das ganze Gerät steht eine 9V Blockbatterie/Akku zur Verfügung. Jetzt 
benötigt die Hintergrundbeleuchtung des S65 Displays aber so 10-11 V.

Kann bitte mal jemand von euch das Display an 9V hängen und mir 
mitteilen ob es überhaupt geht, oder wieviel die Beleuchtung dunkler 
ist. (Ist rein subjektiv ich weiß)

Oder hat jemand eine Idee für eine Ladungspumpe von 9V auf die 
geforderten 10-11V?

Dann noch ein/zwei letzte Frage. Kauft Ihr zb bei ebay--numan02003 die 
gebrauchten oder neuen Displays? Wie sind da eure Erfahrungen?


Danke schonmal im voraus.
Gruß Dominic

[der mechatroniker (Gast)]

Bei Zimmertemperatur beträgt die Flußspannung der Backlight-LEDs (die 
sind wohl intern in Reihe geschaltet) mit dem Multimeter gemessene 10,4 
V. Bei 9 wirds wohl net leuchten. Bedenke, daß die LED-Kennlinie 
exponentiell verläuft.

[Dominic B. (Gast)]

Mir ist gerade noch eingefallen.
Macht eine Ladungspumpe von 9V auf 10-11V Sinn?
Oder ist es in diesem Fall besser die Ladungspumpe nach den 5V 
Spannungsregler zu bauen. Denn wenn die Batteriespannung auf zb 7-8V 
fällt, irgendwann geht die Batterie mal zu neige, reicht das für den 
LowDrop 5V Regler immer noch, jedoch evtl. nicht mehr für die 
"berechnete 9 auf 10-11V" Ladungspumpe.

Ich muss zugeben, ich kenn mich mit so Ladungspumpen-Geschichten nicht 
die Bohne aus, und einen fertigen DC-DC Wandler will ich da nicht 
unbedingt einbauen wenns auch anders geht.

[Fabian B. (fabs)]

einen 9V Block zu nutzen macht hier schon keinen Sinn... mit 3-4 AA 
Batterien oder besser Akkus mit 2400mAh biste besser beraten... 9V 
Blocks haben eine zu geringe Energiedichte um lange Strom liefern zu 
können (typ. 250mAh).

Gruß
Fabian

[Gunni (Gast)]

@ Dominic B.:
Ich würde die Ladungspumpe empfehlen, da du damit auch die Möglichekeit 
hast zu dimmer und somit Batterie schonen kannst.

@Hagen:
Super das Geht jetzt.
Nächstes Problem ist jetzt der interne speicher. Er reicht nicht mehr 
aus.
Nen Atmega32 ist halt kein Speicher riese.

Mit ist gerade noch aufgefallen, das ich probleme habe mit dem 
"S65_Init".
Noch arbeite ich mit der Version 2 der Lib.
Ich lasse das Display initialisieren, und sofort etwas ausgeben, aber es 
wird auf dem Display nur die hälte dargestellt.
Also habe ich "vor" und "nach" dem Init eine kurze Pause erzeugt und 
schon läuft es. (Fehler trat nur auf, wenn Stromversorgung unterbrochen 
wurde, nicht bei Reset).

[Hagen (Gast)]

>@Hagen:
>Super das Geht jetzt.
>Nächstes Problem ist jetzt der interne speicher. Er reicht nicht mehr
>aus.
>Nen Atmega32 ist halt kein Speicher riese.

Oben schrieb ich ja, ATMega mit möglichst viel FLASH, wenn man par Fonts 
und Bitmaps verwenden möchte. Deshalb habe ich ja für die Bitmaps die 
Komprimierungsfunktion geschrieben. Bei monochromen Bitmaps kannst du 
mit 900% Komprimierung rechnen im Vergleich zu RAW. Bewi Mehrfarbbitmaps 
mit anständig Farben (> 1024) kannst du mit 50% Komprimierung minimal 
rechnen im Vergleich zu RAW. Meine Icons wurden durchschnittlich auf 
20-25% der RWA Größe reduziert, und dabei sind diese Icons keine 
großflächigen Bitmaps sondern relativ klein. Mein Fullcolor/Fulldisplay 
Logo wird auf 23% der Originalgröße komprimiert. Grob gesagt bekommt man 
mit der Komprimierung also die 4 fache Menge an Bitmaps in den Speicher 
rein, ergo der Softwareaufwand lohnt sich.

Ansonsten: alle Font/Bitmap Datenstrukturen sind so konstruiert das sie 
sequentiell geladen werden können. Man kann also zb. beim zeichnen 
eines/r Fonts/Bitmap auch mit einem sequientiell arbeitenden externen 
Speicher wie I2C EEProms arbeiten. Dazu müssen nur in der Software alle 
Speicherlesezugriff wie pgm_read_byte() usw. ersetzt werden.

Gruß Hagen

[Gunni (Gast)]

@Hagen:
Der Grund, weswegen ich auf die andere Lib umgestiegen bin, ist die 
tatsache, das ich die schrift drehen kann.
Ich möchte das Display 90° gedreht (Querformat) einbauen.
Ich denke, ich werde um einen externen speicher nicht herumkommen, 
MMC/SD wäre eine geeignete Option. Aber eins nach dem anderen.

[Marc S. (eurofighter)]

hi Gunni,

hast du icq ? wenn ja könntest du mir deine nummer an meine mailaddy 
schicken ? ich glaube wir haben sehr ähnliches vor, und ich würde mich 
über einen etwas direkteren Austausch freuen :)
Wie oben schon beschrieben will ich ebenfalls SD/MMC-Karten anbinden und 
über sie Bilder auf dem S65D anzeigen, sowie logdateien auf sie 
speichern!

zu den Komprimierten bitmaps hatte ich diese Routine geschrieben:

  else // Bitmap mit 2 bis 2^15 Farben
    {
    uint8_t    byte = 0;
    uint8_t   bitpointer = 0;
    uint16_t   offset = 0;
    uint16_t   aktcolor = 0;
    uint16_t   colortablesize = 0;
    uint16_t   Pixel = (dimx+1) * (dimy+1);
    uint16_t   counter = 0;
    uint16_t   bytepointer = 0;
    uint16_t   colortableindex = 0;

    aktcolor  =   pgm_read_byte_near(&pic[4]); 
    aktcolor  *=   256;
    aktcolor  +=   pgm_read_byte_near(&pic[3]); 
    colortablesize  =   pgm_read_byte_near(&pic[6]); 
    colortablesize  *=   256;
    colortablesize  +=   pgm_read_byte_near(&pic[5]);

    offset = colortablesize + 7;
    
    S65_allocatearea(y,x,y+dimy, x+dimx);

    while(counter < Pixel)
      {
      byte = pgm_read_byte_near(&pic[offset+bytepointer]);
      if(bit_is_set(byte, bitpointer))
        {
        colortableindex = 0;
        for(uint8_t ccounter = 0; ccounter < BpP; ccounter++)
          {
          colortableindex *=2;
          bitpointer +=1;
          if(bitpointer == 8){bitpointer = 0;bytepointer+=1;}
          byte = pgm_read_byte_near(&pic[offset+bytepointer]);
          if(bit_is_set(byte, bitpointer)){colortableindex += 1;}
          }
        aktcolor = pgm_read_byte_near(&pic[7+colortableindex]);
        }
      else
        {
          S65_wrdat16(aktcolor);
          counter++;
          bitpointer +=1;
          if(bitpointer == 8){bitpointer = 0;bytepointer+=1;}
        }
      }
    }

sie ist eigentlihc so aufgebaut wie von Hagen beschrieben, enthällt aber 
noch bug(s). Wie gesagt, ich habe im moment nicht die Zeit sie zu 
implementieren, aber bereichern würde sie die c-lib nat. schon gewaltig 
!

Gruß, Marc

[Hagen (Gast)]

habs jetzt nur überflogen, aber

aktcolor = pgm_read_byte_near(&pic[7+colortableindex]);

das kann garnicht richtig sein. aktcolor muß ein 16Bit Datentyp sein, 
logisch.

Davon abgesehen würde ich den Pointer "pic" nicht absolut + offset 
benutzen sondern diese Pointer nach jedem Lesen eines Bytes aus dem 
FLASH inkrementieren.

Hm, nachdem ich mir deine Source nochmal angeschauen habe mein ich das 
da einiges nicht stimmt. Du lieste unter Umständen das Datenbyte "Byte" 
mehrmals von der gleichen FLASH Adresse weil sich der "BytePointer" 
nicht verändert hat.

Hier nochmal meine Source, so umgeschrieben das sie ohne ASM Makro 
auskommt. Alle Display-abhängigen Makros habe ich mal als Pseudocode 
eingebaut.

uint8_t powerof2[8] PROGMEM = {1,2,4,8,16,32,64,128};

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

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

    if (!(bitmap)) return; // bitmap = nil exit
    uint8_t w = pgm_read_byte(bitmap++); // lese Breite in Pixeln
    if (!(w)) return;                      // wenn Breite == 0 exit
    uint8_t h = pgm_read_byte(bitmap++); // lese Höhe in Pixeln 
    if (!(h)) return;                      // wenn Höhe == 0 exit
    uint8_t bpp = pgm_read_byte(bitmap++); // lese Farbauflösung in Bits per Pixel
    uint16_t bkcolor = pgm_read_word(bitmap); bitmap += 2; // Hintergrundfarbe lesen, entspricht Pixelfarbe in linker oberer Ecke des Bildes
    if (flags & GLCD_BMP_USECOLORS) bkcolor = glcd.Colors[0]; // falls Flag gesetzt dann soll als Transparenzfarbe die Hintergrundfarbe der GLCD Lib. aus glcd.Colors[0] benutzt werden
    if (bpp == 0) { 
  // Bitmap ist ein einfarbig gefülltes Rechteck
      glcdFillRect(x, y, x + w -1, y + h -1, bkcolor);
      return;
    }
    GLCD_CS_ON(); // CS vom Display ON
    GLCD_SETADDR(x, y); // Pixeladdresse im Display setzen
    GLCD_WINDOW(x, y, x + w -1, y + h -1); // Window im Display setzen, 
// Modus muß sein das X-Koordinate inkrementiert wird und bei Überlauf 
// innerhalb des Windows die Y-Koordinate inkrementiert wird
    if (flags & GLCD_BMP_TRANSPARENT) { 
      GLCD_SETMODE(0x38 | GLCD_ROP_WNE); // Transparenter Modus setzen
      GLCD_SETCOMPARE(bkcolor);
    } else {
      GLCD_SETMODE(0x38);
    }
    GLCD_STARTDATA(); // als nächstes kommen Pixeldaten übers SPI
    if (bpp == 1) {
  // monochrome Bitmap
      uint16_t pixelcount = w * h; // Anzahl der Pixel im Bitmap
      uint16_t fgcolor = pgm_read_word(bitmap); bitmap += 2;
      if (flags & GLCD_BMP_USECOLORS) fgcolor = glcd.Colors[1];
      uint16_t color = bkcolor; // aktuelle Pixelfarbe auf Hintergrundfarbe setzen
      if (flags & GLCD_BMP_SWAPCOLORS) {
        bkcolor = fgcolor; // Farben vertauschen
        fgcolor = color;
        color   = bkcolor;
      }
      uint8_t data = pgm_read_byte(bitmap++); // 1. Datenbyte lesen und dekodieren
      uint8_t pixelbits = ((data >> 4) +1) << 2;
      data &= 0x0F;
      uint8_t temp = data << 4;
      data |= temp; // data enthält nun im beiden Nibbles den Wert des LowNibble
      do {
        GLCD_WAIT(); // warte auf Display-SPI-Kommunikation, also werden noch Bits ans Display gesendet ? Wenn ja warte bis SPI fertig.
        GLCD_OUT(H8(color)); // sende HighByte aus Color ans Display
        if (!(--pixelbits)) { 
        // neue Daten holen
          data = pgm_read_byte_inc(bitmap);
          pixelbits = ((data >> 4) +1) << 2; // Anzahl Pixel zu setzen == HighNibble(Data) * 4
          data &= 0x0F;
          uint8_t temp = data << 4;
          data |= temp; // Data = LowNibble(Data) << 4 or LowNibble(Data)
        }
        GLCD_WAIT(); // warte auf SPI
        GLCD_OUT(L8(color)); // sende LowByte der Farbe
        ROL(data);  // rotate data, data = (data << 1) | (data >> 7);, ASM Makro ist effizienter "ADD Data, Data; ADC Data,0;" 
        color = bkcolor; // Farbe ist Hintergrundfarbe
        if (data & 0x01) color = fgcolor; // wenn Bit in Data = 1 dann Farbe auf Vordergrundfarbe
      } while (--pixelcount);
    } else if (bpp == 16) { 
    // full color Bitmap
      uint16_t pixelcount = w * h;
      while (pixelcount) {
        GLCD_WAIT();
        GLCD_OUT(H8(bkcolor));
        pixelcount--;
        GLCD_WAIT();
        GLCD_OUT(L8(bkcolor));
        bkcolor = pgm_read_word(bitmap); bitmap += 2;
      }
    } else {
   // color, 2 upto 15 BPP Bitmap
      uint16_t colortablesize = pgm_read_word(bitmap); bitmap += 2;
      uint8_t* colortable = (uint8_t*)bitmap; // Farbtabellen-Zeiger
      bitmap += colortablesize; // Farbtabelle überspringen, auf Pixeldaten positionieren
      uint16_t colormask = pgm_read_word(&colormasks[bpp -2]); // Farbmaske laden, das ist die AND Maske mit der das Datenword maskiert werden muß um den Index in Colortable zu berechnen, allerdings *2 multipliziert und damit schon angepasst auf den Fakt das in Colortable ein Farbwert ein 16 Bit Word ist.
      uint32_t data = 0;
      uint8_t databits = 0; // enthält die Anzahl der Pixelbits
      uint8_t bitsmul = 1; // statt Shifts mißbrauchen wir den MUL Befehl, ist effizienter auf ATMegas als Shifts von 16Bit.
      uint16_t pixelcount = w * h;
      do {
        GLCD_WAIT();
        GLCD_OUT(H8(bkcolor));
        pixelcount--;
        while (databits < 16) { 
 // solange weniger als 16 Bits in Data befüllt sind neue Daten vom FLASH holen
          uint16_t t = pgm_read_byte(bitmap++) * bitsmul; // links shift per MUL
          if (databits >= 8) data |= (uint32_t)t << 8;
            else data |= t;
          databits += 8;
        }

        GLCD_WAIT();
        GLCD_OUT(L8(bkcolor));

        if (data & 0x01) { 
// wenn unterstest Bit in Data = 1 dann folgt in Data ein Index auf die Farbtabelle mit neuer Pixelfarbe
          bkcolor = pgm_read_word(colortable + (data & colormask));
          data >>= bpp;
          databits -= bpp;
          bitsmul = pgm_read_byte(&powerof2[databits & 0x07]);
        }
  // "Shiftfaktor" für multiplikativen Shift rechts rotieren
        bitsmul >>= 1;
        if (!(bitsmul)) bitsmul |= 0x80;
        data >>= 1;
        databits--;
      } while (pixelcount);
    }
    GLCD_WAIT(); // warte auf SPI
    GLCD_CS_PULSE(); // CS pulsen
    GLCD_SETMODE(0x30); // Modus auf Standard
    GLCD_CS_OFF(); // Display-SPI deaktivieren
}

Gruß Hagen

[Hagen (Gast)]

Die Makros L8() und H8() extrahieren das Low/High Byte eines 16Bit 
Words. Die Makros HH8((), HL8(), LH8(), LL8() extrahieren die 
entsprechenden Bytes eine 32Bit Words. In gccutils.h schauen.

Wichtig in der 2-15 BPP Routine ist das Data ein >= 24Bit Datentyp ist. 
Es müssen zu jedem Zeitpunkt mindestens 16 gültige Datenbits in Data 
gespeichert sein. Logisch da bei einer 15Bit Bitmap ja der 15Bit 
Farbindex in die Farbtabelle darin enthalten sein müssen. Das unterste 
Bit in Data (Bit #0) wird dann 1 sein um anzuzeigen das die Bits 1# bis 
15# ein Farbindex darstellt. Durch diesen 1 Bit Linksversatz sparen wir 
uns eine Multiplikation mit 2, Linksshift mit 1, um den Offset in die 
Wordbasierte Farbtabelle zu berechnen.

Data wird beim Nachladen eines neuen Bytes von "Oben" befüllt, man setzt 
also die neuen 8 Bits an Daten aus dem FLASH ontop in Data rein. Somit 
kann man Data immer rechtsshiften um X Bits zu entfernen. Dazu benutzen 
wir keinen Linksshift per LSR Opcode sondern eine 8 auf 16 Bit 
Multiplikation. Das ist auf einem ATMega durchschnittlich immer 4 mal 
schneller als ein generischer Shift.

Die Routinen/Datenstrukturen sind dahingehend optimiert das man sie 
effizient in Assembler optimieren kann. Zb.

        ROL(data);
        color = bkcolor;
        if (data & 0x01) color = fgcolor;

kann in ASM so geschriebenen werden

[asm]
  movw  color, bkcolor
  add  data, data
  bnc  @@next
  inc data
  movw color, fgcolor
@@next
[/asm]

also rotieren von data und das setzen von color in einem Branch.

Gruß Hagen

[Hagen (Gast)]

sorry

[asm]
  movw  color, bkcolor
  add  data, data
  bnc  @@next
  movw color, fgcolor
@@next
[/asm]

das inc data ist überflüssig.

Gruß Hagen

[Hagen (Gast)]

der wert in bitsmul entspricht 2^(databits & 0x07).

Gruß hagen

[Gunni H. (gunni)]

@Hage &  Marc Seiffert:
Ihr habt euch ja nun recht intensiv mit dem Display beschäfftig, wäre es 
nicht sinvoll die beiden Libs zu einer zusammen zu fügen, soweit dieses 
Funktioniert?
Wo es geht, würde ich helfen.

Gruß
Gunni

[Hagen (Gast)]

Jo sinnvoll ist alles ;) Ich tendiere aber dazu, wenn ich es persönlich 
auch bräuchte, meine Lib nur so anzupassen das man damit andere S65 
Displaytypen unterstützt. Denn es existieren schon alle Funktionen, zb. 
Ellipsen, abgerundete Rechtecke und ein vollständiges Menusystem samt 
verschiedener Editoren um die angezeigten Parameter im Menu zu 
editieren. Soll heisen: meine LPHxxxx Library fürs S65 Display hat einen 
höheren Funktionsumfang, und der ist getestet. Im Gegensatz zur Nodkia 
GLCD Library von damals habe ich diesesmal einiges verbessert. Alles in 
C, bis auf par Kleinigkeiten bei denen ich nicht widerstehen konnt um 
den GCC Code zu verbeseren. Desweiteren alle Display-Controller 
abhängigen Ansteuerungen per Makros. Man sollte also nur diese Makros 
anpassen müssen und ansonsten die speziellen Ansteuersequenzen die 
spezialfeatures des Controllers benutzen.

Nur halte ich es im Hobby aber auch so das ich nur das programmiere was 
ich auch wirklich benötige. Und das S65 habe ich in meinem 
Drumpad-Projekt benötigt und dieses ist schon längere Zeit 
abgeschlossen.

Wenn ich ein Display mit anderen Typ zum Testen hätte dann und nur dann 
würde ich mirs eventuell nochmal überlegen auch dieses Display zum 
laufen zu bringen. Aber im Grunde wäre das Zeitverschwendung da ich es 
nicht brauche zur Zeit.

Und dann kommt noch das problem hinzu das ich mich im Gegensatz zur 
Nokia Library entschlossen habe meine S65 Library eben nicht frei zu 
veröffentlichen. Die Gründe sollten Insider ja bekannt sein. Das hat 
nichts damit zu tuen das ich mein Wissen nicht teilen möchte, das dürfte 
wohl klar sein.

Gruß Hagen

[TheMason (Gast)]

wow ...
dieser artikel geht auf die 1000'er marke zu :-)

schade nur das ich mir noch kein s65-display organisiert habe.
weiß jemand (sorry habe mir den thread nicht komplett durchgelesen :-)))
ob das s65 kompatibel (wenns nicht gar dasselbe) ist wie das 1.5'' TFT 
auf display3000.com ?

[Gunni (Gast)]

Soweit ich herausgefunden habe, ist eines der Displays auf Display3000 
ein S65.
Das andere ist bzw. war mal ein Nokia. Das Nokia hat soweit mir bekannt 
4.000 Farben. Dort wird aber ein verkauft, welches mehr Farben hat.
Ich möchte hier niemanden etwas unterstellen, aber ich meine mal gehört 
zu haben, das der Quellcode von Display3000 einer "kostenlos" 
erhältlichen Lib für die Displays sehr ähnlich ist.
Also ich würde dir Empfehlen besorg dir ein "richtiges" Nokia oder S65 
Display und benutze eine hier erhältliche Lib.
Kommst auf jeden fall günstiger bei weg.
Gruß
Gunni

[EDAconsult Udo Kuhn (Gast)]

Auf der Jagd nach Display's bin ich zufällig hier

Bin gleich los und wie sollte es anders sein ist natürlich das Epson 
Display auf meinem Tisch gelandet, geht auch.  Wie nicht anders zu 
erwarten habe ich ein ATmega8L angeschlossen, geht auch mit 2.8V, nein 
kein aber. Von allen drei Display's habe ich versanden den letzten zu 
erwischen. Dann noch den kleinen ATmega8L, kann ich noch tiefer fallen. 
Geht aber alles, nur duch lesen, das Ding läuft. Falls jemand wirklich 
damit Fehrnsehen möchte, sollte sich überlegen ob min. 24 Bilder in der 
sec. auch mit bester Ausstattung überhaupt auf dem LCD ankommen!

Ansonsten bin ich mit allem was ich hier bekommen konnte schwerstens 
zufrieden, auf alle Fragen habe ich eine Antwort gefunden.

Besonderen Dank an C. Kranz und H. Reddmann.

[sebastian (Gast)]

S65 display and 3D effect
http://serwis.tv/3d_kwadrat_s65.mpg
http://serwis.tv/3d_x_s65.mpg

N6610 display and 3D effect
http://serwis.tv/3d_kwadrat.mpg

[EDAconsult Udo Kuhn (Gast)]

S65 display LS020 und ATmega8L 8MHz 2,8V.

[Borsty (Gast)]

Ich hab mir mal die Mühe gemacht dem LS020 einen Controller zur seite zu 
Stellen der per UART ansprechbar ist.

Kleine Demo: ( läuft über den pc, Baud 38400 )
http://www.youtube.com/watch?v=-lzhdzzPxKI

Doku und Sourcecode folgt in der nächsten oder übernächsten Woche für 
die die's interessiert :)

Befehle die zZ unterstütz werden:
Pixel setzen, Linie zeichnen, Box zeichnen, Quadrat zeichnen, 5x8px 
Text, 3x5px Text, Hintergrund- und Vordergrund-Farbe setzen (interne 
24bit->16bit Umrechnung), Baudrate ändern.

Was noch geplant ist:
Zugriff auf freie Ports und ADC, Neben Uart auch TWI/I2C slave 
unterstützung.

Das Endergebniss soll ein einfach anzusteuerndes I/O-Interface mit 
Display werden :)

[Michi Müller (Gast)]

Wow, sieht gut aus. Hab ich das richtig gesehen : War da auch Fading ?

Ich hab auf jeden Fall Interesse an dem Projekt !