The Siemens S65 132x176, 65536 color display with AVR

[Matthias Dehof (Gast)]

Hallo auch,

erst mal "vielen Dank" an Christian für seine Arbeit.

Ich habe mir ein S65-Display besorgt (habe eines mit dem EPSON L2F50
Controller erwischt) und habe den L2F50_display4_V02 Code auf meinen
Arm7 (UNC20) portiert. Mein Code ist soweit identisch, ausser dass ich
nach dem fill_screen() nur "hello world" anzeige.

Ich beobachte ein seltsames Verhalten: das Display initialisiert
korrekt, der Hintergrund wechselt auf grün und der Text (Schwarze
Schrift vor weissem Hintergrund) wird angezeigt, dann nach geschätzten
200-400 ms scheint der grüner Hintergrund von oben nach unten über den
Text zu laufen und kurz darauf wird wieder alles weiß

Nachdem der Text kurz angezeigt wird, scheine ich ja das meiste richtig
zu machen. Ich habe schon alles mögliche probiert, aber mir gehen die
Ideen aus. Hat noch jemand einen Vorschlag ?

Anmerkung: der UNC20 hat keinen SPI, ich takte jeweils 8 Datenbits mit
einem Clock ins Display - und, wie gesagt, nachdem der Text kurz
erscheint, scheint das ja auch zu passen.

Wie ist das: muss man das Display ständig refreshen, oder sollte nicht
einfach der letzte Text stehen bleiben ?

Nochwas, wenn ich mein Programm starte und "TEST" anzeige, dann kommt
auch "TEST" im Display, wenn ich nun den Text auf "HALLO" ändere,
kommt beim nächsten Start nochmal "TEST" und erst beim wiederum
nächsten Start kommt "HALLO"

danke für eure Hilfe,
Matthias

[Matthias Dehof (Gast)]

...habs gefunden: ich hatte eine Diode verwendet um die 2.9V
zusammenzubasteln, damit brach offenbar die Versorgungsspannung immer
wieder kurz ein - seit ich alle Signale einfach komplett aus 3.3V
versorge läuft das Display.

Dann hatte ich noch am Ende meiner Routine ein "Select Display CS=1"
- damit kann man auch prima Unsinn machen. CS=0 und das Bild ist stabil
und bleibt stehen,

Matthias

[Bernd X. (mc-bernd)]

Hallo,
da ich die Programmiersprache C  nicht beherrsche, habe ich mit Hilfe
der Beschreibung von Christian Kranz ein Bascom- Programm für das
LS020XXX  geschrieben und damit das Display zum laufen gebracht. (Siehe
Bild)
Hier ein paar Punkte die mir beim Arbeiten aufgefallen sind:
1. Init: die 7 ms nach Init2 dürfen auch länger sein !
   (100 ms funktionieren bei mir auch !!!)
2 .Zwischen Init3 und Init4 darf ich kein delay einfügen !?
3. Locate(X,Y)  =  0x6YS, 0x7XS
4. PMEMWRX: (X-direction)  =  X mit Y vertauscht!
                            Arbeitet bei mir so richtig;
                            0xEF90,  0x0504,  0x08Y1,  0x09Y2,
                            0x0AX1,  0x0BX2

5. Pin 1V8 hat bei mir den Anschein als ob es NC ist !!!  (not
connected) (bin aber nicht absolut sicher !) Kann auch keinen Strom
messen.

Seltsames:
- Wenn ich eine blaue Linie oder Box zeichne werden die anderen
  Farben merklich blasser, nachdem das Zeichnen beendet ist.
  Zeichne ich danach z.B.  eine schwarze Linie  sind die Farben
  wieder kräftiger.

- Der Kontrast ist bei senkrechter Betrachtung schlechter als wenn
  ich etwas von Rechts auf das Display schaue !
  (Direction: Lange Seite Unten)
  Ist dies bei euren Displays auch so ?

Frage:
- Ich habe gelesen, dass das L2F50.... bei einigen auch
  funktioniert.
  Kann aber keine Beschreibung der Steuerparameter finden.
  Könnte jemand die bekannten Steuer Befehle für das L2F50...
  senden ?

[SuperUser (Gast)]

Hallo Bernd,

sieht ja sehr gut aus.

* Das mit den nicht-konstanten Farben habe ich nicht beobachtet. Bei
mir sind die Farben konstant.

* Beim LS020 ist der 1.8V tatsächlich not connected

* Wegen X/Y Vertauschung: Beziehst du dich auf das Bild auf der
Web-Seite?

* Für das L2F50 kannst du dir die Init-Sequenzen ebenfalls von
superkranz runterladen (in C). Allerdings gibt es keine so detailierte
Beschreibung wie für das LS020...

[Bernd X. (mc-bernd)]

Hallo SuperUser,

* Wegen X/Y Vertauschung: Beziehst du dich auf das Bild auf der
Web-Seite? ...
-> Ja Direction Lange Seite unten. (0x0504)

* Für das L2F50 kannst du dir die Init-Sequenzen ebenfalls von
superkranz runterladen (in C). Allerdings gibt es keine so detailierte
Beschreibung wie für das LS020...
-> Problem ist nur, dass  mir C sehr suspect ist!!!
(Programiere in Turbo-Pascal, Nili-Pascal, Delphi, etwas Assembler und
Basic, aber C liegt mir absolut nicht!)
Bräuchte die Befehle und das Init hald extrahiert!
Für jemand der C versteht sollte dies doch mit wenig Aufwand möglich
sein...

Gruß Bernd

[Mike Bird (Gast)]

Hallo Bernd,

magst Du eventuell Deinen Bascom Code auch mal mit anhaengen?
Es waere schon sehr interessant, wie Du dies geloest hast.
Und vor allem, nutzt Du die SPI Unterstuetzung vom Bascom selbst?

Gruss Mike

[Bernd X. (mc-bernd)]

@Mike

Hallo Mike,
nein SPI bei Bascom hab ich mal kurz versucht funktionierte bei mir
aber nicht.
Ich verwende den ShiftOut Befehl.

Hier ein Beispiel:
*********************************************************
Rs Alias PortD.3          'Register Select (Command/Data)
Cs Alias PortD.2
Sclk Alias PortD.1
Sdata Alias PortD.0
LCDReset Alias PortD.5

Const Kommando = 1
Const Parameter = 0

Dim Ausgabe As Word

'---------------------------------------------------
'--- LCD_Send = Send Data to Display        --------
'---------------------------------------------------
LCD_Send:
  CS = 0
  Shiftout Sdata , Sclk , Ausgabe , 0                       'Msbl
  CS = 1
Return
'--------------------------------------------------------

'--------------------------------------------------------
'-- PSet = Set Pixel(X,Y,Color)                  --------
'--------------------------------------------------------
Sub PSet(byval Lx1 As Byte , Ly1 As Byte , Color As Word)
   Rs = Kommando
   '------- Locate ------
   Ausgabe = &H0600 + LY1                                   'Y
   Gosub Lcd_send
   Ausgabe = &H0700 + LX1                                   'X
   Gosub Lcd_send
   '---------------------
   Rs = Parameter
   CS = 0
   Shiftout Sdata , Sclk , Color , 0                        'Msbl
   CS = 1
End Sub
'-----------------------------------------------------------

'ENDE ENDE ENDE
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


Nun noch eine Frage an alle die C- können.....
Ich versuche gerade ASM-Routinen in Bascom mit einzubinden und dann
noch mal den SPI-Anschluß zu testen.
Probleme machen mir aber die C-Teile im ASM Code !!!

    ; setup serial data interface
    ; select clock phase positive going in middle of data
    ; master mode
    ; enable SPI
    ; speed is CPUclock/2

    ldi     r24,(1<<MSTR) | (1<<SPE); | (1<<SPR0);  ; Master Mode,

*** Welcher Wert wird hier in R24 geladen ?


    Enable SPI, fCPU/16 clock

*** Wie wird das in ASM umgesetzt ?

Vielleicht kann das ja jemand beantworten......

Gruß
Bernd

[Kay (Gast)]

Hallo Bernd,

ich habe auch schon versucht, dieses Display mit Bascom anzusteuern.
hat aber leider nie geklappt. dein beispiel funktioniert. Haste vor,
das ganze noch zu erweitern, also z.B. Text darstellen, bilder anzeigen
usw. ?

mfg Kay

[Kay (Gast)]

hi ich nochmal,

also nicht dein Beispiel ( Bernd ) funktioniert, sondern das von
MartinK. Wäre es möglich, mal deinen funktionsfähigen Beispielcode per
email zu erhalten ?

mfg Kay

[Daniel L. (bucho)]

Hallo!

Im PDF und hier im Thread steht, daß als Spannungsregler ein
IRU1205CLTR in Frage kommt. Hat ihr einen justierbaren genommen und auf
2,9V eingestellt, oder die Fetsspannungsversion mit 2,8V gewählt?

Gruß
         Daniel

[MC-Bernd (Gast)]

Hallo,

ich habe einen LM317 L genommen.
Mit R2= 330 Ohm und R1= 240 Ohm kommt man auf 2,9 Volt.

Gruß
Bernd

[André K. (andre-)]

Die Shiftout Funktion von Bascom ist fuer dieses Display leider nicht
wirklich geeignet. Man hat mit einem AVR so schon zu knabbern, eine
brauchbare Geschwindigkeit hinzubekommen und macht sich mit dieser
Funktion alles kaputt (am besten einfach mal den Disassemler
drueberjagen, dann sieht man, was ich meine).


Ich hatte eine Erstatzfunktion geschrieben, die nur das noetigste
enthielt, aber die scheint mir beim Umstieg auf HW-SPI leider verloren
gegangen zu sein. Also hier noch einige Schnipsel fuer Bascom bei
Benutzung des HW-SPI und eines LS020 Controllers (mehr moechte ich
ungern veroeffentlichen).

Es handelt sich um Schnipsel, nicht um kompletten Code. Wer etwas damit
anzufangen weiss, sollte aber dennoch klarkommen ;).

Die 3 Init-Sequenzen wurden in eine Einzige verpackt, die Aufteilung
erfolgt durch das Programm selbst (platzsparender).

Besten Dank uebrigens noch an alle, die die Benutzung dieser Displays
ueberhaupt ermoeglicht haben :).

Beste Gruesse,
André

[André K. (andre-)]

den DisassemBler meinte ich natuerlich :)

[Avr N. (avrnix)]

@Andre K:
Ich probiere gerade aus was deine Routinen bringen. habe bei der
Compilierung folegenden unklaren Fehler gefunden:


Getinitbytes:
   !nextbyte3:
   lpm r26, z+
   lpm r27, z+

   sts {a+1}, r27
   Sts {a} , R26
Shout
   subi r20,1
   sbis sreg,sreg_z   <-- ? Was für ein Wert?
   rjmp nextbyte3
ret


bei sreg_z bekomme ich ne Fehlermeldung, was muss da eigentlich
stehen.

Error :illigal Character - wie ist sreg_z declariert?
Ich bin mal gespannt wie deine Routine Funktionieren werden :-)

Grüsse

[André K. (andre-)]

Sreg_Z ist in m168.def als 1 definiert und bezeichnet das Zero-Flag in
Sreg. Bei anderen, aelteren regfiles steht das nicht drin, hast recht.
Sofern Z also Bit1 ist (wenn ich mich nicht irre, bei allen AVRs), dann
einfach 1 hinschreiben.

Beste Gruesse

[edisen (Gast)]

Hallo Leute,

Ich hab eine kleine Zwischenfrage.
Ich bin auf der Suche nach einem Datenblatt für das S55 Display
(LM15SGFNZ07 mit den Controller DJ360055). Da Ich beim Suchen schon
verzweifle (und da Ihr ja scheinbar alle das Datenblatt für das S65
gefunden habt), bitte Ich euch mir weiter zu helfen oder mich in ein
passendes Forum zu lotsen.
Ich habe 4 Stück dieser Displays bei mir und möchte Sie schnellst
möglich in ein Projekt integrieren. Falls mir jemand hilfreichen C-Code
zur Verfügung stellt bin ich auch sehr dankbar.

Mit der Bitte um hilfe, der Entschuldigung für den Themafremden Eintrag
und mit freundlichen Grüssen, edisen

[Avr N. (avrnix)]

@Andre K:

So habe deine Routinen mal ausprobiert , allerdings ohne erfolg :-(
Könntest du mal das Listing anschauen ob da noch was fehlt.

Das Display macht nichts, es sollte blau werden (CBlue)

ich arbeite mit einen ATMEGA16L mit 8MHz das Display LS020... wird
direkt angeschlossen.

[Avr N. (avrnix)]

Habe mit den Codeschnipsel von Martin K und Bernd_XXX
paar Routinen geschrieben, allerdings habe ich folgende Probleme:

1)
Buchstabe wird nicht an die Position gezeichnet und die
Hintergrundfarbe ist schwarz, obwohl eine andere angegeben wurde.

2)
Buchstaben werden mit grossen versatz geschrieben bzw garnicht.

3)
Und es wird nicht immer die Farbe ausgegeben die angegeben wurde.

Vielleicht habe ich da was übersehen?
Könntet Ihr mal schauen wo ein  fehler vorliegt,
bzw besser gemacht werden kann?

Hardware Mega16L Display L020.. direkt am A Port dran bei 2,9V.

thx.
AVRNix

[rotfuchs (Gast)]

Hallo! Bin Anfänger in Sachen Display-Ansteuerung. Was hat es mit den
Hexwerten auf sich, z.B. 0xEF00, muss dann die Bitfolge
1110111100000000 an einem Pin ausgegeben werden, oder wie?

