@Ralf:
wie gesagt steht oben meine EMail Adresse, ich kann dir meinen Source
mailen.
Du benutzt 8Bit SPI und vor jeder "Aktion" mit dem Display sendet man
1.) Identifikations Byte mit Addresse des Displays + Kommando Bits die
beschreiben ob man ein Daten/Command Register lesen/schreiben möchte.
2.) der Index des Registers das man ansprechen möchte
3.) die entsprechenden Daten die man schreiben möchte, beim Lesen sind
es nur Dummybytes aber das ist eh überflüssig da beim SPI keine MOSI
Leistung nach aussen geführt ist.
Das steht aber so auch im Datenblatt drinnen.
Gruß Hagen
Hallo Martin,
wenn du die libraray benutzt, musst du die auch neu kompilieren.
Ansonsten durchsuch doch mal den Quellcode, ob irgendwo noch direkt PB7
steht...
@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:
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
@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?
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.
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
@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
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
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
Hi to all!
Anybody knows where to find datasheet for the most popular LS020 display
or its LR38826 controller?
It seems that all the displays (LPH and L2F50) is pretty documented now,
except for LS020... :((
Dear H. Reddmann!
I`ve found your FontEditor (from the library package) very useful for
me. It is simple and powerful enough.
Can you, please, help me to understand how to work with the .font files
generated by the editor? Especially - how to decompress them?
Yes i can help you ;)
First use the newest version i've attached. It contains a checkbox to
explicitely tell the program not to compress the data. In older versions
this descision was made automaticaly by the program, now with user
invention.
There exist two possible formats of the font data:
1.) not compressed fonts
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
1.) font_Bits_Per_Pixel must have set the MSB to true to identify a
compressed font.
2.) font_Byte_Padding is a multiply of Bytes wich we have used to pad
our character data in font_Data[], explanation follows.
3.) font_RLE_Table[] contains 3 entries, but in realty there a 4. The
first one, not saved entry is always 1.
4.) font_Char_Sizes[] contains the count of bytes used for each
character in font_Data[]. We need this array to find the right
beginning.
Because this array[] can only save a byte for one character, eg. the
maximal data bytes of one characters can 256 bytes we have a problem on
large fonts. To solve this we use font_Byte_Padding. If as example
Font_Byte_Padding is 2 the all charcaters in our font use data chunks of
a multiply of 2 bytes in length. Now our font_Char_Sizes[] entry stores
the real bytecount divided by 2. A character in this font that need 127
real data bytes would be thus consume 128 bytes and the entry in
font_Char_Sizes[] would be 64. Thus we can now save characters with upto
512 bytes each instead of only 256 bytes.
Thus in the computation of our start index into font_Data[] we iterate
now over font_Char_Sizes[] from font_First_Char upto ASCII_code -1 and
accumulate all sizes. After we mulptiply it with font_Byte_Padding and
we have our index computed.
5.) the font_Data[].
Load the font_RLE[] Table into an array with 4 entries, the first entry
must be initialized with 1.
This Table contains now a Run Length of Pixels to be painted in one
Color.
As example a 4 color Font. We need 2 Bits to indentify the color in our
Datastream. After this 2 bits we store 2 Bits of RLE Code, that is a
index into our RLE Table. Load from the color index the real color from
glcd_Colors[]. Load from RLE Code from RLE_Table[] the count of pixels
to be painted in this color. Paint again from left outer Columns to
right outer from top line to bottom.
In our example one pixel need in worst case 4 Bits in our stream. 2 bits
color index and 2 bits RLE Table index. In best case, depended on RLE
Table[1..3] we need 2 Bits color index and 2 bits RLE index, but we
paint as example 13 Pixels in this color sequientialy, because in RLE
Table[2] was saved 13.
If our RLE Table would be {1,2,5,13} and we have sequientialy to paint
20 pixels in same color then our stream contains exactly 12 Bits. 2 Bits
color + 2 bits RLE index = 3 -> 13 Pixel, then 2 bits again same color
index, 2 Bits RLE Index = 2 -> 5 Pixel, then 2 bits same colorindex and
2 bits RLE Table Index = 1 -> 2 Pixel.
The compression function in my Font Editor tries out now all possible
combinations of this 4 entray RLE Table compared to the existing font
datas to find the one solution wich would be need the smallest count of
these chunks.
It was a conceptionaly descision of me to use smalles memory
requierements as possible wit compact design and not to many expensive
computation overhead on small MCUs.
Best Regards, Hagen
sorry some errors ;)
On compressed font a chunk contains
2 Bits RLE Index
x Bits Color Index, where X == font_Bits_Per_Pixel.
The order is reversed to my last post ;)
1
bitsmul=pgm_read_byte(&powerof2[bitscount&0x07]);
2
if(bitscount<8){
3
bitscount+=8;
4
bits|=pgm_read_byte_inc(data)*bitsmul;// faster as shifting
5
}
6
pixelcount=1;
7
do{
8
i=FontHeight;
9
do{
10
if(!(--pixelcount)){
11
pixelcount++;
12
if(flags&0x80){// compresed Font ??
13
pixelcount=rle[bits&0x03];
14
bits>>=2;
15
bitscount-=2;
16
}
17
bitscount-=bitspixel;
18
bitsmul=pgm_read_byte(&powerof2[bitscount&0x07]);
19
color=colors[bits&bitsmask];
20
bits>>=bitspixel;
21
}
22
GLCD_WAIT();
23
GLCD_OUT(H8(color));
24
if(bitscount<8){// read in advance while we wait for SPI
25
bitscount+=8;
26
bits|=pgm_read_byte_inc(data)*bitsmul;// faster as shifting
27
}
28
GLCD_WAIT();
29
GLCD_OUT(L8(color));
30
}while(--i);
31
}while(--charwidth);
Here the inner most source cut of my S65 lib font routine (you can mail
me iff you want to get the source).
Bits is our databuffer that is repeately filled from font_Data[]. We
append these new datas read on most significant side and then right
shift out these bits such as needed.
First we eaxtract on compressed fonts the lower most to bits to get the
index in our Run Length Table. From this we load our PixelCount
variable. On uncompressed fonts we do this not, instead set PixelCount
to 1.
After this we shift right the Bits variable 2 bits. BitCount Variable
stores the count of valid bits in Bits this we have to decrement it by
2.
Then we load our color index into glcd_Colors[] array. Dependend on
font_Bits_Per_Pixel we have to and mask Bits to get the index. After we
shift right again variable Bits.
Now we have Color and the PixelCount to be set in this color examined,
we paint it.
Variable BitsMul is a special thing for MCU that supports fast
multiplication. On ATMega MCU as example we can shift left (one byte
shifted into a word) faster by a multiplication as with ordinary shift
opcodes.
Logical, above source can be only used on compressed fonts with maximal
2^6 colors, otherwise our 16bit Bits databuffer can be underflow. It can
be easily rewritten when we expand variable Bits to 24 or 32 Bits width
and if we check that always more as 2 + font_Bits_per_Pixel Bits are
valid. One 256 colors fonts that are 2 + 8 + 8 = 18 bits maximal width
for variable Bits.
Best Regards, Hagen
Hagen Re wrote:
> Yes i can help you ;)
Thank you very much for an explanation!
I`ve got it :)
I`am just interesting, is there is a way to stop LCD controller from
screen refreshing while data write is in progress?
It is better to see the whole picture at once, than observe appearance
of each pixel...
There must be some synchronization between the data transfer and actual
picture change, because the screen updates momentarily when LCD is in
the phone.
Any ideas?
Not to my knownledge. You cant stop the refreshing of the LCD, thats
transparently done in background without affecting our communication
trough SPI with it. Thus phone MCU done only one thing better as our
lame small MCU, they SPI works most realy faster.
On my S65 Library i worked with 8 Mhz SPI and my bitmap drawing
functions get mostly the full troughput on decoding/decompression while
SPI sends data. I get about 16 frames per second. But as example the S65
LCD could be driven with 27 Mhz SPI instead of lame 8 Mhz. Of course
with hardware SPI and not with some bit banging soft SPI ;) Thus i
have'nt any problems to see "apperance of each pixel", even'nt with
slower functions as with my font drawing functions (they are even more
complex stuff in software, you known;). Currently i have the feeling
that my lame 16 Mhz ATMega128 is on drawing a complex menu system faster
as some commercial phones.
And we must strongly differentiate between the phone displays. Newer one
use far more faster communications.
Best Regards Hagen
The mobile phone uses a copy of the display ram (shadow). The phone-µC
itself writes only (very fast) to the shadow that is connected the µC
bus. The shadow is copied after µC request (or automatically for video
and camera) to the display by hardware. Therefor you can not see the
display content build up pixel by pixel. The SPI clock frequency is
13MHz -> 29ms is the shortest screen refresh period (>30 frames/sec).
The copy-hardware and shadow function is part of the grafik controller
chip in the phone. The grafik controller chip also takes care about
camera functions.
If you think about the 46kByte you need for display shadow that is not
suitable for small µC systems....
Thanks for the answers :)
I did not mean really that I see how each pixel is changing during data
write.
I`am talking about Vertical Synchronization.
I communicate with the display (LS020) through 12 MHz SPI of my AT91SAM7ARM controller. The whole screen transfer takes about 31,6 ms. Almost as
in the phone.
>The SPI clock frequency is 13MHz -> 29ms is the shortest screen refresh period
(>30 frames/sec).
Yes, but the screen refresh (most likely) is twice as high. And display
contents will be scanned and updated twice while data is fully
transferred.
And this is the cause of so called "tearings" (I do`nt know how to name
it exactly in english...).
>Therefor you can not see the display content build up pixel by pixel.
But, without vertical sync, its easy to see (during full screen data
write - 31,6 ms) that the screen updates not at once.
In order to avoid this "tearings", the only high speed SPI is not
enough.
There must be such a synchronization, and the phone does it somehow. But
how?
At least, 12 MHz did not helps. I can try higher - up to 24 MHz with my
controller. If the LCD can operate at that frequency, of course...
Ok i understand now.
First on LCD there exists no Vertical Synchronization, there exists no
vertical retrace like in CRT monitors ;)
But the LPHxxxx Display as Example supports a interlaced frame cycle
control -> interlaced drive and high speed Burst RAM Write.
1.) HWM mode: we send 4 pixel and first after this the display put it
into GRAM. This avoid jitter.
2.) interlaced drive: prevent flicker and is what you want. Read the
HD66733R Datensheet on page 103.
On my experiments with my S65 library on LPHxxx displays i played around
this interlaced drive control. Yes it avoid flicker but reduce
remarkable the display quality if we display as example a large gray
background and in the middle a sharp square. Then we see shaddow effects
on the remaining gray area. Thats why i don't use it. I think it's only
usefull when we display fast animations but never usefull for static
displaying on menu sytems, graphics etc.pp.
Best Regards Hagen
>First on LCD there exists no Vertical Synchronization, there exists no>vertical retrace like in CRT monitors ;)
Maybe, but image building mechanisms are the same: 60 frames per second,
"beam" goes from topmost row down to bottom. 176 rows each of 132
pixels.
I`ve attached the image with explanations of these "tearings" (or
flicker) I`am trying to avoid:
http://www.sonycman.newmail.ru/LCD_Image_building.zip
LCD display refresh frequency is 60 Hz and the SPI speed is 12 MHz (30
frames per second).
Does my LS020 (LR38826) is in any way compatible with HD66733
controller?
Best regards,
Vladimir
not compatible but very probable supports the controller same mechanism
as the HD66733. But we don't know because we have'nt the original
datasheet. Thats why i choose only the LPHxxxx displays.
I will try on my LPHxxxx display your example.
>Maybe, but image building mechanisms are the same: 60 frames per second,>"beam" goes from topmost row down to bottom. 176 rows each of 132>pixels.
Even not. Dependend on the LCD and the mounting the AC Drive of the
scanlines can be any order. Mybe topdown or bottomup, mybe first top
half in topdown and second half bottomup or even interlaced, lines by
lines interleaved with upto 4 frames needed to display the full image
one times or even pixel chunks interleaved. There exists many different
drive controls compared to a common CRT monitor wich have a vertical
retrace cycle, very long time to put in hidden the next image.
Best regards, Hagen
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.
Found some datasheet for LS020 LCD module.
It seems (see attachment) that two its interface pins - CS and RS - are
bidirectional (input/output).
Interesting, what kind of data they can provide?
Hello, Hagen Reddmann.
I`ve just finished writing basic routines for the text printing...
Thanks again :)
My next step will be into displaying the images converted by your
S65-bitmap converter.
Would you be so kind to reveal to me structure of its output files?
RLE compression is used, I presume?
PS: What do you think about using GIF or PNG compressors? 256 colors
will be enough for most cases...
Yes i give you ;)
Last thing as first:
My compression is better as PNG !? ;) Yes, i thought it can't never so
good as PNG or GIF but i compared the resulting filesizes, and get this
result. Maybe, my assumption is that we use relatively small images
compared to common use in GIF and/or PNG. The overhead for such small
files in headers are bigger in ratio to the complete image in these
formats. My headers are very small and my compression is realy primitve
and straightforward.
And thats the more important thing, then we need a easy dataformat,
instead of a complex LZW/LZH compressed GIF or much more complex PNG
dataformat. PNG especialy supports much more different encoding
schematas with larger need on memory or processor resources. Both are
good for big PCs or fast ARMs but for my tiny ATMega i'am faster to my
goal with a own format. I considered it at first but i was much faster
with my own solution. As Example the Delphi program to convert, mirror,
scale down, import and compress the images was done in about five hours.
One hour later i finished my glcdDrawBitmap() (without optimization). I
think in this shirt time i could'nt understand the PNG dataformat alone.
That i get as side effect a better compression had me let wonder.
The argument "we need most times only 256 color images" was a "no no"
for me. No, i need most times even images with far more colors,
otherwise i could pay a lame monochrome LCD with fixed 2 lines in one
font charset. Instead i payed for a 2^16 smart color display and even
want to display colorfull images ;)
Ok the file format:
There exists 4 different formats:
1.) unichrome images, thats nothing others as a rectangle filled in one
color. The header looks like
1
structbitmap{
2
uint8_tWidth;
3
uint8_tHeight;
4
uint8_tBits_Per_Pixel;
5
uint16_tBkColor;
6
}
- Width in Pixels
- Height in Pixels
- Bits per Pixel, color depth == 0
- backgroundcolor
Paint a rectangle in given Width and Height relative to the coordinates
X,Y filled with BkColor.
2.) full color images, each pixel is 16 Bit
1
structbitmap{
2
uint8_tWidth;
3
uint8_tHeight;
4
uint8_tBits_Per_Pixel;
5
uint16_tBkColor;
6
uint16_tPixels[Width*Height-1];
7
}
- width, height see above
- Bits per Pixel == 16
- Color, first left top Pixel color, most used as transparency color. If
my glcdDrawBitmap() routine should paint this bitmap transparent then
this color, eg. the top left pixel, marks this transparent color. In the
LPHxxxx Display we can setup a special graphics raster operation that
filter out all data sends with this color. Thus would'nt paint this
pixels.
- Pixels[] the remaining pixel
Ah, i forgot, the Pixel data is line by line from left to right, eg. the
natural order.
Calculate PixelCount = Width * Height, setup the first Pixel in BkColor
the remaining PixelCount -1 Pixel read as 16Bit from Data[].
3.) monochrome image, eg. 2 colors. This image format use real RLE
compression but in a litte differnt format, especialy optimized for AVR
processors.
1
structbitmap{
2
uint8_tWidth;
3
uint8_tHeight;
4
unit8_tBits_Per_Pixel;
5
uint16_tBkColor;
6
uint16_tFgColor;
7
uint8_tData[];
8
}
- Width, Height hm se above ;)
- Bits per Pixel == 1
- BkColor left top most pixel
- FgColor the second color used in monochrome images
Because BkColor contains the first top left Pixel our compressed Data[]
have already one information that we do'nt need to encode at first.
Read 1 Byte from Data[] ->
Buffer = *Data++;
PixelBits = ((Buffer >> 4) +1) << 2;
Buffer &= 0x0F;
Buffer |= Buffer << 4;
We have read one RLE Code Byte. In the Low Nibble we have encoded a 4
Bit Pixel Mask. As Example 0011b means: set 2 Pixel in BkColor and set 2
Pixel in FgColor. In the High Nibble we have encoded the repeat count of
such a 4 Pixel sequence. Iff we have 0000b in High Nibble then we must
repeat one times the 4 Bit encoded sequence. Because my loop decrement
the PixelBits on every pixel we have thus to compute PixelBits =
((Buffer >> 4) +1) * 4; to get the real pixel count to setup. Now we
fillup Buffer in the high nibble with its context form low nibble, eg.
we ecpand our sequence from 4 Bit to 8 bit. Thats easy on AVR because
they have a SWAP Instruction for nibbles. In our inner loop we set now
Width*Height pixels, rotate Buffer one Bit left -> ROL(), check if
lowest Bit is TRUE and select FgColor as Pixelcolor otehrwise FgColor.
After we have setup PixelBits Pixel we must read the next RLE Code Byte.
Decode it such as above and repeat.
4.) 3 upto 2^15 Color Bitmaps. Thats the most complex format, not realy
;)
1
structbitmap{
2
uint8_tWidth;
3
uint8_tHeight;
4
uint8_tBits_Per_Pixel;
5
uint16_tBkColor;
6
uint16_tColor_Table_Size;
7
uint16_tColor_Table[Color_Table_Size/2];
8
uint8_tData[];
9
}
- Bits_Per_Pixel between 2 upto 15
- BkColor see above
- Color_Table_Size, size in BYTES of following Color Table, with this
member we could easy skip to member Data[] (our pointers).
- Color Table, contains sorted all used colors in the image, the next
higher power of 2 of they count defines Bits_Per_Pixel.
Now Data[] contains a Bit Stream. So far as we read a 0 Bit we paint a
Pixel in the current active Color. That is on startup logical BkColor.
When we read a 1 Bit we get a new color. Then read Bits_Per_Pixel Bits
from Data[] as Index into our Color_Table[]. Load the new Color from it,
and paint one Pixel in this new color. Then again read from Data[] all 0
Bits and set a pixel in this color until we have Width*Height Pixels set
or we read a 1 Bit from Data[], the next color index into Color Table.
The Bits in Data[] are right justified, thus you load one Byte from
Data[] and right shift out Bit by Bit.
Best Regards, Hagen
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?
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
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
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!
ist das Bitmap als PROGMEM_UPPER deklariert und hast du die Section im
MakeFile ? Schau dir mal mein Drum Projekt Source + MakeFile an.
Falls du die Bitmaps nicht in einer eigenen FLASH Section speichern
möchtest, dann gehe in glcdDrawBitmap() und entferne das Makro
SET_RAMZ(1) oder setze es auf 0.
Ich habe das gemacht weil ich in meinem ATMega128-Drum-Projekt mit den
großen Bitmaps auf Probleme mit dem Compiler stieß, er wollte es nicht
mehr kompilieren. Zudem spare ich mir so die ständige Berechnung einer
24 Bit Adresse ins FLASH -> RAMPZ:ZH:ZL -> bei jedem Zugriff um nur 1
Byte aus dem FLASH zu laden. Also: Section textupper ins Makefile die
zb. an Addresse 0x11000 beginnt. Alle Bitmaps als PROGMEM_UPPER ->
textupper -> deklarieren, und fertig. Vorteil: andere FLASH Konstanten,
wie aufwändiges Menusystem, Fonts usw. liegen gemeinsam mit dem Code am
Anfang des FLASHs. Am Ende liegen nur die großen Bitmaps.
Gruß Hagen
beim Text hast du vorher
1.) einen Font eingebunden ?
2.) glcdSelectFont(dein_font) aufgerufen ?
3.) in glcd.Colors[0..3] die Farben gesetzt ?
Gruß Hagen
Hallo 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:
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
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
--------
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?
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
Hallo,
ich habe heute mal mich etwas mehr mit dem LCD auseinander gesetzt, und
mus sagen WOW.
Ich habs hinbekommen mit knapp 50MHz SPI Clock anzusprechen.
Controller ist der SAM7.
Nun setz ich mich ersteinmal an das Thema FONTs etc mal sehn, was raus
kommt.
Das Programm von Mike Bird befindet sich hier und heisst
BMPConvert16.zip
da der Link oben tot ist findet man es hier:
http://home.arcor.de/dirk.milewski/seite72.html
für unsere BASCOM und Assembler Freunde.
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
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
ich habe mal eine frage: das datenblatt des controllers ist doch
inzwischen bekannt oder?
Dann müsste die powerdown sequenz doch auch bekannt sein oder?
Weil ich verwende das LS020xxx Display und zu diesem steht in dem PDF
bei powerdown nix dabei außer halt de reset methode...
Es wurden ja 2 Datenblatter reingestellt, beide von Hitachi, sind das
überhaupt die Controller für die LS020xxx Displays oder gilt das nur für
die anderen Typen?
MFG
luxx
hallo an alle,
ich schliesse mich mal fragend an luxx beitrag an: wie steht es um das
LS020- gibt es eine spec dafuer? koennte die mal jemand posten oder per
mail verteilen?
gruss dudu
Hallo,
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
1
SPI_SEND:
2
sbi SPCR,SPE ;enable SPI
3
out SPDR,r24 ;load byte in SPI data register
4
SPI_SEND_0:
5
sbis SPSR,SPIF
zu
1
SPI_SEND:
2
push r30 ;!!!
3
in r30, SPCR
4
sbr r30, SPE
5
out SPCR, r30
6
7
out SPDR,r24 ;load byte in SPI data register
8
SPI_SEND_0:
9
in r30, SPSR
10
sbrs r30,SPIF
11
..
12
pop r30 ;!!!
13
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
Hallo,
diese Register kannst du nur über den SRAM ansprehen, wenn diese zu hoch
liegen.
Ich mein das war mit ST - Store Indirect From Register to data space
using Index X
Gruss Jens
Hallo,
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?
Hallo,
kaum hat man das LS20.... zum laufen gekriegt,
fangen die Probleme schon an.
Ich will meine Hintergrundfarbe prog.
Leider habe ich vergeblich versucht eine 16 Bit Farbtabelle
zu finden. 24 Bit ist an jeder "Ecke" zu haben.
Oder anders: der Hintergrund soll zum Display meines Yaesu Tranceiver
passen.Wäre Rotbraun oder so.
Mit probieren habe ich es schon stundenlang versucht.
Hat jemand da was parat?
Dank für Eure Hilfe.
Wigbert
Hallo,
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..
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
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
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)
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
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).
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.
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
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.
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!!!!!
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
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"
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
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...
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.
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.
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.
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?
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
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?
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.
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(martinheintze@msn.com).
bin grad echt etwas frustriert.... viele dank schon mal...und geniale
arbeit soweit !!
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
Hallo everyone
Hopefully you don't mind that this post is in English (can't write
German just a little understanding because I speak Dutch and English).
I tried the last getting a Siemens S65 display to work... After one
week, I finally get 'random noise (all pixels light up in a different
color'.
Can someone help me with that? Or does someone has the correct init
codes, maybe a simple example program wich turns on some pixel(s) or
draw a char?
I'm using the Arduino NG Board (http://www.arduino.cc) en the
environment (Arduino-0008) which is basically AVR-GCC with a bootloader.
I do also have a blog at http://www.arduinoprojects.blogspot.com where
you can read mij 'experience' ;-)
I hope someone of you can help me or get this project running.
Thanks a lot in advance!
Andy
Hallo,
ich hatte schon vor längerer Zeit ein LS020 mit den Routinen von
Christian zum Laufen gebracht. Als einzige Änderung hatte ich auf
Soft-SPI umgestellt und alles lief auf Anhieb auf einem mega8
(mittlerweile: mega168).
Danach hatte ich vom gleichen ebay-Handler zwei L2F50 Displays bekommen,
die ich im Moment versuche, zum Laufen zu bringen. Ich verwende einen
mega168.
Meine Versuche:
1. simple-code von Christian, Pins angepaßt und mein Soft-SPI (der beim
LS020 funktionierte)
Ergebnis: nix!
2. simple-code von Christian, Pins angepaßt mit original Hard-SPI
Ergebnis: nix!
3. Version 1. aber RS-Signal gedreht (wie bei LS020)
Ergebnis: Wenn in der init-sequenz lcd_wrcmd(DISON); kommt, dann
schaltet das Display ein und man sieht Zufallswerte/Rauschen, aber
danach funktionieren keine weiteren Kommandos, wie DISOFF,DISINVERT etc.
Wenn ich dann ein fill_screen() mit allen möglichen Farben durchtickere,
dann wird das Display zwischendurch mal ganz oder teilweise weiß.
Hat jemand eine Idee?
Ich werde meinen Test-Code mal entrümpeln und anhängen. Ist im Moment
für Außenstehende unlesbar (wie üblich bei mir, wenn ich zu lange an
etwas rumteste...)!
Gruß,
Matthias
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
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!
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?
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
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! :)
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..
> 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
@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.
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.
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
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
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?
@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)
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.
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.
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.
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
Wenn du das nur n paar mal privat (also nicht in serie) bauen willst
kannst du einfach mal deine controller durchtesten, mein mega16 macht
bei 2,9V noch volle 16MHz. Wenn man in Serie baut, kann man sich dadrauf
natürlich nicht mehr so verlassen ;)
Hallo,
ich habe das S65 vor einigen Tagen mit der einfachen Testsoftware auf
von CK zum laufen gebracht. Läuft alles prima und problemlos, bisher tut
es das was ich will. Da das Display nacher einmal mehr ausgeben soll als
nur ein bisschen Text und nen bunten Hintergrund und ich keine Zeit habe
eigene Routinen zu entwickeln wollte ich nun die
GLCD-Lib einbinden um auch komplexere Dinge auf den Bildschirm zu
bringen.
Mit der Installation von Bibliotheken habe ich keine große Erfahrung,
und so erschließt sich mir auch nach mehrmaligem lesen der
Installationsanleitung nicht, wie genau ich die Bibliothek installieren
soll. Vor allem finde ich bei mir keine compile.bat. Ausserdem entstehen
bei mir beim Entzippen andere Ordner als in der Installation angegeben.
Könnte mir jemand kurz erlären wie genau ich die Bibliothek einbinde ?
Ich nutze AvrStudio 4.13 SP2 in Verbindung mit Winavr-20070525.
Netten Gruß,
Marc
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.
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 ?
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:
Auf stderr werden Informationen ausgegeben und auf stdout wird das
umgewandelte Bild ausgegeben, dass in die Code (include file) bepipt
werden kann.
Hier noch ein mini Demoprogramm:
1
#include"s65.h"
2
3
[...]
4
5
S65_Init();
6
7
S65_Fillscreen(S65_RGB(0,255,0));
8
S65_Dawpic(10,40,(void*)pic,0);
Vielleicht kann es ja wer gebrauchen...
So Far
Jürgen
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 ^^
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
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 :-)
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 ^^
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...
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
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
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
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)
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
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))
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..
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 !
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
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 ?
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?
@ 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
@ 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.
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
@ 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
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)
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
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.
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ß, €
@ 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
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.
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
@ 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
@ 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
@ 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
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
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
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....
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
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
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)
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
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
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
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 ^^
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
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 ^^
@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
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
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 ?
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
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
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.
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.
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
@ 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:>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
@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.
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:
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
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_tw=pgm_read_byte(bitmap++);// lese Breite in Pixeln
9
if(!(w))return;// wenn Breite == 0 exit
10
uint8_th=pgm_read_byte(bitmap++);// lese Höhe in Pixeln
11
if(!(h))return;// wenn Höhe == 0 exit
12
uint8_tbpp=pgm_read_byte(bitmap++);// lese Farbauflösung in Bits per Pixel
13
uint16_tbkcolor=pgm_read_word(bitmap);bitmap+=2;// Hintergrundfarbe lesen, entspricht Pixelfarbe in linker oberer Ecke des Bildes
14
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
15
if(bpp==0){
16
// Bitmap ist ein einfarbig gefülltes Rechteck
17
glcdFillRect(x,y,x+w-1,y+h-1,bkcolor);
18
return;
19
}
20
GLCD_CS_ON();// CS vom Display ON
21
GLCD_SETADDR(x,y);// Pixeladdresse im Display setzen
22
GLCD_WINDOW(x,y,x+w-1,y+h-1);// Window im Display setzen,
23
// Modus muß sein das X-Koordinate inkrementiert wird und bei Überlauf
24
// innerhalb des Windows die Y-Koordinate inkrementiert wird
25
if(flags&GLCD_BMP_TRANSPARENT){
26
GLCD_SETMODE(0x38|GLCD_ROP_WNE);// Transparenter Modus setzen
27
GLCD_SETCOMPARE(bkcolor);
28
}else{
29
GLCD_SETMODE(0x38);
30
}
31
GLCD_STARTDATA();// als nächstes kommen Pixeldaten übers SPI
32
if(bpp==1){
33
// monochrome Bitmap
34
uint16_tpixelcount=w*h;// Anzahl der Pixel im Bitmap
bitmap+=colortablesize;// Farbtabelle überspringen, auf Pixeldaten positionieren
81
uint16_tcolormask=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.
82
uint32_tdata=0;
83
uint8_tdatabits=0;// enthält die Anzahl der Pixelbits
84
uint8_tbitsmul=1;// statt Shifts mißbrauchen wir den MUL Befehl, ist effizienter auf ATMegas als Shifts von 16Bit.
85
uint16_tpixelcount=w*h;
86
do{
87
GLCD_WAIT();
88
GLCD_OUT(H8(bkcolor));
89
pixelcount--;
90
while(databits<16){
91
// solange weniger als 16 Bits in Data befüllt sind neue Daten vom FLASH holen
92
uint16_tt=pgm_read_byte(bitmap++)*bitsmul;// links shift per MUL
93
if(databits>=8)data|=(uint32_t)t<<8;
94
elsedata|=t;
95
databits+=8;
96
}
97
98
GLCD_WAIT();
99
GLCD_OUT(L8(bkcolor));
100
101
if(data&0x01){
102
// wenn unterstest Bit in Data = 1 dann folgt in Data ein Index auf die Farbtabelle mit neuer Pixelfarbe
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.
1
ROL(data);
2
color=bkcolor;
3
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
@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
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
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 ?
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
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.
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 :)