Mit Waitstate hats nicht funktioniert, ohne funktionierts? Dann wars aber nicht das Layout. Da wärs ehr andersrum gelaufen ;) Wahrscheinlicher ist, dass die Framerate zu hoch war. Mit Waitstate braucht der Interrupt deutlich länger. Du hast die 8-Graustufen-version in der eh schon mehr Zeit im Interrupt verbracht wird. Mit Waitstate hats dann halt nicht mehr gereicht. Aber glückwunsch dass es jetzt läuft. Sebastian
Dein Kommentar hat mich etwas verwirrt. Wenn ich in param.h die (normalerweise nicht gewählte) Option Waitstate aktiviere, dann nehme ich in lcd.c doch die Version mit (1<<SRW10 im MCUCR). Damit schalte ich den Waitstate doch ein und nicht aus! Oder habe ich da etwas falsch verstanden? Bruno
Achso! Bei dir funktionierts nur mit Waitstate? Ja, dann könnte es wirklich der Aufbau sein. Hatte deinen letzten Post falsch verstanden.
Eine Frage an die Experten! Kann ich mit HTerm die Befehle und Daten in einem Textfile übertragen und wenn ja, wie? Bruno
Hallo Bruno, >>Kann ich mit HTerm die Befehle und Daten in einem Textfile übertragen >>und wenn ja, wie? Textfile geht nicht. Mit einem Hex Editor ein Binärfile erstellen. In HTerm SendFile anklicken und den Binärfile auswählen. Alternativ kannst du auch Befehle mit ASend verschicken. (dazu Bin markieren)
Sorry, ich meinte nicht Binär, sondern alles Hex !!!
Hallo Helfender, nun hat es endlich geklappt. Herzlichen Dank für den Tip! Bruno
Angehängte Dateien:
-
Testbild.jpg
22 KB
Ich bin es schon wieder! Ich habe mich zu früh gefreut! Wenn ich Bilder übertrage, dann werden diese immer irgendwie geteilt, u.z. unabhängig davon ob ich mit HTerm oder mit einem Controller übertrage. Es ist auch egal, ob ich den Code von Benedikt mit 4 Graustufen, oder den erweiterten von Sebastian nehme. Der Unterschied scheint nur zu sein, daß im Benedikt Code das Bild in der Mitte geteilt ist (siehe Anlage) und beim Sebastian Code links ca. 2/3 des Bildes erscheinen. Das ist aber mit Vorsicht zu betrachten, da sich das hin und wieder auch ändert. Hat jemand eine Idee? Bruno
Hallo Bruno, ich habe hier noch ein Testbild. Kannst es ja mal probieren. Mit einem Hex Editor siehst du auch die entsprechenden Befehle dazu.
Hallo Helfender, dein Bild hat mir zwar nichts Neues gebracht, aber trotzdem bin ich dadurch auf die richtige Spur gekommen. Ich hatte bei meinen Bildern immer einen Clear-Befehl (12) an den Anfang gesetzt und das verträgt der Code offensichtlich nicht. Dank und Gruß Bruno
Hallo Helfender, ich brauche nochmals Rat. Dein Beispiel war zwar nur mit 2 Farben, ich gehe aber davon aus, daß du dich auch mit der 4 und 8 Graustufen Version beschäftigt hast. Ich habe Probleme mit dem xs Wert. Wenn ich ein Bild 320x240 übertrage, dann habe ich im s/w Modus 320/8=40. Im 4Grau Modus sind das dann 2*320/8, also 80 und im 8Grau Modus müßten es doch 3*320/8, also 120 sein. Das ergäbe 120*240=28800 Bytes für das gesamte Bild. Mein Problem ist, daß ich bei der Erzeugung eines 8Grau Bildes mit dem GrafikConverter hier aus dem Forum aber 38399 Bytes bekomme. Rein rechnerisch müßte ich dann ja 38399/240 ~ 160 Bytes mit xs übertragen. Ganz egal wie ich es aber anstelle, es kommt nur Müll. Liegt es nun an der Einstellung des GrafikConverters oder an meiner Berechnung des xs. Die 4Grau funktioniert übrigends problemlos. Bruno
Hallo Bruno, ich dir mal etwas im Anhang, da sind die Bilddaten320x240 in 8Graustufen und eine Schleife die die Bilddaten ausgibt. kannst ja mal probieren obs klappt, wäre gut wenn du dich dann nochmal mit nen foto meldest mfg
Hallo Bruno, na klar habe ich auch 8 Graustufen probiert. >>Im 4Grau Modus sind das dann 2*320/8, also 80 und im 8Grau Modus müßten >>es doch 3*320/8, also 120 sein. Das ergäbe 120*240=28800 Bytes für das >>gesamte Bild. Das ist richtig. Header = 16,170,0,0,40,240,2 -> für 3bpp 8 Graustufen 1 -> für 2bpp 4 Graustufen 0 -> für 1bpp 2 Graustufen Also liegt es am GrafikConverter, den du benutzt. Dazu kann ich aber nichts sagen, da ich ein anderes Programm benutzt habe. Welches kann ich nicht mehr sagen. Irgendeinen Grafik LCD Konverter.
Angehängte Dateien:
-
Rambo.jpg
240 KB
Hallo gasst und Helfender, ich danke für die prompte Antwort. Der Rambo ist angekommen (siehe Anlage). Ich habe ihn allerdings mit HTerm übertragen. Wie ich aus euren Antworten entnehme, sind die 3bpp nur bei der Anzahl der Bytes zu berücksichtigen, Ich war bisher davon ausgegangen, daß im Befehl das xs auf 40, 80 bzw. 120 gesetzt werden muß. Da es bei mir aber mit der 4Grau trotzdem geklappt hat, muß mein GrafikConverter die Daten anders aufbereiten. Könnt ihr mir euren Converter verraten? Bruno
Ich melde mich noch einmal. Das mit dem GrafikConverter hat sich erübrigt. Ich habe die richtige Einstellung gefunden. Bruno
Ich habe noch etwas rumgespielt und dabei folgendes festgestellt: Wenn ich 4grau haben will, muß ich den xs Wert tatsächlich verdoppeln. Nur die Anzahl Bytes des Bildes funktioniert nicht. Man sieht dann immer nur das halbe Bild durchlaufen. Wenn ich 8grau haben will, darf ich den xs Wert hingegen nicht erhöhen. Jetzt würde mich natürlich schon interessieren, ob es am GrafikConverter liegt, oder am Code.
Angenommen das Bild ist 320x240 Pixel. Es werden horizontal jeweils 8 Bit (Pixel) übertragen. (xs = 320 / 8) Bei 2 Grauwerten reichen diese 8 Bit (jeweils 0 oder 1). Also xs=40, ys=240, 1bpp = 9600 Byte. Bei 4 Grauwerten reichen diese 8 Bit nicht mehr. Also braucht man 2bpp. Also xs=40, ys=240, 2bpp = 19200 Byte. Bei 8 Grauwerten braucht man 3bpp. Also xs=40, ys=240, 3bpp = 28800 Byte.
Hallo Helfender, genau so hatte ich dich verstanden! Aber das scheint nicht zu stimmen. Für die 2grau und 8grau passt es, aber für die 4grau muß ich xs=80, ys=240 eingeben. Alles andere funktioniert nicht. Offensichtlich war das von Benedikt auch so vorgesehen, da er am 1.6.2009 die anliegende Datei ins Forum gestellt hat. Die Befehlszeile ist darin 0x10, 0xAA, 0x00, 0x00, 0x3C, 0xF0, 0x01, d.h. er hat für ein 30 Byte breites Bild xs=60 eingegeben.
Hallo Bruno, >>Die Befehlszeile ist darin 0x10, 0xAA, 0x00, >>0x00, 0x3C, 0xF0, 0x01, d.h. er hat für ein 30 Byte breites Bild xs=60 >>eingegeben. So genau habe ich mir das damals nicht angesehen. Wenn ich das richtig verstanden habe, gibt der letzte Wert die Bit pro Pixel an. Dann wäre das obige Beispiel eigendlich 1bpp ??? xs=60, ys=240, 1bpp = 14400 Byte Ist im Endeffekt das gleiche wie ich dachte. (240 / 8) xs=30, ys=240, 2bpp = 14400 Byte Aber warum xs 60 ist kann ich dir auch nicht beantworten. Ist mir auch nie aufgefallen, da ich mit 4 Graustufen nie probiert habe.
> Ich hatte bei meinen Bildern > immer einen Clear-Befehl (12) an den Anfang gesetzt und das verträgt der > Code offensichtlich nicht. Der sollte eigentlich keine Probleme machen. Wenn du allerding den Busy-pin nicht abfragst kann das leicht probleme machen. Clear brauch relativ lang zum ausführen. Wenn du jetzt blind daten sendest wird erstmal der Puffer vollgeschrieben. Danach gehn die Daten verloren bis Clear fertig ist. Könnte durchaus sein, dass das in etwas eine halbe Bildzeile ist. Als Resultat ist dann das gesamte Bild ein Stück nach links verschoben und das was links rausgeschoben wurde wird rechts angezeigt. Zu deinem xs-problem kann ich dir nicht wirklich helfen. Was ich nach kurzem Überfliegen aus dem code gelesen habe ist, dass für 1bbp und 3bbp der maximalwert für xs 40 ist und für 2bbp 80. Sicher bin ich mir aber auch nicht. Erscheint irgendwie unlogisch. Ich weiß nur noch, dass mir der xs-wert auch ständig probleme gemacht hat als ich die 3ppb programmiert habe. Sebastian
Herzlichen Dank für eure Antworten! Ich habe das mit dem Busy Pin zwar schon gelesen, aber ich weiß nicht wie ich das realisieren kann. Eigentlich wäre es doch sinnvoll die Abfrage in den Übertragungscode einzubauen (bei mir scheitert das aber noch immer am C++), oder welche Möglichkeiten gibt es sonst noch? In der Zwischenzeit hatte ich selbst festgestellt, daß es funktioniert, wenn ich nach dem "Clear" ca 500 Leerbytes einfüge. Das mit dem xs ist kein Problem mehr, da ich ja nun weiß was ich tun muß. Gruß Bruno
Nachtrag: Beim Übertragungscode meinte ich eigentlich Empfängercode. Wenn ich die Daten per µC sende läßt es sich sicher relativ einfach realisieren, da ich aber immer mit HTerm sprich vom PC sende, kenne ich keine Lösung. Bruno
Ich weiß jetzt zwar nicht genau wo dein problem liegt, aber vielleicht hilft dir ja das CTS-Signal der RS232-schnittstelle.
Herzlichen Dank für den Tip! HTerm hat ja tatsächlich ein CTS Kästchen zum Ankreuzen (Flow control), nur leider scheint es nicht zu funktionieren. Bei mir bleibt die Übertragung jedenfalls schon am Anfang hängen. Trotzdem habe ich aber kein wirkliches Problem, da es ja einige Alternativen gibt. Bruno
Du musst dann natürlich auch Physikalisch CTS der RS232 und Busy vom Controller verbinden. Ich weiß auch nicht, ob die beiden Signale von der Polarität zusammenpassen. Und bevor du sie einfach zusammenlötest denk auch mal über die Pegel nach, die drauf liegen. http://de.wikipedia.org/wiki/EIA-232 Sebastian
Da du mir dieses Thema schon so nahe bringst, bleibt mir ja gar nichts anderes übrig, als mich etwas näher damit zu befassen. Ich habe also angefangen mich mit der RS232 und dem busy pin zu beschäftigen und stoße natürlich wieder auf Fragen. Als erstes habe ich die Spannung am PIN D2 gemessen und festgestellt, daß er auf high steht. Nach der Erklärung von Benedikt, müßte ihn aber doch das Programm hochziehen, wenn der Puffer zu 3/4 gefüllt ist. Schaue ich nun in den Ursprungscode von Benedikt, dann hat er in der "int main" PORTD=3 und DDRD=254 gesetzt. Danach wäre der Pin D2 ein Ausgang mit 0 Level. Dann dürfte er also nicht auf high stehen. Schaue ich aber nun in die von Benedikt modifizierte, oder auch in deine 8grau Version, dann wird PORTD=7 gesetzt. Damit ist D2 immer high. Wie paßt das zusammen??? Bruno
Mit HTerm geht es mir ähnlich. Laut Beschreibung sollte die Übertragung gestoppt werden, wenn CTS high geht. Die Spannung am CTS Pin ist auch normal 0. Nur funktioniert dann die Übertragung nicht. Wenn ich CTS high setze wird zwar übertragen, aber am Display kommt nur Datenmüll an????? Hast du mit HTerm Erfahrung? Bruno
Ne, leider überhaupt keine Erfahrung mit HTerm. Und auch allgmein so gut wie nichts an der PC-RS232 gemacht. Kann also kaum helfen. Bzw. halt nur dokumentattion lesen, aber das kannst du ja auch selbst machen. Der Busy-pin des Displaycontrollers verhält sich bei mir so wies in dem beigelegten pdf steht (also das aus der .zip). Gib nicht zu viel auf den wert, auf den Busy initialisiert wird. Es zählt nur, wie das ganze in der UART-lib behandelt wird. Pass bei RS232 mit high/low auf. Ich hab irgendwas im Kopf, dass da logisch 1 = physikalisch low ist. Aber sicher bin ich mir da auch nicht.
Hallo, hat jemand schon mal bei einem Mega162 mehr als einen Zeichensatz eingebaut ? Der Speicher sollte das ja zulassen, oder ? Da die beiden ja Pin-kompatibel sind, könnte man ja den 8515 schön damit ersetzen. Das wäre für mich ne ziemliche Erleichterung, da ich (noch) nicht so viel Erfahrung mit C habe. Ich programmiere zwar schon ein paar Jahre, aber meist eben mit Bascom oder Delphi und nicht in C. (Ich arbeite grade dran :-) ) Gruß Markus
Hi ! hat überhaupt schon jemand den ATMega 162 bei dem Projekt eingesetzt ? Der 8515 ist im Moment leider nicht zu bekommen und ich müsste eins meiner Boards ersetzen .. Gruß Markus
Die haben den 8515 als DIP (erlauben leider keinen direktlink): http://www.csd-electronics.de Reichelt hat ihn als PLCC: http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=A363;GROUPID=2959;ARTICLE=47365;START=0;SORT=artnr;OFFSET=500;SID=312DLrCawQAR8AAFDRLwge20a5628acfd6c3563eb32d5f802a711 als TQFP: http://www.reichelt.de/?;ACTION=3;LA=444;GROUP=A363;GROUPID=2959;ARTICLE=50557;START=0;SORT=artnr;OFFSET=500;SID=312DLrCawQAR8AAFDRLwge20a5628acfd6c3563eb32d5f802a711 und hier gibts ihn nochmal als DIP (wieder kein direktlink): http://www.segor.de Bei mir kannst du auch einen als DIP (und ich glaube auch als TQFP) im tausch gegen einen 12er Metallbohrer haben. Und ein paar andere Versender haben ihn sicher auch auf lager ;) Gruß, Sebastian
Hi, hast du noch Platinen übrig? Würde evtl. was abkaufen. Ich habe noch ein 320x240 Display von Nanya rumfliegen und würde gerne die Schaltung aufbauen. Gruß Alex
@Alex (Gast) ich hab noch ein paar Platinen machen lassen, die sollten am 27.11 eintreffen Wigbert
Hallo Wigbert, wenn Du noch Platinen übrig hast, die Du nicht brauchst hätte ich auch Interesse. Gruß Markus
Ich hatte das mal angekündigt, hat sich etwas verzögert. Wie gesagt Platinen + NAN-YA Adapter werden geliefert. Preise und Bauteile siehe Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Wigbert
Hallo, ich bin neu bei diesem Projekt. Ich habe fast den ganzen Tag damit verbracht, den Thread mit den vielen Links zu lesen und halbwegs zu verstehen. Ein wirklich tolles Projekt. Nun würde ich ebenfalls gerne loslegen - doch Pollin hat all die schönen Displays mit CCFL Hintergrundbeleuchtung bis auf eine Ausnahme (Best.Nr. 120 486) ausverkauft. Und dummerweise fehlt hier das Datenblatt. Wer von euch hat besagtes Display vielleicht schon einmal eingesetzt oder kennt die Anschlussbelegung ? Oder eine andere Bezugsquelle als Pollin für solche Displays mit CCFL? Vielen Dank schon mal! Gruß Josef
Hat jemand das schon auf dem LCD TG322450 von Pollin zum laufen bekommen? :) Liebste Grüße Florian
Hallo. Ja, geht problemlos, musst bloss eine Positive Kontrastspannung generieren. CU Bernd
Hi, die GLCD_32K Platinen und auch die NANYA Adapterplatinen sind jetzt vorrätig. Vielleicht gerade richtig zur kalten Jahreszeit. Ich hab mal schnell von der Serie eine aufgebaut, lief promt auf Anhieb. Einige Verbestellungen schreibe ich noch mal an, ansonsten bitte eine Mail. Wigbert
Angehängte Dateien:
-
Dodge_2.png
40 KB
Hi @ all, ich (bzw. mein Vater und ich) haben uns von Wigbert 2 Platinen besorgt. Meine funktioniert auch schon wunderbar (mein Vater ist noch am Bestücken), VIELEN DANK AN WIGBERT UND BENEDIKT! Aber ich komme mit der Grafik konvertierung und dem Bild Befehl nicht klar. Wie das mit 1bpp läuft ist mir in der Theorie klar. Aber wie läuft das mit 2bpp (4 Graustufen) und 3bpp (8 Graustufen)? Ich verstehe die (leider ziemlich knappe) Erklärung in dem .pdf nicht so wirklich. Werden bei 2bpp immer 2 aufeinanderfolgende Bits zusammengefasst und stehen dann sozusagen 4 Pixel in einem Byte? Wie soll des bei 3bpp funktionieren? stehen dann 2,67 Pixel in einem Byte??????????? Wie konvertiere ich das Bild im Anhang (ist momentan mit 8bpp Farbtiefe aufgelöst) nach 2 oder 3bpp? 1bpp müsste ja Schwarz Weiß entsprechen (macht ja Paint). Wie bekomme ich dann die Tabelle aus der Grafikdatei? Ich selbt benutze Bascom AVR zum Programmieren. Ich hoffe es kann mir jemand weiterhelfen, wie ich das (oder ein beliebiges Bild) auf das Display bringe. Mfg Bimbo385
Richtig, bei 2 und 3 bpp werden immer 2 bzw. 3 aufeinanderfolgende bit zu einem Pixel zusammengefasst. Bei 3bpp müssen dann immer 3 Byte zusammen gesendet werden, damit Pixelgrenze und Bytegrenze wieder zusammenfallen. Also immer vielfache von 8 pixeln. Hier und an vielen anderen Stellen im Thread wurde das schonmal erklärt: Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Konvertieren kann mit dem hier ganz gut: Beitrag "Grafikkonverter Tool für AVR/Mikrocontroller (BMP2C, BMP2ASM, BMP2BASCOM)" Gruß, Sebastian
Total Geil! Alles funktioniert wie es soll. Danke dir Sebastian! und euch Allen!!! @ Wigbert: Ich möchte allen vorsichtshalber mitteilen, dass es bei FFC-Buchsen welche gibt, bei denen die Kontakte des Folienleiter zur Platine zeigen müssen (beim Reinstecken) (solche hat Wigbert) und, dass es FFC-Buchsen gibt, bei denen die Kontakte des Folienleiters nach oben (also von der Platine weg) zeigen müssen (solche habe nämlich ich). Somit hängt es von der verwendeten FFC-Buchse ab, wierum die kleine NANYA Adapterplatine (von Wigbert) auf die Hauptplatine von Wigbert gelötet werden muss. Bie mir muss man, im Gegensatz zu Wigberts Fotos, die FFC-Buchse von oben sehen können. Auf jeden Fall muss sich am Ende Die blaue Beschriftung des Folienleiters auf der Bestückungsseite der Hauptplatine befinden. Außerdem möchte ich die Frage nach dem Inverter für die Hintergrundbeleuchtung nochmal aufwerfen. Ich habe noch so einen Schwarzen Kasten für 2x 30cm CCFL's (Casemodding). Kann ich den einfach verwenden? Hat das schon mal jemand gemacht? Mfg Bimbo385 PS: Die HEX-Datei im Anhang kann man mit HTerm senden und enthält den Befehl für die Bildausgabe!
@Bimbo 385 (bimbo385) Danke für den Hinweis. Auf der Platine ist ein Pin, auf der die Adapterplatine aufgesteckt wird, sicherheitshalber mit 1 gekennzeichnet. Also schön aufpassen! Ich erweitere mal meinen beigelegten Merkzettel, wenn meine FFC Buchsen nicht verwendet werden. Die Adapterplatinen lassen sich ja problemlos drehen. Wigbert
Hallo Wigbert Picht-dl1atw und Günter S. Hat einer von euch noch Platinen abzugeben? vielen Dank! mfg Andreas
@Andreas Pachler (Firma: No Company) (arsirc) Ja, schick mir eine Mail Wigbert
hallo, ich habe mir den lcd Controller auch aufgebaut läuft supi, ich habe mir ein bild erstellt(184x74Pixel) in 8 Graustufen mit den GrafikConverter weiter oben,diese Bilddaten sende ich von einem extra Controller zum display das funktioniert herrvoragend. nun meine frage , als Controller des Lcds verwende ich einen atmega162,ich wollte gern diese Bilddaten im flash speichern und dann am lcd ausgeben im 1bpp funktionierts aber im 3bpp läufts nicht. kann mir denn da jemand weiter helfen mfg
Hallo zusammen! Habe gerade ein Wintek H3224V von Pollin an den Controller, basierend auf Wigbert's Platine, angeschlossen und genieße meine Triumpf: Es erscheint das Testbild und es nimmt brav Befehle entgegen. Hier schonmal ein riesen Dankeschön an Euch alle! Nur läuft es noch nicht ganz rund: Ich habe flackernde senkrechte Streifen die wohl immer dort entstehen, wo etwas angezeigt wird. Ein Rechteck mitten im Bild z.B. wird somit ab und zu zu einem kompletten senkrechten Streifen von oben bis unten. Hat jemand eine Idee? Zweites Problem wäre der Anschluss "M" des Displays, wo gehört der denn hin? auf wigbert's Schaltplan ist ein Pin dafür vorgesehen, auf der Platine finde ich aber irgendwie nichts. An diesen Pin habe ich gerade einfach nur ein Kabel hinkrokodilt und lasse es in der Luft hängen. Ohne dieses verblasst das Bild binnen einiger Sekunden. MfG, Der fast ganz Glückliche
Schau mal links von IC4 dort ist M als Lötpad herausgeführt. Rechts von R7 auf meiner Platine. Ist auf der Top Platinenansicht mit M bezeichnet Wigbert
Oh Gott bin ich blind... Bin eh schon Kurzsichtig und seh sowas net. Vielen Dank Wigbert! Funktioniert jetz alles wunderbar. Aber um etwas für den Lerneffekt zu tun: Für was ist das Signal gut?
@neuer: Ich hab mir deinen Code jetzt nicht genau angeschaut, aber dein Problem könnte schlicht darin liegen, dass du die Falsche Funktion aufrufst. Für 8-Graustufen-bilder darfst du nicht mit lcd_writebyte schreiben sondern musst lcd_writebyteg8 nehmen. Beachte, dass lcd_writebyteg8 mehr Parameter verlangt. Wenn du Die 8-Grastufen-daten mit der lcd_writebyte schreibst kommt jedenfalls nur müll im Speicher an ;) Sebastian
hallo Sebastian ich schreibe ja mit der Funktion lcd_writebyteg8 es wird ja auch von den abmessungen richtig dargestellt also breite und höhe. nur siehts halt verschwommen aus.in den 4Graustufen passt alles. vielleicht wäre es möglich mir da ein bischen weiterzuhelfen mfg
Nachdem ich nur mutmaßen kann wo der Fehler ursprünglich ist erklär ichs mal bissl ausführlicher - sollst ja auch wissen, was du da tust ;) Es gibt prinzipiell mal zwei Stellen, wo man die Graustufenzahl einstellen kann. Das erste ist bei den Parametern - hier stellt man ein, mit wie vielen Graustufen der Controller arbeitet. Dabei ändert sich primär die Organisation des RAMs. Stellt man hier 2 ein kann der Controller einfach nichts mit 4 oder 8 Graustufen anfangen. Umgekehrt kann aber ein 8-Graustufen-build natürlich auch 2 Graustufen anzeigen. Die andere Ecke ist dann die Datenverarbeitung selbst. Also das, wo man am UART-interface zu den Bilddaten noch den Modus mitschicken muss. Über den Modus wählt man dann aus, ob die lcd_writebyte, die lcd_writebyteg oder die lcd_writebyteg8 verwendet werden soll. Die Routinen erwarten dann aber auch entsprechend Daten mit 2,4 bzw 8 Graustufen. Die Art, wie die Daten im RAM abgelegt werden regeln die Routinen dann intern. Du kannst also per Config auf 8 Graustufen flashen und mit der lcd_writebyteg ein 4-Graustufen-bild zeichnen. Bei dir liegt der Fehler genau bei der Verwendung von lcd_writebyte*. Du musst -unabhängig davon was in den Parametern steht- für 2-Graustufenbilder die lcd_writebyte, für 4-Graustufen die lcd_writebyteg und für 8-Graustufen die lcd_writebyteg8 nehmen. Die lcd_writebyteg8 erwartet dann aber auch 3 aufeinanderfolgende Datenbytes (und natürlich auch eine Vorlage mit 8 Graustufen) und nicht wie bei dir dreimal das selbe Byte. Sebastian
hallo Sebastian erstmal vielen dank für deine Antwort, > > (und natürlich auch eine Vorlage mit 8 Graustufen) <Das bild mit 8Graustufen liegt im Flash vom Controller > und nicht wie bei dir > dreimal das selbe Byte. > lcd_writebyteg8 erwartet dann aber auch 3 aufeinanderfolgende Datenbytes <ja daran harperts bei mir weil ich nun nicht so viel Ahnung von C habe,um mir eine Routine zu schreiben die die richtigen Bytes ausliest. deshalb meine frage,ob mir da jemand weiterhelfen könnte. mfg
Muss es zwingend möglich sein, beliebige Bildbreiten darzustellen (wenn ich deinen Algorithmus richtig interpretiere versuchst du das ja)? Dann müsstest du nämlich an einem Rand Füll-pixel einfügen um in der Breite auf vielfache von 8 pixeln zu kommen. Das geht aber leichter, wenn du die Füllpixel gleich im Bild vorsiehst. Wenn du mit der beschränkung leben kannst, dass die Bildbreite vielfache Werte von 8 hat, dann kannst du quasi den Algorithmus aus der main.c nehmen und einfach uart_getchar() durch pgm_read_byte(...) ersetzen. Das sollte eigentlich recht problemlos laufen. Wenn du wirklich auf beliebige Breite ohne Füllpixel bestehst muss ich dich leider allein lassen. Das erfordert tiefere Eingriffe in die lcd_writebyteg8 für dich ich leider keine Zeit habe. Sebastian
@Glücklicher Displaybesitzer: Nochmal für den Lerneffekt: Das Signal M sorgt für die nötige, gleichspannungsfreie Ansteuerung des Displays, indem es in regelmäßigen Abständen invertiert wird. Es gibt Displays, die dieses Signal intern erzeugen und nicht herausführen, anderen muß man es liefern.
Das Display lief jetzt so schön, nun zeigt es nur noch senkrechte Streifen mit verschiedenen Stärken an. Auch musste ich feststellen, dass der RAM warm wird. Ich habe schon sämtliche 74hctxx und den 8515 gewechselt, keine verbesserung. Da dürfte wohl der RAM gehimmelt sein, oder?
Hallo Leute Wer könnte mir denn den Code soweit minimieren das ich den Displaycontroller nur noch im s/w Modus betreiben kann ohne jeglichen Schnick Schnack??? Ich möchte die Daten auch am liebsten parallel (8bit) in den Controller schaufeln um so schnell wie möglich ein Bild aufzubauen. Ich sende momentan nur reine Bilddaten mit 666666 baud. Schriftarten werden bei mir in einem anderen Controller erzeugt. Momentan hängt es bei mir an der Geschwindigkeit der Bildübertragung. Die scheint hier einige ms in Anspruch zu nehmen. Ich müsste das Bild (320x240) allerdings in weniger als 0,004 s aufgebaut haben. Ist das Möglich? Eigentlich bräuchte ich den Grafik-Controller nur als Bildspeicher der autark das Timing des Displays übernimmt.. Ich hab nicht soviel (sehr wenig Programiererfahrung) in "C". Ich hoffe, mir kann jenand helfen. Grüße Steffen
Hallo @Benedikt Vieleicht kann mir aber auch der Benedikt nochmal kurz beschreiben wie der Ablauf/Timing vom AVR zum Display abläuft. Dann versuch ich es mal selber in ASM zu programmieren. Grüße Steffen
Die minimal-version kann man sich sehr leicht selbst zusammenstellen indem man in den parametern nur die s/w-version auswählt. Die ganzen grafikfunktionen verlangsamen das programm wirklich nur unwesentlich. Wenn man Text sendet ists vollkommen irrelevant. Und bei den Grafikfunktionen ist die Render-Zeit der Grafik deutlich relevanter als das, was man sparen würde, wenn man ein Paar der Funktionen rausschmeißt. Über die 4ms solltest du nochmal gut nachdenken. Wie groß ist denn die Reaktionszeit deines Panels? Die NANYA-displays, die hier massenhaft verwendet werden haben, glaub ich, gute 100ms. In dem Fall wären die 4ms vollkommen lächerlich. Zumal das Display -wenn ich mich recht erinner- auch im sw-Modus mit wenigstens 70Hz betrieben wird. Du hast also eh schon bis zu 14ms Latenz bis die neuen daten überhaupt angezeigt werden. Du kannst auch überlegen, das Bild erst zu puffern und dann den Bildbereich umzuschalten. In der SW-Version kann man ja bis zu 3 Vollbilder im Speicher vorhalten. Die Latenz wird dadurch zwar nicht kleiner, aber man muss dem Bild nicht beim aufbau zuschaun. Wenn das alles nichts hilf: Ich hab daheim ne Version, die Bilder mit 2MBaud entgegen nimmt, ohne den Master dabei zu bremsen. In dem Fall ist dann sowohl die CPU als die UART voll ausgelastet (= ca.7fps) - ich weiß nicht, wie noch mehr gehn soll. Ist aber nur für 3bpp-bilder implementiert und nicht gut dokumentiert. Wenn du willst, kann ich das mal hier anhängen, aber anpassen auf SW kann ichs nicht: Leider zu wenig Zeit und gerade auch keine Hardware hier ums zu testen. Parallele Datenübertragung hilft nur, wenn die CPU momentan unterfordert ist. Das ist sie aber -soweit ich mich erinner- in der Originalversion bei 666kbaud nicht. Nachteil an paralleler Datenübertragung ist, dass man entweder Bandbreite verliert, weil der Hardware-Buffer der UART während dem Anzeige-Interrupt nicht mehr genutz werden kann, oder einen Handshake braucht, den man in Software bedienen muss => CPU-zeit. => Parallele Datenübertragung bringt wenn überhaupt nur was, wenn man den Anzeigeinterrupt kräftig umbaut und wirklich nur SW anzeigen will. Aber auch da wär ich mir nicht sicher. Für 3bpp-bilder dürfte nicht mehr als ca. 7fps machbar sein. Die Ansteuerung des Displays selbst kann man eigentlich ganz gut aus dem Datenblatte des Displays (Timingdiagramm) und der Interrupt-Routine des Controllers verstehen. Nachdem aber eh nur die High-level-Routinen in C geschrieben ist (Der Interrupt ist also in ASM) könntest du auch einfach Benedikts Interrupt übernehemen und nur den rest neu implementieren - wenn du das denn unbedingt willst. Viele Grüße, Sebastian
Hallo Sebastian >Über die 4ms solltest du nochmal gut nachdenken. Wie groß ist denn die >Reaktionszeit deines Panels? Die NANYA-displays, die hier massenhaft >verwendet werden haben, glaub ich, gute 100ms. In dem Fall wären die 4ms >vollkommen lächerlich. Ich hab gestern nochmal drüber nachgedacht und du hast völlig Recht! Das ist nur Wunschdenken. Außerdem, falls irgendein Display jemals so schnell sein sollte, könnte das Menschliche Auge es sowiso nicht einzeln folgen.. >Wenn das alles nichts hilf: Ich hab daheim ne Version, die Bilder mit >2MBaud entgegen nimmt, ohne den Master dabei zu bremsen. In dem Fall ist >dann sowohl die CPU als die UART voll ausgelastet (= ca.7fps) - ich weiß >nicht, wie noch mehr gehn soll. Die Version hattest du mir schon mal vorgeschlagen. Damals wusste ich noch nicht so genau wo mein Vorhaben mich hin führt. Wenn ich mit dem Display 10fps erreiche wär ich jedoch trotzdem froh. Soll auch alles NUR S/W werden. Und ich nutze wirklich nur Bilddaten. Ich hab sozusagen das komplette Bild schon im anderen Controller gespeichert und muss es nur noch so schnell wie möglich zum Display-Controller schreiben. >Nachteil an paralleler Datenübertragung ist, dass >man entweder Bandbreite verliert, weil der Hardware-Buffer der UART >während dem Anzeige-Interrupt nicht mehr genutz werden kann, oder einen >Handshake braucht, den man in Software bedienen muss => CPU-zeit. Also wird hier der Hardwarebuffer der UART genutzt um mehr Zeit für den Anzeige-Interrupt zu haben? Ist denn das Timing zum Display so knapp bemessen? >Du kannst auch überlegen, das Bild erst zu puffern und dann den >Bildbereich umzuschalten. In der SW-Version kann man ja bis zu 3 >Vollbilder im Speicher vorhalten. Die Latenz wird dadurch zwar nicht >kleiner, aber man muss dem Bild nicht beim aufbau zuschaun. An genau so etwas hab ich auch gedacht. Zwei Bildspeicher die man nach jedem neu empfangenen Bild umschaltet. Soll heißen: >Bildbereich1: Wird verwendet zum Refresh des Displays durch den Controller >Bildbereich2: Wird verwendet zum Speichern der neuen Bilddaten Wurden die neuen Bilddaten übermittelt dan wird umgeschaltet. >Bildbereich2: Wird verwendet zum Refresh des Displays durch den Controller >Bildbereich1: Wird verwendet zum Speichern der neuen Bilddaten Also immer schön im Wechsel. Ist dies möglich? Ist da mein Ansatz so schon ganz gut? >Die Ansteuerung des Displays selbst kann man eigentlich ganz gut aus dem >Datenblatte des Displays (Timingdiagramm) und der Interrupt-Routine des >Controllers verstehen. Nachdem aber eh nur die High-level-Routinen in C >geschrieben ist (Der Interrupt ist also in ASM) könntest du auch einfach >Benedikts Interrupt übernehemen und nur den rest neu implementieren - >wenn du das denn unbedingt willst. Ich hab da schon mal durch den Code gesehen. Aber ich kam da wegen dem UART nicht mehr weiter. Denn der ist in C geschrieben. Den UART-FIFO hab ich da auch nicht mehr nachvollziehen können. Dann noch die ganzen Auswahlmöglichkeiten.. Da ist man schnell am Ende wenn man nicht wirklich C kann. Na dann werd ich mir am WE wohl mal den ASM Code anschauen. Danke aber trotzdem für deine Hinweise und Hilfe Sebastian. Grüße Steffen
> Wenn ich mit dem > Display 10fps erreiche wär ich jedoch trotzdem froh. Soll auch alles NUR > S/W werden. Dann sollten mit 2 Mbaud 20,8fps möglich sein, wenn man den Display-Interrupt aufteilt. In SW könnten dann mit parallelem Interface sogar noch mehr gehen, aber das wird auf jeden fall aufwändiges gebastel und du bräuchtest auch erstmal ein Display, das unter 50ms schaltzeit hat. > Also wird hier der Hardwarebuffer der UART genutzt um mehr Zeit für den > Anzeige-Interrupt zu haben? Ist denn das Timing zum Display so knapp > bemessen? Ja genau. Während dem Displayinterrupt landen die UART-daten erstmal im Hardwarepuffer. Der hat 2 oder 3 byte (weiß ich nicht mehr sicher). Ist er voll muss der Interrupt fertig sein, sonst gehen daten verloren. Darüber bestimmt sich auch die maximale Baudrate. Will man mehr Baudrate muss der Interrupt kürzer werden. > An genau so etwas hab ich auch gedacht. Zwei Bildspeicher die man nach > jedem neu empfangenen Bild umschaltet. Soll heißen: >>Bildbereich1: Wird verwendet zum Refresh des Displays durch den Controller >>Bildbereich2: Wird verwendet zum Speichern der neuen Bilddaten > Wurden die neuen Bilddaten übermittelt dan wird umgeschaltet. >>Bildbereich2: Wird verwendet zum Refresh des Displays durch den Controller >>Bildbereich1: Wird verwendet zum Speichern der neuen Bilddaten > Also immer schön im Wechsel. > Ist dies möglich? Ist da mein Ansatz so schon ganz gut? Genau so wars gemeint. In der aktuellen Version gibts auch schon die passenden befehle dafür. Man hat ein Virtuelles Bild das gut dreimal so breit ist, wie das was angezeigt werden kann. Mit einem Befehl kann man jetzt festlegen ab welcher Spalte angezeigt werden soll, mit einem anderen ab welcher Spalte geschrieben werden soll. > Ich hab da schon mal durch den Code gesehen. Aber ich kam da wegen dem > UART nicht mehr weiter. Denn der ist in C geschrieben. Den UART-FIFO hab > ich da auch nicht mehr nachvollziehen können. Dann noch die ganzen > Auswahlmöglichkeiten.. Da ist man schnell am Ende wenn man nicht > wirklich C kann. Na dann werd ich mir am WE wohl mal den ASM Code > anschauen. Den UART-Code brauchst du nicht anschaun. Das ist eine fertige Library (von Peter Fleury glaub ich) die Benedikt recht rabiat umgebaut hat. Für so extremen Datendurchsatz (20fps SW) musst du den Software-FIFO sowieso rausschmeißen. der braucht zu viel Rechenleistung. Sorge lieber dafür, dass beim Bilder übertragen die Daten wenigstens so schnell verarbeitet werden, wie sie über die UART kommen. Dann kann der Master einfach so schnell senden wie's die Schnittstelle hergibt. Wichtig ist aber, den Displayinterrupt zu verstehen und verstehen, wie die Daten im Speicher hinterlegt sind. Viele Grüße, Sebastian
Hallo Sebastian
So, ich hab mich mal rangewagt und so ziemlich viel Code
rausgeschmissen. Die Übertragung bleibt seriell. Mit 1Mbaud funktioniert
das ganze noch. Mit 2Mbaud kommen nur noch wilde Streifen, sieht eher
aus wie rauschen.
Da ich ja sowieso nur reine Bilddaten zum DSP-Controller sende, hab ich
auch die ganzen anderen Commands rausgeschmissen.
Ich sende jetzt nur noch 0x16, 0xAA, Data_0, Data_1,..,Data_9599. Also
genau ein Bild der Größe 320x240 pixel.
In der asm routine wird FLM/Frame gesteuert. Der OCR1A (PD5) steuert
LP/Load und ich denke mal RD steuert XSCL/CP und den 4aus8 MUX und wird
aktiviert durch einen lesenden Zugriff auf den externen Speicher durch
ld Rd, X+.
Richtig so?
>>Was ich überhaupt nicht verstehe:
Wo wird CKDIS gesteuert? Hab ja die ganzen Routinen rausgeschmissen wo
dies passierte..
Hast du in deiner 2Mbaud Version den UART umgebaut?
Im Anhang mal meine extrem geschrumpfte Version. Aber sie funktioniert!
Grüße Steffen
Hallo zusammen, nach längerer Suche nach einem ATMega8515-16PU habe ich noch eine Quelle gefunden. Bei http://www.kessler-electronic.de gibt es noch ein paar... lg, Loki
> So, ich hab mich mal rangewagt und so ziemlich viel Code > rausgeschmissen. Die Übertragung bleibt seriell. Mit 1Mbaud funktioniert > das ganze noch. Mit 2Mbaud kommen nur noch wilde Streifen, sieht eher > aus wie rauschen. Wenn du mal die Takte des Displayinterrupt zählst und überlegst, wie lang ein Byte mit UART braucht - dann noch den Hardwarepuffer bedenken - dann sollte klar werden warum ;) Eventuell musst du noch die Latenz des UART-interrupt bedenken. Wenn du mehr willst als 1Mbaud wirst du den Displayinterrupt aufteilen müssen. Aber wahrscheinlich nutzt du die 1Mbaud momentan noch nicht mal voll. Der Software-FIFO braucht massig Rechenzeit und bremst die UART aus. An deiner Stelle würde ich den Datenempfang per Polling in der ASM-Routine erledigen. Aus der brauchst du auch eigentlich garnicht mehr rausspringen. Die kann man zur Main-Loop befördern. Muss aber nicht sein. Auf die Weise solltest du dann auch Netto 1Mbaud/10fps schaffen. Wenn du den Displayinterrupt noch halbierst sollten auch 2Mbaud/20fps drin sein. > In der asm routine wird FLM/Frame gesteuert. Der OCR1A (PD5) steuert > LP/Load und ich denke mal RD steuert XSCL/CP und den 4aus8 MUX und wird > aktiviert durch einen lesenden Zugriff auf den externen Speicher durch > ld Rd, X+. > Richtig so? Sollte stimmen. >>>Was ich überhaupt nicht verstehe: > Wo wird CKDIS gesteuert? Hab ja die ganzen Routinen rausgeschmissen wo > dies passierte.. Was ist CKDIS? > Hast du in deiner 2Mbaud Version den UART umgebaut? Ja, der Software-Fifo bremst enorm. Mit dem sind 2Mbaud Netto nicht drin. Um 2Mbaud Brutto erstmal zu erreichen muss man aber den Displayinterrupt verkürzen. Viele Grüße, Sebastian
Danke für deine Hilfe Sebastian Doch da tun sich gleich wieder Fragen auf: >Ja, der Software-Fifo bremst enorm. Mit dem sind 2Mbaud Netto nicht >drin. Kannst du bitte mal deine 2Mbaud Version anhängen damit ich mal schauen kann wie du das gelöst hast? >Um 2Mbaud Brutto erstmal zu erreichen muss man aber den >Displayinterrupt verkürzen. Welcher ist denn der Displayinterrupt?
1 | .section .bss |
2 | XStart: .ds.b 1 |
3 | YCnt: .ds.b 1 |
4 | #define XSIZEV XVSIZESW
|
5 | .section .text |
6 | .global TIMER1_OVF_vect |
7 | TIMER1_OVF_vect: |
8 | push r16 |
9 | in r16, _SFR_IO_ADDR(SREG) |
10 | push r16 |
11 | push XL |
12 | push XH |
13 | push r18 |
14 | lds XL, viewstart |
15 | lds XH, YCnt // Zeilenadresse laden |
16 | inc XH |
17 | cbi _SFR_IO_ADDR(PORTD), FLM |
18 | ld r16, X+ // 320 bits ausgeben |
19 | ld r16, X+ |
20 | ld r16, X+ |
21 | ld r16, X+ |
22 | ld r16, X+ |
23 | ...
|
Etwa der hier? Was genau bedeutet diese Schreibweise hier?
1 | .global TIMER1_OVF_vect |
>Was ist CKDIS?
Das hier:1 | // PortD
|
2 | #define CKDIS 3 //?????
|
3 | #define FLM 4
|
4 | #define LP 5
|
5 | #define WR 6
|
6 | #define RD 7
|
7 | |
8 | // PortE
|
9 | #define EnLCD 0
|
10 | #define ALE 1
|
11 | #define PWM1 2
|
>An deiner Stelle würde ich den Datenempfang per Polling in der >ASM-Routine erledigen. Wenn die ASM-Routine die selbe ist wie die oben erwähnte mit .global TIMER1_OVF_vect, dann wird die doch durch den Timer1 angesprungen, oder?? Also immer nur in einer bestimmten Zeit! Ich konnt das nicht simulieren, da der Simulator dort irgendwie überhaupt nicht reinspringen will. Hab versucht mir dort in der Simulation einen Brakepoint zu setzen. Das ging irgendwie nicht. Wie gesagt, zu "C" muss ich noch viel lernen.. Sonst hätt ich das alles schon komplett in ASM umgeschrieben. Kann man meiner Meinung nach viel besser simulieren! >Wenn du mal die Takte des Displayinterrupt zählst.. Das bekomm ich hin ;-) >und überlegst, wie >lang ein Byte mit UART braucht - dann noch den Hardwarepuffer bedenken - Ist in "C" geschrieben.. = Bahnhof ganz groß für mich :( Aber den Empfang bekomm ich auch in ASM hin. Ich sehe nur nicht, dank meiner magelnden C-Kentnisse, wo und wie der UART die ankommenden Daten speichert. Da ist ja immer noch der Empfangs-FIFO drin. => kein Plan hab! Wäre echt nett mal deine Version kennen zu lernen. Grüße Steffen
>>Um 2Mbaud Brutto erstmal zu erreichen muss man aber den >>Displayinterrupt verkürzen. > Welcher ist denn der Displayinterrupt? > Etwa der hier? ja, genau, den meinte ich. Teile ihn in zwei teile und ruf ihn doppelt so oft auf. Verkürzen (über Codeoptimierung) wirst du nicht viel können. > Was genau bedeutet diese Schreibweise hier? >
1 | > .global TIMER1_OVF_vect |
2 | >
|
Ist die Sprungmarke für den Timer1 Overflow. Ist ne eigenheit von C/ASM-Mischprojekten, dass man diese Formulierung auch noch hinschreiben muss. >>Was ist CKDIS? > Das hier: Sicher bin ich mir nicht, aber glaube das ist, um Daten aus dem RAM zurücklesen zu können, ohne, dass sie auf dem Display angezeigt werden. Am anfang der main wird der Pin initialisiert. Solange du das drinlässt kann dir der Pin eigentlich egal sein. >>An deiner Stelle würde ich den Datenempfang per Polling in der >>ASM-Routine erledigen. > Wenn die ASM-Routine die selbe ist wie die oben erwähnte mit .global > TIMER1_OVF_vect, dann wird die doch durch den Timer1 angesprungen, > oder?? Nein, ich meinte die lcd_writebyte > Ich sehe nur nicht, dank > meiner magelnden C-Kentnisse, wo und wie der UART die ankommenden Daten > speichert. Da ist ja immer noch der Empfangs-FIFO drin. => kein Plan > hab! einfach die ganze library (alle dateien, die irgendwie UART heißen) rausschmeißen. Und dann die uart_getchar() selbst implementieren (mit polling) oder gleich den gesamten UART-empfang in den ASM-teil verfrachten. > Wäre echt nett mal deine Version kennen zu lernen. Hab ich angehängt. Hoffe, du verstehst den code halbwegs. Ist für 8 Grastufen und es ist noch ne Bankumschaltung mit dabei - hab etwas mehr RAM an meinem Controller. Sebastian
Danke dir Sebastian für deine Hilfe. Den Code werde ich morgen mal durchforsten. >Verkürzen (über Codeoptimierung) wirst du nicht viel können. Ja, da hast du recht.. Das ist schon sehr kutz und knackig gehalten. >ich meinte die lcd_writebyte Was genau wird da eigentlich gemacht? Ist die zum speichern der empfangenen Daten da? In der mainloop steht die ja drin. Aber WANN genau wird die aufgerufen? ..und noch was: Wozu ist eigentlich der COMAND_TIMEOUT gut?
1 | #define DOTIMEOUT() ctimeout=COMMAND_TIMEOUT; while (!uart_data()) if (!ctimeout) goto mainloop
|
Grüße Steffen
Angehängte Dateien:
-
Grafik3.jpg
10 KB -
Grafik4.jpg
10 KB
Hallo an alle, Betr.: Display Wintek WD-H3224V von Pollin Nachdem ich nun das Display im Textmodus mit der Schaltung von Benedikt zum laufen gebracht habe und den Touchscreen mit Bascom wunderbar abfrage habe ich mich an die Grafikvariante von Benedikt getraut aber hier gibt es nun bei mir ein Problem. Wenn ich die Software von Benedikt in den Atmega 8515 lade erhalte ich ein sauberes Bild aber keine Graustufen (siehe Foto), lade ich die Software von Sebastian in den Atmega erhalte ich zwar 8 Graustufen aber das Bild wird im 1. Drittel noch mal dargestellt (siehe Foto). Eine Veränderung in den jeweiligen Programmen (Waistate, Framerate usw.) bringt keine Verbesserung, kann mir jemand weiterhelfen ??? mfg Walter10
Was für ein RAM wird denn benutzt?
Das hier: Marke Cypress Semiconductor Hersteller-Teilenummer CY62256LL-70PXC
Auszug aus dem Datenblatt: Address Bus Breite 15Bit Anzahl Bits per Word 8Bit Anzahl I/O Lines 8Bit Anzahl Ports 1 Anzahl Worte 32K Data Rate Architecture SDR Density 256KBit Maximum Betriebsstorm 50mA Maximum Betriebstemperatur 70°C Maximum Random Access Time 70ns Minimum Operating Temperatur 0°C Mounting Durchsteckmontage Pin Count 28 Product Height 4.95 Product Length 37.59 Product Width 13.97 Supplier Package MDIP Timing Typ Asynchron Typische Versorgungsspannung 5V
Ich würde jetzt mal einen Brücke zwischen irgendwelchen Adressleitungen tippen. Warum?: Die s/w Variante braucht nicht soviel Speicher wie die 4Bit oder 8Bit Variante. Deswegen scheint ja auch s/w zu funktionieren. Gruß Steffen
Ja diesen Fehler hatte ich schon vorher, bei meinem Layout war eine Verbindung zwischen einer Adressleitung und dem Masse-Polygon was dazu geführt hat das die Anzeige unvollständig war also nur Bruchstücke angezeigt wurden und versetzt dargestellt wurde. Daraufhin hab ich alle Adressleitungen noch mal durch gemessen und überprüft, aber keinen Fehler mehr gefunden. Ich werde mir wohl noch mal einen neuen Atmel und Speicher besorgen vielleicht haben die etwas abbekommen, oder es gibt jemanden der diesen Fehler auch schon mal hatte und eine Lösung kennt. mfg walter10
@Walter Hammes ich lehne mich mal ganz weit aus dem Fenster und behaupte bit 6 oder 7 der Adressleitungen liegt fest auf einem Pegel :D Ne, ernsthaft. Der Tip mit den Adressleitungen klingt plausibel, schau die mal an. Aber was anderes: Verwende doch bitte die Version, die Benedikt im Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" gepostet hat. Das ist die letzte offizielle version und enthält auch 8 Graustufen. Die älteren Versionen von Benedikt haben teilweise auch noch ein paar Bugs, die da nicht mehr enthalten sein sollten. Wenn du weniger Farbe willst konfiguriere es über die param.h. Alles was ich danach noch gepostet hab ist mehr oder weniger experimentell. Bei mir läufts/lief es, mehr kann ich aber auch nicht garantieren. @Steffen Auch wenn du es mitlerweile selbst rausgefunden haben dürftest: Die lcd_writebyte schreibt die Daten, die an sie übergeben werden, als Bilddaten in den RAM. Die Funktion ist also nicht sonderlich intelligent. In meiner letzten Version übernimmt die lcd_writebyteg8 auch noch den Datenempfang selbst. Damit spart man sich das verlassen und wieder aufrufen der Funktion, was doch jedes mal einige Takte sind. COMAND_TIMEOUT ist als Timeout beim Bilder übertragen gedacht. Wenn auf dem Weg ein Byte verloren geht würde der Displaycontroller ja erstmal ewig auf dieses Byte warten. Die Bild-routine würde erst beendet werden, wenn wieder ein neues Byte kommt. Wenn dieses neue Byte zu einen Befehl auslösen sollte funktioniert das nicht, weil es ja noch als letzte Bild-Byte angesehen wird. Man kann aber auch einfach eine Hand voll Nullen nach jedem Bild senden, dann kann man auf den Timeout verzichten ;) Sebastian
@Sebastian @Steffen Vielen Vielen Dank, ich habe heute morgen einfach noch mal die kompletten Adressleitungen vom Ram auf meinem Layout frei gekratzt und siehe da es funktioniert tadellos. Das nenne ich absoluten Fachverstand. Vielen Dank. Werde in Zukunft größeren Abstand zum Massepolygon lassen. Nun werde ich mal versuchen ein paar Kreise und Bilder auf dem Display anzuzeigen. mfg walter10
Eine Frage an die Profis. Ich habe hier ein LCD TLX-1241 (480x128 4_Datenbits). Dieses würde ich gerne mit meinem kleinen Computer Z86 clone (UB8830 8MHz) bedienen. Wäre das möglich? Gibt es eventuell fertige routinen für den Prozessor?
Hallo zusammen, ich möchte das Projekt auch gerne realisieren, ich warte noch auf die Teile, von daher probiere ich schon mal alles zu verstehen. Was ich nicht verstehe ist warum ad0 vom controller zwar am latch hängt, aber nicht weitergeführt wird, an den Speicher? 64K können adressiert werden wir haben aber nur 32K Speicher, da brauch man auch keine 16 adressleitungen. Jedoch ist nicht gerade diese eigentlich notwendig? Ist es nicht das bit das angibt ob eine adresse gerade oder ungerade ist? Oder war es vielleicht doch anders rum und bit0 gibt an ob wie die ersten 32K oder die nächsten 32K anschauen? Jedenfalls ist es in anderen Beispielschaltungen anders die ich gesehen habe... Und auf eines von beiden kann man doch nicht verzichten...? Z.B. Hier: http://www.mikrocontroller.net/articles/Speicher#Anschluss_an_den_Mikrocontroller Vielen dank für eure Antworten. Grüße Felix
@Peter: willst du dein Display mit dem Z86 Clone ansteuern? Dann bist du im falschen thread. Wenn du das Display mit dem Controller hier aus dem Thread ansteuern willst, und diesen Controller dann mit deinem Z86 Clone, dann passt der Thread. Fertige routinen dürfte es dazu kaum geben. Ich hab hier jedenfalls noch keine gesehen. Dein Display müsste sich prinzipiell mit Benedikts Controller ansteuern lassen, aber ich glaube, du müsstest den Code etwas anpassen. @Felix: Auch wenns mit sicherheit schonmal hier im Thread erklärt wurde: Das Display will die Daten 4-bit weise. Um die Speicher voll auszunutzen speichert Benedikt die daten aber 8-bit weise im Speicher. Um möglichst einfach nacheinander an die oberen und unteren 4 bit einer Speicheradresse zu kommen wird ad0 nicht zum speicher geführt. Dadurch zeigen immer 2 controller-interne Adressen auf die gleiche physikalische Speicherstelle. Bei jedem Lesevorgang wird dann noch der Multiplexer umgeschaltet und so zwischen den oberen und unteren vier bit ausgewählt. Warum AD0 jetzt noch gelatcht wird, wird wohl Benedikts geheimnis bleiben. Für die Funktion der Schaltung ists egal. Man sollte allerdings den Eingang des Latches auf einen definierten pegel legen. Je nach layout kanns da durchaus das einfachste sein, ihn mit AD0 zu verbinden. Viele Grüße, Sebastian
Hallo Thread. Mal zwei schnelle Fragen: - welches ist die aktuellste Version der Firmware ? Ich hatte gelesen, dass es etliche neuere Fassungen sowie einige Variationen gegeben hat. Kann mir jemand eine Empfehlung geben, welche Version am universellsten einzusetzen ist ? - Benedikt hat ja sowohl Schaltung als auch Firmware für den Betrieb mit 16 MHz ausgelegt, spricht irgendwas dagegen, das Ganze mit einem 12MHz Quarz (und entsprechender Änderung in der Firmware) umzusetzen ? Gruss und schöne Pfingsten, der Nachbauer
Hi bezüglich der Software kann ich dir auch nicht wirklich helfen das ist hier mittlerweile etwas durcheinander geraten. Ich denke die Letzte von Benedikt sollte die sein die mit dem ursprünglichen Projekt am ehesten läuft. Wobei die anderen Softwaren sicher auch funktionieren sollten. Bezüglich des Quarzes: Es hat seine Gründe weshalb ein 16Mhz Quarz eingesetzt wurde. Da der Display Controller ja in Software geschrieben ist benötigt die ganze Schaltung erst einmal einen höheren Takt und das Display Timing brauchbar zu erzeugen. Ansonsten ist die gGfahr dass das Display stark flimmert relativ hoch. ich hoffe dir soweit schon mal geholfen zu haben. MfG Kai
Hey Kai. Na, das ist aber weder ein Ja noch ein Nein. Dass auch Du keine konkrete Aussage wegen der Firmware machen kannst, bestätigt ja nur meinen Eindruck, dass es mittlerweile zu viele Varianten davon gibt. Ich werde so wohl zunächst einmal die Version aus dem Kopf dieses Threads verwenden. Mit der Frequenz hingegen konntest Du mich so noch nicht überzeugen - an anderer Stelle las ich, dass auch die Verwendung langsamer SRAMs ohne nennenswerte Probleme funktionieren soll [finde den Beitrag gerade nicht, erinnere aber, dass Benedikt dies im Thread zu der text-only Fassung der Firmware irgendwo schrieb: Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" ] Flimmern sollte das Display so oder so auch bei einem geringeren Takt am µC nicht - der Bildschirminhalt wird doch aus dem SRAM abgerufen. Da dürfte es relativ unbedeutend sein, wie schnell dieser Inhalt in den SRAM geschrieben wird.
Hi, das ist hier im Forum die wohl die aktuellste SW. In der param.h lässt sich alles einstellen. Die PDF sagt auch was über das Timing (und damit den Takt) des AVRs aus. Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Langzeiterfahrung habe ich sogar mit der Version 1.0 Man müsste den Beitrag wirklich mal etwas sortieren. Wigbert Schöne Feiertage.
Hey Wigbert. Danke für Deinen Hinweis. Ich habe jetzt die Firmware aus dem Link geladen, für die Verwendung mit einem 12MHz Quarz geändert [ #define XTAL_CPU 12000000UL ] und mal in den ersten Testbetrieb genommen. Jetzt zeigt mir das angeschlossene Display [das Wintek wd-h3224v] nur ein schwarzes Bild an, jedoch kann ich kurz nach dem Einschalten Benedikts Testscreen einmal aufblitzen sehen, danach wird das Display komplett schwarz. Jemand eine Idee, woran das liegen könnte ? [ Die Kontrastspannung, die ich von einem MC34063 beziehe, beträgt +26V, kann's vielleicht daran liegen ? ] Gruss, Martin
Hallo Martin, die +26V scheinen etwas zu hoch zu sein, sind bei meinen Display's zwischen 21,5 und 22V. Versuch mal zu reduzieren. Viel Erfolg Ralf-Peter
Grelli, erneut meinen Dank - nachdem ich die Kontrastspannung auf ca. 22V gedrosselt habe, ist jetzt ein Bildinhalt zu erkennen. Leider ist dieser noch ein wenig zerschreddert ( nur bestimmte Teile - v.a. die Schrift und Teile des Rahmens in Benedikts Testbild, die Gradientenlinie wie auch einige der Quadrate sind o.k. ), aber durch Deinen Hinweis bin ich schon einen guten Schritt weiter gekommen. Danke Dir !
Nachtrag: Ich habe noch ein bisschen herumprobiert - dabei unter anderem auch mal die brown out detection [BODEN und BODLEVEL] des Mega8515 angeschaltet. Siehe da - schon blieb das Display leer. Also habe ich ein stärkeres Netzteil (1.5A max, anstelle des 350mA) ausprobiert - ohne Erfolg. Kann es überdies sein, dass der "gestörte" Bildinhalt, wie ich ihn im vorherigen Post beschrieb, auch damit zusammen hängt ? Hat jemand eine Idee ?
Hallo Martin, - JEDE - Fehlersuche beginnt beim Netzteil ! Wie erzeugst Du die ca. +22V ? Grelli
Ralf-Peter Grellmann schrieb: > Wie erzeugst Du die ca. +22V ? MC43063 mit Widerständen R1 = 1.5k und R2 = 20k.
Die aktuellste offizielle Version ist die, die Benedikt zuletzt gepostet hat. Der Link von Wigbert zeigt genau auf den richtigen Post. Es gibt noch einige andere mehr oder weniger experimentelle Versionen für mehr Datendurchsatz oder um das Display hochkant zu verwenden. Die würde ich aber nur nehmen, wenn ich sicher weiß, dass meine Hardware läuft. Zum Prozessortakt: Der ist aus sehr gutem Grund auf 16MHz. Der Controller muss zwar die Daten nicht erst aus dem RAM zurücklesen um die auf dem Display anzuzeigen, aber er gibt den Takt vor, mit dem die Daten vom RAM ins Display kommen. Da das in Software gemacht wird, braucht es auch einiges an Rechenzeit. Deine Probleme KÖNNTEN vom zu geringen Takt kommen. Stell mal die Anzeigefrequenz auf 3/4 des aktuellen Wertes. Oder deaktiviere die 8 Graustufen funktion. Oder beides. Oder steck versuchsweise einen 16MHz Quarz rein. Wenn es läuft kannst du die Anzeigefrequenz auch wieder hochdrehen. Darunter leidet allerdings die Geschwindigkeit, mit der die Bilder aufgebaut werden. Also nicht höher stellen als nötig. Viele Grüße, Sebastian
Danke für den Hinweis, Sebastian. Jedoch dürfte das alleine nicht die Sache mit den brown outs erklären, oder ? Gruss, Martin
Hallo Martin, wie sieht eigentlich deine 5Volt Versorgung aus? Hast du hier einen 5V Festspannungsregler mit entsprechenden Kondensatoren? Der Prozessor sollte seinen obligatorischen 100nF direkt am VCC Pin haben. Da gibts kein wenn und aber. Ich hatte hier bei nem Versuch auch gedacht die brauch ich zu testen nicht aber falsch gedacht! Eventuell noch einen Pullup an Reset schaden tuts nicht. Verbessert auf jeden fall das EMV Verhalten. MfG Kai
Hey Kai. Die Spannungsquelle ist ein 7805. Ja, so mehr ich hier lese, desto eher glaube ich, dass ich meinem Board noch ein paar Folienkondensatoren und eine Prise Pullups spendieren sollte. Danke für den Hinweis ! Gruss, Martin
Kleines Update: An der Frequenz liegt's nicht - ich habe jetzt den 12MHz Quarz durch einen 16er ersetzt und auch die entsprechende Firmware [direkt das unveränderte "Original"] auf den µC übertragen - das zerschredderte Bild bleibt dennoch. [Zur Erinnerung: Auf dem LCD wird im oberen Drittel der entsprechende Teil von Benedikts Testbild verzerrt dargestellt. In den beiden unteren Dritteln der Anzeige wiederholt sich dieser Teil.] Ich habe mir auch nochmal die Musse gegönnt und die Spannungen an den VCC der verwendeten ICs nachgemessen [jeweils gegen den entsprechenden Massepin] - alle ICs liegen bei ca. 4.2 ~ 4.6 V, was laut den Datenblättern kein Problem darstellen dürfte. [ Vielleicht mit Ausnahme des SRAMs ? Wie kann ich die Spannung dort auf einem höheren Level stabil halten ? Der 7805, welchen ich zur Spannungsversorgung verwende, spuckt ca. 4.8 V aus. ] Hat noch jemand eine gute Idee, an welcher Ecke ich mit der Fehlersuche weiter machen könnte ? Gruss, Martin (a.k.a. der Nachbauer)
Schieß doch mal ein Foto vom Display. Das was angezeigt wird ist klar und (halbwegs) kontrastark zu erkennen? Ist dein RAM groß genug? Hast du irgendwo Adressleitungen vertauscht und/oder miteinander verbunden? Gleiches für Datenleitungen? Welche Version des Schaltplans hast du verwendet? Die im ersten Posting des Threads enthält einen Fehler. Ich muss aber zugeben, dass ich hier ziemlich im dunklen stocher ;) Viele Grüße, Sebastian
Angehängte Dateien:
-
2011-06-18_01.14.41.jpg
730 KB
Hey Sebastian. Der SRAM dürfte eine 50ns Variante sein. Die Schaltpläne habe ich mir auch noch einmal genau angesehen und die Leitungen nochmals alle durchgemessen. So weit kann ich keinen Fehler entdecken. Anbei eine Aufnahme des angezeigten Bildinhaltes. Ich hoffe, dass dieser Aufschluss über die mögliche Fehlerursache geben kann. Gruss, Martin
Hi, ich hatte mal am Anfang sowas Ähnliches, da war am HC157 Pins vertauscht. Anbei mal die Schaltung wie sie sein soll. Wigbert
@Martin: Da stimmt was an deiner Schaltung nicht ;) Bei den Leitungen vom HC157 zum Display dürfte eine leitung keinen Kontakt haben oder Fest auf Ground gezogen sein (Brücke zur Nachbarleitung?) Die Horizontalen Widerholungen sind etwas komisch, aber normal kommt sowas von Fehlern in den Adressleitungen. Einfach nochmal alles durchschaun und nachmessen ;) Sebastian
Jetzt erinnere ich mich , am Hc74 war ein Pin vertauscht. Wigbert
Hallo Wigbert, hey Sebastian. Lieben Dank für Eure Hinweise und den Schaltplan. Ich habe heute Abend alle Kontakte erneut durchgemessen und noch fehlende Abblockkondensatoren [je 100nF] vor alle ICs gesetzt. [Sebastian: ich habe genau darauf geachtet, es ist (leider) keine Datenleitung auf Masse gezogen] Leider stellte sich keine Veränderung am Ergebnis ein. Vielleicht spielt es eine Rolle: Ich verwende das Wintek WD-H3224V Display von Pollin -- mittlerweile das zweite, um ggf. vorhandene Probleme auf Seiten des Displays auszuschliessen. Ich werde Morgen erneut alle Verbindungen durchmessen, um ganz sicher zu gehen. Gruss, Martin
Heute habe ich mir die Zeit genommen, noch einmal in Ruhe alle Leitungen durchzumessen - es ist alles so, wie es sein sollte. Darüber hinaus konnte ich jedoch eine interessante Beobachtung machen: Bei einem probeweisen Einschalten der Schaltung gab es mit einem Mal erstmals ein einwandfreies Bild. Natürlich habe ich diesen Zustand auf Reproduzierbarkeit testen wollen, jedoch zeigte sich schon beim erneuten Neu-Einschalten wieder die o.g. Störung. Vielleicht könnt Ihr mit dieser Information etwas anfangen. Gruss, Martin
Hallo Leute Ich brauche unbedingt ein EEPROM an dem Mega8515 um ein Bild (Startbildschirm) gleich nach der Initialisierung anzuzeigen. Ich habe mir dafür ein ATMEL25256A SPI EEPROM ausgesucht. Die Anschlüsse dafür wären ja noch frei. Hab mir auch schon die Application-Note AVR107 (Interfacing AVR serial memories) herunter geladen. Anschlussbelegung: EEPROM SCK -> SCK Mega8515 EEPROM SI -> MOSI Mega8515 EEPROM DO -> MISO Mega8515 EEPROM /CS -> /SS Mega8515 -> /CS noch über einen 4k7 Widerstand gegen 5V Funktion: Wenn der Display-Controller initialisiert wurde soll der Startbildschirm aus dem EEPROM geladen und sofort angezeigt werden. Danach wird der Uart frei gegeben. Ich hab die Controllerversion auch schonmal so weit abgespeckt (fast alle Funktionen entfernt) da ich nur jeweils ein s/w Bild laden muss. >>Hat schonmal jemand sowas gemacht? >>Brauche da mal eure HILFE!!! Ich komm mit "C" einfach nicht klar Wo definier ich zum Beispiel die Ports für den SPI? Hab mal die SPI-Treiber und meine Abgespeckte Version mit angehangen
Schau dir mal die lcd.c genauer an. Da wird (wenn ichs richtig im kopf hab) alles initialisiert. Da hängst du dann auch die SPI-Init rein. In der lcd.c wird auch das aktuelle Startbild erzeugt. Diesen Code müsstest du dann einfach durch deinen eigenen ersetzen (also daten aus SPI laden und über die im pdf dokumentierten subroutinen ins RAM schreiben). Du kannst auch überlegen, ob du dein Bild algorithmisch erzeugen kannst (also über rechtecke, kreise, linien, text,...). Dann könntest du dir eventuell das externe EEPROM sparen. EDIT Ich bin mir nicht sicher, welche Version du runtergeladen hast, aber von den experimentellen, die ich noch gepostet habe kann ich nur abraten, wenns mit den Programmierkenntnissen nicht sooo gut steht. Die bei dir eingestellten 2MBaud machen mich jedenfalls hellhörig. Mit der letzten offiziellen Version von Benedikt wird das nicht funktionieren und mit meinen experimentellen Versionen könnte sw probleme machen. Nimm doch bitte diese Version. Die Sollte auf jeden Fall funktionieren: Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Viele Grüße, Sebastian
Hallo Sebastian Endlich eine Antwort. Huhu.. Meine Baudrate ist momentan bei 1Mbaud. Das funktioniert auch alles supi. Ich hab mich heute schon soweit durchgewurschtelt und all die SPI-Routinen zum Laufen gebracht. Jetzt steh ich natürlich wieder auf dem Schlauch, was die Einbindung zum RAM angeht. Hier mal ein kurzer Auszug aus der Funktion zum EEPROM lesen. Funktion:
1 | char GetCharArray(int address, int nb_of_bytes, char* destination); |
und hier der code in der "main"
1 | int main(void) __attribute__((OS_main)); |
2 | int main(void) |
3 | { PORTA=255; |
4 | PORTC=255; |
5 | PORTD=7; |
6 | // DDRB=255;
|
7 | DDRD=254; |
8 | DDRE=255; |
9 | |
10 | init_spi_master(); |
11 | |
12 | int start_address = 0; |
13 | static char destArray[2*PAGE_SIZE * sizeof(char)]; |
14 | static char* dest = destArray; |
15 | |
16 | //Read a page
|
17 | while (GetCharArray(start_address, (PAGE_SIZE-1), dest) != TRANSFER_COMPLETED) {} |
18 | //the page is available in the SRAM buffer pointed by dest
|
19 | |
20 | |
21 | lcd_init(); // LCD Controller initialisieren |
22 | uart_init(UART_BAUD(UART_BAUD_RATE, XTAL_CPU),UART_BAUD_U2X(UART_BAUD_RATE, XTAL_CPU)); |
Ich würde das auch gern in der lcd.c einbinden. Und zwar da wo der RAM gelöscht wird.
1 | void lcd_clear(void) |
2 | { unsigned short i; |
3 | for (i=0; i<(65536-DDRAM); i++) |
4 | mem[i]=0; |
5 | }
|
Wie kann ich jetzt den Pointer auf das Array von den SPI-Daten gleich in den Display-RAM schreiben??? Ich glaub ich bin schon so na.. Aber ich bekomms einfach nicht hin! Kanst du mir da noch helfen? LG Steffen
Ach ja, mein Bild im EEPROM hat 320x240 Bit (40x240 Byte)
Ich denke mal ich muss
1 | unsigned char * const mem=(unsigned char * const)DDRAM; |
nur igendwie mit dem Array
1 | static char destArray[2*PAGE_SIZE * sizeof(char)]; |
2 | static char* dest = destArray; |
verbinden, oder??
"Einfach so" in den RAM schreiben funktioniert nicht, weil die Daten nicht linear im RAM abgelegt sind. Nimm die vorhandenen Subroutinen. Für dich also die lcd_writebyte. Der Aufruf davon ist im pdf aus dem projekt-zip dokumentiert. In die lcd_clear würde ich das nicht hängen. Ist einfach unsauber. Schreib dir eine eigene Funktion, die die Daten aus dem EEPROM ausliest und dann mit lcd_writebyte in den RAM schreibt. Die rufst du dann da auf, wo auch aktuell das Startbild erzeugt wird. Wenn du Benedikts Version verwendest läuft 1MBaud aber nur sauber, wenn du mit dem Master nicht so schnell senden kannst, wie es der Slave zulässt. Eigentlich ist nämlich der Displayinterrupt zu lang, sodass du Bytes verlieren würdest. Noch ne andere Idee: Du steuerst das Display ja eh von außerhalb an. Wieso nicht einfach von dort das Startbild reinschieben? Dann sparst dus dir an einem fremden System zu basteln. Das aktuelle Startbild kann man ja rauskommentieren. Dann bleibt das Display schwarz, bis was an der UART kommt. Sebastian
HAllo Sebastian >"Einfach so" in den RAM schreiben funktioniert nicht, weil die Daten >nicht linear im RAM abgelegt sind. Das hab ich gestern auch noch gemerkt. :( >Schreib dir eine eigene Funktion, die die Daten aus dem EEPROM ausliest >und dann mit lcd_writebyte in den RAM schreibt. Die rufst du dann da >auf, wo auch aktuell das Startbild erzeugt wird. So hab ich es jetzt erst mal gelöst. Ich verwende nun die "lcd_writebyte(x,y,c)". Und es funktioniert erst mal soweit wie es aussieht. Allerdings etwas unschön. Ich hol mir jetzt momentan jedes einzelne Byte vom EEPROM und sende es gleich danach weiter über die "lcd_writebyte". Das heißt für jeden EEPROM Zugriff habe ich jetzt einen Head von 4 Byte für ein Nutz-Byte. Das ist eher subotimal. Wenn ich den EEPROM mit dem Bild gefüllt habe häng ich mal ein Bild an. (PonyProg funktioniert dafür leider doch nicht) >Wenn du Benedikts Version verwendest läuft 1MBaud aber nur sauber, wenn >du mit dem Master nicht so schnell senden kannst, wie es der Slave >zulässt. Eigentlich ist nämlich der Displayinterrupt zu lang, sodass du >Bytes verlieren würdest. Ich weiß. Ich muss natürlich das Busy beim Senden abfragen. Und schon sind es effektiv keine 1Mbaud mehr. Aber es reicht mir so. >Das aktuelle Startbild kann man ja rauskommentieren. Dann bleibt das >Display schwarz, bis was an der UART kommt. Das hab ich schon gemacht. Ich habe ja bis jetzt keinen Startbildschirm mehr. >Noch ne andere Idee: Du steuerst das Display ja eh von außerhalb an. >Wieso nicht einfach von dort das Startbild reinschieben? Das wär die einfachste Lösung. Aber der andere Controller hat einen Bootloader drauf der nach den Reset/Einschalten erstmal ca 5sec wartet bis er die Application startet. Deswegen möchte ich ja auch in dieser Zeit ein Startbild im Display anzeigen und kein schwarzen Bildschirm.
Angehängte Dateien:
-
Startbidschirm.jpg
110 KB
Hallo So, ich hab es nun endlich hinbekommen. Der Startbildschirm läuft nun endlich direkt aus dem EEPROM der einfach an der ISP Buchse hängt. Steffen
Hallo zusammen, ich hab mal eine Frage an die Bild Spezialisten. Mein Touchscreen von Pollin im 8 Graustufen Modus funktioniert wunderbar, ich kann Rechtecke, Kreise und Linien darstellen und das Touchpad abfragen nur würde ich gerne mal ein Bild anzeigen ,aber hier komme ich zu keinem Erfolg, ich Programmiere in Bascom und steuere den 8515 mit einem Atmega32 an. Die Anleitung in Bascom hier im Forum zur Anzeige des Hasen funktioniert einfach nicht bei mir. Wäre es möglich eventuell eine kleine Anleitung zu geben ? (z.B Bild mit Grafikkonverter umwandeln, welche Einstellung, Erzeugte Daten in Bascom einbinden und an 8515 übergeben mit Hinwies zu den Graustufen und Pointervarialblen zu den Datenbanken) Vielen Dank walter10
Hallo Walter, hast du dir den Thread (ab da, wo es die 8Graustufen-Version gibt) durchgelesen? Mit den Bildern hatten schon einige Probleme. Vielleicht findest du da was. Im Doku-pdf ist glaube ich ein kleiner Fehler drin beim Senden von 3bit Bildern. Um dir zu helfen wäre es hilfreich, wenn du mal postest, was du überhaupt an den Controller sendest, und was das Display dann macht. Ich kann dir aber nicht versprechen zu antworten. Bin grade im Urlaub. Viele Grüße, Sebastian
Angehängte Dateien:
-
IMG441.jpg
1,1 MB
Hallo zusammen, also ich hab jetzt soweit alles mögliche versucht und habe immer das Problem das die Bilder nach ca 3 mm von oben verschoben sind, egal wo ich sie auf dem Display hinsetzte. Ich hab mal ein Bild aus dem Grafikkonverter auf 208x144 Pixel verkleinert und im Floyd-Steinberg Verfahren umgewandelt und entsprechend für Bascom nachbereitet ergibt dann 3744 Bytes wie in der Anleitung und sende diese Daten zum Display. Auch wenn ich den Hasen aus dem Forum nehme und die Daten ausgebe sind die Füße von dem Hasen nach rechts verschoben, kann da eventuell ein Hardwarefehler vorliegen. Zur Kontrolle hab ich auch mal das Basicprogramm mit eingestellt. mfg walter10
Könnte gut am gewählten Quarz und der Baudrate liegen. 10,24MHz sind sehr ungewöhnlich. 10,24MHz und 57,6kBaud hat ne Fehlerrate von rund 1% da kann es sehr gut sein das der Empfänger hin und wieder mist empfängt und das bild dann so aussieht. Versuch mal einen anderen Quarz am besten einen Baudraten Quarz wie z.B. 14.7456 MHz oder auch 12MHz. Tritt der Effekt immer an der selben Stelle oder immer an unterschiedlichen Stellen auf?
Also hab mir einen 14.7456 MHz Quarz besorgt und neu Compiliert aber der Fehler bleibt ca. die ersten paar Zeilen sind korrekt und dann macht das Bild einen Sprung und wird verschoben und der rechte Teil wird links angelegt und das Gesamtbild wird nach rechts verschoben. Das Problem tritt immer auf egal wo ich das Bild auf dem Display platziere. PS. der 10,24MHz Quarz war noch ungenutzt, den 14,7456 Mhz hab ich aus meinem AVR-Server mit Kamera ausbauen müssen. mfg walter10
mal die ganze Sub für mein "Karnickel" Sub Bild Local Count As Word Local B As Byte If Bild_bit = 1 Then 'Flag, woher auch immer Printbin 16 ; 170 ; 30 ; 63 ; 8 ; 64 ; 0 ' Bildplatz If Wahl = 0 Then Restore Hase : 'Bildauswahl If Wahl = 1 Then Restore Schildkroete : If Wahl = 2 Then Restore Taste : For Count = 1 To 512 'hole Byte Read B Printbin B Next Count Bild_bit = 0 'Flag auf 0 setzen End If End Sub Ich hatte das mit Bitmap_Converter in C ausgegeben und für Bascom umgeschrieben. Vielleicht ist was Hilfreich. Wigbert
Angehängte Dateien:
-
IMG439.jpg
46 KB
Hab ich gemacht und so sieht das Ergebnis aus: siehe Bild walter10
Es funktioniert: Aber ich mußte mir nochmal fast das ganze Forum durchlesen um den Fehler zu finden, es liegt nicht am Quarz. Und zwar der Beitrag von Bruno M hat mich auf die Lösung gebracht. Es ist ganz alleine der Clear Befehl(Printbin 12) wenn der vorher gesendet wird, dann klappt es nicht mit den Bildern. Weiß jetzt nicht ob das nur an Bascom liegt aber irgendwie werd ich das jetzt hinbekommen, und mich nun mal mit den Graustufen beschäftigen. Vielen Dank walter10
Hallo Walter, du handlest das Busy-signal nicht richtig. Wenn du das richtig machst, ists auch egal, welcher Befehl vorher kommt. Sobald das Busy-signal anliegt darfst du nur noch eine Hand voll Bytes an den Displaycontroller schicken. Wie viele das sind sollte im Doku-pdf stehen. Wenn du das in den Sourcen anders konfiguriert hast musst du dich natürlich an deine Konfig halten. Bei dir passiert momentan folgendes: Du Lässt das Display löschen und sendest gleich die ersten Bilddaten. Die kommen dann erstmal in den Puffer des Displaycontrollers. Der ist aber voll, bevor der lösch-befehl abgearbeitet ist - genau hier gehen dir Daten verloren. Dadurch entsteht der Versatz. Viele Grüße, Sebastian
Hallo, Ich mir mal so überlegt, ob man mit einem ATmega1284P-PU (gibt es bei Pollin) nicht sogar den LCD-8Graustufen_Grafikcontroller implementieren könnte. Der ATmega1284P-PU hat intern 16kByte RAM !!! Damit könnte einiges an Hardware des LCD-8Graustufen_Grafikcontroller wegfallen und der Aufbau sich ähnlich einfach gestalten wie hier dieser LCD-Text_Controller. Was meint ihr??
Um es kurz zu machen: Nein. ;) Die 16kByte würden erstmal eh nur für S/W reichen. 4 Graustufen brauchen 18,75kByte und 8 Graustufen brauchen 28,125kByte für je ein Vollbild. Wenn man sich auf S/W beschränkt könnte es hinhaun, hab ich aber nicht durchgerechnet. Aber sobald du Graustufen willst wirds mindestens knapp, wenn nicht unmöglich (abgesehen vom Speichermangel). Benedikts Schaltung ist so gebaut, dass für einen Displayrefresh die Daten direkt vom RAM ins Display geladen werden. Der Controller gibt nur den Takt vor. Würdest du die Daten im internen RAM vorhalten, müsste die CPU erst den RAM auslesen und die Daten dann auf einem Port dem Display zur Verfügung stellen. Die Steuersignale des Displays kämen dann auch noch dazu. Das dauert definitiv länger, auch wenn die Zugriffszeit im internen Ram etwas kürzer ist. Du kaufst dir den geringeren Schaltungsaufwand also durch mehr CPU-Last, was die Framerate deutlich drücken dürfte. Aber schau dir doch mal den LCD-Controller im Textmodus (da hast du ja unerhörterweise genau das gleiche gepostet) genauer an. Vielleicht kannst du den mit Hilfe des Mega1284 soweit aufbohren, dass er grafikfähig wird. Ich kenne die Software des Textcontrollers nicht genau, aber eigentlich müsste es (mit genug RAM) möglich sein, dem Grafik beizubringen. Oder was viel Sinnvoller wäre: Nimm einen der vielen Displaycontroller die es gibt. Zum Beispiel von Epson. Das verringert den Schaltungsaufwand auch enorm und dürfte sogar eine deutlich höhere Leistung bringen als die Lösung hier. Sebastian
Sebastian ... schrieb: > Die 16kByte würden erstmal eh nur für S/W reichen. 4 Graustufen brauchen > 18,75kByte und 8 Graustufen brauchen 28,125kByte für je ein Vollbild. Ja, das hab ich wirklich nicht bedacht. Da hast du wohl recht Sebastian. Dann lohnt es sich wirklich nicht mit dem ATmega1284 rum zu experimentieren. Der kostet ja auch immerhin min. 7 Euronen. Naja, war halt nur mal so eine Überlegung.. LG Steffen
Hallo zusammen, Hab bei mir im schrank noch nen sp14q002 gefunden und würde den controller gerne nachbauen. Hat noch wer ne unbestückte platine zum verkauf?
>Hat noch wer ne unbestückte platine zum >verkauf? Ich, schick mir eine Mail. Wigbert
Angehängte Dateien:
-
SP14Q002.jpg
290 KB
Hi, mal was neues von der GLCD-Front. Ein SP14Q002 an Benedikts Graphikkarte. Zusätzlich muss nur ein Poti die Spannung V0 einstellen. Es ist etwas grösser wie das NANYA. Blauer Hintergrund. Preis des Displays etwa 9 Euro+Versand. Eine Adapterplatine ist auch schon geroutet. Ich mach noch ein paar SW Tests und könnte mir dann eine Sammelbestellung vorstellen. Vielleicht noch was für Weihnachten. Wigbert
Hey Wigbert. Würden bei der Sammelbestellung auch wieder Platinen mit aufgegeben ? Oder hast Du ggf. noch eine rumliegen ?
Angehängte Dateien:
-
Disp.jpg
390 KB
Hallo, ich habe heute noch mal die Display-Platine an die RS232 Schnittstelle gehangen. Mal zur Ansicht, ein halb invertiertes Display bei Spannungswerte VEE, V0 laut DBL. Man kann mit dem Display sicher keine Wunder erwarten, aber ein kostengünstiges Spielzeug. @Martin Schröer ich hatte an ein Bausatz mit folgendem Umfang gedacht: Graphikkartenplatine; Adapterplatine für GLCD; FFC Buchse; S-Ram;alle SMD; Speicherspule; und das GLCD. Schönes Wochenende. Wigbert
Hallo Wigbert Wenn man sich schon so konsequent mit den GLCD's wie du beschäftigst, warum integrierst du nicht auch gleich den Inverter für die Hintergrundbeleuchtung mit in das Layout?
@Wigbert Picht-dl1atw Wenn du eine Sammelbestellung machst, würde ich 2 bis 3 Platinen nehmen.
@Steffen H. na ja, sooo viel mach ich auch wieder nicht. Ein Inverter nachbauen lohnt sich wohl preislich kaum. Ich wollte Benedikts GRAKA nicht sterben lassen, nur weil es keine NAN-YAs mehr gibt und such immer nach Ersatzdisplays. Wobei, für Hinweise bin ich immer offen. Ich hatte schon mal in Erwägung gezogen ein Inverter aufzustecken. Die Spannungsversorgung(5V) ist ja schon auf dem Board vorgesehen. Wigbert
Hier mal ein Vorschlag für einen Inverter. Diese Schaltung funktioniert so bei meinen Displays schon seit Langem. Den CCFL Trafo bekommt man leider nur bei DigiKey, Mouser oder auch Farnell. Gruß Steffen
>Den CCFL Trafo bekommt man leider nur bei DigiKey, Mouser oder auch >Farnell. Eigentlich kommt wohl nur Digikey in Frage. Ca 4-5 Euro für den Trafo. Steffen hast Du mal auch Langzeittests gemacht? Bei zu hohen Strom leiden sicher die CCFL-Röhren. Wigbert
Diese Schaltung wurde schon ausgiebig getestet und wird in medtec Produkten so verbaut. Bei mir selber läuft das ganze schon länger als 2Jahre ohne die CCFL Röhre zerstört zu haben.
Angehängte Dateien:
-
Testbild.jpg
320 KB
Hi, der Adapter-Prototyp des SP14Q002 läuft anstandslos auf mein Board. Ich denke, anfang des neuen Jahres werde ich einige machen lassen. Ansonsten: Siehe Testbild Wigbert
Moin allerseits, Ich habe mal wieder ein tolles e-Bucht Angebot genutzt und mir 2 Epson EG-4801-ER gekauft... Nun zu meiner Frage, das Display hat eine Auflösung von 512*128 Pixel, bekomme ich den Controller soweit "aufgebohrt"? Das Datenblatt ist übrigens hier: http://www.knjn.com/files/512%20x%20128%20Graphic%20LCD%20Display%20-%20EG4801.pdf MfG
Sollte recht problemlos gehen. Die Ansteuerung des Displays scheint auf den ersten blick sehr ähnlich zu den hier verwendeten zu sein, also wenig oder keine anpassungen an der Hardware nötig. Die Software muss natürlich an die neue Auflösung angepasst werden. Wenn die S/W reicht geht das relativ einfach. Bei 4 Graustufen bin ich mir jetzt ohne nachschaun nicht sicher, aber sollte auch ohne weiteres machbar sein. 8 Graustufen sind an sich auch kein Problem, allerdings musst du dann die Daten im RAM anders anordnen. Das sollte prinzipiell ganz gut machbar sein, aber man muss sich halt schon etwas tiefer in die Software einarbeiten und muss auch alle low-level Schreib-Routinen anpassen. Grund dafür ist, dass die 512 Pixel bei 3bpp nicht mehr "nebeneinander" in den RAM passen. Momentan liegt eine Displayzeile immer so, dass sich die höchsten 8 Adressbits innerhalb der Zeile nicht ändern. Das wäre mit 512 Pixeln in einer Zeile nicht mehr gegeben. Viele Grüße, Sebastian
Hallo. Das klingt gut. Mir würden im Prinzip auch schon 2 Graustufen genügen. Dann werde ich mal eine Platine Fräsen und etwas ausprobieren. Könnte mir jemand mit der Softwareänderung helfen? Meine Kentnisse beschränken sich leider nur auf BASCOM. Was die Anpassung für mich etwas kompliziert macht. Jedoch habe ich den AVR-GCC Installiert und sollte in der lage sein änderungen vorzunehmen... MfG und Danke
Klar, wenn du Fragen hast dann stell sie einfach. Für den Anfang solltest du halt den vorhanden Code zumindest halbwegs verstehen, sonst wirds reine Glückssache. Der wichtigste teil für dich dürfte der Display-interrupt sein. Der ist in Assembler geschrieben. Ist aber auch kein größeres problem. Die Befehle sind alle in der Hilfe vom Studio erklärt. Darin müsstest du in Jeder zeile einige Pixel mehr ausgeben als das jetzt der fall ist und dafür nur 128 Zeilen durchlaufen lassen bevor das Bild beendet wird. In der param.h gibts auch parameter, die die Displaygröße angeben. Die solltest du auch ändern, weil sie für einige berechnungen hergenommen werden. Wenn ich mich nicht irre musst du die Schreibroutinen nicht weiter anpassen. Für den Gültigen Bereich sollten die auf die Displaygröße aus der param.h zurückgreifen. Sicher bin ich mir aber nicht. müsste auch erst wieder in den code schaun. Viel Erfolg bei deinem Vorhaben! Sebastian
Hallo. Ich habe gerade angefangen mein Layout an die Gegebenheiten anzupassen, da fiel mir auf, dass das Display mehr Anschlüsse hat, als der Graphikcontroller... Ich habe bis jetzt Contr.-- Display D3 --- D3 . . . . D1 --- D1 XSCL --- XSCL LP --- LP ON/OFF--- YDIS Übrig ist bis jetzt am Controller : "M_AC" und "FLM_Frame" Am Display ist noch : "FR" , "YSCL" und "DIN" frei. Wie ist dies anzuschließen, bzw. der Controller anzupassen? MfG
Hallo zusammen, kann mir jemand sagen für welche Spalten - u. Zeilen - Treiber die Software geschrieben wurde. Könnte das Display "Grafikdisplay 320x256" bei Pollin füe 5,-95€ passen.
halo, h habe habe in paar Problm einBitmap bild zum glcd Conrole un üertragen mein Sourccode ist im Anhang. das bild ist 240x240 pixel gross,die Abmessung auf dem Display stimmen aber der Inhalt sind nur wirre pixel erkenbar. Wenn ich das ganze in Assembler schreibe geht es, aber in C gehts überhaupt nicht. vielleicht kann mir einer von ihnen weiterhelfen was ich Falsch mache mfg
Erstmal sorry, dass ich mir so lange Zeit gelassen habe. War viel zu tun... @Denis Hat sich das Problem mitlerweile gelöst, oder soll ich mir das nochmal anschaun? Aus dem Stand weiß ich jetzt auch nicht, was mit den übrigen leitungen anzufangen ist. @Ronny Prinzipiell sollte das Display gehen. Problem ist aber, dass du kein Datenblatt dazu hast. Dir fehlt also die Anschlussbelegung. Auch die höhe der Kontrastspannung kannst du so eigentlich nur raten. Schau dir doch mal das Wintek hier an: http://www.pollin.de/shop/dt/Mzk0OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_WINTEK_WD_H3224V.html Dazu gibts auch ne Anschlussbelegung und in Benedikts anderem 320*240-GLCD-Thread gibts auch genug erfahrungen mit dem Display sowie eine Umbauanleitung auf weiße Hintergrundbeleuchtung. @Heinz Wenn sich das Problem noch nicht gelöst hat, dann schieß doch mal ein Bild deines Displays. Oft erkennt man daran schon ungefähr, was schief läuft. Dann muss ich mich nicht erst durch deine Quellen arbeiten ;) Viele Grüße, Sebastian
Angehängte Dateien:
-
20120205_135413.jpg
200 KB
hallo Sebastian , Anbei der Display-Inhalt sind nur lauter wirre zeichen, vielleicht könnten sie mir da ein wenig weiterhelfen. mfg
Aber nur, wenn du mich duzt ;) Das schaut stark danach aus, dass du den Befehl zum Bild anzeigen nicht sendest. Ein kurzer Blick in den Code scheint das zu bestätigen. Sollte ich die entsprechenden Befehle im Code übersehen haben, dann prüfe bitte nochmal, ob du das Kommando wirklich richtig ans LCD schickst. Wie's geht weißt du ja, sonst würds ja in ASM nicht laufen. Wenn es dann immernoch nicht geht hängt das Display vermutlich noch in einem anderen Befehl. Dann geht entweder im Displaycontroller beim starten was schief, oder du hast vor dem Bild-senden ein Kommando in deinem Code, dem du nicht alle Parameter mitgibst. Als work-around hilft in beiden Fällen, vor dem Bild-Kommando einige nullen (zehn oder so) zu Senden. Das ist aber keine endgültige Lösung! Viele Grüße, Sebastian
Ah, jetzt hab ich auch die stelle gefunden, wo du den Befehl sendest. uart_putc(16 ); uart_putc(0xAA); uart_putc(0 ); uart_putc(0 ); uart_putc(0 ); uart_putc(30 ); uart_putc(240 ); uart_putc(0 ); da ist eine null zu viel zwischen 0xAA und 30. Richtig gehts so uart_putc(16 ); uart_putc(0xAA); uart_putc(0 ); uart_putc(0 ); uart_putc(30 ); uart_putc(240 ); uart_putc(0 ); In deiner version wird die Breite des bildes als 0 interpretiert. => Der Bildbefehl beendet sich gleich wieder und die restlichen Bilddaten werden als Text interpretiert. Sebastian
hallo Sebastian, es Funktioniert nachwie vor nicht ich bekomme nur Zeichsalat angezeigt. was mach ich da nur verkehrt. mfg
Funktioniert denn normales text schreiben richtig, oder kommt da auch schon nur mist an? Wenn nicht: Läuft der Controller wirklich auf dem vorgesehenen Takt? Ist die Taktfrequenz im Code/im Projekt richtig angegeben? Am besten prüfen indem man mit warteschleife pins toggelt. Ist die Baudrate richtig angeben? Sendet er auch wirklich mit der baudrate? Am besten mit Oszi/Logicanalyzer nachmessen. Ansonsten würd ich die LoadBitmap_P mal hardcoded aufbauen. Also die Parameter ignorieren und die Schleifengrenzen fest in den code schreiben. Keine Sonderfälle mehr behandeln. Einfach nur stur auf speziell dieses eine Bild trimmen. Schließt schonmal wieder ein paar mögliche Fehlerquellen aus.
Sebastian ... schrieb: > > Ansonsten würd ich die LoadBitmap_P mal hardcoded aufbauen. Also die > Parameter ignorieren und die Schleifengrenzen fest in den code > schreiben. Keine Sonderfälle mehr behandeln. Einfach nur stur auf > speziell dieses eine Bild trimmen. Schließt schonmal wieder ein paar > mögliche Fehlerquellen aus. hallo Sebastian, Das Wars:) Läuft jetzt alles supi auch im Modus2 viellen Dank nochmal . Manchmal ist das doch soeinfach wenn man draufkommt mfg
Hallo Sebastian
danke für Deine Antwort.
Grund meiner Frage nach dem Display bei Pollin war, dass ich noch
einige Grafikdisplay (Anzahl > 30, 160 x 128 Pixel) mit den
Spalten-/Reihen- Treibern Hitachi HD61104/HD61105 habe.
Das Display habe ich versucht wie weiter unten beschrieben zu betreiben.
Pin 1 GND
V0
VCC
VEE
CL1 LP
CL2 CP
DI FRM
M M
D0 D0
D1 D1
D2 D2
Pin 14 D3 D3
Funktioniert aber nicht.
Die Displays habe ich schon einmal mit einem Hitachi H8 angesteurt,
sie funktionieren aber die Framerate war leider zu gering, hat zu
stark geflimmert.
Wäre schön wenn die Controller-Software hier passen würde und ich damit
meine Displays Hitachi LMG6490 (natürlich gibts dazu auch keine Daten-
blätter mehr) betreiben könnte.
Das schaut erstmal nicht falsch aus. Hab mal etwas in die Datenblätter reingeschaut. An sich sollten die Treiber sich mit dem Controller hier vertragen und die Verbindungen schaun auch passend aus. Dispoff ist auf dem panel verdrahtet? Das müsste sonst halt auch noch versorgt werden. GND, VCC sollten ja klar sein. Die Spannung an VEE passt? Was ist V0? Wenn dein Display aber wirklich nur 160*128 Pixel hat, musst du auf jeden Fall die Software umbauen! Ich bin mir jetzt auch nicht sicher, ob es reicht, in der param.h die auflösung anzupassen. Glaube du musst auch im code selbst (anzeigeinterrupt) änderungen machen. Viele Grüße, Sebastian
Hallo Sebastian, V0 ist der Kontrast, liegt zwischen VCC +5V und VEE -15V (max -32V). die Controller-Sofware wurde an das Display soweit angepasst.
Dann kann ich, mit den vorhandenen Informationen, leider auch nicht helfen. Wenn du hilfe willst wäre der angepasste Quellcode hilfreich. Außerdem eine genauere Beschreibung was genau das Display macht oder nicht macht. Auch die Haredware könnte duraus noch fehlerhaft sein. Hier gabs schon einige, die schon 3 mal alles kontrolliert hatten. Am Ende lags dann doch an der Hardware. Zur Sicherheit hier gleich noch der Hinweis: Der Schaltplan aus den ersten ein oder zwei Versionen ist fehlerhaft. Viele Grüße, Sebastian
Für alle, die diesen (oder mechanisch baugleiche) "Standard-billig-inverter" für Ihre Display-CCFL verwenden und auch noch keinen passenden Stecker auf Hochspannungsseite gefunden haben: http://www.conrad.de/ce/de/product/720398/INVERTER-FUeR-KALT-KATHODEN-LAMPE-150-MM/SHOP_AREA_17393&promotionareaSearchDetail=005# Bei PC Hub gibts 10 stück für 4,39$ versandkostenfrei. http://www.pchub.com/uph/laptop/841-67833-18868/UPH-Connector-Connector-Wafer-DIP.html Sind exakt die verbauten Stecker, passen also optimal. Hab dort schon ein paar mal bestellt, lief immer problemlos. Allerdings dauerts grob einen Monat bis die Teile hier sind. Gruß, Sebastian
Hallo. Nein, mein Problem hat sich noch nicht gelöst. Ich habe auch die letzte Woche keine Zeit zum recherchieren gehabt, meine Arbeit hat mich doch sehr gefordert... ich bin am Überlegen, ob ich XSCL und YSCL miteinander verbinden soll/kann. Für Hilfe mit diesem Display wäre ich froh. MfG Denis
Hallo Denis, sorry, dass ich zur Zeit immer so lange brauche. Ist halt grad Prüfungszeit.... Hab mir das Datenblatt deines Displays grade etwas genauer angeschaut und gemerkt, dass das Ding als 1024*64 organisiert ist. Ist erstmal kein problem, aber die Software muss man entsprechend anpassen. Das werden schon tiefere Eingriffe... Zu den Verbindungen: FR (Display) muss an M/AC (Controller) XECL (Display) müsste man noch extra erzeugen. Das muss alle 64 Pixel einmal kurz high geschaltet werden. Sollte ganz gut in Software machbar sein, aber muss man halt machen. DIN (Display) müsste an FLM_Frame (Controller) gehören. YSCL kann man eventuell mit an LP hängen, aber sicher bin ich mir da nicht. Unterm Strich scheint mir das display deutlich nerviger zu sein, als ich erst dachte ;) Sebastian
Hallo, ich beobachte diesen Thread schon seit langem, und genauso lange wollte ich diesen bzw. einen seiner "Geschwister-Controller" hier im Forum nachbauen. Da ich wohl nicht dazu kommen werde verkauf ich nun meine LC-Displays mit Touchpanel. Vielleicht kann sie ja jemand von euch ehernvoll in Betrieb nehmen. Hab sie im Markt eingestellt (Beitrag "Verschenke/Verkaufe Touch LC-Displays, Textoolsockel, div. USB und Audio IC´s"). Philipp @Moderator: ich hoffe diese "Werbung" ist erlaubt, sonst bitte löschen.
Hi, hat noch jemand eine Platine zu diesem Projekt liegen? Gruß Malte
>Malte Pöggel (maltep87)
Du hast Post.
Wigbert
Hallo Wigbert, ich hätte auch noch Interesse an zwei Platine. Gibt es noch welche? Gruß Jens
@Jens H. (devil65) Du hast Post. Wigbert
Hallo zusammen, gibts eine Zusammenfassung vom Projekt? ist doch sehr unübersichtlich. Eine Wiki Seite konnte ich nicht finden. Oder sind die Sourcen aus dem Eröffnungspost gar noch aktuell? Gruß
Die Sourcen aus dem eröffnungspost sind definitiv nicht mehr aktuell. Das findet man aber schon nach einer Hand voll Beiträge raus. ;) Die aktuelle Version gibts hier Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Die hat dann auch 8 Graustufen und einen leicht korrigierten Schaltplan. Später im Thread kommen noch ein paar andere Versionen, aber die sind als experimentell anzusehen und sind nur in ausnahmen empfehlenswert. Eine Zusammenfassung gibts leider nicht. Jedenfalls kenne ich keine. Sebastian
Ich finde es eigentlich auch schade, das ein gewisser Überblick fehlt. Die Grafikkarten werden nach wie vor gerne genommen. Auch hätte ich einige Adapterboarde schon in der Schublade. Leider fehlt mir im Moment die Zeit, eine aktuelle Zusammenfassung zu erstellen. Wigbert
Ja, mir gehts da ähnlich. Keine Zeit. Ein Wiki-Artikel wäre echt schön. Zumindest gibts ja das pdf-file in den zip-ordnern. Das fasst ja das wichtigste schon zusammen. Habe in der letzten Version von Benedikt ja auch noch einige Änderungen vorgenommen, die ich ja auch schon veröffentlicht habe. Aber das ist halt so inkonsequent, dass mans nicht empfehlen kann. Das wollte ich eigentlich auch noch alles vernünftig implementieren. Aber halt wie immer zu wenig zeit. Mal schaun, vielleicht schaffen wir ja mit vereinten kräften zumindest einen wiki-artikel ;) Sebastian
Ich hab jetzt mal im Wiki einen Artikel zu dem Controller angefangen. Aktuell besteht er nur aus einer Kurzbeschreibung sowie einer Linksammlung zu den verschiedenen Versionen mit Changelog. Zu einer ausführlichen Beschreibung hatte ich bisher noch keine Lust. Vielleicht findet sich ja dafür auch noch jemand ;) Was vielleicht auch noch sinn macht: Alle bekannten Pinbelegungen (Display <-> Controller) dokumentieren. Fürs erste gibts hier mal den Link zum Artikel http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen Vielleicht könnte ja ein Mod den Artikel im ersten Beitrag hier im Thread verlinken? Benedikt ist hier leider nicht mehr aktiv (hab ihn jedenfalls lang nicht mehr gesehen), kann das also nicht selbst machen. Sebastian
Vielen Dank! werde natürlich auch meinen betrag dazu leisten wenn ich die Geschichte mal aufbaue. Das kann natürlich auch noch ein wenig dauern. Aber ein Anfang ist ja schonmal da :-) Da kann man auf jeden Fall mit arbeiten! Gruß
@Sebastian ... (zahlenfreak) kann ich jetzt Hardware ohne weiteres was zufügen? Wigbert
Du meinst in dem Wiki-artikel? Na klar! Ich kenne mich ohnehin besser mit dem Softwareteil aus. Werde also auch im Artikel vor allem was zur Software schreiben. Aber auch alle, die was zur Software zu sagen haben sind immer gerne gesehen. Ich wollte mit der aktuellen Form nur mal einen Anfang schaffen. Sebastian
kannst Du im Inhaltsverzeichnis ein "Hardware" Punkt setzen, den ich dann bearbeiten kann. Ich komme da irgendwie nicht ran. Wigbert
Achso! Hab ich gemacht. Neue Inhaltspunkte kannst du setzen, indem du, wenn der Artikel offen ist, links im Bereich "Dieser Artikel" auf "Bearbeiten" gehst. Dann hast du den ganzen Artikel im Editor und kannst auch neue Überschriften erstellen. Sebastian
Achja, Danke! Noch eine Frage: Wir gehen teilweise mit fremden Eigentum um. Ich denke, ich sollte Benedikt informieren, was wir vor haben. Wenn er nicht schon mitliest. Wigbert
Ja, über das Thema hab ich auch schon nachgedacht. Wäre wohl sinnvoll, Benedikt zumindest noch als Urheber auf der Wiki-Seite zu nennen. Ich denke aber, solange der Artikel nur eine Zusammenfassung des Threads/Linksammlung auf Beiträge darstellt ist das (rechtlich) unkritisch. Der Artikel darf halt nicht so ausschaun, als hätten wir den Controller entwickelt. Wenn du Kontakt zu ihm hast wäre es sicher nicht verkehrt, ihn darauf aufmerksam zu machen. Ich hab leider seit 2 Jahren nichts mehr von ihm gelesen. Sebastian
So ich hab auch etwas dazugetan. Benedikt wird sicherheitshalber benachrichtigt. Kann man den Link nicht sichtbar oben anhängen? Oder wir machen jedesmal ein Anhang bei unserer Unterschrift Wigbert http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Angehängte Dateien:
-
DSCN1873.jpg
36 KB
Ich habe die Schaltung nachgebaut, beim Display aber ein Problem: es sind Streifen drauf! (siehe Anhang) Display ist das Wintek WD-H3224V, als SRAM ist nen Cypress CY7C199D verbaut. Durchgemessen hab ich schon alles, konnte aber noch nichts finden, was den Fehler begründen könnte. Verbindungen kommen alle am Display an. Hat wer ne Idee, woran das liegen könnte und wie man das Problem lösen könnte?
Die Ansteuerung scheint soweit eigentlich zu passen, sonst wäre das eigentliche Bild nicht so ungestört. Nur beim M/AC signal könnte ich mir vorstellen, dass was schief läuft. Hoffe du hast den Schaltplan nicht aus dem Eröffnungspost genommen, da ist nämlich genau in der Ecke ein Fehler drin. Ändern sich die schlieren, wenn sich der Bildinhalt ändert? @Wigbert Den link zum Artikel in jedem Beitrag mitzuposten ist sicher nicht schlecht. Auf Dauer wärs aber geschickter, wenn ein Moderator oder Benedikt selbst den Link im Eröffnungspost reineditiert. Sebastian http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Sebastian ... schrieb: > Die Ansteuerung scheint soweit eigentlich zu passen, sonst wäre das > eigentliche Bild nicht so ungestört. Nur beim M/AC signal könnte ich mir > vorstellen, dass was schief läuft. Hoffe du hast den Schaltplan nicht > aus dem Eröffnungspost genommen, da ist nämlich genau in der Ecke ein > Fehler drin. Dochdoch, genau den hab ich verwendet. Sehe ich das richtig, dass der Fehler cder ist, dass der eine FF statt auf LP Load auf FLM Frame liegt? > Ändern sich die schlieren, wenn sich der Bildinhalt ändert? Hab ich noch nicht getestet, erst mal wollte ich die Schaltung zum laufen bringen, bevor ich anfange, da was drauf zu schreiben.
Ich hab da jetzt mal die Verbindung LP Load an den CLK vom FF getrennt und den CLK stattdessen auf FLM Frame gelegt. Schon läufts.
Es sind drei Fehler: M/AC und FLM/FRAME sind falsch benannt (heißen in der falschen Version FLM/AC und M/FRAME), könnte also sein, dass du die falsch angeschlossen hast. Der 74HC157 muss an den Ausgang Q des einen 74HC74 Gatters, nicht an Q_nicht, wie im ersten plan gezeichnet. Außerdem wird das andere Gatter des 74HC74 nicht von LP/Load gespeist sondern von FLM/FRAME. Wenn ich mir das so anschau, kannst du eigentlich nicht nach dem ersten Schaltplan gebaut haben, sonst wäre noch mehr verkehrt. Entweder hast du also doch einen neueren Plan genommen, oder beim nachbaun einen "fehler" gemacht. Prüf die ecke auf Jeden Fall nochmal durch. Denke dass der Fehler da irgendwo liegt. Die Frage, ob die Fehler sich mit dem Bildinhalt ändern hab ich gestellt weil, wenns sich ändert, ists wahrscheinlich deine Hardware. Wenns sich nicht ändert ist ehr das Display hinüber. Sebastian http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Sebastian ... schrieb: > M/AC und FLM/FRAME sind falsch benannt (heißen in der falschen Version > FLM/AC und M/FRAME), könnte also sein, dass du die falsch angeschlossen > hast. In unserem Schaltplan heißen die wirklich FLM AC und M FRAME - da das Datenblatt des Displays die Pins aber nur als FLM und M angibt, wird das wohl keinen Einfluss gehabt haben. > Der 74HC157 muss an den Ausgang Q des einen 74HC74 Gatters, nicht an > Q_nicht, wie im ersten plan gezeichnet. Faszinierenderweise ist bei uns im Schaltplan der $A$/B-Pin auch an Q und nicht an Qnicht angeschlossen. Also schon richtig angeschlossen. > Außerdem wird das andere Gatter des 74HC74 nicht von LP/Load gespeist > sondern von FLM/FRAME. Genau das war der Fehler. Nach dem Auftrennen der Leiterbahn auf der LP und einbringen eines Drahtes auf FLM ist das Display streifenfrei. > Wenn ich mir das so anschau, kannst du eigentlich nicht nach dem ersten > Schaltplan gebaut haben, sonst wäre noch mehr verkehrt. Entweder hast du > also doch einen neueren Plan genommen, oder beim nachbaun einen "fehler" > gemacht. Welchen Plan ich da genau genommen haben, kann ich da jetzt auch nimmer sagen. Aber wird wahrscheinlich wirklich der erste gewesen sein und ich habe aus versehen den einen FF "falsch" - und somit richtig - angeschlossen. > Prüf die ecke auf Jeden Fall nochmal durch. Denke dass der Fehler da > irgendwo liegt. Jetzt läufts ja zum Glück. Auch wenn die Graustufen nicht ganz so intensiv rüberkommen, ists immerhin nutzbar. Nur die Kontrastregelung ist unter den Tisch gefallen - ich brauche für das Display nämlich +24V und hab entsprechend einen einfachen Stepup-Wandler eingebracht, der arbeitet wunderbar, so lange ich über nen Poti einen Teil der Kontrastspannung auf den CINV-Pin führe, aber wenn ich wie im Schaltplan beschrieben das PWM-Signal mit reinmixe, geht das ding auf 5V runter. aber das ist ja denk ich mal nicht so wichtig.
hallo, ich versuche schon seit tagen eine andere Schriftart 12x16 einzubinden aber leider werden mir die zeichen nicht richtig dargestellt. Die Schriftarten habe ich von hier Beitrag "LCD Schriftarten ( Fonts in veschiedenen Größen )" vielleicht kann mir einer weiterhelfen. mfg
Wie werden die Zeichen denn dargestellt? Am Besten ein Foto + Beschreibung, was du erwarten würdest. Viele Grüße, Sebastian
Angehängte Dateien:
-
8x12_horizontal_MSB_1.jpg
200 KB -
12x16_horizontal_MSB_1.jpg
200 KB
Es sollte eigentlich angezeigt werden; 57600 Kbs Baud 8 colour mode by Sebastian Anbei noch 2 fotos Schriften bis 8x14 werden korrekt angezeigt aber alles was Grösser ist kommt nur Pixelsalat raus. mfg
Hallo, Kann mir einer von Ihnen weiterhelfen Mfg
Ehrlich gesagt hab ich immernoch nicht genau in deinen Code geschaut (einfach keine Zeit...), aber kanns sein, dass du den Code, der den Text zeichnet, nicht angepasst hast? Das müssten eigentlich größere Code-änderungen sein. Jedenfalls, wenn man Text mit einer Breite ungleich 8 pixel anzeigen will. Würde jedenfalls zu deinem Fehlerbild passen. Sebastian
Angehängte Dateien:
-
fuse_meg8115.JPG
200 KB
Hi, bin ebenfalls daran diesen Controller nachzubauen. Leider bekomme ich noch nicht einmal ein Bild aufs Display. Nutze die LP von Wigbert und ein GLCD Wintek wd-h3224. Nun bin ich mir nicht sicher, ob meine Fuse vom ATmega stimmen (siehe Anhang mit PonyProg). Weiter bin ich mir nicht sicher, ob das Datenblatt von pollin zu dem Display stimmt. Könnte mir jemand dabei mal helfen.... Danke & Gruß MAT
@MAT die Fuses schauen eigentlich gut aus. Hast du das Display richtig angeschlossen? Keine Kurzschlüsse am Displayanschluss? Liegen alle Spannungen richtig an? Kontrastspannung? @Julian Soweit ich das gesehen habe, hast du wirklich nichts am Code geändert. So kann das nicht funktionieren. Ehrlich gesagt wurnderts mich gerade, dass es überhaupt mit anderen Fonts läuft. Das Problem ist, dass der Code ziemlich auf 8 Pixel breite Buchstaben ausgelegt ist. Da sind tiefgreifendere Änderungen nötig, wenn du einen breiteren Font verwenden willst. Am einfachsten wäre wohl noch ein 16 Pixel breiter, aber auch hier sind definitiv Anpassungen am Code nötig. Das ist alles machbar und von der Rechenleistung her kein Problem (auch andere Größen als 16Px), aber man muss eben den Code (lcd_writechar in der lcdcon.S) entsprechend ändern. Viele Grüße, Sebastian
Hallo an alle. Ich habe eben in einem anderen thread beim stöbern ein FARB LCD http://www.reichelt.de/LCD-Module-Touch-Grafik/TFT-DIS-3-5/3//index.html?ACTION=3&GROUPID=3011&ARTICLE=101746&SHOW=1&START=0&OFFSET=500&; gefunden. Kann man das mit einem ähnlichen Controller wie diesem hier realisieren? MfG
Nein, dafür reicht die Rechenleistung des AVR nicht mehr aus. Die nötigen Datenraten sind für Farbe einfach viel zu hoch. Nimm einen displaycontroller der dafür gemacht wurde. Epson stellt sowas zum beispiel her. Einige ARMs haben sowas auch integriert. Und selbst mit extra displaycontroller wäre zu fragen, ob der AVR wirklich genug leistung hat, die Bildinhalte in vernünftiger Zeit zu generieren. Aber da kommts dann einfach auf die Anwendung an. Gruß, Sebastian
Reines bauchgefühl, nicht durchgerechnet: Mit nem Pic24 / Pic33 könnte man das display auch zum laufen bringen. Aber sowohl der Pic als auch der Propeller sind wenig sinnvoll, wenn du eigentlich auf AVRs unterwegs bist. Ein fertiger Displaycontroller dürfte kaum mehr kosten, der Aufwand, den du treiben musst ist aber deutlich geringer. Sebastian
Das ist echt ne super Anleitung, will mir auch sonen Controller nachbauen! Ich Frage mich ob es von der Leistung her einen großen Unterschied macht, diesen Controller hier (mit AVR) zu nehmen oder so einen SED oder S1D oder wie auch immer. Bei dem SED/S1D steht im Datenblatt was von 3 Layer usw... Also wie sieht es bei dem selbstbau hier aus? Schafft der noch was an Grafikfunktionen oder ist der mit Textausgabe schon ausgelastet? Zu meinem Vorhaben: Es sollen auf einem 320x240 LCD (wintek bei Pollin 4,95€) alle möglichen Messwerte eines Motors angezeigt werden. Soweit kein Problem, jedoch wollte ich schon ein paar grafische effekte drinne haben, zB habe ich für ein 128x64 mit KS0108 eine Funktion geschrieben, die ein neues Bild (Menü zB) von der Seite ins Display "reinschiebt", also wie ein slide effekt auf touchscreen handys. Ist sowas mit dem eigenbau controller möglich? Oder überhaupt mit dem SED(1335?)? MfG Waldemar
Das hängt stark von den effekten ab. Ich denke als worst case kannst du die leistung beim bloßen bilder anzeigen sehen. Die müsstest du halt gegebenenfalls vorberechnen. Mit vollbildern schafft die letzte version von Benedikt (wenn ich mich recht erinnere) etwa 3fps. Bei kleineren Bildern entsprechend mehr. Wenn du die Grafikfunktionen nutzt kanns deutlich schneller gehen, aber auch langsamer. Das hängt stark von den effekten ab und davon, wie geschickt du es programmierst. Gerade wenn es nur darum geht, grafikelemente im Bild zu verschieben, wäre es sicher hilfreich, den vorhandenen Code um BitBlt-funktionen zu erweitern. Also zum beispiel, die möglichkeit, bildbereiche zu kopieren. Das könnte dann durchaus relativ performant laufen. Zu den Epson-controllern kann ich nicht so viel sagen, weil ich nie einen selbst angesteuert habe. Allerdings würde es mich stark wundern, wenn die nicht schneller wären, als der hier vorgestellte AVR. Außerdem kriegt man den sicher auch mit einer 2-layer platine zum laufen (3 layer gibts garnicht, wenn dann 4). Bei single-layer platinen könnte es schwer fallen, das ganze zu entflechten. Sebastian http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
Mit den Layern meinte ich eigentlich "Bild-layer", ich glaube damit ist dann gemeint dass mehrere Bilder gleichzeitig im Ram sind aber nur eines davon angezeigt wird, bzw man dann unter denen verschiedene Funktionen ausführen kann. Ich habe mir auch schon gedacht dass ein "richtiger" LCD Controller leistungsfähiger ist, aber mich interessiert halt wie leistungsfähig und ob es sich für mich lohnt eine smd platine zu "entwickeln" oder ob ich mir das auch sparen kann. Ich denke ich probiere es erstmal mit dem Bausatz hier, ist ja eigentlich ne schnelle und günstige geschichte und wenn mir das zu langsam ist versuch ich mich am Epson Controller. Habe ich eigentlich einen großen Nutzen wenn ich einen größeren SRAM dranhänge? Mal davon abgesehen dass ich mehr Adressleitungen brauche, könnte man doch zB Menüs und Untermenüs schon vorher in den RAM laden und bräuchte nur noch "umzuschalten" anstatt den ganzen Bildinhalt erst in den RAM zu laden. Da ich eh nur S/W nutzen wollte wären das bei 32Kx8 ja schon 3 Vollbilder und wenn ich bei Reichelt gucke, dann gibts da auch 512Kx8 dann wären das schon 16 Bilder, damit könnte man dann auch einiges anstellen und viel schnellere Effekte erzeugen denke ich... MfG Waldemar
Hi, wie damals die ersten Pollin-LCDs aufgekommen sind, dachten wir ein AVR einzusetzten der über Uart Daten empfängt und übersichtliche Einstellungen beinhaltet. Es ist als kostengünstiges Gerät gedacht um irgendwelche Visualisierungen (Grafik) darstellen zu können. Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Wer mehr will muss sicher auch mehr für tun. Ich habe ein Board zu laufen mit ein 128x8K S-Ram, allerding 15ns. Dort kann ich natürlich mehrere Bilder ablegen, und kopieren. Da wäre sogar S-Ram und Platine vorrätig. Das sollte eigentlich der Nachfolger werden, aber wir haben was Besseres als Bausatz in Vorbereitung. Nun ist ehrlich das Wintek mit rosa Hintergrund einer der wenigen GLCDs die mich NICHT interessieren. Wenn du nur kleine Bildchen bei Deinem Projekt mit einfliessen lassen willst, ist der Bausatz GLCD-32K durchaus richtig. Sollen da Bilder laufen lernen wohl kaum. Wigbert
Was habt ihr denn noch besseres als Bausatz in Planung ? bzw wie lange wird es dauern bis der Bausatz fertig ist (bzw man erste Veröffentlichungen sehen darf)? Wie benutzt du denn 128kx8 als Sram, ich habe vorhin in die Datenblätter geguckt und gesehen dass bei 64k externem sram ende ist, oder machst du das dann in software ? MfG Waldemar
Die SW ist bei 128K schon weiterentwickelt, da werden dann weitere Pins zugeschaltet. Kopierfunktion, im Hintergrund Bild schreiben und dann irgendwann aufs GLCD kopieren. Solche SW kann man dann natürlich nicht mehr ins Netz posaunen. Ich hatte auch schon ein 512K Bausatz in Vorbereitung, aber wir wollten dann doch was Moderneres versuchen. Das GLCD 32K wird, da grösstenteils in Dip, bleiben, dazu kommt dann, wenn alles klappt im Herbst was Leistungsfähiges. Wigbert
Aufgrund des Hardware-aufbaus lässt sich in diesem Projekt sogar nur 32kByte SRAM direkt ansteuern. Das lässt sich auch nicht ändern, ohne das projekt komplett neu aufzurollen. Für mehr muss man dann mit GPIOs die restlichen Adressleitungen in Software ansteuern. Sebastian
Sebastian ... schrieb: > @Julian > > Soweit ich das gesehen habe, hast du wirklich nichts am Code geändert. > So kann das nicht funktionieren. Ehrlich gesagt wurnderts mich gerade, > dass es überhaupt mit anderen Fonts läuft. > Das Problem ist, dass der Code ziemlich auf 8 Pixel breite Buchstaben > ausgelegt ist. Da sind tiefgreifendere Änderungen nötig, wenn du einen > breiteren Font verwenden willst. Am einfachsten wäre wohl noch ein 16 > Pixel breiter, aber auch hier sind definitiv Anpassungen am Code nötig. > Das ist alles machbar und von der Rechenleistung her kein Problem (auch > andere Größen als 16Px), aber man muss eben den Code (lcd_writechar in > der lcdcon.S) entsprechend ändern. Hallo Sebastian, Vielen Dank für ihre Antwort, leider reichen meine Kenntnisse nicht aus um in der lcdcon.S das soweit zu ändern für eine andere Schriftart deshalb war meine frage ob mir den jemand weiterhelfen kann mfg
Habe leier zur Zeit keine Möglichkeit Code zu testen und auch eigentlich keine Zeit, Code anzupassen. Ohne testen krieg ich die änderung wohl nicht hin, hab extra geschaut. Aber Assembler ist nicht so schwer. Wäre doch eine gute möglichkeit sich weiterzubilden. Übrigens: In Foren zu siezen gilt als unhöflich ;) Gruß, Sebastian http://www.mikrocontroller.net/articles/Grafikf%C3%A4higer_LCD_Controller_f%C3%BCr_320x240_LCD_mit_8_Graustufen
erstmal danke für deine Antwort, ich habe mal ein paar Werte in der Lcdcon.s bei lcd_writechar geändert aber leider ohne erfolg. Getest hab ichs mit der 16x24 Schriftart versucht. mfg
Thread beobachten
Seitenaufteilung abschaltenBitte 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.