Gruß, der Rotfuchs

[Avr N. (avrnix)]

Welche HEXwerte meinst du ? Die können Speicherstellen sein ( Display )
oder 16 Bit Farbwerte in RGB 5-6-5 format.
Die werden dann über SPI zum S65 übergeben.

[André K. (andre-)]

Hallo AVRNix,

ich kann keinen Fehler finden, das sollte so eigentlich funktionieren
(tuts zumindest auf meinem atmega168).

Schaltest du die Hintergrundbeleuchtung zeitig genug ein? Ich habe die
Erfahrung gemacht, dass sich das Display ohne diese Spannung manchmal
nicht initialisieren laesst.

Beste Gruesse

[rotfuchs (Gast)]

Hallo! meine die hier genannten init-Daten
http://www.superkranz.de/christian/S65_Display/DisplayProgramming.html

[Avr N. (avrnix)]

keine Ahung sind von Christian K. analysiert worden.
Da es kein datenblatt gab.

[Avr N. (avrnix)]

@Andre:

Wozu dienen die Routinen Defpartxyxyh und Defpartxyxy und welche
Parameter werden dort eingetragen?

Kann das sein das es ein Ausgabebereich def. wird?

[André K. (andre-)]

Hi,

genau. (x1;y1) =  linke untere ecke. (x2;y2) = obere ecke.

Mit defpartxyxy kannst du logischerweise beide eckpunkte des Rechtecks
angeben. Bei Defpartxwyh hingegen gibst du nur einen Eckpunkt, sowie
Hoehe und Breite des Rechtecks an. Man kann eigentlich einfach eines
ins andere umrechnen, aber ich habs eben getrennt gemacht. Hast du das
nun inzwischen ans Laufen bekommen?

Beste Gruesse,
André

[Avr N. (avrnix)]

nein - mache ich morgen, ich habe das Backlight direkt an einer anderen
Stromversorgung dran. Nur komisch das, das Display nicht anspringt :-(

Hast du mal mein Programm auf dem M168 laufen gelassen ?

bis dann

[rotfuchs (Gast)]

@AVRnix ist schon klar, dass er sie selber hinausgefunden hat. aber sind
das daten die über den Bus laufen, oder speicheradressen wo ich was
reinschreiben muss oder...? Weil da steht ja nicht was man mit diesen
Init-Daten machen muss die er "mitgeloggt" hat.

[SuperUser (Gast)]

rotfuchs: Die musst du über SPI an das Display schicken...

[Avr N. (avrnix)]

@Andre:

So habe es ausprobiert, nichts zu sehen auf dem Display.
Das Display bleibt mit Bunten Pixel und wird nicht Blau eingefärbt.

Hat es schon einer zum laufen gebracht und auf welchen Mega?

Habe es mit M16L und M32 probiert, nicht zusehen von der Blauen Farbe
schneit mit Hard-SPI nicht zu klappen :-(

[Kay (Gast)]

Hi AVR nix,

habe es auch mit Hardware SPI probiert. funktioniert bei mir auch
nicht.

mfg Kay

[André K. (andre-)]

Merkwuerdig, sollte bei den AtmegaX8ern irgendetwas anders sein, das ich
uebersehen habe? Bei mir laeuft es zumindest einwandfrei, getestet mit
12 LS020 Displays.

Beste Gruesse,
André

[Kay (Gast)]

also ich benutze nen mega16 mit 16Mhz. Mit Shiftout gehts, nur mit
hardware SPI nicht.

mfg Kay

[Avr N. (avrnix)]

@Kay: hast du die Hard SPI gegen Shiftout getauscht(Programm aus "S65
mit SPI" )?
kannst du dann mal das Programm posten?

[Kay (Gast)]

hi,

ich habe das Programm von MartinK benutzt. Es zeichnet bunte streifen
aufs display. Das programm gibts in diesem Thread ( in einem Link ).

mfg Kay

[MC-Bernd (Gast)]

@ Andre K.:
Hi Andre,
hast Du einen guten Lieferanten für die Displays ?
Habe gelesen, Du hast 12 Stück gtestet....
Ich habe bei Dreamcover ein neues Display bestellt und gebrauchte Ware
bekommen ! Diese Firma ist also nicht zu empfehlen.
Gruß Bernd

[Henning Sommerkamp (Gast)]

Hab mir auch eins bei dreamcover bestellt, vor 2,5 Wochen sofort
überwiesen. Heute erst angekommen. :( Und es ist auch gebraucht. Aber
bei dem Preis werd ichs wohl verschmerzen.

[André K. (andre-)]

Koennte bei Interesse evtl. neue anbieten. Bei Interesse Mail (27780 ätt
newdsl punkt de).

Warum mein Code nicht funktioniert, kann ich euch leider immer noch
nicht sagen. Ich kann keinen Fehler entdecken.

Beste Gruesse,
André

[Avr N. (avrnix)]

@Andre: wie hoch ist der (unter Option/Enviroment/Compilier) HWSTACK
SoftStack unf Framesize ?

Und hast du den Code mal auf einen M16 ausprobiert?

[André K. (andre-)]

AvrNix:
Stell einfach alles mal auf 60 (reicht dicke fuer so ziemlich alles
aus). Ich hab dort meist ueberall 40 drin.

Ich hab momentan leider nur Atmega88s und 168s hier, weil ich in
letzter Zeit nichts anderes verwendet hab.

Beste Gruesse,
André

[Avr N. (avrnix)]

@Klappt auch nicht :-(

Hat jemand mal das
http://www.mikrocontroller.net/attachment.php/420053/S65+mit+SPI.txt

ausprobiert?

Und was ist das ergebnis?

[André K. (andre-)]

Merkwuerdig. der einzige Unterschied zu meinem Aufbau duerfte darin
liegen, dass ich auch die LED-Spannung vom µC erzeugen lasse
(PWM+100µH+Transi), die ich eben vor der Init noch einschalte.
Ansonsten kann ich mir wirklich nur noch vorstellen, dass bei diesen
Atmegas beim HW-SPI irgendetwas anders laeuft (es wurden bei den *8 ja
einige Register umbenannt, evtl. greift der ASM-Teil nun auf die
falschen Register zu?! Muesste man mal ueberpruefen.

Beste Gruesse

[Daniel L. (bucho)]

Hallo alle zusammen!

Ich hab mal ne kleine Interfaceschaltung entwickelt, die ich demnächst
bauen werde. Die LED-Hintergrundbeleuchtung soll durch einen
LED-Treiber (gtaktete Stromquelle angesteuert werden). Nun die Frage:

Leuchten die LEDs sofort bei angeschlossener Spannung an den Pins, oder
muß man intern nochwas einschalten?

Wenns das der Fall ist, habe ich Bedenken, daß die Stromquelle bei
ausgeschalteter Hintergrundbeleuchtung eine zu hohe Spannung auf das
Display drückt und es dadurch einen Schaden geben könnte.

Gruß

[Daniel L. (bucho)]

Hehe und schon einen Fehler im Schaltplan entdeckt...

[Frank N. (z80)]

Hallo avr / lcd - freaks !

Habe die Diskussion schon längere Zeit verfolgt - interessant.
Da ich selbst "stolzer" Besitzer eines D062x-Moduls (132*132) von
Display3000 bin, mich aber von Anfang an die Benutzung von "BASCOM"
gestört hat, habe ich nach Alternativen gesucht.

Also erst mal WinAVR - kostenlos, praktisch -> gut !
Dann hat mich der Code von Hagen R. (glcd11) (www dot apetech dot de)
zum Nachdenken angeregt...

Was dabei rausgekommen ist, ist eine neue (C-) Bibliothek, die alle
Funktionen der GLCD11 enthält. Ich hoffe Hagen R. hat nichts dagegen
:-)

Was ich aber nicht weiss, ist, wie sich Hr. Küsters zu einer
Veröffentlichung dieser Bibliothek verhält; in seinen FAQs kann man
folgendes lesen:

F: Muss ich auf die Software Lizenzgebühren zahlen, wenn ich sie selber
in kommerzielle Produkte einbauen möchte?
A: Wir haben das Copyright auf unsere Software und die Dokumentation.
Sie dürfen die Software jedoch in Ihre eigenen Projekte nach Belieben
integrieren und verkaufen - ohne jegliche weitere Zahlung an uns. Die
einzige Einschränkung: Ihre Applikation muss kompiliert sein. Es ist
nicht gestattet, einen lesbaren Source-Code weiterzugeben. Die
Dokumentation über die Ansteuerung des Displays dürfen Sie nicht
weitergeben (auch nicht auszugsweise).

Is ja'n Ding...

Wenn ich also eine Bibliothek - wohlgemerkt OHNE seinen Basic-Code -
weitergebe, dann habe ich also ein Problem ? Oder wie ??

Aber vielleicht hat ja jemand Interesse ...

[Frank N. (z80)]

Nachtrag:

Als ich mir die Beschreibung des "Neuen" Moduls D073 laden wollte
(den link hat mir Display3000 als Kunden geschickt) lese ich
(sinngemäß)folgendes:

Ein böser, böser Mensch (ts, ts, ts) hat den Link zum Datenblatt
veröffentlicht. Deshalb bekommt das Datenblatt nur, wer ein eMail an
Hr. Küsters schickt.

(sicherlich muss er vorher eine Geheimhaltungserklärung abgeben ...)


Ich habe nichts dagegen, wenn man mit seiner Arbeit Geld verdienen will
bzw. muss. Ich habe ja auch für das Modul bezahlt. Aber als
(potentieller) Kunde habe ich doch wohl das Recht, mir die Datenblätter
- NICHT DIE KONSTRUKTIONSUNTERLAGEN - an- bzw. einzusehen.

Meinungen  ??

[SuperUser (Gast)]

Hallo Frank,

ich denke du kannst ohne Probleme deinen C-Source Code freigeben,
allerdings nicht den Teil der das Display ansteuert (also initialisiert
usw.) wenn du den aus den BASCOM Sourcen übernommen hast.

Das mit dem Datenblatt verstehe ich nicht, und kann ich auch nicht
nachvollziehen. Schliesslich ist das eine kostenlose Werbung für sein
Produkt. Wenn man duch diesen Thread durchblättert, gibt es einige, die
Probleme mit dem Thema haben und denen eine fertige plug&play Lösung
willkommen ist -> potentielle Kunden.

Ich habe nichts dagegen, wenn jemand wie Herr Küsters sich die Arbeit
macht und so etwas zusammenstellt, dann damit auch Geld verdient.

Schön wäre nur, wenn er auch der "Community" etwas zurück geben
würde. Vielleicht sollte man den Code für zukünftige Displays doch
unter sowas wie der GPL veröffentlichen.

[Frank N. (z80)]

Danke für die Antwort.

Ich sehe das genauso.

Werde also versuchen, aus meiner "Bibliothek" eine echte "Lib" zu
machen, dann handelt es sich um binar-Code und dem Willen von Herrn
Küsters ist genüge getan ...

[antiterrorist1967 (Gast)]

ñîáñòâåííî, ñàáæ. àìåðû çàðûëè ãîëîâû â ïåñîê, âûñòàâèëè æîïû, êàê
ñòðàóñû è æäóò ïîêà èõ òåððîðèñòû ïîèìåþò.
íó, â ïðîìåæóòêàõ åùå ìîãóò ñúåçäèòü ïîáîìáèòü Èðàê èëè âðîäå òîãî.
áëîã ïðàâäà èçðàèëüñêèé, ñî ñâîèìè óðîäñòâàìè, íî è ñî çäðàâûìè ìûñëÿìè
òîæå, http://www.samsonblinded.com/ruindex.html
ãóãë åãî ñ ïåðâîé ñòðàíèöû â îäèí äåíü ñáðîñèë íà äåñÿòóþ è çàîäíî
çàðïåòèë ðåêëàìó. à ÿ åãî ïî÷èòûâàë èíîãäà, áëèí.
òàê ÷òî, íàðîä, òåïåðü ðóñè-àðàáè áõàé-áõàé? íàäîåëî äî ÷åðòèêîâ,
èçáàâèòüñÿ áû îò ýòèõ òåððîðèñòîâ, à òî â ñàìîëåò ñåñòü íàïðÿãàåò.

[bwd (Gast)]

Hmm, schön günstig aber welches Modell ist das? sieht keinem ähnlich...
http://cgi.ebay.de/LCD-DISPLAY-SIEMENS-S65-M65-CX65-SK65-100-ORIGINAL_W0QQitemZ120036878157QQihZ002QQcategoryZ40579QQssPageNameZWDVWQQrdZ1QQcmdZViewItem

http://www.superkranz.de/christian/S65_Display/DisplayIndex.html

[Hagen R. (hagen)]

"Also erst mal WinAVR - kostenlos, praktisch -> gut !
Dann hat mich der Code von Hagen R. (glcd11) (www dot apetech dot de)
zum Nachdenken angeregt...

Was dabei rausgekommen ist, ist eine neue (C-) Bibliothek, die alle
Funktionen der GLCD11 enthält. Ich hoffe Hagen R. hat nichts dagegen
:-)

Was ich aber nicht weiss, ist, wie sich Hr. Küsters zu einer
Veröffentlichung dieser Bibliothek verhält; in seinen FAQs kann man
folgendes lesen:"

Ich muß mich nun doch dazu äußern.

1.) wir stellen mal die Frage wie eigentlich eine solche GLCD fürs
Nokia  entstehen konnte. Die Antwort ist sehr einfach, einige Leute
haben das Nokia reverse engineered und dann herausgefunden welche
Kontroller benutzt wurden, dann aufwendig deren Datenblätter gesucht
und anschließend eine GLCD dafür programmiert. Ich persönlich bin zb.
erst zu einem Zeitpunkt dazu gestoßen als Ape schon längst eine Lib
programiert hatte. Entscheidend ist aber der Fakt das die Leute hier im
Forum hauptsächlich diese Informationen + Ansteuerung erarbeitet haben,
und allen interessieten Lesern auch frei zur Verfügung gestellt haben,
ohne Profit damit machen zu wollen.

Wichtig bei diesen Erläuterung ist aber der Punkt das erst viel später
die Angebote von Display3000 erschienen. Ich möchte hier keine
Unterstellungen machen aber Display3000 hat defakto die Ansteuerungen
die hier im Forum entwickelt wurden zu Geld gemacht. Das Recht dazu hat
jeder der clever genug ist, das ist meine Meinung.

Sehr interesant ist der Fakt das zb. einige der ScreenShots auf
Display3000 definitiv von Software stammt die mit meiner GLCD
entstanden sein müssen !! Denn soweit wie ich es weis unterstützt nur
meine Lib für das Nokia auch proportionale und mehrfarbige Fonts.

2.) wenn du eine neue Software Ansteuerung für eine Hardware
entwickelst was interressieren dich dann irgendwelche Lizensansprüche
des Hardware Herstellers ? Ich meine Display3000 hat keinerlei
juristische Möglichkeiten dir zu verbieten deinen Source zu
veröffentlichen. Display3000 hat keinerlei Rechte an deiner Software
und kann auch nicht irgendwelche Rechte nur auf Grund der gekauften
Hardware an deiner Software implizieren.

3.) da deine Lib auf einem OpenSource und freien Source basiert,
nämlich meiner Library, sieht es eher so aus das allerhöchsten Ape oder
ich, irgenwelche Urheberrechte haben könnten.

4.) ich kann einige EMails vorweisen in denen Käufer bei Display3000
mich fragten was sie denn an meiner GCLD anpassen müssten damit sie auf
deren Boards läuft. Ich fragte natürlich nach woher sie denn meine
Addresse hätten und sie von der GLCD wüsste. Die Antworten sind
ziemlich interessant verwiesen sie doch auf Display3000.

