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
...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
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 ?
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...
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
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
@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
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
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
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
Hallo, ich habe einen LM317 L genommen. Mit R2= 330 Ohm und R1= 240 Ohm kommt man auf 2,9 Volt. Gruß Bernd
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é
@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
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
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
@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.
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
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
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.
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
Hallo! meine die hier genannten init-Daten http://www.superkranz.de/christian/S65_Display/DisplayProgramming.html
keine Ahung sind von Christian K. analysiert worden. Da es kein datenblatt gab.
@Andre: Wozu dienen die Routinen Defpartxyxyh und Defpartxyxy und welche Parameter werden dort eingetragen? Kann das sein das es ein Ausgabebereich def. wird?
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é
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
@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.
rotfuchs: Die musst du über SPI an das Display schicken...
@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 :-(
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é
also ich benutze nen mega16 mit 16Mhz. Mit Shiftout gehts, nur mit hardware SPI nicht. mfg Kay
@Kay: hast du die Hard SPI gegen Shiftout getauscht(Programm aus "S65 mit SPI" )? kannst du dann mal das Programm posten?
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
@ 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
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.
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é
@Andre: wie hoch ist der (unter Option/Enviroment/Compilier) HWSTACK SoftStack unf Framesize ? Und hast du den Code mal auf einen M16 ausprobiert?
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é
@Klappt auch nicht :-( Hat jemand mal das http://www.mikrocontroller.net/attachment.php/420053/S65+mit+SPI.txt ausprobiert? Und was ist das ergebnis?
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
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ß
Hehe und schon einen Fehler im Schaltplan entdeckt...
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 ...
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 ??
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.
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 ...
ñîáñòâåííî, ñàáæ. àìåðû çàðûëè ãîëîâû â ïåñîê, âûñòàâèëè æîïû, êàê ñòðàóñû è æäóò ïîêà èõ òåððîðèñòû ïîèìåþò. íó, â ïðîìåæóòêàõ åùå ìîãóò ñúåçäèòü ïîáîìáèòü Èðàê èëè âðîäå òîãî. áëîã ïðàâäà èçðàèëüñêèé, ñî ñâîèìè óðîäñòâàìè, íî è ñî çäðàâûìè ìûñëÿìè òîæå, http://www.samsonblinded.com/ruindex.html ãóãë åãî ñ ïåðâîé ñòðàíèöû â îäèí äåíü ñáðîñèë íà äåñÿòóþ è çàîäíî çàðïåòèë ðåêëàìó. à ÿ åãî ïî÷èòûâàë èíîãäà, áëèí. òàê ÷òî, íàðîä, òåïåðü ðóñè-àðàáè áõàé-áõàé? íàäîåëî äî ÷åðòèêîâ, èçáàâèòüñÿ áû îò ýòèõ òåððîðèñòîâ, à òî â ñàìîëåò ñåñòü íàïðÿãàåò.
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
"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.
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
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
Um nochmal auf meine Frage (weiter oben) zurückzukommen. 49 Downloads und keiner weis eine Antwort??
Und auf meine auch nicht, wo bezieht ihr eure siemens-displays her, die eindeutig identifizierbar sind?
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
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.
Danke, dann gönne ich mir doch mal so ein lph :)
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
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?
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...)
@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ß
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.
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: Bernd888@gmx.net
Danke; für den ersten Test will ich die Hintergrundbeleuchtung einfach anlassen. Die Schaltung ist nur dafür gedacht, das Display auszuprobieren. Gruß
Bernd ich glaube, da suchen hier sehr viele nach
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
@Bernd
> habe das Datenblatt für den HD66773 gefunden
Das ist doch schon alles vor einem Jahr ausdiskutiert worden.
@ 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
Datenblatt Seite 7 RS: "When using SPI, fix it to Vcc or GND level"
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
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.
Hi, I finded this link and it´s very interesting, have information about all controler HD66XXX.
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/
Hallo, den HD66773 auf dem Siemens S65 kann man scheinbar auch mit 3,6V betreiben. Kann das jemand bestätigen? Gruß
Der controller schon, das Display selbst nicht. Wenn man das Display mit mehr als 2,9V betreibt werden die Farben extrem unschön.
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ß
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?
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ß
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.
macht der MSP keine 3,3V mit? ich dachte schon oder? sonst ein einfacher Spannungsteiler funktioniert bei kurzen leitungen als pegelwandler sehr gut :>
Hallo, Der MSP macht die 3,3V schon aber da hat der keine 8MHz. Ich denke ich muß den uC mit 8MHz takten. Gruß
Achso, dann würd ichs mit Widerständen probieren, wenn deine Kabel nicht allzu lang sind ist das kein Problem.
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
@MC_bernd: gehts auch bei 3,3V mit deinen GLCD ?
@ AVRNix Hallo, habe 3,3V nicht ausprobiert, da es für mich keinen Grund gibt, das Display mit Überspannung zu betreiben! Gruß Bernd
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.
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.
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
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
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
Mal ne Frage: Wie generiere ich aus 16 MHz Haupttakt die 13 MHz SCK? Laut datenblatt gehts bei F_CPU/2 los...
zu 13MHz: gar nicht, das SPI läuft dann mit 8MHz. Was ist ein pn2? (neugestartet und es geht??)
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.
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?
hm...kein wunder, hab ja auch nur die abgespeckte lib oben auf deiner seite gefunden, und die unten übersehen....
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
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 :>
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?
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....
@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
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.
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 ;-).
> 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.
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)
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 - läuft es bei dir mit BASCOM über Hard SPI ? Wenn ja wie hast du das angestellt?
@ 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.
@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
@ KennyOswald könntest Du die Firmware für 18F4550 posten, ich bekomme das Display nicht initialisiert? MfG Andi
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
@ Mike Bird: Gibts Fortschritte mit der Hard-SPI ?
@ 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
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
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
Hallo Patrick, du hast wahrscheinlich keinen µC mit 46kByte RAM oder? Darum meckert der Compiler... Grüße SU
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
@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
@Patrick: schaust du hier... http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Speicherzugriffe
@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!
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
Hier noch mal ein kleines Bildchen von meinem "Abfallprodukt" in Funktion. Nun auch mit "Kaffee" als Hintergrund :o)
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ß
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
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.
Oh, ich dachte du nutzt immer noch (?) Bascom. Sorry. Beste Gruesse
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
@ André K Der Index des Array ist aber nur 23232 sollte also reichen? Gruss Patrick
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ß
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
Hallo Steff, hab die bmp Datei ins gleichen Verzeichnis kopiert. geht aber nicht. Programm meldet Datei nicht gefunden? Gruss Patrick
Hallo Patrick, hast du den kompletten Dateinamen also inclusive der Endung .bmp eingegeben? MfG Steff
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
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
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
hmmm email ohne adresse super idee :P naja pn tuts ja auch ;)
Hallo, etwas neues zur Adressierung des LS020 Display RAMs: http://www.superkranz.de/christian/S65_Display/DisplayRamAccess.html
@Christian K. Danke für die neuen infos. @ALL Das PDF-Update ist natürlich auch schon fertig. ~ gruß Lightning
good job... someone, give me the link to a new projects about these topic...
Ist der Konverter weiter entwickelt worden? Und wo bekomme ich den aktuellen Konverter? mfg Lötnix
Hallo, welche Funktionalität bräuchtest du denn? evtl. kann ich dir ja weiterhelfen. MfG Steff
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
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
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).
1 | #include "glcd.h" |
2 | |
3 | uint16_t colormasks[14] PROGMEM = {0x0006, 0x000E, 0x001E, 0x003E, 0x007E, 0x00FE, 0x01FE, 0x03FE, 0x07FE, 0x0FFE, 0x1FFE, 0x3FFE, 0x7FFE, 0xFFFE}; |
4 | |
5 | void glcdDrawBitmap(glcdCoord_t x, glcdCoord_t y, const prog_char* bitmap, uint8_t flags) { |
6 | |
7 | |
8 | #define GLCD_LOAD_BITS(data0, data2, databits, addr, bitsmul) \
|
9 | asm volatile( \
|
10 | "cpi %2, lo8(16)" "\n\t" \
|
11 | "brsh .%=2" "\n\t" \
|
12 | "movw r30, %A3" "\n\t" \
|
13 | "lpm r0, Z+" "\n\t" \
|
14 | "mul r0, %4" "\n\t" \
|
15 | "cpi %2, lo8(8)" "\n\t" \
|
16 | "brsh .%=1" "\n\t" \
|
17 | "or %A0, r0" "\n\t" \
|
18 | "or %B0, r1" "\n\t" \
|
19 | "subi %2, lo8(-(8))" "\n\t" \
|
20 | "lpm r0, Z+" "\n\t" \
|
21 | "mul r0, %4" "\n\t" \
|
22 | ".%=1:" "\n\t" \
|
23 | "or %B0, r0" "\n\t" \
|
24 | "or %1, r1" "\n\t" \
|
25 | "subi %2, lo8(-(8))" "\n\t" \
|
26 | "movw %A3, r30" "\n\t" \
|
27 | ".%=2:" "\n\t" \
|
28 | "clr r1" "\n\t" \
|
29 | : "=r" (data0), \
|
30 | "=r" (data2), \
|
31 | "=a" (databits), \
|
32 | "=r" (addr), \
|
33 | "=r" (bitsmul) \
|
34 | : "r" (data0), \
|
35 | "r" (data2), \
|
36 | "a" (databits), \
|
37 | "r" (addr), \
|
38 | "r" (bitsmul) \
|
39 | : "r0", "r1", "r30", "r31" \
|
40 | );
|
41 | |
42 | #define GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor) \
|
43 | asm volatile( \
|
44 | "movw r30, %A0" "\n\t" \
|
45 | "lsr %1" "\n\t" \
|
46 | "ror %B0" "\n\t" \
|
47 | "ror %A0" "\n\t" \
|
48 | "brcs .%=0" "\n\t" \
|
49 | "dec %2" "\n\t" \
|
50 | "lsr %6" "\n\t" \
|
51 | "brne .%=3" "\n\t" \
|
52 | "ori %6, lo8(0x80)" "\n\t" \
|
53 | "rjmp .%=3" "\n\t" \
|
54 | ".%=0:" "\n\t" \
|
55 | "and r30, %A4" "\n\t" \
|
56 | "and r31, %B4" "\n\t" \
|
57 | "add r30, %A3" "\n\t" \
|
58 | "adc r31, %B3" "\n\t" \
|
59 | "lpm %A7, Z+" "\n\t" \
|
60 | "lpm %B7, Z" "\n\t" \
|
61 | "mov r30, %5" "\n\t" \
|
62 | "cpi r30, lo8(8)" "\n\t" \
|
63 | "brlo .%=1" "\n\t" \
|
64 | "mov %A0, %B0" "\n\t" \
|
65 | "mov %B0, %1" "\n\t" \
|
66 | "clr %1" "\n\t" \
|
67 | "andi r30, lo8(0x07)" "\n\t" \
|
68 | "breq .%=2" "\n\t" \
|
69 | ".%=1:" "\n\t" \
|
70 | "lsr %1" "\n\t" \
|
71 | "ror %B0" "\n\t" \
|
72 | "ror %A0" "\n\t" \
|
73 | "dec r30" "\n\t" \
|
74 | "brne .%=1" "\n\t" \
|
75 | ".%=2:" "\n\t" \
|
76 | "sub %2, %5" "\n\t" \
|
77 | "dec %2" "\n\t" \
|
78 | "mov r30, %2" "\n\t" \
|
79 | "andi r30, lo8(0x07)" "\n\t" \
|
80 | "clr r31" "\n\t" \
|
81 | "subi r30, lo8(-(powerof2))" "\n\t" \
|
82 | "sbci r31, hi8(-(powerof2))" "\n\t" \
|
83 | "lpm %6, Z" "\n\t" \
|
84 | ".%=3:" "\n\t" \
|
85 | : "=r" (data0), \
|
86 | "=r" (data2), \
|
87 | "=a" (databits), \
|
88 | "=r" (colortable), \
|
89 | "=r" (colormask), \
|
90 | "=r" (bpp), \
|
91 | "=r" (bitsmul), \
|
92 | "=r" (bkcolor) \
|
93 | : "r" (data0), \
|
94 | "r" (data2), \
|
95 | "a" (databits), \
|
96 | "r" (colortable), \
|
97 | "r" (colormask), \
|
98 | "r" (bpp), \
|
99 | "r" (bitsmul), \
|
100 | "r" (bkcolor) \
|
101 | : "r30", "r31" \
|
102 | );
|
103 | |
104 | |
105 | if (!(bitmap)) return; |
106 | uint8_t w = pgm_read_byte_inc(bitmap); |
107 | if (!(w)) return; |
108 | uint8_t h = pgm_read_byte_inc(bitmap); |
109 | if (!(h)) return; |
110 | uint8_t bpp = pgm_read_byte_inc(bitmap); |
111 | uint16_t bkcolor = pgm_read_word_inc(bitmap); |
112 | if (flags & GLCD_BMP_USECOLORS) bkcolor = glcd.Colors[0]; |
113 | if (bpp == 0) { |
114 | glcdFillRect(x, y, x + w -1, y + h -1, bkcolor); |
115 | return; |
116 | }
|
117 | GLCD_CS_ON(); |
118 | GLCD_SETADDR(x, y); |
119 | GLCD_WINDOW(x, y, x + w -1, y + h -1); |
120 | if (flags & GLCD_BMP_TRANSPARENT) { |
121 | GLCD_SETMODE(0x38 | GLCD_ROP_WNE); |
122 | GLCD_SETCOMPARE(bkcolor); |
123 | } else { |
124 | GLCD_SETMODE(0x38); |
125 | }
|
126 | GLCD_STARTDATA(); |
127 | if (bpp == 1) {// monochrome |
128 | uint16_t pixelcount = w * h; |
129 | uint16_t fgcolor = pgm_read_word_inc(bitmap); |
130 | if (flags & GLCD_BMP_USECOLORS) fgcolor = glcd.Colors[1]; |
131 | uint16_t color = bkcolor; |
132 | if (flags & GLCD_BMP_SWAPCOLORS) { |
133 | bkcolor = fgcolor; |
134 | fgcolor = color; |
135 | color = bkcolor; |
136 | }
|
137 | uint8_t data = pgm_read_byte_inc(bitmap); |
138 | uint8_t pixelbits = ((data >> 4) +1) << 2; |
139 | data &= 0x0F; |
140 | uint8_t temp = data << 4; |
141 | data |= temp; |
142 | do { |
143 | GLCD_WAIT(); |
144 | GLCD_OUT(H8(color)); |
145 | if (!(--pixelbits)) { |
146 | data = pgm_read_byte_inc(bitmap); |
147 | pixelbits = ((data >> 4) +1) << 2; |
148 | data &= 0x0F; |
149 | uint8_t temp = data << 4; |
150 | data |= temp; |
151 | }
|
152 | GLCD_WAIT(); |
153 | GLCD_OUT(L8(color)); |
154 | ROL(data); // rotate data, data = (data << 1) | (data >> 7); |
155 | color = bkcolor; |
156 | if (data & 0x01) color = fgcolor; |
157 | } while (--pixelcount); |
158 | } else if (bpp == 16) { // full color |
159 | uint16_t pixelcount = w * h; |
160 | while (pixelcount) { |
161 | GLCD_WAIT(); |
162 | GLCD_OUT(H8(bkcolor)); |
163 | pixelcount--; |
164 | GLCD_WAIT(); |
165 | GLCD_OUT(L8(bkcolor)); |
166 | bkcolor = pgm_read_word_inc(bitmap); |
167 | }
|
168 | } else {// color, 2 upto 15 BPP |
169 | uint16_t colortablesize = pgm_read_word_inc(bitmap); |
170 | uint8_t* colortable = (uint8_t*)bitmap; |
171 | bitmap += colortablesize; |
172 | uint16_t colormask = pgm_read_word(&colormasks[bpp -2]); |
173 | uint8_t databits = 0, data2 = 0, bitsmul = 1; |
174 | uint16_t data0 = 0; |
175 | // uint32_t data = 0;
|
176 | uint16_t pixelcount = w * h; |
177 | do { |
178 | GLCD_WAIT(); |
179 | GLCD_OUT(H8(bkcolor)); |
180 | pixelcount--; |
181 | GLCD_LOAD_BITS(data0, data2, databits, bitmap, bitsmul); |
182 | |
183 | // while (databits < 16) {
|
184 | // uint16_t t = pgm_read_byte_inc(bitmap) * bitsmul;
|
185 | // if (databits >= 8) data |= (uint32_t)t << 8;
|
186 | // else data |= t;
|
187 | // databits += 8;
|
188 | // }
|
189 | |
190 | GLCD_WAIT(); |
191 | GLCD_OUT(L8(bkcolor)); |
192 | |
193 | GLCD_LOAD_COLOR(data0, data2, databits, colortable, colormask, bpp, bitsmul, bkcolor); |
194 | |
195 | // if (LL8(data) & 0x01) {
|
196 | // bkcolor = pgm_read_word(colortable + (L16(data) & colormask));
|
197 | // data >>= bpp;
|
198 | // databits -= bpp;
|
199 | // bitsmul = pgm_read_byte(&powerof2[databits & 0x07]);
|
200 | // }
|
201 | // bitsmul >>= 1;
|
202 | // if (!(bitsmul)) bitsmul |= 0x80;
|
203 | // data >>= 1;
|
204 | // databits--;
|
205 | } while (pixelcount); |
206 | }
|
207 | GLCD_WAIT(); |
208 | GLCD_CS_PULSE(); |
209 | GLCD_SETMODE(0x30); |
210 | GLCD_CS_OFF(); |
211 | }
|
hi hat einer vielleicht ein datenblatt zu dem L2F50 zu hand und mag es mal posten? habe bis jetzt keins gefunden.. mfg micha
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.
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
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
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,
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).
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,
@Mike Bird, wie binde ich denn die DATA in Bascom ein ? Restore Bildname ..... ? ich bekomms nicht hin. kannst Du mir helfen ? mfg Kay
@Mike Bird, habs hinbekommen. danke. Kann ich denn irgendwie bestimmen, an welcher position das Bild angezeigt werden soll ? mfg Kay
@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.
@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
@Kay Meld Dich doch kurz hier an, dann brauchen wir nicht das Forum dichtzuschreiben (PN / E-Mail) Gruss Mike
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.
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
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
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
Also der HC4050 funktioniert auf alle Fölle den hab ich bei mir auch verbaut.
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
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.
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
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
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
das kann schon am Makefile liegen, sprich den Compilerswitches. Ist halt C wo solche "Ungereimtheiten" möglich sind ;) Gruß Hagen
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
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
..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
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
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...
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?
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!
@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
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.
@lupin ok, thanks, digging further ;) aethr
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
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
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
Quick note: indeed was a timing issue with reset. When the delays around reset become too large, screen doesn't initialize properly. aethr
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
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.
>> 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
i forgot to say, my GLCD are ready for the LPH. Its based and most times compatible to my Nokia GLCD. Best reagrds, hagen
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
Its a fully rewrite in C. The mcu depended stuff are implented as macros. Thus should be easily portable. Best Regards, Hagen
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
@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
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
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
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
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
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.