5.) Ich für meinen Teil bestehe darauf das du deine Software
veröffentlichst (ist aber deine Entscheidung ;) Denn du kannst damit
der Community auch was zurückgeben, die ja erst diese GLCD ermöglicht
hat. Gerade dieser Community Gedanke, der Gedanke nicht immer aus allem
Profit machen zu wollen, womöglich noch Ideen klauen, ist es gewesen
warum ich zb. meine GLCD sofort als OpenSource veröffentlicht habe.

Davon mal abgesehen gibts noch einige andere Portierungen der GLCD, zb.
eben auch fürs S65 Display.

Eines weis ich aber mit Gewissheit: sollte ich jemals nochmal so eine
GLCD coden dann wird sie wieder OpenSource sein aber dieses mal mit dem
Lizensvermerk das kommerzielle Wiederverkäufer einen Obolus an zb.
dieses Forum entrichten müssen ;)

Gruß Hagen

PS: ich habe eigentlich nichts dagegen das man Profit machen möchte und
als Nebeneffekt so auch ungeübte Bastler an preiswerte Boards rankommen.
Aber man sollte doch wenigstens auch die Urheber, die das nötige
Knownledge erarbeitet haben, erwähnen.
Suche einfach hier in der Codelib und du wirst sehr lange Threads
finden die diesen "Engineering-Prozess" der Leute hier wiedergeben.

[Hagen R. (hagen)]

Um das also mal klarer auszudrücken:

Die Ansteuerung des LCDs, das Knowhow wurde zuerst, nämlich mindestens
2 Jahre vor Display3000, hier in diesem Forum entwickelt !

Aber! da gibts ein klitzekleines Problem, denn im Grunde fällt die
Ansteuerungslogik der Nokia/Siemens Displays in den Rechtsbereich der
Hersteller dieser Displays, denn die zugehörigen Datenblätter zb vom
Display oder auch Handy (aus den Service-Datenblättern wurden nämlich
wichtige Informationen ermittelt) stehen nur unter NDA beim Hersteller
zur Verfügung. Wenn also irgendjemand Rechte daran hat dann die
Hersteller wie Nokia, Siemens usw.

Gruß Hagen

[Tobias S. (tobias)]

Also wenn man auf Wikipedia unter
http://de.wikipedia.org/wiki/Reverse_Engineering schaut findet man
folgendes:

Viele Firmen untersagen das Reverse Engineering ihrer Produkte durch
entsprechende Lizenzbedingungen. Die Analyse von Protokollen ist davon
rechtlich nicht betroffen, weil dabei die Software selbst gar nicht
Gegenstand der Untersuchung ist.

und

Benutzt man das Ergebnis des Reverse Engineerings zum gewerblichen
Nachbau, so wird man sich mit der großen Menge der gewerblichen
Schutzrechte (z. B. Plagiat) in ähnlicher Weise konfrontiert sehen, so
wie es auch bei Ergebnissen der ganz normalen eigenständigen Forschung
und Entwicklung der Fall sein kann (z. B. Patent).

Da hier im Prinzip auch nur ein Protokoll duch abhoeren und testen
untersucht wurde duerfte das(zumindest fuer nicht kommerzielle Zwecke)
legal sein.(Soweit der Wikipedia-Artikel korrekt ist)

Gruss Tobias

[Daniel L. (bucho)]

Um nochmal auf meine Frage (weiter oben) zurückzukommen. 49 Downloads
und keiner weis eine Antwort??

[bwd (Gast)]

Und auf meine auch nicht, wo bezieht ihr eure siemens-displays her, die
eindeutig identifizierbar sind?

[bwd (Gast)]

Oder ich kaufe hier, da gibts alle 3 typen, welches ist denn das Display
bei dem die meiste Erfahrung vorliegt, bzw. am "einfachsten"
anzusteuern ist? Ich will aus lerngründen mir die soft nämlich
selberschreiben.

http://cgi.ebay.de/original-Siemens-CX65-M65-S65-SK65-LCD-Display_W0QQitemZ200033316973QQihZ010QQcategoryZ40579QQssPageNameZWDVWQQrdZ1QQcmdZViewItem

[SuperUser (Gast)]

Hallo Daniel,

- wie schaltest du die Backlight LED's ein- und aus?
- möchtest du die Beleuchtung nicht auch dimmen können?

Hallo bwd,

Je nachdem was du machen willst, empfehle das LS0. Ansteuern lassen
sich  alle drei gleich gut. Aber bis jetzt gibt es nur für das LS0 in
einer Orientierung die glcd.
Für das LPH sollte die Portierung der glcd aber eigentlich viel
einfacher möglich sein, da ein nahezu kompatibles Datenblatt existiert.
Nur hat sich noch keiner die Arbeit gemacht. Mit dem LPH sollten alle
Orientierungen einfach realisierbar sein.

[bwd (Gast)]

Danke, dann gönne ich mir doch mal so ein lph :)

[Peter (Gast)]

Hallo,

habe mir das S65 LPH Display besorgt und versuche es mit einem MSP430
anzusteuern.  -Leider bislang ohne Erfolg- :-(

FnLcdS65PortInit();

FnLcdS65InitC();

FnFillScreen(0x0780);

An dieser Stelle sollte das Display doch grün hinterlegt sein.
Ist es bei mir aber nicht. Es zeigt keinerlei Reaktion.

Im Anhang habe ich mal die FnLcdS65InitC() angehängt.
Vielleicht kann mir ja jemand sagen ob die Komando- und Daten- Werte
überhaupt richtig sind, die ich dem HD66773 über die DAT Leitung
reintakte.

Danke

[grüner (Gast)]

Hallo! Ich habe auch ein grünes, und habe mir die Init-Sequenz mit
delayms mal eben selbst zusammengebastelt, läuft aber noch nicht so
recht. Stimmen die auf Christians Seite angegebenen Befehle (die er
logic analyzed hat) für alle Displays?

[SuperUser (Gast)]

Hallo Peter,

du hast die 10ms Reset-Zeit "wegoptimiert". Kann durchaus sein, dass
das Display eine längere reset-Zeit benötigt. Ist zumindest nicht
unüblich.

Hast du dir mal die Timings auf deiner SPI Schnittstelle angeschaut?
(Flanken- zu Signal...)

[Daniel L. (bucho)]

@SuperUser:
Also, das Problem an der ganzen Sache ist, daß ich bei meinem Interface
keine Spannungs-, sonder eine STROMQUELLE an die Hintergrundbelechtung
anschließe. Ich weis jetzt nicht genau ob die Hintergrundbeleuchtung
sofort leuchtet, wenn man da was anschließt, oder ob sie noch per
Software eingeschaltet werden muß. Wenn der zweite Fall vorliegt, habe
ich die Sorge, daß die Stromquelle eine unzulässig hohe Spannung am
Sisplay erzeugt, wenn intern der Trompfad der Hintergrundbeleuchtung
nicht durchgeschaltet ist.

Gruß

[SuperUser (Gast)]

Hallo Daniel,

die LED's sind einfach durchverbunden - ohne irgendwelche Schalter auf
dem Display. D.h. Stromquelle ist schon i.O.

Darum fehlt mir bei deinem Schematic auch noch der Ein-/Aus-Schalter,
es sei denn du willst die Hintergrundbeleuchtung immer eingeschaltet
lassen.

[Bernd (Gast)]

Hallo,
hatt denn jemand das Dattenblatt des HD66773 Controllers ?( für Display
LPH88...) Es währe super wenn jemand sagen könnte wo es zu finden ist,
oder mir per E-Mail zusenden könnte.

Danke
Bernd

E-Mail: [e-mail]

[Daniel L. (bucho)]

Danke; für den ersten Test will ich die Hintergrundbeleuchtung einfach
anlassen. Die Schaltung ist nur dafür gedacht, das Display
auszuprobieren.


Gruß

[Peter (Gast)]

Bernd
ich glaube, da suchen hier sehr viele nach

[Bernd (Gast)]

Hallo,
habe das Datenblatt für den HD66773 gefunden.(Ist Beigefügt)
Hier wird aber auch eine RS (Register select Leitung) benützt um
zwischen Daten und Kommando zu unterscheiden !
Beim LPH88.... bei dem der HD66773 drin sein soll, sagt Christian aber,
dass hier keine RS-Leitung benützt wird !?
Ist dann da etwas durcheinander gekommen ? Gehört sich evtl. der
HD66773 doch nicht zum LPH88.... ???

Gruß Bernd

[MartinK (Gast)]

@Bernd

> habe das Datenblatt für den HD66773 gefunden

Das ist doch schon alles vor einem Jahr ausdiskutiert worden.

[Bernd (Gast)]

@ MartinK
würdest Du ganz kurz das Resultat der Diskussion nochmal schreiben, da
ich vor einem Jahr noch nicht dabei war!!!
Ich hab die Beiträge zwar durchgeschaut, aber keine eindeutige Aussage
hierzu gefunden.

Gruß
Bernd

[MartinK (Gast)]

Datenblatt Seite 7
RS: "When using SPI, fix it to Vcc or GND level"

[Bernd (Gast)]

Ok. Danke.
Dann sollte das Datenblatt des HD66773 ja für das LPH88... passen!
Hast Du dieses Display am laufen ?
Evtl. zusätzliche Funktionen implementiert ?

Gruß Bernd

[MartinK (Gast)]

Leider nicht. Vor etwa 1 Jahr hatte ich dieses Display am laufen,
doch ich bin auf das LS020xxx-Display umgestiegen, weil dieses
eine wesentlich hellere Hintergrundbeleuchtung hat.

[Ronaldo (Gast)]

Hi, I finded this link and it´s very interesting, have information about
 all controler HD66XXX.

[Ronaldo (Gast)]

I forgot the link:
http://america.renesas.com/fmwk.jsp?cnt=color_display_for_mobile_apparatus_family_landing.jsp&fp=/products/lcd/color_display_for_mobile_apparatus/

[Peter (Gast)]

Hallo,

den HD66773 auf dem Siemens S65 kann man scheinbar auch mit 3,6V
betreiben.
Kann das jemand bestätigen?

Gruß

[Hauke Radtki (Gast)]

Der controller schon, das Display selbst nicht.

Wenn man das Display mit mehr als 2,9V betreibt werden die Farben
extrem unschön.

[Peter (Gast)]

Hallo,

zwischen keine Anzeige und eine unschöne Anzeige, liegt ein kleines
Erfolgserlebnis.

Mit 3,6V .... ist da das Display noch am Leben oder hat es sich da
schon längst verabschiedet.

Wenn ich das Display angesteuert habe, kann ich an die schöneren Farben
denken.

Gruß

[Hauke Radtki (Gast)]

Wenn möglich würde ich 3.3V probieren, da ging meins auch über nen
größeren Zeitraum.

Unschöne farben hin oder her, ich weis nich ob das gut für das LCD
selbst ist (bzw für die kristalle oder was weis ich)

wo liegt denn dein Problem?

[Peter (Gast)]

Hallo,

also ich verwende den MSP430f149 um das S65 LPH88.. anzusteuern.
Der MSP wird mit dem internen DCO (8.388.608Hz) getaktet. Das Display
hängt am Hardware SPI des Mikrocontrollers.

Mit dem Oszi sehe ich, dass über den SPI Bus die Commandos und Daten
für das Display getaktet werden. Nur zeigt dieses eben das .."grüne
Display".. nicht an.

Nun bin ich eben dabei, die Zeiten zu überprüfen.

Gruß

[Avr N. (avrnix)]

Mir ist bei 3,6V ein LS020.. in Popo gegangen, als ich es ein zweites
mal anschiessen wollte. Ob jetzt an der Spannung gelegen hat oder weil
die Folie kaputt gegangen ist. Kann ich nicht sagen.

[Hauke Radtki (Gast)]

macht der MSP keine 3,3V mit? ich dachte schon oder?

sonst ein einfacher Spannungsteiler funktioniert bei kurzen leitungen
als pegelwandler sehr gut :>

[Peter (Gast)]

Hallo,

Der MSP macht die 3,3V schon aber da hat der keine 8MHz.
Ich denke ich muß den uC mit 8MHz takten.

Gruß

[Hauke Radtki (Gast)]

Achso, dann würd ichs mit Widerständen probieren, wenn deine Kabel nicht
allzu lang sind ist das kein Problem.

[MC-Bernd (Gast)]

Thema: Pegelwandler (5V->3V)
Hinweis an alle die Probleme mit den Farben haben, "unschöne" und
blasse Farben. Ich hatte das Problem auch. Nachdem ich die
Pegelwandelung mit Spannungsteiler durch eine Wandelung mit dem
74HC4050 ersetzt habe, ist dieses Problem absolut beseitigt und die
Farben sind jetzt richtig schön und kräftig! Durch die Pegelreduzierung
mit den Widerständen werden anscheinend die Flanken der Signale zu sehr
"verrundet" so dass bei der Initialisierung nicht alle Spannungen
korrekt gesetzt werden. So ist auch zu erklären, warumm bei einigen die
Farben so spannungsabhängig sind!

Gruß
MC-Bernd

[Avr N. (avrnix)]

@MC_bernd: gehts auch bei 3,3V mit deinen GLCD ?

[MC-Bernd (Gast)]

@ AVRNix
Hallo,
habe 3,3V nicht ausprobiert, da es für mich keinen Grund gibt, das
Display mit Überspannung zu betreiben!
Gruß
Bernd

[Hauke Radtki (Gast)]

Ich "betreibe" das Display direkt am STK500 und lasse mir vom STK500
die 2.9V bereitstellen. So sind auch die IO-Spannungen auf 2.9V und ich
hab das "problem" mit den spannungsabhängigen farben trotzdem.

[Avr N. (avrnix)]

Kann das sein ( hier beim LS020.. ) wenn die Hintergrundspannung für die
 LEDs so hoch ist das der Effekt der Spannungsabhänigen Verfärbung
auftritt? So sind die Spannungen bei mir im Bereich 2,9V für I/O bei
10V-11V Hintergrundspannung.

[MC-Bernd (Gast)]

Hallo AVRNix,
ich denke nicht, dass die LED-Spannung einen Einfluß darauf hat.
Ist meiner Meinung nach total separat!
Ich glaube das Problem hat mit der Initialisierung zu tun.
Bei mir änderten sich die Farben auch wenn ich zum Schluß eine helle
oder dunkle Farbe gezeichnet habe und die Farben waren nur kräftig bei
Betrachtung von (leicht) rechts!(schlechter Blickwinkel)
(Ich benütze auch LS020)
Ist jetzt alles weg.
Gruß
MC-Bernd

[Andi (Gast)]

hi @ all,

hat es nun jemand mit 18f4550 geschaft?

ich habs versucht, aber das Display springt nicht an, wahrscheinlich 
habe ich noch Fehler was die SPI Schnittstelle angeht.

gruss andi

[bwd (Gast)]

So, mein Display ist nun da und wollte es auf Funktionsfähigkeit testen, 
habe es an atmega8 anpassen wollen (makefile und portpins geändert), 
jedoch:

illegal opcode call for mcu atmega8 in
[asm]call    port_init_io    ;init SPI[/asm]

Ich kann leider kein Assembler, also was ist da los?

Portpins:

#define LCD_CS     PB2
#define LCD_RESET  PB0
#define LCD_RS     PB1
#define LCD_MOSI   PB3
#define LCD_MISO   PB4
#define LCD_SCK    PB5

[bwd (Gast)]

Hm, mal das pn2 neugestartet, nun gehts?!

[bwd (Gast)]

Mal ne Frage: Wie generiere ich aus 16 MHz Haupttakt die 13 MHz SCK? 
Laut datenblatt gehts bei F_CPU/2 los...

[Christian K. (christiank)]

zu 13MHz: gar nicht, das SPI läuft dann mit 8MHz.

Was ist ein pn2? (neugestartet und es geht??)

[bwd (Gast)]

Hm, okay danke, ist da so ne große Toleranz drin bezüglich des Taktes, 
oder ist da noch nen Trick bei? Naja ich werds nachher mal ausprobieren.

pn2 ist das Programmers Notepad (mitgelieferter editor von winavr mit 
integriertemr gcc- und avrdude-unterstützung), das benutze ich lieber 
als das Studio, da man schneller kompilieren und programmieren kann (via 
Hotkey), und die debug- und Simulationsfunktionen brauche ich aktuell 
sowieso nicht.

[bwd (Gast)]

Hi, nochmal ne Frage, du schriebtest auf deiner Homepage:

    *  setting pixel
    * draw lines
    * draw rectangles, filled and with border
    * draw ellipses and circles
    * proportional and fixed fonts with different colors
    * clipping rectangle for all outputs
    * all routines support transparent drawing

Aber ich habe die im quelltext nirgendswo gefunden?

[bwd (Gast)]

hm...kein wunder, hab ja auch nur die abgespeckte lib oben auf deiner 
seite gefunden, und die unten übersehen....

[Jens D. (jens)]

lol
ich denke unten die ist auch recht schwer zu verstehen..

Der Takt ist nach untenhin sehr offen, bei SPI zumindest, bei einem 
RS232 Signal, hast du ja keine Taktleitung, und darum muss ein sehr 
genauer Takt eingehalten werden.

Bei SPI hast du eine eigene CLOCK Leitung, welche sagt, wann Daten 
geschrieben werden können bzw gelesen

[Hauke R. (lafkaschar)]

Der Takt is bei dem Display uberhaupt kein Problem nach unten hin ^^ Ich 
hatte den  Takt vom STK500 ma auf 32kHz ... ist schon lustig zu sehen, 
wie sich die Pixel aufbauen :>

[bwd (Gast)]

Okay, thx :). Habe nun ein Problem: Die kompilierte komplette Lib ist 
über 32kB groß. Gibt es in der "kleinen" die Möglichkeit einzelne Pixel 
zu zeichnen?

[Christian K. (christiank)]

Hallo bwd,

du meinst vmtl. die Grösse des glcdlib.a files? Das ist noch lange nicht 
die Grösse des fertig gelinkten Codes. Compilier doch einfach mal das 
beiliegende test Program.

Weil die glcd in Assembler geschrieben ist, ist sie nämlich ziemlich 
klein....

[Hagen R. (hagen)]

@bwd:

werden nur Basisfunktionen der GLCD benutzt so benötigt sie maximal 800 
Bytes FLASH. Werden alle Funktionen benutzt, besonders Clipping etc. 
dann sind es 2800 Bytes Flash. Das gleiche in reinem WinAVR GCC C würde 
dann 4800 Bytes verbrauchen. Bedenkt man was die GLCD schon mit 800 
Bytes leistest -> Transparenz, Linien, Rechtecke, Füllungen, Mehrfarben 
und eben proportionale komprimierte Fonts, dann sind 800 Bytes wirklich 
nicht viel.

Wenn du weist das eine Bibliothek wie die GLCD eine echte 
Link-Bibliothek ist so wüsstest du auch das dadurch die binäre Größe der 
Linklib. stärker anwachsen muß als bei einer normalen Library. Das liegt 
eben daran das in diesem File noch viele zusätzliche Informationen 
gespeichert sein müssen damit später der Linker überhaupt in der Lage 
ist nicht benutzte Funktionen aus der Lib weg zu optimieren. Dh. der 
Linker linkt nur diejenigen Funktonen aus der GLCD in dein fertiges HEX 
die du in deinem Source benutzt hast. Das ist keineswegs eine Normalität 
wenn du 3'rd party Libraries benutzt.

Gruß Hagen

[bwd (Gast)]

Danke, ich schau heute abend mal, wenn ich daheim bin.


PS: die .hex ist übrigens so groß geworden, nicht die lib selber, habe 
mich da etwas falsch ausgedrückt.

[bwd (Gast)]

Hallo,
d.h. bei den .a libs handelt es sich um "Intelligente" libs, die auch 
nur die Funktionen importieren, die benutzt werden? Weil von .c /.h 
kennt man es ja, dass der Compiler die Datei nur "stumpf" in die 
haupt-c-datei reinkopiert.

weil dann finde ich das etwas komisch, hab jetzt die test.c nochmal 
abgespeckt (siehe Anhang), aber komme immer noch nicht auf Deine <8kB 
mit meiner Hexdatei. Mit der original test.c wie sie "mitgeliefert" wird 
lande ich bei besagten 34kB hexdateigröße.

Entschuldigung für die Fragen, aber mit libs habe ich mich noch nicht so 
eingehend beschäftigt ;-).

[Christian (Gast)]

> aber mit libs habe ich mich noch nicht so eingehend beschäftigt

Mit hex-files aber wohl auch noch nicht...

Im Hex-File ist dein binary file - das Ergebniss des Linkers - mehr oder 
weniger im Textformat gespeichert. Öffne das doch einfach mal... Du 
wirst viele Zeilen mit HEX Zeichen im ASCII Format finden. Darum ist das 
hex-file sehr viel groesser als das eigentliche binary.

Mit avr-size kannst du dir die Größe der einzelnen Bereiche anzeigen 
lassen.

[Delta4.elektronik (Gast)]

Guten tag. Ich habe problem mit AVR CODE in CodeVision AVR. --- 
http://www.delta4.info/delta4/files_2/AVR_L2F50_display.zip danke aus 
help! Czech Republic :o)

[Mike Bird (Gast)]

Hallo,

kann mir vielleicht jemand ein Proggy nennen, mit dessen Hilfe ich eine 
Bilddatei (BMP-24Bit zum Beispiel) in eine Rohdatendatei im RGB 5:6:5 
Format konvertieren kann ?
Irfan View kann leider nur in das 24Bit RGB Format konvertieren.
Habe nun unter Bascom einen kompletten Unterroutinensatz fuer das LF02 
geschrieben (Plot, Line, Circle, Rectangle, Filled Circle, Filled 
Rectangle, Text, Clear, uvm.) Nun moechte ich fuer meine Anwendung zum 
Beispiel Icons verwenden, und da waere das Konvertieren aus Bilddateien, 
etc. natuerlich einfacher, als komplett neu zu Pinseln.

Fuer Eure Hilfe waere ich sehr dankbar.

Liebe Gruesse
Mike

[Mike Bird (Gast)]

abo

[Avr N. (avrnix)]

Mike Bird - läuft es bei dir mit BASCOM über Hard SPI ?
Wenn ja wie hast du das angestellt?

[Hauke R. (lafkaschar)]

@  Mike Bird.

Ich bin gerade dabei sowas zu basteln, bin aber noch nicht ganz fertig. 
Jetzt fahr ich erst mal in den Urlaub. In 10 Tagen bin ich wieder da, 
dann werd ich weiter machen.

[Mike Bird (Gast)]

@AVR Nix:
nein, leider habe ich es auch nicht zuverlaessig ueber Hard-SPI zum 
laufen bekommen, die waits haben letztendlich mehr Zeit gefressen, als 
wenn ich es gleich ueber Soft-SPI laufen lasse (Shiftout).
Ich werde mir aber am Wochenende wohl nochmal das Thema Hard-SPI 
vornehmen, waere doch gelacht, wenn man das Ganze nicht doch damit zum 
Laufen bekommt.

@Hauke:
Na, dass hoert sich doch sehr gut an, vor allem, dass Du nun Urlaub hast 
:o)  Waere aber nett, wenn Du uns danach mal auf dem Laufenden haelst. 
Denn ein Kaffee-Vollautomat, mit TFT-Menue, schreit einfach nach netten 
Kaffeetassen-Symbolen, fuer die einzelnen Produkte und auch im 
Systemmenue.) Sowie natuerlich auch das Firmenlogo, beim Einschalten.

Bin jetzt erstmal mit den Hauptroutinen beschaeftigt 
(Temperatursteuerung, Antriebseinheit, Mahlwerk, Pumpe und 
Magnetventile, sowie der Sicherheitsueberwachungen, etc.)
Sprich, es gilt noch viele Bugs zu Programmieren :o)

Gruss Mike

[Andreas L. (andimaniac)]

@ KennyOswald

könntest Du die Firmware für 18F4550 posten, ich bekomme das Display 
nicht initialisiert?

MfG Andi

[Patrick (Gast)]

Hallo Hauke

an dem Programm zur BMP Konverierung währe ich auch interessiert.

@Peter vielleicht kannst du ja die Quellen zu deinem Tool 16pbbColors 
posten?

Gruss Patrick

[Avr N. (avrnix)]

@ Mike Bird: Gibts Fortschritte mit der Hard-SPI ?

[Mike B. (mikebird)]

@ Avr Nix:
Nein, leider noch nicht, da ich momentan viel auf Achse bin, komme ich 
zur Zeit doch nicht dazu.
Da bei mir das Display-Timing in dem Projekt nicht so extrem wichtig 
ist, sind natuerlich auch erstmal andere Prioritaeten gesetzt. 
(Ablaufsteuerung)
Trotzdem reizt es mich natuerlich auch fuer zukuenftige Projekte, das 
Timing zu optimieren, um Ressourcen fuer andere Dinge freizuhalten.
Also denke ich mal, dass ich in meinem Urlaub, in 3 Wochen, spaetestens 
dazu kommen werde, mich weiter dem Teilchen zu widmen.
Denn momentan laeuft es nur als Farbige Analoguhr, und schaut zumindest 
schonmal gut aus (wenn auch voellig Sinnlos...lol).
Halt ein Abfallprodukt der Routinenschreiberei :o)

Gruss Mike

[Mike B. (mikebird)]

Hallo,

mich liess momentan das Problem der Konvertierung keine Ruhe, auch wenn 
ich heut wieder Frueh raus muss....*grummel*
Bin dann erst am Freitag (Nachts) wieder da.
Habe also kurz mal nen BMP 24Bit zu RGB565 Exporter geschrieben,
moechte ihn aber noch nicht veroeffentlichen....kommt am Wochenende !
Nun habe ich nur das Problem, dass Bascom es wohl irgendwie nicht auf 
die Reihe bekommt, groessere Datenmengen per Restore / Read, 
nacheinander zu lesen. Irgendwie ueberschlaegt sich da wohl ein Pointer.

Das angehaengte File ist ein Testfile, welches ich mit dem Exporter 
erstellt habe. Die ersten beiden Daten sind die Bildgroesse (x,y),
dann folgen die Farbdaten, sequentiell.

Habe versucht das Bild mit folgender Routine darzustellen, aber nach ci 
20% kommt nur noch Muell an. Vielleicht kann sich da ja jemand die Tage 
dran versuchen?

Folgende Routine nutzte ich als Darstellungsroutine:

Restore Bildname
Read X
Read Y
X = X - 1
Y = Y - 1
For Y1 = 0 To Y
For X1 = 0 To X
Read Z
Gosub Lcd_pset '(Subroutine setzt einen Pixel an X1,Y1 mit der Farbe Z)
Next X1
Next Y1

Gruss Mike

[Patrick (Gast)]

Hallo Forum,

mal noch eine Frage zur Array Deklaration in der das BMP drin sein muss.
ich hab zum Testen mal folgende Funktion erstellt:

void testBitmaps_2(void) {
  uint8_t x=0, y=175;


  glcdColor_t Bitmap[23232];

  for(uint16_t i=0; i<23232; i++) {


    glcdSetPixel(x, y--, Bitmap[i]);

  }
}

Später soll dann in "Bitmap" mal das gewandelte BMP drin sein. Das 
Problem ist das der compiler eine Fehlermeldung test.c:417: error: size 
of variable 'Bitmap' is too large bringt.

Was mach ich falsch?

Gruss patrick

[SuperUser (Gast)]

Hallo Patrick,

du hast wahrscheinlich keinen µC mit 46kByte RAM oder? Darum meckert der 
Compiler...

Grüße
  SU

[Patrick (Gast)]

Hallo SU,

nein, hab einen ATMega128, der genug Flash hat. Wie bekomme ich das 
Array in
das Flash bzw. kann es von dort wieder laden?

Gruss Patrick

[Ralf K. (123ralle)]

@Mike

Einige Bascom Versionen haben wohl einen Bug, was große Bereiche mit
DATA Zeilen angeht.
Es hilft, wenn man ca. alle 3 KB eine leere Sprungmarke einfügt

DATA xx,xx,xx,xx
marke1:
DATA xx,xx,xx,xx

Ich kann aber im Moment nicht testen obs hilft.

Gruss,
Ralf

[SuperUser (Gast)]

@Patrick:
schaust du hier...
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Speicherzugriffe

[Keine Ahnung (Gast)]

@MIkeBird: kannst du mal dein "AbfallProdukt" zeigen?
zum lernen wäre doch mal ein Anfang! Wurde mich interresierren wie du 
die Uhr gemacht hast , da ich so ein teil gern Nach bauen möchte!

wäre ganz toll!

[Mike B. (mikebird)]

Sodele..

@Keine Ahnung:
Mail mir einfach! Oder registriere hier im Forum.

@Ralf: Vielen lieben Dank, der Tipp von Dir mit den Einsprungmarken hat 
funktioniert. Habe es auch gleich letzte Nacht in mein BMP2DATA 
converter mit eingebaut. (setzt alle 3kb eine blinde Einsprungsmarke mit 
einem aus Uhrzeit, Datum und einem Zaehler, gewonnenen Namen. Somit 
schliesse ich irgendwelche doppelten Marken nahezu aus)

Und nun an alle, die Interesse an dem Konverter Tool haben:
Ich haette dies ja gerne hier mit angehaengt, nur irgendwie funktioniert 
es nicht. Daher mailt mir bitte, wenn Ihr dies Tool haben wollt,
ich maile es dann so schnell es geht zu.

Momentan kann es nur .BMP Dateien mit 24Bit konvertieren, da ich noch 
keine Palettenbehandlung implementiert habe. Es sollte aber kein Problem 
darstellen, ein 8Bit .BMP zuvor mit z.Bsp. Paint, als 24Bit umzuwandeln, 
und dann mit dem Tool umrechnen zu lassen.

Das Tool kann ueberall hinkopiert werden, es benoetigt keine 
Registrierung, oder Installation.
Nach dem Start waehlt man das File, welches man konvertieren moechte, 
mit den Cursortasten aus und mit Enter wird dann die Konvertierung in 
ein Textfile mit dem Namen des Quellfiles +.txt Endung im selben 
Verzeichnis der Quelle, durchgefuehrt.

Man braucht dann nur noch den Inhalt des Textfiles ins Bascom File zu 
kopieren, die Einsprungsmarke am Anfang auf den gewuenschten Namen 
umzuaendern, und das wars.

Bitte Mailt mir, wenn Ihr noch Aenderungsvorschlaege habt, oder Fehler 
findet. (ist eh noch nicht ganz fertig)

Viel Spass beim Experimentieren!

Gruss Mike

[Mike B. (mikebird)]

Hier noch mal ein kleines Bildchen von meinem "Abfallprodukt" in 
Funktion.
Nun auch mit "Kaffee" als Hintergrund :o)

[Andre (Gast)]

Hallo,

versuche nun schon seit Tagen das S65 LPH88.... Display zum Laufen zu 
bringen. Leider ohne Erfolg.

Kann vielleicht jemand seinen Initialisierungscode hier posten?

Funktioniert das Display auch mit 4MHz  und
wie wichtig sind eigentlich die Pausen zwischen den Sequenzen.

Danke und Gruß

[Patrick (Gast)]

Hallo S65 User,

anbei mal ein kleine Testroutine um ein BMP aufs Display
zu zeichnen. Dabei ist auch ein kleinen VB Tool um die BMP C Quellen
zu erzeugen. Läuft gut hab’s mit 4,5 und 16Mhz ausprobiert.

Eine Sache ist mir aber nach wie vor unklar. Ich muss z.Z zwei Array mit
je einer Bildhälfte erzeugen. Lege ich die beiden Arrays zusammen gibt’s
einen Fehler beim compilieren. ?? Wo ist die Grenze des Array Index?

Noch was: im Code welches das VB Tool erzeugt gibt es eine Textmarke
"Trennzeichen" um die beiden Array auseinander zuhalten. Einfach ein 
24Bit
BMP mit 132x176 Pixel laden und Code erzeugen. Dann den Code bis zum 
Trenn
zeichnen in das erste Array einfügen, ab dem Trennzeichen bis zu Ende 
den
den Code in das zweite Array einfügen.

Gruss Patrick

[André K. (andre-)]

Auszug aus Language fundamentals:

The index must be a numeric constant, a byte, an integer, word or long.
The maximum number of elements is 65535.
The first element of an array is always one. This means that elements 
are 1-based.

[André K. (andre-)]

Oh, ich dachte du nutzt immer noch (?) Bascom. Sorry.

Beste Gruesse

[Mike B. (mikebird)]

Hier nochmal etwas zu meinem Bitmap Converter (ehemals BMP2DATA).

Dieser kann nun dank AVRNix auf seinem Board heruntergeladen werden 
(falls der Anhang hier mal wieder nicht klappen sollte).
http://www.comwebnet.de/zip-dateien/Bascom_Picture_Converter11a.rar

Momentan ist er so optimiert, dass auch mit aelteren Bascom-Versionen,
die Bilder nahezu problemlos dargestellt werden koennen.
Daher befinden sich in den Ausgabe-Dateien, alle 3kb eine 
Ghost-Einsprungsmarke, da sonst die aelteren Bascom-Versionen nicht in 
der Lage sind, solch Datenmengen per Read, am Stueck zu lesen.

Bei Fragen und Verbesserungsvorschlaegen zu dem Tool, mailt mir bitte!!

Gruss Mike

[Patrick (Gast)]

@ André K  Der Index des Array ist aber nur 23232 sollte also reichen?

Gruss Patrick

[Daniel L. (bucho)]

Hallo allerseits!

Ich habe nochmal eine Frage zum Beispielprogramm. Wenn ich das Programm 
mit dem mitgeliefertem Makefile compiliere, dann wird noch ein 
EEpromfile erzeugt. Wenn ich dieses File mit AVR-Studio programmieren 
möchte, dann bekomme ich eine Fehlermeldung. Allerdings funktioniert das 
Programm auch ohne das EEpromfile. Irgendwie habe ich sowieso 
festgestellt, daß bei meinem AVR-Studio das EEprom nur mit Hex-files 
gefüttert werden kann; Eep-Files haben eine Fehlermeldung zur Folge. Ich 
hoffe, daß mir jemand weiterhelfen kann.

Gruß

[Stefan B. (beckst)]

Hallo miteinander,

ich habe mir einen kleinen Bitmapkonverter programmiert.
er wandelt ein 24bit Bitmap in ein 16bit Bitmap (5-6-5) passend fürs
Display um. Bei mir funktionierts bestens wobei ich Fehler nicht
ausschließen will.
als Zieldatei wird die Datei S65.h erzeugt welche für die Einbindung in
Assembler-Quellcode formatiert ist.
viel Spaß damit

Mfg Steff

[Patrick (Gast)]

Hallo Steff,

hab die bmp Datei ins gleichen Verzeichnis kopiert.
geht aber nicht. Programm meldet Datei nicht gefunden?

Gruss Patrick

[Stefan B. (beckst)]

Hallo Patrick,

hast du den kompletten Dateinamen also inclusive der Endung .bmp 
eingegeben?

MfG Steff

[Mike B. (mikebird)]

Hallo Steff,

ich habe mir kurz mal ein Resultat von Deinem Konverter angesehen.
In welcher Reihenfolge sind die Werte ?
ist der erste Wert das High-Byte oder Low-Byte?
Wuerde sonst die Ausgabemoeglichkeit auch in meinen Konverter mit 
einbauen, somit waere es dann fuer Bascom und Assembler nuetzlich.
Und welche Direction hast Du ? Erster Wert oben links ?
Ich weiss, ich koennte auch ein paar Testbilder durchlaufen lassen und 
vergleichen, aber momentan fehlt ein wenig die Zeit dazu.
Nur die Aenderung des Ausgabeformates ist kein Beinbruch in meinem 
Proggy.
Wollte eh noch ein Down-Scale, sowie BMP Konvertierung mit 
Farbpalettenauswertung einbinden (dann muessen es keine 24Bit BMP mehr 
sein)

Gruss Mike

[Stefan B. (beckst)]

Hallo Mike,

also erster Wert ist der oben links
und es wird wie du schon vermutet hast zuerst das High-Byte geschrieben.
es wär natürlich eine klasse Sache wenn du so ein all in one Programm 
bereitstellen würdest also mach dich ran.

MfG Steff

[diego (Gast)]

OT an Matthias Dehof

hallo matthias
ich habe hier auch einen unc20 und wollte dich mal fragen ob du es 
jemals versucht hast auf die seriellen schnittstellen zuzugreifen (nicht 
fürs debugging/terminal) irgendwie scheint mir da nämlich das LxNetes 
etwas schräg... ich kann da nämlich die baudraten usw. nicht setzen, da 
keine termios struktur vorhanden scheint.
Falls du irgendetwas dazu weisst wäre ich dir dankbar wenn du mir hier 
oder per mail antworten könntest.

gruss diego

[Diego .. (diego)]

hmmm email ohne adresse super idee :P naja pn tuts ja auch ;)

[Ivoi (Gast)]

To  Smartie.
Dont work AT91SAM7.zip! Can you send me all project?

Thank you.
Best regards

[Christian K. (christiank)]

Hallo,

etwas neues zur Adressierung des LS020 Display RAMs:

http://www.superkranz.de/christian/S65_Display/DisplayRamAccess.html

[Ben (lightning)]

@Christian K.
Danke für die neuen infos.

@ALL
Das PDF-Update ist natürlich auch schon fertig.


~ gruß Lightning

[Goga (Gast)]

good job... someone, give me the link to a new projects about these 
topic...

[Lötnix (Gast)]

Ist der Konverter weiter entwickelt worden?
Und wo bekomme ich den aktuellen Konverter?

mfg

Lötnix

[Stefan B. (beckst)]

Hallo,
welche Funktionalität bräuchtest du denn?
evtl. kann ich dir ja weiterhelfen.
MfG Steff

[Lötnix (Gast)]

Der sollte ein Bild x x Y x Farbtiefe umwandeln können egal was für eine 
Farbtiefe ich habe. Es ging doch nur mit dem 24 Bit  BMP Bild.

Es gibt ja auch naoch andere Formate. bzw. eine Kompression des Bildes 
um im AVR nicht soviel Arbeitsspeicher zu verschwenden.

War doch hier im Gespräch?

mfg
Lötnix

[Mike B. (mikebird)]

Hallo Lötnix,

momentan kannst Du Dir ja damit weiterhelfen, indem Du mit sonstigen
Gfx-Proggys vorweg Dein Bild in ein 24Bit Bitmap umwandelst.
Da ich in den letzten Wochen leider noch nicht weiter dazu gekommen bin, 
an meinem Converter herumzubasteln, ist noch keine neue Version mit 
Assembler konformen Ausgaben verfuegbar.
Ich hatte allerdings in einer nicht veroeffentlichen Version schon 
einmal ein wenig mit RLE Kompressionen herumprobiert, da ich aber 
hauptsaechlich die Ausgaben fuer Bascom Programme verwende, ist die 
Decompression dabei doch sehr zeitraubend. Werde dies aber dann doch 
nochmal mit implementieren.
Die Einbindung der Konvertierung von "nicht 24-Bit bmp" ist schon etwas 
Umfangreicher, da hierbei mit Farbpaletten gearbeitet wird und nicht mit 
direkten Farbanteilen fuer jedes Pixel.
Daher war die Funktionalitaet erstmal nur auf das Minimum begrenzt,
also die Konvertierung verschieden grosser (max. 176x132) 24Bit Bitmaps 
in ein Data-Format, welches sich ohne Probleme im Bascom verarbeiten 
liess.

Also sobald ich wieder ein wenig Zeit habe, werden Stueck fuer Stueck 
folgende Funktionen mit eingebaut: (nach Prioritaet absteigend)
-Assembler-Quellcode konforme Ausgabe waehlbar
-bmp Konvertierung von nicht 24Bit Dateien
-RLE Kompression waehlbar
-Up/Downscale der Bildgroesse

Die Versionen werden dann wieder hier, sowie auf den Seiten von AVRNix 
zur Verfuegung stehen.

Ein vorweihnachtlicher Gruss aus dem hohen Norden
Mike

[Hagen R. (hagen)]

Anbei eine Beta meines Konverters.

Vorerst müsste das Exportieren in das RAW Format ausreichend sein. Dazu 
einfach die Checkbox "RAM Data" anhacken und es wird eine C Header Datei 
gespeichert in der die Pixel mit 16Bit Farbwerten codiert sind.

Für die anderen 3 Datenformate die ich verwende kann ich noch 
Erklärungen und Beispielcode in C nachliefern, wenn gewünscht. Vorerst 
nur mal par Stichpunkte was drinnen ist:

- 1 Farb Bitmaps, das sind nichts anderes als mit einer Farbe 
ausgefüllte Rechtecke, quasi leere Bitmaps mit einer Hintergrundfarbe

- 16 Bit Bitmaps, das sind unkomprimierte Bitmaps in voller Farbe, 
meistens weil eine Komprimierung nichts bringt

- Monochrome Bitmaps (2 Farben) mit Komprimierung. Die Daten sind per 
RLE komprimiert und man erreicht ca. 2000-3000% Packungsrate im 
Vergleich zu RAW

- 2 Bit bis 15 Bit Farbbitmaps, also von 3 Farben bis 32765 Farben. Die 
Daten sind komprimiert und benutzen eine Farbtabelle. Die 
Komprimierungsrate ist fast immer besser als bei PNG Bildern. Wichtig 
ist das man nur durchschnittlich 16 AVR Takte pro Datenbyte in den 
Zeichenroutinen benötigt für diese Dekomprimierung. Man erreicht also 
defakto den maximalen Datendurchsatz bei 8Mhz SPI auf einem 16Mhz AVR, 
direkt aus dem FLASH ohne zusätzlichen SRAM zu verbrauchen.


Die Software selber kann
- PNG, BMP, WMF, EMF, ICO, JPEG laden
- in beliebigem Farbformat
- in beliebiger Größe
- das Bild wird runter skaliert auf maximal 176x132 Pixeln wenn nötig, 
Seitenverhältnis wird beibehalten
- die Farbpalette/-anzahl kann reduziert werden
- das Bild kann in 90 Gradschritte rotiert, und gespiegelt werden


Gruß Hagen

Ausschnitt meines bisherigen Codes für meine S65-GLCD des LPH88xxx 
Display (Philips HD66773R Controller).

#include "glcd.h"

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

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


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

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


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

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

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

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

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

[Micha (Gast)]

hi
hat einer vielleicht ein datenblatt zu dem L2F50 zu hand und mag es mal 
posten? habe bis jetzt keins gefunden..

mfg
micha

[Martin B. (mborman)]

Hello,

i've tried to connect my l2f50...  to PIC 18f2550(18f4550) from 
Microchip (using sources from Mark de Jong), but my display is silent.
Can somebody consult me about connection and sources?

I uses 3.0 power supply for both (cpu and display) units, without 
resistors and diodes (direct connection)


PS: to power the backlight I uses the MAX232 chip, powered by 5 volt - 
the output to rsr232 line lets 9.4 volts. It is enought to switch on the 
led.

[Mike B. (mikebird)]

Hallo,

nun doch noch in diesem Jahr bin ich dazu gekommen,
mich ein wenig weiter mit meinem Konverter zu beschaeftigen.
Sprich, ich hab mal wieder die letzte Nacht zum Tag gemacht.

Folgende Aenderungen sind nun im Tool vorgenommen worden:
- Etliche Bugs im Filebrowser behoben
- Dabei auch ein wenig an der Optik und Struktur gefeilt
- als Ausgabeformat fuer Bascom unterstuetzt er nun:
  1. Bascom 16Bit Raw Data (wie zuvor auch)
  2. Bascom 8Bit Raw Data (direkte Ausgabe HiByte/LoByte)
  3. Bascom 8Bit RLE Data (wie oben, nur mit einfacher RLE Compression)
  Alle 3 Formate erhalten einen anderen Ausgabenamen,
  daher auch ist es auch Problemlos moeglich, nacheinander
  alle 3 Codierungen durchlaufen zu lassen, und zu vergleichen.
  (Eben halt ob die RLE Kompression in dem jeweiligen Fall etwas bringt)
  Zudem wird auch nach der Konvertierung die Anzahl der benoetigten
  Data Bytes angezeigt.

Die Assembler Source Ausgabe ist gerade in Arbeit, und wird vielleicht
schon morgen als Version 1.6 hier zu finden sein.

Wer Verbesserungsvorschlaege hat, bitte mailt mir (PN) oder einfach hier 
ins Board schreiben.

Bis dahin erstmal liebe Gruesse aus dem hohen Norden
Mike

[Mike B. (mikebird)]

Tja, manchmal gehts schneller als man denkt.....
Schiebe hier nochmal schnell die Version 1.6 nach.
Hab kurz die Assembler Hex Sourcecode Ausgabe mit eingebunden.

Achja, der Name des Tools hat sich noch geringfuegig geaendert,
da es ja nun nicht mehr fuer Bascom alleine da ist.

Viel Spass damit

Gruss Mike

[Mark de Jong (Gast)]

Hello Martin,

Here is the latest library, perhaps there where some errors in the other 
library.
This one is test and work with my target (C164, C165 and C167)

Regards Mark,

[Martin B. (mborman)]

Hello, Mark,

> Here is the latest library, perhaps there where some errors in the other
> library.
> This one is test and work with my target (C164, C165 and C167)

Thank You, very much.

But I've still having problem - nothing appears on screen.

When I tries to remove cpu from slot, the "garbage" is appears on the 
display or, (offtenly) display becomes black; but when I drops CPU back 
and switch on the device - screen keeps white. After InitDisplay the 
FillScreen (with RED color) calls, but nothing happens.

Can You, please, help me to understand the problem?
May be, i have not L2F50? (but it seems like L2F50 from Kranz site).

[Mark de Jong (Gast)]

Hello Martin,

Ok, then it is normal my SW doesn't work, I wrote it for the LS020.
As soon as I get a L2F50 display I will adapt the SW.

Regards Mark,

[Kay (Gast)]

@Mike Bird,

wie binde ich denn die DATA in Bascom ein ? Restore Bildname ..... ?
ich bekomms nicht hin.

kannst Du mir helfen ?

mfg Kay

[Kay (Gast)]

@Mike Bird,

habs hinbekommen. danke. Kann ich denn irgendwie bestimmen, an welcher 
position das Bild angezeigt werden soll ?

mfg Kay

[Mike B. (mikebird)]

@Kay,

das sollte doch eigentlich einleuchtend sein.
Nochmals anhand der alten Routine, wenn Dein Bild Beispielsweise 96x32 
gross ist:
------------------------------------------------------------------------ 
--
X2= 40            <- Hier kannst Du Deine horizontale Verschiebung 
angeben
Y2= 30            <- Hier kannst Du Deine vertikale Verschiebung angeben

Restore Bildname
Read X            <- liest hierbei 96, als Bildbreite
Read Y            <- liest hierbei 32, als Bildhoehe
X = X - 1         <- korrigiert X um -1 da 0-95 = 96 Bildpunkte ergibt
Y = Y - 1         <- korrigiert Y um -1 da 0-31 = 32 Bildpunkte ergibt

For Y1 = Y2 To Y+Y2   <- wuerde dann bedeuten Y1 zaehlt von 30 bis 61
For X1 = X2 To X+X2   <- wuerde dann bedeuten X1 zaehlt von 40 bis 135
Read Z

Gosub Lcd_pset '(Subroutine setzt einen Pixel an X1,Y1 mit der Farbe Z)

Next X1
Next Y1
------------------------------------------------------------------------ 
--
Nun setzt er Dir Deine Bildpixel an zwischen 40,30 (x,y) und 135,61.

Du solltest Dich vielleicht erstmal ein wenig mit Basic vertraut machen, 
und Dich fragen, was wohl in den jeweiligen Zeilen passiert.
Probiere es einfach aus, veraendere Variablen oder schaue in die Hilfe 
vom Bascom.
Nur so kann man als Anfaenger verstehen, was man eigentlich macht.
Auch wenn fuer Dich dann zu Anfang die Programme mehr einer "Was 
Passiert Dann ?" Maschine gleicht.
Anders habe ich damals (1981) mit meinem ZX81 auch nicht dessen Basic 
gelernt.

Liebe Gruesse
Mike

P.S.: wenn Du Dich hier anmeldest, kannst Du mich auch gerne per PM 
kontaktieren.

[Kay (Gast)]

@mike Bird,

danke für den Code. habs ausprobiert. klappt fast. die "Startposition" 
ist die Richtige. Nur verschiebt sich das Bild. Wir quasi umgeklappt. 
Aber wie ich versuch das selbst hinzubekommen.Hat mit HardSPI geklappt, 
werd das auch noch hinbekommen. Hast ja recht :-)

mfg Kay

[Mike B. (mikebird)]

@Kay
Meld Dich doch kurz hier an, dann brauchen wir nicht das Forum 
dichtzuschreiben (PN / E-Mail)

Gruss Mike

[Martin B. (mborman)]

Hello everybody,

in attachment You can see the datasheet for mysterious L2F50.

I hope, it can be helpful.

PS: unfortunately, this is draft, but man who hat sent me this file says 
that all commands are correct.

[Joghurt3000 (Gast)]

Hallo,

ich habe hier ein LPH8836 an einem ATMega16 mit 16MHz Quarz. Das Display 
bekommt von einem LM317 2,92V auf den Eingängen 2v9 und 1v8 und die 
anderen Leitungen Clock, Data, etc. sind über einen 74hc4050 mit dem AVR 
verbunden (GND hängt auch am LM317). Ich habe mal die Ports einzeln über 
Software aktiviert und gemessen ob dort eine Spannung zu messen ist wo 
eine zu messen sein sollte und demnach ist alles korrekt verdrahtet. Das 
Display bleibt allerdings "schwarz". Ich habe die V01 & V02 ausprobiert, 
gleiches Resultat. Hat jmd. vllt. eine Idee woran es liegen könnte? Ist 
der Level-Shifter schuld? LowFuse ist auf 0x3f programmiert womit der 
externe Oszi verwendet werden sollte und mit F_CPU=16000000 sollte es 
dann auch alles rictig getimed sein, oder? (hfuse=0x99)


Beste Grüße J3k

[Joghurt3000 (Gast)]

Hallo,

ich habe hier ein LPH8836 an einem ATMega16 mit 16MHz Quarz. Das Display 
bekommt von einem LM317 2,92V auf den Eingängen 2v9 und 1v8 und die 
anderen Leitungen Clock, Data, etc. sind über einen 74hc4050 mit dem AVR 
verbunden (GND hängt auch am LM317). Ich habe mal die Ports einzeln über 
Software aktiviert und gemessen ob dort eine Spannung zu messen ist wo 
eine zu messen sein sollte und demnach ist alles korrekt verdrahtet. Das 
Display bleibt allerdings "schwarz". Ich habe die V01 & V02 ausprobiert, 
gleiches Resultat. Hat jmd. vllt. eine Idee woran es liegen könnte? Ist 
der Level-Shifter schuld? LowFuse ist auf 0x3f programmiert womit der 
externe Oszi verwendet werden sollte und mit F_CPU=16000000 sollte es 
dann auch alles rictig getimed sein, oder? (hfuse=0x99)

Achja, MOSI->DAT, oder?

Beste Grüße J3k

[Joghurt3000 (Gast)]

Hallo,

ich habe hier ein LPH8836 an einem ATMega16 mit 16MHz Quarz. Das Display 
bekommt von einem LM317 2,92V auf den Eingängen 2v9 und 1v8 und die 
anderen Leitungen Clock, Data, etc. sind über einen 74hc4050 mit dem AVR 
verbunden (GND hängt auch am LM317). Ich habe mal die Ports einzeln über 
Software aktiviert und gemessen ob dort eine Spannung zu messen ist wo 
eine zu messen sein sollte und demnach ist alles korrekt verdrahtet. Das 
Display bleibt allerdings "schwarz". Ich habe die V01 & V02 ausprobiert, 
gleiches Resultat. Hat jmd. vllt. eine Idee woran es liegen könnte? Ist 
der Level-Shifter schuld? LowFuse ist auf 0x3f programmiert womit der 
externe Oszi verwendet werden sollte und mit F_CPU=16000000 sollte es 
dann auch alles rictig getimed sein, oder? (hfuse=0x99)

Achja, MOSI->DAT, oder (da sollte er ja rausshiften als master)?

Beste Grüße J3k

[Michael I. (iller101)]

Also der HC4050 funktioniert auf alle Fölle den hab ich bei mir auch 
verbaut.

[Roland B. (micfan)]

Hallo,
ich bin mir nicht sicher ob das angegebene Code Beispiel "simple_display 
LPH_display4_V02" für das LPHxxx Display so funktioniert. Dort sind 
Zeitmarken "start at 355ms" angegeben, die für meine Begriffe ohne 
zugehörigen wait Aufrufe nicht eingehalten werden. Habe die Hardware 
genau so aufgebaut, wie dies auf der Seite von Christian angegeben 
wurde. Bei meinem Display sehe ich nur die Hintergrundbeleuchtung. Habe 
also auch genau das gleiche Problem wie Joghurt3000. Ich stehe jedoch 
noch komplett am Anfang und muss mir die Initialisierung noch genau 
anschauen.

Grüße Roland

[Hauke R. (lafkaschar)]

Ich hab das bei mir mal getestet (auch LPH display) und es ging, ich 
hatte aber keine pegelwandlerbauteile dazwischen hab den Mega16 direkt 
mit 2,9V befeuert.

[Roland B. (micfan)]

Hallo Hauke,
verstehe ich dich richtig, Du verwendest das Beispielprogramm "LPH 
simple.." ohne Änderung mit einem ATmega16 und mit 16 Mhz Takt ? Ich 
frage wegen dem Timing..

Gruß
Roland

[Hauke R. (lafkaschar)]

Jo mega 16 16MHz ..

[Roland B. (micfan)]

Vielen Dank Hauke,
dann kann ich meine Fehlersuche einschränken. Mein ATmega128 läuft mit 
5V und ich verwende die angegebenen Spannungsteiler. Bin leicht 
verwundert dass Dein ATmega16 mit 16 MHZ bei 2.9V läuft. Das würde bei 
mir einiges vereinfachen.

Gruß
Roland

[Roland B. (micfan)]

Hallo,
mein LPH Display läuft jetzt!

Ich musste jedoch das Beispielprogramm ändern...

Das folgende Konstrukt wurde von gcc beim compilieren mit einer Warnung 
versehen, dass die Verarbeitungsfolge der Variablen j nicht garantiert 
ist.
Ich hatte die Fehlermeldung zuerst ignoriert, da es ja ein erprobtes 
Beispielprogramm ist... ??

hier der Abschnitt:
// starts at 125ms
  j=0;
  for (i=0; i<6; i++)
  {
    lcd_comtype(ct1[i]);
    lcd_comdat(cd1[j++],cd1[j++]); <-- hier ist nicht garantiert,
        welchen j-Wert param1 und param2 von lcd_comdat erhält.
  }

wenn die Reihenfolge des inkrement definiert ist, dann funktioniert's
// starts at 125ms
  j=0;
  for (i=0; i<6; i++)
  {
    lcd_comtype(ct1[i]);
    lcd_comdat(cd1[j],cd1[j+1]); <- keine Compilerwarnung
    j+=2;
  }

Das Ganze wiederholt sich noch 3 mal im Programm für cd2, cd3 und cd4

Hier die Frage an die Experts... kann es an der Compilerversion liegen?
Ich arbeite mit winXP und AVRStudio und verwende WinAVR 20060421 mit 
libc 1.4.5

Gruß
Roland

[Hagen R. (hagen)]

das kann schon am Makefile liegen, sprich den Compilerswitches. Ist halt 
C wo solche "Ungereimtheiten" möglich sind ;)

Gruß Hagen

[C. Kranz (Gast)]

Das wird wirklich am Compiler liegen. Die Beispiele wurden mit einer 
gcc-Compiler Version 3.x aus 2005 kompiliert. Ich glaube nicht, dass es 
damals überhaupt Warnungen gegeben hat. Normalerweise versuche ich immer 
alle Warnungen zu beseitigen.

Die Zeiten in den Kommentaren beziehen sich auf die gemessenen Zeiten am 
Handy. Die Initialisierung im Beispielcode läuft viel schneller ab als 
im Original und funktioniert auch so. Man muss keine waits einbauen.

Grüße
  Christian

[Dennis (Gast)]

Hallo,

ich habe mir jetzt auch zwei Displays unterschiedlicher Anbieter 
besorgt.

Leider werde ich das ganze auf einem Fujitsu Controller implementieren. 
Ich habe diesen Thread fast komplett durch geackert, und bin momentan 
noch ein wenig überfordert.

das linke müsste der letzten Versio des allround pdfs das Lso20 sein, 
und das rechte das L2f50....

Anschlussbelegungen habe ich auch gefunden.. also werde ich erstmal den 
Testaufbau rein harwaremässig vornehmen.

mit den Initsequenzen kann ich noch nicht zu 100% etwas anfangen, da 
fehlen mir noch ein paar timing angaben, von denen ich hier auch schon 
einige gesehen habe.

wenn dort etwas in 16bit hex aufgeführt ist, dann fehlt mir eigentlich 
nur:

wann muss welche leitung auf high-bzw low, Msb first oder last....

und bei den bmp toolz, die ich übrigens sehr sehr nett finde, fehlt mir 
vielleicht noch die angabe, wieviel bit in welcher reihenfolge für 
welche farbe vorgesehen ist. es war da mal was von RGB 5/5/6 im gespräch 
meine ich...

ich verfolge diesen thread schon recht lang, und intensiv gelsen habe 
ich vor ca 2 monaten, dann kamen mit einiger verzögerung die displays, 
und jetzt so langsam ist mal wieder etwas luft...

vielleicht kann mich ja noch jemand mit der nase in eine fehlenden info 
drücken....

dank euch,
Dennis

[Dennis (Gast)]

..ach ja, ich vergaß,

ich bin kein atmel nutzer, toggelt ihr die pins mit entsprechenden 
befehlen, oder setzt eure kommunikation grundsätzlich auf einem bereits 
vorhandenen uart auf!?

dennis

[Hauke R. (lafkaschar)]

Das ganze läuft per Hardware SPI oder?

[C. Kranz (Gast)]

Die ganzen Beispiele laufen auf dem Hardware SPI Interface des ATmega, 
grundsätzlich ist auch SW Port-Toggling möglich.

Für die Polarität und Flanken der Signale gehst du am besten auf die 
Reenginieering Seite der web-page. Dort kannst du ein paar gemessene 
Screen-Shots runterladen. Die zeigen Phase- und die Polarität der 
Signale. Die sind bei allen Displays für Clock- und Daten gleich. MSB 
first transmission.

Alternative ist Atmel-Data Sheet und Hardware SPI Initialisierung 
vergleichen....

Grüße
  Christian

[Dennis (Gast)]

Hallo,

dank dir,

damit vervollständigt sich mein Bild zunehmend schnell!!!

Dennis

ps.: eine kleingkeit noch, hälst du das bild im speicher zwischen, oder 
liest du auch daten zurück um einen pixel einzumaskieren..? aber 
warscheinlich ist eh für jeden pixel eine farbkombi vorgesehen...werde 
ich dann ja im quelltext auch finden...

vielleicht kann ich ja einiges wiederverwenden... wenn der quelltext auf 
einer art "write data, write inst" und "read date, falls nötig" besteht, 
und darauf aufsetzten eine init() und einer write befehl, 
write(x,y,color) ansetzt, sollte man das ja recht schnell auf unterster 
ebene angeflickt bekommen...

[James (Gast)]

Hallo,

Ich wollt mal vorsichtig fragen ob sich jemand mit der glcd für L2F 
Display beschäftigt hat. Und weitergekommen ist.
Ich hab ein lauffähiges Display mit einem Mega32 aufgebaut.
Da ich erst Anfänger bin war es für mich schon ein Erlebnis, eine 
Temperatur auf dem Display anzeigen zu lassen.
(Großer Dank geht an Christian Kranz.)
Aber ich würde gerne die Schriftart verändern und ein bischen 
Hintergrund hinzaubern.
Hat jemand vielleicht ein TIP für mich.
Ich dachte zuerst an GLCD. Aber es funzt ja noch nicht oder?

[Thomas R. (thomas-r)]

Hallo,

ich möchte das LS020... mit eurer Lib in WinAVR zum Laufen bewegen.

Leider bisher ohne Erfolg. Mit einem angepaßten BASCOM-Programm (sorry!) 
funktioniert die Ansteuerung...

Meine Hardware ist ein Butterfly mit direkt angeschlossenem Display.

Ich verwende WinAVR (20060421) mit Programmers Notepad 2.

Den Takt und die CPU habe ich angepaßt. Entsprechend der Anleitung. Die 
Pinbelegung ist analog meinem Bascom Programm. Es erscheint nichts auf 
dem Display.

Die Programmierung mit WinAVR funktioniert ebenfalls, da meine 
ASURO-Programme  laufen.

Hat jemand eine Idee, wo ich den Fehler noch suchen könnte? Hat jemand 
für meine Hardware schon einmal ein Programm compiliert?

Wer kann helfen?

Gruß Thomas!

[aethr (Gast)]

@lupin

am trying to get a LPH display to run on an LPC2148 and am not having 
success. The code you posted looks similar to my port of disp.c. Looking 
at my scope, all signals look fine; cs is asserted low as is reset and 
sck and miso data are all there.

I connected rs to +, have you tried using software command/data or are 
you using rs?

What SPI settings do you have? Can you post your code including SPI? 
Have brought SPI speed down to 500k.

Any ideas what might be wrong?

Thanks,

aethr

[Lupin (Gast)]

Sorry, i have no idea. because i don't have the code/hardware any more. 
I think RS is not connected on the LPH display.

[aethr (Gast)]

@lupin

ok, thanks, digging further ;)

aethr

[aethr (Gast)]

OK, have it working now. It needed a delay of about 2 us in the SPI 
write function. Digging through this extremely large thread I found 
Lupin needed to do this as well with his LPC setup.

For the record, can run SPI now at clk/8, the fastest possible for the 
LPC2148.

aethr

[Christian K. (christiank)]

Hi aethr,

may i ask you for posting the source code for the LPC4148 here? That 
would save me and others the trouble of porting the code...

BR
  Christian

[aethr (Gast)]

Hi Christian,

yes, I will. I do have to factor out the code from my project, so needs 
a little time.

While cleaning up the code, ran into a problem that I didn't have 
before. After I reset the LPC, the screen becomes faintly green colored 
instead of bright, a power cycle fixes the problem till the next reset.

Now I remember reading on this thread about it, but the thread has 
become so large, it's very hard to find back.. I do think the problem 
relates to timing reset and/or init sequences.

Anyone with a hint?

Thanks,

aethr

[aethr (Gast)]

Quick note: indeed was a timing issue with reset. When the delays around 
reset become too large, screen doesn't initialize properly.

aethr

[aethr (Gast)]

Spoke too soon.. after it worked for a while, the bad 'bleeched' colors 
came back. It's strange, when I power up the board+display, 
initialization is fine; nice vibrant colors.

When I give the board a reset, the display gets the init sequence as 
before, but the colors look very faint, with a shadowy appearance..

Anyone seen this?

Looking at the datasheet and the init sequence, I wonder about this:

LCD_RESET;    // reset display, low (pseudo code)
LCD_CS;      // CS is high during reset release

delay_ms(1);    // must be held low for at least 1 ms, page 48
LCD_RESET;    // release reset, high
delay_ms(10);
LCD_CS;      // select display, low

// starts at 58.8ms
lcd_comtype(0x00);
lcd_comdat(0x00,0x01);  // this actually starts the oscillator, so now 
wait at least 10 ms?


So after the reset goes high, a 10ms delay is given. Then a command type 
0x00 is given which starts the oscillator. As per datasheet, a 10ms 
delay should be issued, but this is not done in the original sequence.. 
why?

Also when I do use a delay after the osc. command, I don't see any 
change. I was hoping the osc. didn't have time enough to stabilize, 
hence the bad display quality.

Any ideas?

aethr

[aethr (Gast)]

ACHTUNG, WARNING, don't drive the LPH display directly with 3.3V on 
logic and supply! After a day of operation, the display started to 
behave erratically; starting with faint colors after reset (but not 
after power up) and later displaying erroneous data before dying 
completely.

Also the logic lines were not able to go high anymore and kept a level 
of ~2V instead of 3.3V. Apparently logic was pulling considerable 
current as the LPC2148 got confused and couldn't finish initialization.

Ok, one dead LPH display.

Hooked up a new one with a 470/68 voltage divider on logic lines and 
2.9V supply; one happy display with nice colors and speed.

So whenever faint colors are seen on the display, power down immediately 
and fix voltage levels!

BTW, just before it died, had enabled vertical scrolling with just two 
commands, only too bad it wraps the screen around and doesn't do 
horizontal(?). The chip also supports interlaced drawing for animated 
graphics, logic operations and boundary drawing.. some more stuff to 
hack into ;)

aethr
ps: pulling the LPH apart revealed three white LEDs connected in series; 
this was of course expected.

[Hagen R. (hagen)]

>> logic operations

only two of the six logic modes are present into serial communication. 
The important and most usefull modes don't work. The only useable modes 
are

LG0-2 = 000 Replace, normal mode
LG0-2 = 110 Write Data correspondend
LG0-2 = 111 Write Data not corresponend

The last two can be used to support transparency on fonts or bitmaps 
without filtering in software of the transparent color. On some 
circumstances this can speedup data transmission, eg. on small 
pixelparts that need less pixeldata compared to a rewrite of the address 
window and cursor.

All other modes seems to requiere a parallel data interface because they 
use the data-read-latch for the boolean operations. It seems this is not 
correctly read in SPI serial mode.

If it instead should work in your tests then inform me please. But i 
think i do it all right.

Scrolling is solved badly by the controller and splitscreens are not 
very usefull.

Remarkable are the very flexible memory adressing.


Greatings Hagen

[Hagen R. (hagen)]

i forgot to say, my GLCD are ready for the LPH. Its based and most times 
compatible to my Nokia GLCD.

Best reagrds, hagen

[aethr (Gast)]

Thanks Hagen for the response. A drawback of using display specific 
functionality is portability, I'll have a look at the thing and see what 
comes out.

This also raises a question about your glcd lib, I've seen two versions, 
one written in C and the other in AVR assembly. What version are you 
referring to? If it's in C I can use it on my ARM LPC2148 chip, which is 
much faster than the AVR and therefore doesn't need assembly. (and is 
portable as well)

aethr

[Hagen R. (hagen)]

Its a fully rewrite in C. The mcu depended stuff are implented as 
macros. Thus should be easily portable.

Best Regards, Hagen

[Andreas B. (ofenandreas)]

Hallo miteinander,
zuerst einmal ein ganz großes Kompliment an alle die hier so viel Arbeit 
reingesteckt haben! SUPER!!!

Ich habe folgendes Problem mit der GLCD - bis zum m128 alles o.k., aber 
nun möchte ich einen m2561 einsetzen, in der GLCD.INI neue Sektion 
eingefügt, Headerfiles besorgt. Dann versucht zu builden.

Jetzt haben aber die m***1 das  LCD_SPCR auf $2C und LCD_SPSR auf $2D. 
SBI und SBIS können aber nicht auf Add > 32 zugreifen - wird in 
GLCD_INIT.ASM Zeile 91 und 94 benutzt.
Man könnte in Register kopieren, bearbeiten und zurückschreiben - Meine 
Frage - welches Register benutzen (möglichts ohne 
Sicherungsnotwendigkeit).

Bis jetzt die einzige (gemeldete) Inkompatibilität - sind noch mehr 
Probleme zu erwarten?

Für Hilfe wäre ich dankbar.
Gruß Andreas

[Fabian B. (fabs)]

@Hagen:
mag komisch klingen die Frage: wo finde ich deine GLCD-Lib? Ich hab 
gestern hier im Thread um im Forum gesucht, wurde aber nicht fündig...
Isses so offensichtlich dass ichs nicht sehe?

Gruß
Fabian

[Hagen R. (hagen)]

Die Nokia GLCD gibts in verschiedenen Versionen hier im Forum oder bei 
www.apetech.de. Allerdings sind die neusten Versionen hier im Forum -> 
Thread mit "Nokia 6100 Lib die zweite" oä.

Die GLCD fürs LPHxxxx kann bei mir per EMail angefragt werden -> 
hareddmann bei t bindestrich online punkt de. Frei veröffentlichen werde 
ich sie diesesmal nicht.

In kurz die Feature:

- Pixel, Linien, Rechtecke, abgerundete Rechtecke, Ellipsen, Kreise
- Fonts aufbauend auf Nokia GLCD 2.2, sprich mehrfarbig, komprimiert
- FontEditor für den Windows PC mit Import und Konvertierung von 
TrueType-Fonts
- Bitmaps in Unichron, Monochrom komprimiert per RLE, 3-15 Bit Farbtiefe 
komprimiert per Farbtabelle und quasi Huffman, 16 Bit Vollfarben 
unkomprimiert
- Bitmaps unterstützen Transparenz
- Dekomprimierung der Bitmaps läuft auf dem AVR mit 16Mhz und 8Mhz 
HW-SPI fast ohne Waitstates, dh. wir erreichen annährend vollen SPI 
Datendurchsatz beim Darstellen der Bitmaps obwohl noch Dekomprimiert 
wird.
- für die Bitmaps gibts vergleichbar zum FontEditor eine PC Software, 
sie kann JPEG,BMP,WMF,ICO,PNG importieren, skaliert die Bilder 
nötigenfalls auf Displaygröße runter, rotieren, spiegeln und ganz 
wichtig Farbreduzierung. Die druchschnittliche Kompressionsrate beträgt 
200% und ist damit effizienter als PNG. Export in C Header Dateien.
- Bitmaproutinen sind die einzigsten die Inline ASM Makros benutzen und 
somit inportabel sind. Der dazugehörige funktionale C Source ist aber 
noch enthalten, kann als wieder aktiviert werden.

Nicht drinnen ist das Clipping wie bei der Nokia GLCD. Es kosten viel 
Rechenpower, gerade wenn man nur in reinem C codet. In den meisten 
Fällen wird man eh Pixelexakt seine Grafiken zeichnen.
Ebenfalls nicht vorhanden ist die Rotation in 90 Grad bei den 
Fontzeichenroutinen. Man kann hardcoded die Orientation des Display 
einstellen in 90 Grad Schritten + Spiegelung, aber eben nicht dynamisch 
zur Laufzeit die Rotation der Fonts. Auch das ist ein Feature das 
nachimplementierbar ist aber meistens nicht benötigt wird.

Zusätzlich drinnen ist aber ein komplettes Menusystem.
- alle Daten im FLASH
- Event/Ereignisorientiert
- benutzt vollständig nur die Fontzeichenroutinen und glcdFillRect(), 
keine andere Grafikfunktion
- Anzeige von Icons pro Menu
- einstellbare Farben pro Menu
- komplette Bedienung funktioniert mit Rotary-Encoder, aber eigene 
Bedienungslogiken sind einfach durch ändern einer einzigsten Event 
Routine möglich
- Menus sind scrollbar
- die Menuitems zeigen ihre Caption an und gleichzeitg auch den Wert den 
man damit editieren kann, dh. im Menu selber kann man die einstellbaren 
Paramater anzeigen und editieren
 unterstütze Editoren sind -> Zahlen im Bereich von bis, Enums mit 
auswählbarer textanzeige pro Wert, Texte/Strings mit 
Löschen/Einrückungen/Cursor/Groß-Klein-Sonder Buchstaben/Ziffern

Die ganze Lib gibts als Source der
- komplett alles in einem enthält
- aufgesplittet nach jeder Funktion und somit kompilierbar als echte 
Lib-Library bei der der GCC-Linker nur die benötigten Funktionen 
einlinken kann

Insgesamt 65Kb an Sourcen. Im Aanhang das Menusytem+Bitmaps in Aktion.

Gruß Hagen

[Hagen R. (hagen)]

Achso:

die Lib ist momentan nur füs LPHxxxx Display, da wir dort das offizielle 
Datenblatt des Controllers haben und dieser eben die nötigen DisplayRAM 
Addressierungen unterstützt damit wir das Display in jeder möglichen 
Ausrichtung/Einbauweise ansprechen können.

Nur 2 Funktionen -> Fonts/Bitmaps machen zusätzlich von speziellen 
Boolschen Operationen des Display gebrauch (Tranzparente Farbe 
ausblenden). Das lässt sich aber in beiden Funktionen auch in Software 
machen und sollte leicht abzuändern sein.

Die Ansteuerung der Hardware ist komplett mit Makros gemacht und richtet 
sich immer nach der gleichen Logik -> LCD selektieren -> 
Daten/Kommandomodus auswählen -> Pixeldaten senden -> Warten auf SPI -> 
LCD deselektieren. Es müsste also einfach sein die Lib an andere 
Displays anzupassen.

Eines muß man aber bedenken: Wenn man schon mit verschiedenen Pixelfonts 
und aufwendigen 16Bit Bitmaps/Icons und komfortablen Menus arbeiten 
möchte so ist klar das nur ein großer ATMega mit 16/20Mhz Takt und >= 
32Kb sinnvoll ist. Bei meinem Drumprojekt verbrauche ich fast die ganzen 
oberen 64Kb an FLASH eines ATMega128 für diese Daten. Der SPI Takt 
sollte 8Mhz sein da ansonsten die Ansteuerung des Displays zu langsam 
und damit flickerig wird. In meinem Projekt kann man die Menus absolut 
flüssig und verzögerungsfrei bedienen, auch beim Scrolling des Menus. 
Das ganze Drumprojekt benötigt zur Bedienung nur einen Rotaryencoder, 
wobei man dazu bedenken muß das man im Menu mit diesem Encoder auch sehr 
schnell zb. Namen als Strings eingeben kann.

Und wie immer -> Dokumentation ist keine ;)

Gruß Hagen

[Michael R. (rubi)]

Hallo Hagen

Toll!
Gratuliere!

[Ralf (Gast)]

Hallo,
ich finde das sehr interessant was Ihr hier geleistet habt. Respekt.

Ich habe ein Display mit dem Controller NT3911 hier vor mir liegen und 
habe festgestellt, dass der dem HD66773 bis auf 2 bit im Befehlssatz 
ansonsten genau gleicht.

Ich möchte das gerne ansteuern und hab auch schon eniges versucht nur 
klappt das irgendwie nicht. Ich glaube das initialisiert sich nicht 
richtig.
Meint Ihr Eure Routine funktioniert auch bei diesem Kontroller?

Falls ja, könntet Ihr die bitte mal posten oder an meine Email schicken?
ich arbeite mit einem MSP430 deswegen kann ich das wohl eher nicht so 
übernehmen.

Danke und liebe Grüße
Ralf

[Hagen R. (hagen)]

Welche 2 Bits wären das ?

DU möchtest Hilfe also sendest DU eine EMail die man dann beantworten 
kann. Da du keine EMail angegeben hast kann man DIR keine EMail senden, 
ergo meinst du das man hier den Source posten sollte. Und wenn man das 
nicht möchte ?

Gruß Hagen

[Ralf W. (schumbi)]

Hallo,
uieh sorry hatte eher so das Gefühl dass es sich hier um ein Forum 
handelt, wo man rein schreibt was man für Sorgen hat.
Und ich bin leider so neu hier, dass ich noch davon ausgegangen bin 
lieber niemanden gleich persönlich anzuschreiben.

Das Datenblatt für den NT3911 
(http://newsletter.spezial.de/pdfdata/NT3911_V05.zip)

Also die Unterschiede zwischen dem NT3911 ( Datenblatt im Anhang oben) 
sind dass der NT3911 im Gegensatz zum HD66773R ein paar veränderte und 
noch ein paar zusätzliche Register kennt.

1. der Device code für R00h ist 3911

2. R05h (Entry mode) hat ein benutztes Bit (DIT) mehr

3. 5 Register mehr:
  - R23h, R24h für Write data Mask
  - R25h, R26h als Compare register
  - R50h OP-Amp Control

Die Instruction Set Initialisierung ist die gleiche bis 7.(HD6673 ist 
das g Compare Register)

Ich betreibe den NT3911 mit einem MSP430 und zwar über das 16bit 
Interface.

Die Probleme mit denen ich kämpfe:

1. Was kommt zuerst?

Es gibt in den Datenblättern einmal die Instruction Set Initialisierung 
und dann noch den Instruction Setting Flow.  Mit welchem der beiden 
beginne ich den, wenn ich meinen Controller und das Display einschalte?
Oder ist die Instructionset Initialisierung automatisch vollzogen wenn 
der POR gemacht wird?

2. Die Befehle übermitteln

Muss ich, wenn ich einen neuen Befehl übermitteln will den NT3911 bzw 
HD66773 das irgendwie anzeigen? also muss ich das Schreibe-Signal 
toggeln?
Ich weiß Ihr macht das mit SPI und da wird eh ein für den Controller 
externer Takt verwendet aber vielleicht hat damit ja schon mal jemand 
Erfahrungen gemacht.


lG Ralf

[TeraByte (Gast)]

Hallo S65-AVR Progger!

Vielleicht könnt ihr mir weiterhelfen!

Habe ebenfallt ein Atmega128 + S65 Display (scheinbar SPI-Mode, by 
Superkranz)

Nun habe ich folgendes Problem: Möchte gerne PowerBooster für die 
Hintergrundbeleuchtung einrichten und muss Pin PB7 auf ein anderen 
legen.
Nun, ich ändere im "define" den PB7 auf z.B. PB5 und nix passiert.

Display läuft immernoch auf PB7, woran kann das liegen.

Bin schon am verzweifeln, da ich definieren kann, was ich will, aber es 
ändert sicht nicht. Bitte nun um hilfe.

Viele grüße an euch, genialer Thread
Martin