Christian J. schrieb: > 38400 ist die, die bei mir im dauerfeuer funzt ohne dass es zu Verlusten > führt. 56700 klappte nicht, der Busy Pin reagiert einfach nicht, ich > frage den immer vor jedem Byte ab was ich sende. Deine Probleme mit 57600Baud gehen mir nicht aus dem Kopf. Momentan streame ich gerade ein Video mit 500kBaud auf das Display. Das sind im Graustufenmodus leider nur 2fps, aber egal. Jedenfalls schafft der Controller die Verarbeitung von so vielen Graustufendaten nicht und aktiviert Busy, was mit CTS vom UART des PCs verbunden ist. So wird der Datentransfer ausgebremst (auf ca 310kBit/s). Das funktioniert wunderbar, ich habe zumindest schon >50MByte ans Display gesendet, ohne Probleme. Die einzigen Probleme die ich mir vorstellen kann, sind eine nicht ganz exakte Baudrate von deinem ARM: Bei mir sind 57600 Baud in Wirklichkeit 58823 Baud. Das sind 2,1% zu viel. Das sollte aber kein Problem sein, denn erst ab >4% treten Probleme auf. Außer deine Baudrate ist auch nicht genau und weicht in die entgegengesetzte Richtung ab. Schau mal nach ob das vielleicht zutreffen kann. Ansonsten kannst du auch einen 18,432MHz Quarz einbauen, dieses minimale Übertakten schafft der mega8515 meist problemlos. Damit sollten die ganzen Standardbaudraten ohne Fehler möglich sein. Die maximale Baudrate die möglich ist, ist übrigens 500kBaud. Alles darüber (was nur 666kBaud, 1MBaud und 2MBaud wären), schafft der Controller nicht weil der UART Hardwarepuffer überläuft, da der Interrupt zur Datenausgabe ans LCD zu lange braucht.
Oder probier mal diese Version aus: Ich habe die UART Routinen nun erweitert, dass automatisch ab einem Fehler von >1,5% in den 2X Modus umgeschaltet wird. Dadurch reduziert sich der Fehler auf 0,7%. Die Version ist auf 2bpp, 57600Baud eingestellt.
Naja, es funktioniert ja, also lasse ich es mal wie es ist :-) Never touch a running system.
Hallo Benedikt, ich hätte mal rein interessehalber eine Frage (der Aufwand würde sich wohl nicht lohnen): Ziel der Überlegung ist es, einen höheren Pixeltakt zu erreichen ohne die Prozessorlast zu vergrößern bzw. eben den AVR zu entlasten. Man hängt zwischen Pin5 des 74HC02 (Das Gatter von der CP-erzeugung) und das RD-Signal einen Flankendifferenzierer. Also bei jedem Flankenwechsel von RD gibts einen kurzen Puls auf CP. Auf diese Weise könnte man mit jedem ld Befehl des AVR ein ganzes Byte zum Display schicken, da das Display mit steigender und mit fallender Flanke von RD Daten übernimmt. Der Multiplexer ist ja über das Flipflop auch von CP gesteuert. Bzw. wäre zu überlegen, ob man A\/B dann nicht direkt an RD hängen könnte. Der Flankendifferenzierer müsste etwa 100ns lange Pulse rausgeben, damit es zum Display passt. Zwischen die I/O des SRAM und den Multiplexer müsste wohl noch ein Latch, da ja das zweite Nibble erst ans Display gelegt wird, wenn RD wieder High geht. Dann sind aber auch die I/Os auf High-Impedance. Also einen Latch der die Daten bei einer steigenden Flanke von RD latcht. Wie gesagt, man müsste dann mit einem ld-Befehl pro Byte statt einem pro nibble auskommen und hätte fast die Hälfte der Prozessorlast gespart. Dann sollten auch höhere Frameraten beim Video streamen möglich sein, oder? An sich müsste es dann doch sogar gehen, 8 Graustufen darzustellen, oder? Macht das Display (zb. die hier zuerst genannten von Pollin) das mit? Der SRAM reicht ja für 3 Monochrombilder aus, also auch für ein 3-Bit-Bild. Würde mich mal interessieren, was der Experte zu diesen Überlegungen sagt. Gruß, Sebastian
Sebastian schrieb: > Man hängt zwischen Pin5 des 74HC02 (Das Gatter von der CP-erzeugung) und > das RD-Signal einen Flankendifferenzierer. Also bei jedem Flankenwechsel > von RD gibts einen kurzen Puls auf CP. Auf diese Weise könnte man mit > jedem ld Befehl des AVR ein ganzes Byte zum Display schicken, da das > Display mit steigender und mit fallender Flanke von RD Daten übernimmt. So eine ähnliche Schaltung gab es mal in der Elektor für einen Displaycontroller für einen 8051. Da dieser langsamer ist, bleibt mehr Zeit, so dass dies richtig sinn macht. Da wurde das ganze mittels Monoflop gelöst. > Der Flankendifferenzierer müsste etwa 100ns lange Pulse rausgeben, damit > es zum Display passt. Das Problem ist, dass der RD Impuls gerade mal etwa 62ns lang ist. Streng genommen bin ich momentan sogar außerhalb der Specs, denn das Pollin Display verlangt mindestens 65ns high Zeit. Und das ist ein recht modernes Display, ältere sind da noch langsamer. Bei dem Pollin Display ist der maximale Takt mit etwa 6,5MHz spezifiziert. Da ein Zugriff auf das SRAM 3 takt dauert, sind so theoretisch 5,33MHz möglich. Eine Verdopplung ist daher nicht möglich, außer man baut Waitstates ein. Wirklich viel ist also nicht zu gewinnen. > Zwischen die I/O des SRAM und den Multiplexer > müsste wohl noch ein Latch, da ja das zweite Nibble erst ans Display > gelegt wird, wenn RD wieder High geht. Dann sind aber auch die I/Os auf > High-Impedance. Also einen Latch der die Daten bei einer steigenden > Flanke von RD latcht. Jain. Ein Latch braucht man, aber aus einem anderen Grund: Momentan gebe ich die Daten mit der steigenden Flanke von RD\ aus, und verletze damit eigentlich auch die Hold Zeit des Displays. Bei der fallenden Flanke von RD\ liegen die Daten noch nicht an, erst nach einer gewissen Zeit. Man müsste also den ersten Impuls verzögern. > Wie gesagt, man müsste dann mit einem ld-Befehl pro Byte statt einem pro > nibble auskommen und hätte fast die Hälfte der Prozessorlast gespart. > Dann sollten auch höhere Frameraten beim Video streamen möglich sein, > oder? Es würde minimal etwas bringen, aber den Hardwareaufwand enorm erhöhen: Man müsste die Daten bei der steigenden Flanke von RD\ zwischenspeichern, könnte die ersten Daten direkt mit übertragen. Dann müsste man entweder mittels eines Zählers aus dem Prozessortakt oder mittels Monoflops einen weiteren kompletten Takt (also >65ns high, >65ns low, >65ns high und nochmal >65ns low erzeugen. Wenn man die 16MHz Prozessortakt verwendet um die Takte zu erzeugen, dann bräuchte man etwa 5 Takte für ein Byte (momentan sind es 6 + 0,75Takte). Ich hatte mir diese Lösung anfangs auch überlegt, habe diese dann aber verworfen, da die Lösung möglichst leicht nachzubauen sein sollte. An der Software könnte man etwas auf kosten des Programmspeichers optimieren: Momentan gebe ich in einer Schleife 4 Takte aus, danach kommt der Schleifenzähler + Rücksprung. Also für 12 Takte kommt ein Overhead von 3 Takten dazu. Diese Schleife könnte man entrollen, so dass der Overhead weg fällt. Das würde etwa 15% mehr Geschwindigkeit bringen.
Ah, Dankeschön. Wie gesagt, ich wollte einfach nur wissen, obs möglich wäre. Ich hätte aber doch einen größeren Nutzen erwartet. Aber so würde es sich ja garnicht lohnen. Die Schleife zu entrollen hatte ich auch schon überlegt. Habs aber erstmal auf später verschoben. Gruß, Sebastian
Im Anhang eine neue Version mit einer etwas auf Geschwindigkeit
optimierten Datenausgabe und einem optimierten UART (ein paar Details
beim X2 Mode korrigiert, etwas optimiert).
Bisherige Version bei 16MHz, 75Hz: 40% CPU Load.
Neue Version: 1/3, also 33,3% CPU Load
Dauer des Interrupts: 18,5µs
Die benötigte "Rechenleistung" liegt damit bei etwa 5,35MIPs.
Da der UART Hardware Puffer 2 Bytes umfasst, darf die Baudate damit bei
maximal etwa 850kBaud liegen. Der nächst niedrigere, mögliche Wert liegt
bei 666,6kBaud (16MHz/8/3). Das ist somit die maximale Baudrate bei
16MHz.
Die damit erreichbare Datenrate bei Graustufendaten sind etwas unter
200kPixel/s, bei SW sind es >400kPixel/s.
Wenn die Graustufen komplett deaktiviert werden, sind irgendwas
>500kPixel/s möglich. Das sind rund 7fps Vollbilder.
Eine weitere "Optimierung" wäre das Übertakten auf 18,432 oder 20MHz.
Die meisten mega8515 machen das mit. Damit liegt die Auslastung bei rund
27%. Und man trifft eventuell eine bestimmte Baudrate besser.
Angehängte Dateien:
-
lcd1.gif
19 KB
Hier mal noch ein paar Messungen: Rot ist die Dauer des kompletten Interrupts, grün die XSCL Impulse zum LCD. Man sieht einen deutlichen Overhead der vor allem durch das Sichern der Register im Interrupt und das berechnen der Adressen und Graustufen drumherum entsteht.
Angehängte Dateien:
-
lcd2.gif
14 KB
Und die XSCL Impulse vergrößert. Die Frequenz beträgt exakt 5,33MHz, und die high Zeit exakt 62ns, also 1/16MHz. Die Lowzeit beträgt 125ns, also 2x 1/16MHz, exakt wie erwartet.
Verstehe ich nicht ganz. Die Baudrate ist doch 57600 auf der Uart, oder? Damit kann man aber nicht soviele Bilder pro Sekunde übertragen. Mein Arm nach macht maximal 115kbaud mit. Ist es ok, wenn ich vor jedem Byte an die Uart den Busy Pin auf Low (=Busy) abfrage? Graue Rechtecke sind bei mir übrigens immer noch nicht möglich. Sehr seltsam, der Farbwerte wird ignoriert. Christian
Christian J. schrieb: > Verstehe ich nicht ganz. Die Baudrate ist doch 57600 auf der Uart, oder? > Damit kann man aber nicht soviele Bilder pro Sekunde übertragen. Mein > Arm nach macht maximal 115kbaud mit. Die Werte waren bei 666,6kBaud, also dem maximalen was geht. Durch das Busy werden die Daten aber auf bis zu 400kBit/s ausgebremst. > Ist es ok, wenn ich vor jedem Byte an die Uart den Busy Pin auf Low > (=Busy) abfrage? Ja. Theoretisch würde sogar jedes 64. Byte ausreichen, denn Busy/CTS wird auf high gesetzt, sobald der Puffer zu 75% (=192 von 256 Bytes) voll ist.
Hallo, ich habe es endlich geschafft meine Platine ist funktionsfähig. Nur habe ich jetzt ein Problem mit den Fusebit. Nachdem ich mit Ponyprog diese auf "CKOPT, Boden und Bodlevel" ausgewählt habe kann ich den Prozessor nicht mehr ansprechen. Welche Einstellungen sind richtig? Viele Grüße Gerhard
Hast du die Fuses vorher gelesen?
Angehängte Dateien:
-
lcd3.gif
11 KB
Hier noch das letze Bild der Messung: Setup und Hold Zeiten. rot ist der XSCL Impuls, grün eine Datenleitung die gerade den Pegel wechselt. Die Setupzeit dürfte irgendwo bei um die 55ns liegen, also gerade noch innerhalb der Specs. Die Holdzeit liegt irgendwo bei um die 9ns. Laut Datenblatt sollten es 40ns sein. Da das LCD aber auch für 3,3V spezifiziert ist, kann man bei 5V diesen Wert wohl großzügig unterschreiten. @Gerhard Schau mal in die pdf die bei der Software dabei ist. Da ist seit ein paar Versionen ein Bild zu den Fusebits drin.
ja, es war ein neuer Baustein! Der war noch auf interner Takt gestellt. Er lief jedenfalls auch ohne Quarz.
Benedikt, du bist einfach Spitze! Nicht nur das tolle Projekt, sondern auch die Dokumentation dazu. Und jetzt die Updates sowieso. Einfach klasse! Sebastian
Hallo Bernhard, zunächst einmal viele Dank für dein interessantes Projekt. Ich habe bereits eine 640x480-Displaysteuerung von dir im Einsatz. Diese und auch die aktuelle Variante funktionieren einwandfrei. Da ich ein vertikal angeordnetes Display benötige habe ich deine Software vom 10.05.2008 etwas bearbeitet (spätere Aktualisierungen sind somit nicht berücksichtigt) und möchte diesen Programmcode hier zur Verfügung stellen. Da ich C nicht mag ist die Version als avr-Studio compatibles Assemblerprogramm angehängt, wobei nicht alle von C produzierten Einzelheiten geändert sind. Die Befehle sind etwas modifiziert, aber hoffentlich gut dokumentiert. Die Übertragung von Bildern und benutzerdefinierten Zeichen erfordert eine vertikale Bildabtastung. Ich werde mal mit dem vor kurzem hier veröffentlichten Bild experimentieren. Bisher habe ich diesen Befehl nur mit selbst hergestellten Bilddaten getestet. Ich hoffe, dass ich keine Anpassungen übersehen habe. Viel Spaß beim ausprobieren. Horst-Dieter
Hallo, die letzt gepostete Version läuft bei mir nur im Textmode, Grafik wird verhackstückelt, die Koordinaten stimmen nicht, ein Rechteck um den ganzen Bildschirm wird in der Mitte abgeschnitten, quasi nach links verschoben. Busy geht auch nicht, 56700 sendet der Arm7 sauber raus, der PC versteht es einwandfrei, trotzdem werden Zeichen verschluckt, fehlen einfach. Busy rührt sich gar nicht. Habe daher wieder auf vorherige Version umgesattelt.
Könnte mal jemand anders die letze Version ausprobieren und die Ergebnisse von Christian J. bestätigen? Ansonsten schiebe ich die Schuld mal auf den ARM bzw. die Baudrate von diesem, bei mir läuft die nämlich wunderbar und die Baudrate sollte jetzt auch sehr gut passen. Zumindest kann ich problemlos Bilder laden und Text anzeigen.
Also, am Arm liegt es sicher nicht, der tuts ja auch mit einem PC zusammen. Habe testweise ein delay nach jedem Byte eingefügt, bis 100us. Gleiches Resultat. Wie gesagt, Text einwandfrei, nur bei den beiden Rechtecken um den Bildschirm hapert es, die sind einfach 50% nach links verschoben aus dem Bild raus. Schlimm ist es nicht, die eine Version läuft ja und reicht mir auch. Durch die Kapselung der Basis-Funktionen in meinen eigenen Code lässt sich de facto alles machen, was nur denkbar ist solange es keine bewegten Grafiken werden sollen. Liesse sich diese Platine für dieses Display umstricken: Beitrag "Re: LCD Controller für 640x480 LCD mit mega8515" Davon habe ich etliche hier. Wenn man das genauso komfortabel machen kann (ohne S1D...) würde ich glatt noch Platinen machen.
Christian J. schrieb: > Also, am Arm liegt es sicher nicht, der tuts ja auch mit einem PC > zusammen. Habe testweise ein delay nach jedem Byte eingefügt, bis 100us. > Gleiches Resultat. Wie gesagt, Text einwandfrei, nur bei den beiden > Rechtecken um den Bildschirm hapert es, die sind einfach 50% nach links > verschoben aus dem Bild raus. Läuft die andere Version denn mit 57600 Baud? Ich dachte bisher funktionieren nur 28800 Baud. > Liesse sich diese Platine für dieses Display umstricken: > > Beitrag "Re: LCD Controller für 640x480 LCD mit mega8515" Theoretisch ja: Man benötigt einen zweiten SRAM. Zwischen beiden wird über die noch freie Adressleitung umgeschaltet. Dann muss der Umschalter raus, so dass man einen 8bit Bus hat.
Die andere läuft bis 38400 baud, darüber werden Zeichen verloren. Grafik aber ok. Da ich den Brenner nicht hier habe kann ich das leider nicht besser testen.
Das klingt mir fast danach, als wenn irgendwie Busy bei dir nicht funktionieren würde. Busy funktioniert aber, habe ich extra probiert. Sende einfach mal >1000 lange (etwas schräge) Linien Befehle, oder auch Blöcke oder Kreise direkt hintereinander und schau was passiert (natürlich inkl. des Busy Checks). Wenn Busy funktioniert, müsste der Busy Pin dann auf high gehen und deinen ARM ausbremsen. Wenn nicht, dann wird Müll auf dem Display ankommen.
So, ich bin jetzt endlich mal dazu gekommen auf die aktuelle Firmware upzudaten. Bei mir läuft sie einwandfrei. Text geht, Grafik geht. Alles bei 500kBaud und 4 Graustufen. Den Busy-Pin hab ich jetzt nicht angeschaut, aber nehme mal an, dass der sich rühren sollte. Mein Sende-AVR fragt ihn jedenfalls ab. Sende ein 160*200 Graustufenbild und 4 40*40-Rechtecke. Das kommt alles wunderbar an. Sebastian
Angehängte Dateien:
-
8Graustufen.JPG
120 KB
Servus, ich hab wollte mal fragen, ob hier Interesse an einer 8-Graustufen-Version besteht. Hab die Software etwas aufgebohrt, sodass jetzt auch 3-bit Bilder angezeigt werden. Text- und Grafikfunktionen sollten auch auf 8 Graustufen laufen, hab sie aber noch nicht gänzlich getestet. Mir kam's mehr auf die Darstellung von Bildern an. Wenn interesse besteht dokumentier ich mal meine erweiterungen und stell sie hier rein. Das Bild im Anhang ist von einem Normally Black display (das von Pollin). Angesteuert mit 3 bit. Links werden nur 2 bit genutzt, rechts 3. @Benedikt: An deinem Graustufen-Mod (der gegens Flackern) versteh ich eine Sache nicht ganz: Reicht es nicht, am Ende eines Bildes GrayCntMod um eins zu erhöhen und wieder abzuspeicher? 240 ist ja durch 3 Teilbar, daher hat GrayCntMod am Ende eines Bildes ja erstmal den gleichen Wert wie am Anfang. Also um eins erhöhen, und das nächste Bild wird angezeigt. Man würde sich dadurch halt 1 Byte und etwas Rechenzeit im Interrupt sparen. Oder hab ich da was übersehen? Gruß, Sebastian
Sebastian schrieb: > An deinem Graustufen-Mod (der gegens Flackern) versteh ich eine Sache > nicht ganz: Reicht es nicht, am Ende eines Bildes GrayCntMod um eins zu > erhöhen und wieder abzuspeicher? 240 ist ja durch 3 Teilbar, daher hat > GrayCntMod am Ende eines Bildes ja erstmal den gleichen Wert wie am > Anfang. Also um eins erhöhen, und das nächste Bild wird angezeigt. Man > würde sich dadurch halt 1 Byte und etwas Rechenzeit im Interrupt sparen. > Oder hab ich da was übersehen? Das ist genau der Trick an der Sache: Ohne diese Modifikation läuft das ganze genau so. Allerdings kann es dann sein, dass bei einer dunklen Graustufe die viele Pixel beinhaltet, die gesamte Fläche z.B. nur jedes 3. Bild aufleuchtet, die restlichen 2 Bilder aus ist. Um das zu vermeiden, werden die eingeschalteten Pixel über die 3 Frames verteilt indem zusätzlich GrayCntMod in jeder Zeile erhöht wird. Am Ende des Bildes muss zusätzlich nochmal erhöht werden, damit sich in jedem Bild der Wert ändert, also jede Zeile mal jeden Wert sieht. PS: Schöne Erweiterung. Ich hätte nicht gedacht, dass 8 Graustufen so gut aussehen.
Danke, bin auch total begeistert :-) Geht aber nur mit dem normally Black so schön. Auf dem normally White bringts zwar auch was, aber der Kontrast reicht für 8 Graustufen nicht wirklich ganz aus. Das wegen GrayCnMod hab ich wohl etwas ungünstig vormuliert: Ich würde weiterhin GrayCntMod in jeder Zeile eins hochzählen. Am Ende des Bildes dann aber nicht GrayCnt hochzähen und nach GrayCntMod kopieren, sondern einfach GrayCntMod nochmal um eins erhöhen. Auf die Weise startet man auch bei jedem Frame mit einem anderen Wert und wechselt trotzdem bei jeder Zeilen durch. Die Einsparungen sind minimal, ich weiß. Ich wunder mich nur halt, warum du es nicht so gemacht hast. Sebastian
Da die Bildgröße an sich einstellbar ist, funktioniert das nur bei 320x240 so gut. Um auch andere Displaygrößen zu unterstützen (z.B. 320x200 oder auch manche Displays die 241 Zeilen benötigen), habe ich halt die eine Zusatzzeile mit eingebaut. Geschwindigkeitsmäßig ist der Einfluss ja minimal. PS: Wenn man die Bezeichnung des LCDs (LTBE9T372G1K) aufschlüsselt, erhält man folgendes: LT Bezeichnung B CCFL Backlight T Transparent G Normally Black 1K Hoher Kontrast, Version 1 Dieser vergleichsweise hohen Kontrast, den sieht man auch deutlich.
Angehängte Dateien:
-
normallyWhite.JPG
89 KB
Ok, die Software allgemein zu halten ist ein guter Grund. Wobei man das aber auch über den Präprozessor erledigen könnte. So in der Art halt: #define YSIZE 240 #if(lines%3==0) GrayCntMod++; #endif Dann würde man sich immernoch ein Byte, und eine Hand voll Takte sparen. Aber das ist nun wirklich erbsenzählerei. Mit 4 Graustufen reicht die Rechenleistung ja sowieso. Nur bei 8 ist man halt um jeden Takt froh. Andererseits läuft mein AVR jetzt eh auf 20Mhz, da gehts auch wieder recht flott. Das ganze übrigens mit dem 80ns SRAM vom Reichelt. Natürlich weit jenseits der Specs, aber es solange es läuft... Hab mal noch nen Bild vom Normally White mit 8 Graustufen angehängt. Da sieht man schön, dass der Kontrast einfach nicht reicht. Sebastian
Mit welchem Verfahren rechnest du den die Graustufen um? 4 Grauwerte gibt bei mir eigentlich schon ein schickes Bild, 8 Grauwerte sind natürlich echt Luxus! Ich hoffe ja das ich irgenwann mal mein 640x480 Display ans laufen kriege, aber irgenwie kommt immer was dazwischen :) Besonders das Layouten des SRAMs ist immer ne schreckliche Sache :)
hallo Sebastian, mit welchen programm hast du eine bilder erzeugt. mfg kay
Hmmm, SRAM routet sich doch normalerweise recht einfach. Du kannst ja Adress- und Datenleitungen beliebig verdrehen. Ok, hier gehts nicht ganz beliebig wegen dem Display, aber prinzipiell kann man da schon den Schaltplan etwas anpassen. Die Bilder erzeuge ich mit "Grafik Converter". Ist ein kleines Javaprogramm hier aus dem Forum, das dir aus farbigen Bildern welche in Grau erzeugt. Kannst dann auswählen, ob sie als Bild, oder als include-datei für C oder ASM gespeichert werden sollen. Das Bild was ich oben gepostet habe wurde mit Floyd-Steinberg umgerechnet. Mit einfachen Schwellenwerten bilden sich bei Farbverläufen immer so doofe Bögen zwischen zwei Grauwerten. Sebastian
hallo, esrtmal danke für die info,mich würde noch interressieren was ich beim speichern einstellen muss,also bei ausgabeposition mfg kay
Ja das stimmt wohl hab nur leider 32K Cache SRAMs und daher brauch ich min 3 Stück für 640x480... bin schon fast soweit die einfach übereinander zu stapeln ^^ Das Programm ist übrigens von mir, ggf erreichst du ein besseres Ergebnis wenn du die Farbraumangleichung deaktivierst und die Graustufen etwas justierst.
ich wollte nur wissen was ich bei der Ausgabe Optionen einstellen muss,bei Farbtabelle habe ich 2Farben eingestellt, vielleicht könnte mir da nochmal jemand helfen kay
3*32KByte für 640*480? Das stimmt aber nur für Graustufen. Und da wär ich mir nicht sicher, ob das noch vernünftig aus nem AVR zu holen ist. Lass mich aber auch gerne vom gegenteil überzeugen. Wieso nicht stapeln? Wenn's etwas professioneller aussehen soll kannst du ja jeden Ram auf ein kleines Stückchen Platine löten und die Platinen übereinander anordnen. Lässt sich dann auch schön einfach durchverbinden. Bin mir bloß nicht sicher, ob die Signalqualität davon so begeistert ist ;-) An sonsten würde ich halt durch die Pins durchrouten. Bei drei hintereinander sollte man sogar auf nem einlagigen Board noch an die CS-leitungen rankommen. Was macht eigentlich die Farbraumangleichung? Ist das nur, damit ich die Farbtabelle besser auf das jeweilige Bild einstellen kann? Mein Display hat am Ende ja eh nur Graustufen... @kay So schwer ist's eigentlich nicht mit den Bildern. Du machst erst alle Einstellungen (Größe, Farbtabelle, Zoom,...). Dann suchst du dir aus obs Floyd-Steinberg oder Schwellenwert Verfahren werden soll. Dann speichern: Die Einstellungen da sollten für Benedikts Displaycontroller schon passen. Also Horizontal, MSB First und Bytegrenzen bewahren. Dann noch auswählen, ob du es als Bild, header für .asm oder für .c haben willst. Bild (also .bmp,...) macht hier aber eigentlich keinen sinn, also .asm oder .c Dem Controller sendest du dann der Reihe nach: -15 (Startwert) -0xAA (Kontrollbyte) -X (Startposition X, für den ersten Versuch am besten 0) -Y (Startposition Y, auch am besten 0) -xs (breite des Bildes in Byte. xs=1 heißt 8 Pixel, bei 40Pixel wäre xs 5) -ys (Höhe in Pixeln) -1 (Modus, bei 1 bit ist das "eins") - und jetzt die Daten. Viel Erfolg Sebastian
Sebastian schrieb: > 3*32KByte für 640*480? Das stimmt aber nur für Graustufen. Und da wär > ich mir nicht sicher, ob das noch vernünftig aus nem AVR zu holen ist. > Lass mich aber auch gerne vom gegenteil überzeugen. Müsste man halt irgendwie in Bänke unterteilen. 640x480 benötigen 38400 Byte. Das ist ein dummer Wert, man müsste vermutlich irgendwo mitten in einem Bild umschalten.
Benedikt K. schrieb: > Sebastian schrieb: >> 3*32KByte für 640*480? Das stimmt aber nur für Graustufen. Und da wär >> ich mir nicht sicher, ob das noch vernünftig aus nem AVR zu holen ist. >> Lass mich aber auch gerne vom gegenteil überzeugen. > > Müsste man halt irgendwie in Bänke unterteilen. 640x480 benötigen 38400 > Byte. Das ist ein dummer Wert, man müsste vermutlich irgendwo mitten in > einem Bild umschalten. Naja ich dachte halt dies wäre der "Nachfolger" der 640x480er Schaltung oder funktioniert das nur fpr 320x...? Ich würde dann einfach 4x32k stapeln damit man kein "Loch" im Addressraum hat. Geht anstelle des HC753 eigentlich auch ein HCT373? Scheinen mir beides nicht invertierende "transparente" Latches zu sein. >Was macht eigentlich die Farbraumangleichung? Ist das nur, damit ich die >Farbtabelle besser auf das jeweilige Bild einstellen kann? Mein Display >hat am Ende ja eh nur Graustufen... Ist vieleicht ein etwas blöder Begriff was besseres viel mir aber nicht ein. Die Farbraumangleichung ist nur für Grauwertbilder sinnvoll und bewirkt eigentlich nur das der volle Wertebereich genuzt wird. Es wird einmal der Minimale Grauwert und einmal der Maximale Grauwert bestimmt, und dann alle Werte dementsprechen skaliert das sie im Bereich 0...255 liegen.
Läubi .. schrieb: > Naja ich dachte halt dies wäre der "Nachfolger" der 640x480er Schaltung > oder funktioniert das nur fpr 320x...? Mit 640x480 funktioniert das auch, das Problem ist halt eben nur der ungünstige Speicherverbrauch. Bei der 320x240 Version ist der Speicher streng genommen als 256x256x4bit organisiert (da der Speicher aber 8bit breit ist, sind gerade und ungerade Adressen identisch). Das LCD benötigt 80x4bit x 240. Reserviert sind 128x4bit x 240 für ein Bild, das gleich nochmal für das andere Teilbild der Graustufe. Ich denke mal Sebastian hat einfach noch einen weiteren Speicher hinzugefügt und so 2 weitere Teilbilder eingebaut. War bestimmt einiges an Arbeit, vor allem das umrechnen 2 bzw. 3bpp -> 2/4 Teilbilder. > Ich würde dann einfach 4x32k stapeln damit man kein "Loch" im > Addressraum hat. Oder gleich einen 128kx8 SRAM verwenden. > Geht anstelle des HC753 eigentlich auch ein HCT373? Scheinen mir beides > nicht invertierende "transparente" Latches zu sein. Ja, sollte egal sein, bei 0V/5V Pegeln sind beide geeignet.
Ich hab halt ne altes Lapto SW Display was ich da gerne dranhängen würde
hatte erst die "alte" 640x480 Version geplant aber Graustufen sind ja
auch nicht schlecht daher wollt ich jetzt die "Modernere" Variante
wählen.
Bei dem Display wir allerdings 8 bit auf einmal übertragen von daher
wollte ich die "alte" Schaltung mit der "neue" Software aufbauen oder
gibt es da Inkompatibilitäten?
>Oder gleich einen 128kx8 SRAM verwenden
ja okay... aber die Rams hab ich jezt hier und schnelle SRAMs kriegt man
ja auch nicht an jeder Straßenecke...
Läubi .. schrieb: > Bei dem Display wir allerdings 8 bit auf einmal übertragen von daher > wollte ich die "alte" Schaltung mit der "neue" Software aufbauen oder > gibt es da Inkompatibilitäten? Die SRAM Adressieren ist etwas anders. Bei der neuen habe ich den oben beschriebenen, etwas unkonventionellen Ansatz verwendet, A0 vom mega8515 frei zu lassen. Es kann sein, dass ich auch ein paar Pins gedreht habe. Ansonsten sollte das ganze nahezu gleich sein. Du kannst das SRAM (also 2x 32kB) so verdrahten wie bei der 640x480 Version, und für die neue Software A0 vom mega8515 trennen und auf Masse legen.
Aber brauche ich nicht (640*480*2)/8 = 76800 bytes? Das wären dann ja mind 3x32kb nötig. Und verliert man nicht die Hälfte an Speicherplatz nochmal dadurch das A0 fest auf Masse liegt? Das verwirrt mich gerade etwas ;)
Läubi .. schrieb: > Und verliert man nicht die Hälfte an Speicherplatz nochmal dadurch das > A0 fest auf Masse liegt? Das verwirrt mich gerade etwas ;) Ach ich seh gerade das du das manuell ansteuerst! Die erste Frage bleibt aber ;)
Läubi .. schrieb: > Aber brauche ich nicht (640*480*2)/8 = 76800 bytes? Für Graustufen, ja. Aber ob es die Version jemals geben wird, bezweifle ich noch. > Und verliert man nicht die Hälfte an Speicherplatz nochmal dadurch das > A0 fest auf Masse liegt? Das verwirrt mich gerade etwas ;) Ja, aber das ist für die neue 320x240 Version notwendig, die mit 32kByte Speicher auskommt. Diese habe ich bewusst auf möglichst wenige Bauteile optimiert, damit man die leicht nachbauen kann.
Benedikt K. schrieb: > Läubi .. schrieb: >> Aber brauche ich nicht (640*480*2)/8 = 76800 bytes? > > Für Graustufen, ja. Aber ob es die Version jemals geben wird, bezweifle > ich noch. Mist ich dachte die gäbe es schon g Wodran scheitert es denn? Ich werd erstmal die 32kb Version aufbauen (Allerdings ohne die Sache zur Erzeugung des Frame Signales) dann sollte ja erstmal nix kaputtgehen und im zweifel hab ich halt nur SW :)
>Ich denke mal Sebastian hat einfach noch einen weiteren Speicher >hinzugefügt und so 2 weitere Teilbilder eingebaut. War bestimmt einiges an >Arbeit, vor allem das umrechnen 2 bzw. 3bpp -> 2/4 Teilbilder. Nein, das ist ja grade das schöne. In den 32k-RAM passen ja 3 Teilbilder (hast du ja mit einführen der Virtuellen Bildgröße bewiesen). Bei mir liegen die 3 Teilbilder einfach nebeneinader im Ram, so wie bei dir schon die 2 bei 2bpp. Fenster verschieben geht dann natürlich nicht mehr, bringt aber (meiner Meinung nach) eh nur dann wirklich was, wenn man mindestens 2 Vollbilder im Speicher hat. Sobald man also Graustufen will, ist's eh egal. Aber die Hardware ist föllig unberührt. Quarz hab ich auf 20MHz getauscht, läuft aber auch mit 16 noch. Ich häng das ganze jetzt doch mal an. Bringt ja nichts nur drüber zu reden... Sebastian
So jetzt also: 8 Graustufen, hier im Anhang! Die Hex im Anhang ist für 16MHz und 500000 Baud-Rate und natürlich 8 Graustufen kompiliert. Was ist neu: #define GRAY8 aktiviert den 3-bit Modus, aber nur wenn GRAYSCALE auch aktiv ist. Eine 3-bit-Grafik wird erstmal genauso gesendet, wie die anderen auch. X und xs wird 8-Pixel-weise angegeben (also z.B. xs=5 bei 40 Pixel Bildbreite). Y und Ys wird in Zeilen angegeben Modus ist 2 für 3bpp Die Daten muss MSB-First sein und ein kontinuierlicher Bitstream, also nicht Byte-aligned. Hab das so gewählt, um die zu übertragenden Daten klein zu halten. Bei Byte-aligned hätte man 2bit pro Byte umsonst gesendet. 1- und 2bit Grafiken werden gesendet wie bisher. Zur Farbraumerweiterung wird einfach das letzte Bit kopiert: 0->000 1->111 00->000 01->011 10->100 11->111 So krigt man immernoch schönes Schwarz und Weiß hin. Würde man das LSB einfach Null setzen wäre das ja nicht mehr gegeben. Die Grafik und Textfunktionen sollten alle laufen wie Gewohnt. Für die Farben (auch Text- und Hintergrundfarbe) sind jetzt aber die obersten DREI bit relevant, sodass man auch hier 8 Graustufen nutzen kann. Die Befehle für den virtuellen Bildbereich und das setzen des Textanfangs werden ignoriert. Da man das Bild nur um ein paar Pixel verschieben könnte hab ich das für 8 Graustufen deaktiviert. Vielleicht mach ich irgendwann mal ne Bankumschaltung draus, dann bräuchte man aber einen größeren RAM. Performance hab ich bisher noch nicht gemessen, aber es liegt absolut im Bereich des Zumutbaren. Für ein Vollbild 3-bit Grafik grob geschätzt eine Sekunde. Gruß, Sebastian
Sorry für tripple-post. Wollte die Software extra haben und hab jetzt erst bemerkt, dass ich weiter oben Mist geschrieben hab. @kay: Modus muss für Schwarz-Weiß auf 0 gestellt werden. 1 wären 4Graustufen. Sebastian
@ Sebastian Ich habe mir die Software gerade angesehen und muss sagen: Respekt! Ich hätte es nicht besser gekonnt. Hast du was dagegen wenn ich deine Erweiterung übernehme und diese Software als aktuellen Stand übernehme, darin also spätere Erweiterungen einbaue? Dann würde ich das ganze auch mal testen und die neuen Funktionen der Beschreibung hinzufügen.
Vielen vielen Dank. So ein Lob von dir zu hören ist schon was besonderes! Zumal das das erste LCD ist, das ich je zum ansteuern in der Hand hatte! Nichtmal irgendein HD... kompatibles :-) Würde mich sogar freuen, wenn du das übernimmst. Allein schon, weil ich dann auch weiterhin von änderungen profitieren kann, die du einfügst, ohne jedes mal wieder rumbasteln zu müssen. Gruß, Sebastian
Angehängte Dateien:
-
belegung.png
55 KB
So jezt nochmal das ich alles richtig habe weil es ja 2 Schaltplanversionen gibt... AVR --> Display 13 --> XCLK = CP2 14 --> FLM = S 15 --> LP = CP1 31 --> OnOff = DISP (Optopkopler kann wegfallen) Zur Negativen Spannungserzeugung: 29 --> PWM Ausgang Muß es ein BC327 sein? Ich hätte nen BC557 oder BSS84P hier. In welchem Bereich kann die Spule liegen? Ich hätte hier 330µH einmal las L-PIS2408 und einmal SMCC (die Widerstandsvariante) und einmal ne MISC 100µH Diode würde ich ne 1N914 nutzen.
Ich habe mal alle Funktionen der 8 Graustufenversion von Sebastian geprüft: Laufen wunderbar. Das einzige was mich stört ist die hohe Framerate die notwendig ist, um das ganze flimmerfrei anzuzeigen. Daher habe ich die Option GRAYMOD erweitert. Mit dem Wert dahinter kann man nun die Graustufenerzeugung etwas beeinflussen. Somit erreicht man bereits bei 100Hz recht gute Ergebnisse. Da das ganze auch stark vom verwendeten LCD abhängt, kann man mit diesem Wert und der Framerate etwas spielen, bis das Ergebnis zufriedenstellend ist. Eine weitere Neuerung ist nun, dass das LCD Zeilentiming nun hardwaremäßig erzeugt werden kann: Durch den UART Interrupt wird der LCD Timer Interrupt ab und zu für eine kurze Zeit ausgebremst. Dadurch sind manche Zeilen länger, andere kürzer an. Das sieht man dann als Streifen im Bild. Mit steigender Framerate wird der relative Einfluss zunehmend größer. Nun wird der Latchpuls per Timer erzeugt und wird nun nicht mehr durch andere Interrupts beeinflusst. Da der Timer aber schon von der PWM belegt war, musste dieser etwas angepasst werden. Die PWM Frequenz ist nun gleich der Zeilenfrequenz des LCDs.
Läubi .. schrieb: > So jezt nochmal das ich alles richtig habe weil es ja 2 > Schaltplanversionen gibt... Welche Schaltung meinst du jetzt? Die neue 320x240 Version oder die alte 640x480? Ich habe bei der neuen 320x240 Version bewusst den ganzen Ballast der alten Schaltung weg geworfen und alles neu entworfen, daher sind beide nicht 100%ig kompatibel. > Muß es ein BC327 sein? Ich hätte nen BC557 oder BSS84P hier. Ich sag mal ja. Es kann mit einem BC557 funktionieren, aber der dürfte am Rande der Specs betrieben werden. Der BSS84 ist viel zu hochohmig. > In welchem Bereich kann die Spule liegen? Ich hätte hier 330µH einmal > las L-PIS2408 und einmal SMCC (die Widerstandsvariante) und einmal ne > MISC 100µH Sollten eigentliche alle gehen (eventuell bis auf die MISC). Ich verwende meist die in Widerstandsbauform. Der Widerstand der Spule sollte etwa 5-10 Ohm allerdings nicht überschreiten. > Diode würde ich ne 1N914 nutzen. Da dies ein Vergleichstyp der 1N4148 ist, ist die ok.
Benedikt K. schrieb: > Welche Schaltung meinst du jetzt? Die neue 320x240 Version oder die alte > 640x480? Ich habe bei der neuen 320x240 Version bewusst den ganzen > Ballast der alten Schaltung weg geworfen und alles neu entworfen, daher > sind beide nicht 100%ig kompatibel. Ich bau jezt einfach mal die neue 320x240 Version auf. Allerdings ohne die 4bit Unterteilung. > Ich sag mal ja. Es kann mit einem BC557 funktionieren, aber der dürfte > am Rande der Specs betrieben werden. Der BSS84 ist viel zu hochohmig. Okay dann muß ich mal sehen wo ich einen herbekomme. > Sollten eigentliche alle gehen (eventuell bis auf die MISC). Ich > verwende meist die in Widerstandsbauform. Der Widerstand der Spule > sollte etwa 5-10 Ohm allerdings nicht überschreiten. Kann ich das einfach mit dem MM messen oder bezieht sich der Wert auf eine bestimmte Freuenz? Zu deiner neuen "Demo": Sieht SUPER aus! Wenn ich doch nur schon soweit wäre :D
Läubi .. schrieb: >> Benedikt K. schrieb: >> Sollten eigentliche alle gehen (eventuell bis auf die MISC). Ich >> verwende meist die in Widerstandsbauform. Der Widerstand der Spule >> sollte etwa 5-10 Ohm allerdings nicht überschreiten. >Kann ich das einfach mit dem MM messen oder bezieht sich der Wert auf >eine bestimmte Freuenz? Einfach messen. Da der Spitzenstrom irgendwo im Bereich von >100mA liegt, sollten sich die Verluste im Drahtwiderstand in Grenzen halten: Bei 100mA und 10 Ohm gehen 1V verloren. Das sind bei 5V Betriebsspannung schon 20%. Es funktioniert zwar vermutlich auch, nur ist der Wirkungsgrad schnell bei <50%. Daher auch der externe PNP Transistor: Der interne NPN Darlington funktioniert auch (mehr oder weniger), da an diesem aber >1V verloren gehen, reduziert sich der Wirkungsgrad noch weiter.
Wäre es den vom Vorteil den MC34063 mit einer Höheren Spannung zu betreiben? Für den Inverter fürs CCFL brauch ich eh 12V. Ist den meine Verbindung uC--> LCD ansonsten korrekt?
Ja, 12V würden Vorteile bringen, aber auch Gefahren: Der MC34063 kann maximal 40V. Bei 12V und -20V sind das bereits 32V. Sehr viel höher darf man da also nicht gehen, etwa 16V würde ich als Maximum der Eingangsspannung betrachten. Die Verdrahtung sollte so passen. Der Schaltplan in der PDF in dem Paket sollte passen.
hallo, ich würde das gerne mal in den 8Graustufen probieren, nun hab ich noch ein paar Fragen ich hab ein bild 96x62Pixel 1.was muss ich den bei dem oben genanten Programm von Läubi bei der Farbtabelle einstellen ich hab 2Farben und beim abspeichern hab ich 16Bytes eingestellt 2.15,0xAA,0,0,12,62,2 =744byte an bilddaten, aber die abgespeicherte datei hat aber knapp 5KB an daten? vielleicht könnte mir nochmal kurz jemand helfen, speziell bei der 3bpp,muss ich 96:8 oder 96:24 rechnen mfg kay
DIe Daten in der asm Datei liegen im ASCII / AVRStudio format vor, also keine Banege, du must wenn ich das richtig verstanden habe einfach nur die Daten aus diesem Feld senden. (Du kannst die Datei einfach mit notepad öffnen dann siehst du die entsprechenden Hexzahlen) Versuchst du das ganze vom PC aus oder von nem uC?
hallo, ich wollte die asm datei von einem atmega128 übertragen, ich weis jetzt aber nicht ob ich den befehl 15 so richtig gerechnet habe,weil bei 1bpp muss ich ja 96:8=12 in X und 62 in Y das macht 12x62=744 Byte an bilddaten aber, wie ist das jetzt in der 3bpp variante?? kay
Es ist Befehl 16. Ansonsten passt deine Rechnung: Da 8Pixel gezählt werden, musst du 12x62 als Bildgröße senden. Da 8 Pixel 3 Bytes entsprechen, musst du 3x12 x 62 Bytes senden.
also würde das dann so passen,
16,0xAA,0,0,12,62,2
bilddaten:
//Datei: bild_1.bmp
//Größe: 91x62
#include <avr/pgmspace.h>
prog_uchar data_bild_1.bmp[] = {
0x11, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x0D, 0xDA, 0xFD, 0x55, 0x24,
0x92, 0x49, 0x24, 0x92, 0xAA, 0xAA, 0xA8, 0xA5, 0x50, 0xAA, 0x55,
0x55, 0x54, 0xAA, 0xAA, 0xAA,
0xAA, 0xAA, 0x95, 0xAA, 0xD5, 0x55, 0x25, 0x24, 0xA9, 0x25, 0x54,
0xAA, 0xAA, 0xA5, 0x4A, 0xA5,
0x4A, 0x55, 0x2A, 0x49, 0x52, 0x92, 0x52, 0xAA, 0xB6, 0x56, 0xA9,
0x52, 0x92, 0x49, 0x2A, 0x49,
0x4A, 0xAA, 0xA5, 0x55, 0x15, 0x29, 0x49, 0x4A, 0xA4, 0x92, 0x54,
0x94, 0x95, 0x2A, 0xAA, 0xA9,
0x55, 0x4A, 0xA5, 0x21, 0x49, 0x24, 0x49, 0x2A, 0x4A, 0x52, 0xAA,
0x25, 0x2A, 0x45, 0x12, 0x8A,
0x52, 0x52, 0x91, 0x25, 0x25, 0x4A, 0xAA, 0x94, 0x95, 0x14, 0x8A,
0x10, 0x88, 0x84, 0x92, 0x95,
0x4A, 0x48, 0x54, 0x48, 0x48, 0x4A, 0x29, 0x4A, 0x4A, 0x54, 0x89,
0x24, 0xAA, 0x12, 0x55, 0x52,
0x52, 0x08, 0x84, 0x24, 0x90, 0x4A, 0x4A, 0xA9, 0x25, 0x24, 0x11,
0x24, 0x94, 0x4A, 0x21, 0x09,
0x44, 0x52, 0x24, 0x92, 0x4A, 0x54, 0x91, 0x04, 0x24, 0x09, 0x44,
0x82, 0x51, 0x29, 0x2A, 0x84,
0xA4, 0x49, 0x4A, 0x28, 0x2A, 0x02, 0x25, 0x21, 0x10, 0x90, 0x89,
0x22, 0x24, 0x80, 0x08, 0x28,
0x15, 0x10, 0x10, 0x94, 0xA4, 0xA4, 0x12, 0x29, 0x0A, 0xA8, 0x50,
0x40, 0x08, 0xA8, 0xA0, 0x22,
0x49, 0x49, 0x28, 0x84, 0x00, 0x20, 0x22, 0xA4, 0x40, 0x41, 0x51,
0x24, 0x40, 0x90, 0x85, 0x2A,
0xA1, 0x50, 0x00, 0x22, 0x82, 0x01, 0x11, 0x25, 0x09, 0x45, 0x00,
0x00, 0x80, 0x24, 0x50, 0x05,
0x2A, 0x88, 0x82, 0x00, 0x04, 0x0A, 0x49, 0x22, 0x20, 0x20, 0xA0,
0x00, 0x04, 0x45, 0x14, 0xAA,
0x14, 0x20, 0x00, 0x10, 0x90, 0x00, 0xA4, 0x92, 0x21, 0x04, 0x00,
0x28, 0x01, 0x49, 0x20, 0x40,
0x50, 0x80, 0x00, 0x81, 0x0A, 0x21, 0x50, 0x25, 0x00, 0x00, 0x40,
0x40, 0x44, 0x4A, 0x42, 0x84,
0x08, 0x00, 0x90, 0x08, 0x92, 0x41, 0x20, 0x00, 0x20, 0x01, 0x04,
0x28, 0x49, 0x40, 0x48, 0x40,
0x00, 0x00, 0x92, 0x40, 0x44, 0x82, 0x10, 0x20, 0x02, 0x40, 0x01,
0x22, 0x48, 0x00, 0x02, 0x02,
0x02, 0x10, 0x91, 0x09, 0x00, 0x92, 0x00, 0x00, 0x08, 0x88, 0x12,
0x01, 0x02, 0x40, 0x00, 0x44,
0x80, 0x10, 0x41, 0x10, 0x00, 0x40, 0x04, 0x84, 0x42, 0xA8, 0xA2,
0x01, 0x10, 0x21, 0x00, 0x88,
0x40, 0x02, 0x00, 0x29, 0x00, 0x00, 0x12, 0x08, 0x20, 0x02, 0x00,
0x40, 0x92, 0x09, 0x21, 0x09,
0x11, 0x10, 0x08, 0x10, 0x12, 0x10, 0x80, 0x40, 0x08, 0x00, 0x34,
0x08, 0x08, 0x90, 0x00, 0x48,
0x00, 0x00, 0x81, 0x20, 0x49, 0x24, 0x28, 0x08, 0x00, 0x4A, 0x40,
0x04, 0x8A, 0x42, 0x01, 0x40,
0x10, 0x90, 0x28, 0x52, 0x40, 0x02, 0x44, 0x04, 0x00, 0x11, 0x02,
0x48, 0x94, 0xA8, 0xA0, 0x20,
0x92, 0x02, 0x04, 0x24, 0x90, 0x81, 0x00, 0x0A, 0x42, 0x41, 0xA1,
0x45, 0x24, 0x14, 0x20, 0x00,
0x02, 0x0A, 0xA8, 0xD5, 0x7E, 0xAA, 0xA3, 0x7A, 0x28, 0x51, 0xED,
0x5D, 0xB4, 0x6D, 0xFB, 0xF7,
0x55, 0x7B, 0xB5, 0xF2, 0x45, 0x42, 0x14, 0x02, 0x50, 0x45, 0xDF,
0xF9, 0xB5, 0xA9, 0x42, 0x95,
0x26, 0xAD, 0x35, 0xA9, 0x52, 0xB5, 0x6D, 0x5B, 0xD4, 0xAB, 0x54,
0xAA, 0x2A, 0x55, 0x24, 0xD7,
0xFD, 0xFF, 0xE6, 0x8A, 0xAA, 0xA9, 0x52, 0x5A, 0x7B, 0x5B, 0x6F,
0x6C, 0xED, 0x75, 0x5E, 0xD5,
0x55, 0x4B, 0xBE, 0xFD, 0xAA, 0xB6, 0xBB, 0xFD, 0xBB, 0xBF, 0x77,
0xED, 0xEE, 0xDE, 0xBA, 0xDF,
0xAD, 0x5F, 0xFA, 0xFF, 0xF5, 0x7B, 0x2E, 0xD7, 0x76, 0xFD, 0xEE,
0xAF, 0x7F, 0xEB, 0xFB, 0xF5,
0xFE, 0xDF, 0x6F, 0x7B, 0xF6, 0xF7, 0xFF, 0xBB, 0x6F, 0xDA, 0xAA,
0xD4, 0xAA, 0x2A, 0x22, 0x82,
0x22, 0x00, 0x09, 0x2A, 0x2A, 0xB5, 0x6D, 0x6A, 0xAA, 0x12, 0x8A,
0xAA, 0xAD, 0xB6, 0xAA, 0xB5,
0x6B, 0x76, 0x49, 0x4A, 0xBA, 0xAA, 0x55, 0x55, 0x55, 0x2A, 0xAB,
0x77, 0xB5, 0xAD, 0x5A, 0xA8,
0xAA, 0xAA, 0xAA, 0xAA, 0xB6, 0xAD, 0xB5, 0xAD, 0x6D, 0x69, 0x55,
0x6A, 0xAA, 0x5B, 0x55, 0xB5,
0xBE, 0xDB, 0x5B, 0x77, 0x5A, 0xED, 0x55, 0xD5, 0xBA, 0x55, 0xA5,
0xDA, 0xB5, 0xB6, 0xFB, 0xDE,
0xD6, 0xEE, 0xEF, 0x55, 0xF7, 0x6F, 0xDE, 0xF7, 0xDF, 0xBD, 0xDE,
0xAD, 0xD7, 0x6B, 0xB7, 0x6B,
0xB7, 0xAD, 0x7B, 0xAF, 0xDD, 0xFF, 0x6A, 0x55, 0x9B, 0xDB, 0x57,
0xFE, 0xDF, 0xFA, 0xFF, 0xBF,
0xEE, 0xFB, 0xBB, 0xDD, 0x55, 0xF7, 0x5B, 0x6D, 0xAB, 0xED, 0x5E,
0xFF, 0xFE, 0xAD, 0xAE, 0xDD,
0xA7, 0x5B, 0xBF, 0xDF, 0xD7, 0x7E, 0xEB, 0xBB, 0xEB, 0x6D, 0x7D,
0x6B, 0x2D, 0x6A, 0xAF, 0x67,
0xBD, 0xDF, 0xFD, 0xF6, 0xAB, 0xF5, 0x5B, 0xBD, 0x6B, 0xDF, 0x5F,
0xBD, 0x6E, 0xBF, 0xF7, 0x55,
0x92, 0x96, 0xB5, 0x77, 0xEC, 0xB7, 0xEE, 0xD7, 0xFF, 0xDF, 0xB5,
0x7D, 0xAE, 0xF7, 0xD3, 0x55,
0xDF, 0x5F, 0x6D, 0xBD, 0xBE, 0xBD, 0x59, 0x46, 0x23, 0x55, 0x96,
0xE5, 0x7D, 0xB6, 0xBE, 0xFE,
0xFF, 0xC0
}
mein bild hat 12x62Pixel 744Byte
aber wie muss ich die >3x12< x 62 Bytes senden.
mfg kay
Einfach den Befehl und hinterher die Daten. Also 16,0xAA,0,0,12,62,2, 0x11, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, usw.
Du solltest mal nochmal deine Einstellungen beim Grafik Converter überprüfen, das passt glaub ich noch nicht ganz: Das schwarz-weiß-bild im Anhabng wurde mit sicherheit über die "NULL Transformation" oder über "Graustufen Verfahren" erzeugt. Genau die beiden wandeln aber nur nach grau, ohne den Farbraum zu begrenzen. Die ASM-Datei müsste auch größer sein. Du hast ja auch geschreiben, dass die Farbtabelle nur 2 Einträge hat. Danach schaut auch die .asm aus. Ich hab mal zwei Screenshots gemacht. Wenn du die Einstellungen machst wie dort, sollte es auf jeden Fall funktionieren: Die Farbtabelle muss 8 Farben enthalten, die Größe die angegeben wird musst du entsprechend dem Display senden und zum convertieren musst du entweder Floyd-Steinberg oder Schwellenwert-Verfahren auswählen. Beim Speichern ist Horizontal und MSB-First wichtig und dass der Hacken bei "Bytegrenzen Bewahren" wegkommt. Hoffe das hilft Sebastian
hallo Sebastian, habe es mal so gemacht wie du es empholen hast,so mein Beispielbild ist 74x50Pixel, so wenn ich jetzt rechne 74x50=3700Byte aber die tatzächliche Bilddaten grösse ist 1388Byte, wie muss ich den das nun mit dem befehl 16 das übertragen, 16,0,0,?,50,2 muss ich 74:8=9.25*50=462,5 ,x zählt ja nur in 8Pixel, oder irre ich mich da. vielleicht könnte mir da nochmal jemand weiterhelfen. mfg kay
Kay schrieb: > habe es mal so gemacht wie du es empholen hast,so mein Beispielbild > ist 74x50Pixel, > so wenn ich jetzt rechne 74x50=3700Byte > aber die tatzächliche Bilddaten grösse ist 1388Byte, > wie muss ich den das nun mit dem befehl 16 das übertragen, > 16,0,0,?,50,2 Wie weiter oben schon geschrieben: Es werden 8 Pixel Schritte gezählt: 74/8=9,25 -> geht nicht. Du musst also entweder 72 oder 80 Pixel senden. Das wäre dann ein Wert von 9 oder 10. Da pro Wert 3 Bytes gesendet werden müssen, macht das 3 x 9 x 50 bzw. 3 x 10 x 50. Insgesamt wären das 1200 oder 1500 Bytes.
In deiner Beschreibung steht drinn das der MUX auch gleichzeitig als Buffer dient. Da ich den ja jezt weggelassen habe brauch ich dann auch einen Buffer (z.B. HC244).
Angehängte Dateien:
-
mega8515_ALE_AD.gif
10 KB
Wenn das Kabel zum LCD nicht allzu lange ist, dann sollte es keine Probleme geben. Ein zusätzlicher Puffer ist nie verkehrt, denn er entkoppelt die Ausgangsleitungen von dem Adress/Datenbus, aber es funktioniert normalerweise auch ohne diesen Puffer. Ein kritisches Timing ist das Adresslatch, das wie man im Anhang sieht in der Praxis sehr viel unkritischer ist als im Datenblatt (grün: ALE, rot: ADx Signal). Die fallende Flanke von ALE ist interessant, und rum um diese sind die Daten für >+/-20ns stabil (das Datenblatt garantiert z.B. nur 5ns Hold Time). Also mehr als ausreichend, selbst bei einer zusätzlichen Belastung. Das Timing vom LCD ist da meist sogar noch etwas kritischer, aber auch hier ist das Timing in der Praxis sehr viel unkritischer als im Datenblatt: Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen"
Benedikt, du schreibst doch immer, dass du auf deinen Bildschirmen Filme vom PC aus anschaust. Was ist das denn für ein Programm, das du da immer nimmst? Sebastian
hallo, so habe es eben mal versucht ein bild zu laden,aber es hat nicht funktioniert schade es wird nur müll angezeigt, abgespeichert habe ich es als asm-datei und 16Bytes pro zeile. hier ist meine routine zum senden: ;320X240Pixel :320:8=40 locateGrafik320x240picture 0xAA,0,0,40,240,2 ldi ZL, low(2*bild_1) ldi ZH, high(2*bild_1) ldi WH, 240 YsLoop:; ldi XL, 40 XsLoop: lpm WL, Z+;; call USART_TX0 ;Zeichen senden dec XL brne XsLoop dec WH brne YsLoop vielleicht könnte mir jemand weiterhelfen was ich da falsch mache die bolddaten habe ich im anhang mfg kay
Lass mich raten: Das Display zeigt unter anderem Jede Menge Buchstaben an, aber nichts was irgendwie nach einem Bild ausschaut? Du musst die Befehle (also 0xAA,0,0,40,240,2) schon auch zum Display schicken, damit dieses auch weiß, dass jetzt ein Bild kommt. Ansonsten passen jetzt eigentlich alle werte. Wenn du das richtig sendest und dein Bild richtig umgewandelt ist müsstest du was sehen. Wenns dann immernoch nicht geht meld dich mal nochmal. Dann such ich mal meinen LKW mit Startwerten raus. Damit MUSS es dann gehn. Sebastian
hallo Sebastian , das ist ein Macro,hatte ich vergessen zuerwähnen locateGrafik320x240picture 0xAA,0,0,40,240,2 .macro locateGrafik320x240picture push wl ;Register sichern LDI WL,16 call USART_TX0 LDI WL,@0 call USART_TX0 ;an LCD LDI WL,@1 call USART_TX0 ;an LCD LDI WL,@2 call USART_TX0 ;an LCD LDI WL,@3 call USART_TX0 ;an LCD LDI WL,@4 call USART_TX0 ;an LCD LDI WL,@5 call USART_TX0 ;an LCD als Befehl ausgeben pop wl ;Register wiederherstellen .endmacro das bild ist 320x240 320x240=76800byte 320:8=40 3x40x240=28800byte an bilddaten da benedikt sagt Da pro Wert 3 Bytes gesendet werden müssen,denke ich mal ich hab da irgendwo einen fehler in meinen aufruf,ich weiss nich wie ich 3x40 in meinen aufruf schreiben soll, da denke ich liegt der fehler. ;320X240Pixel :320:8=40 locateGrafik320x240picture 0xAA,0,0,40,240,2 ldi ZL, low(2*bild_1) ldi ZH, high(2*bild_1) ldi WH, 240 YsLoop:; ldi XL, 40 XsLoop: lpm WL, Z+;; call USART_TX0 ;Zeichen senden dec XL brne XsLoop dec WH brne YsLoop mfg kay das bild ausgeben aber am display wirds nur zu 1/4 mit wirren pixel gefüllt. die anderen funktionen laufen prima.
Sebastian schrieb: > Benedikt, du schreibst doch immer, dass du auf deinen Bildschirmen Filme > vom PC aus anschaust. Was ist das denn für ein Programm, das du da immer > nimmst? Irgendwo habe ich mal den Sourcecode von einem AVI Player aus dem Netz gezogen. Der liefert die einzelnen Frames als Bilder. Die schicke ich dann weiter ans Display, nachdem ich diese passend zurechtschneide und in das passende Format bringe. Kay schrieb: > da benedikt sagt Da pro Wert 3 Bytes gesendet werden müssen,denke ich > mal ich hab da irgendwo einen fehler in meinen aufruf,ich weiss nich wie > ich 3x40 in meinen aufruf schreiben soll, da denke ich liegt der fehler. > > ;320X240Pixel > :320:8=40 > locateGrafik320x240picture 0xAA,0,0,40,240,2 Das sieht eigentlich alles richtig aus. > ldi WH, 240 > YsLoop:; > ldi XL, 40 > XsLoop: Pro x Wert musst du 3 Bytes senden, dass wären dann 3*40 und nicht nur 40 Bytes pro Zeile.
hallo, so jetzt läufts allerdings fährt immer son balken von unten nach oben danke nochmals für die hilfe mfg kay
Angehängte Dateien:
-
TestJPG.jpg
61 KB
Hallo Benedikt irgendwie hab ich ein Bedienfehler Rechteckübergabe 29;5;0;5;250;0;30;255;0 wenn ich die 250 durch 315 (Rechteck bis fast rechts) ist das Rechteck weg. Linie 18;0;0;230;255;0;230;255 die Linie soll unten horizontal durchgehen wenn ich die mittlere 255 vergrössere, kommen schräge Linien raus. Warum hat x eigentlich low und high Wigbert
> Warum hat x eigentlich low und high
320 passen in 8Bit nicht rein, deshalb high und low.
achja, dann werden > 255 zwei Werte benötigt lang ists her Wigbert
Angehängte Dateien:
-
Hase_weiss2.png
475 Bytes
Hi, noch mal zur Bildübertragung: Ich will ein Bild 1Bpp 64x64 Pixel übertragen bei Pixel x = 80 ; y = 80 aufs Display. Ich übertrage dann : 16 0xAA 10 80 8 64 0 und dann die Daten.... stimmt das soweit? Ich hab hier convert.exe und LCD.Assistent.exe. Oder was kann ich nehmen? Wie war das mit den 3 Byte ? Vielleicht könnte jemand mal die Datei einsehen. Anbei Testbild + Datei h Dank Euch mal schon Wigbert
und die *h
Wigbert Picht-dl1atw schrieb:
> Ich übertrage dann : 16 0xAA 10 80 8 64 0 und dann die Daten....
Nicht ganz: Erst kommt die X/Y Position, dann die Größe:
16 0xAA 8 64 10 80 0
Das Bild in der .h sieht komisch aus: 455Bytes für 16384 Pixel passt
nicht ganz zu dem 80x80 Bild.
schon der erste Konflikt mal anders fragen... Befehl: 16 0AA X Y XS YS Modus Daten... 16 ; 0AA; OK Displaypixel 80 -> 80 :8 = 10 -> X = 10 ? Displaypixel 80 -> 80 -> Y = 80 ? Das Bild wird in 64 x 64 Pixel gesendet (rechts abschneiden) das wären doch 64 : 8 = 8 x 3 = 24 Byte x 64 = 1536 Byte Testbild. bis hier richtig gerechnet ? Wigbert
Äh Mist, deine Zeile oben war richtig. Ich hatte nur das x=80, y=80 gelesen, ich bin heute nicht ganz ausgeschlafen... Du überträgst die Daten im 1bit Modus, ein Bild ist also 64/8*64=512Byte groß. Dein angehängtes Bild ist aber 128 Pixel breit. Beschneide das mal, bevor du das durch die Software schickst.
&H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H0F , &H00 , &H00 , &H00, &H00 , &H00 , &H00 , &H00 , &H1F , &H80 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H18 , &HC0 , &H00 , &H00, &H00 , &H00 , &H00 , &H00 , &H0C , &H60 , &H00 , &H00 , &H00 , &H00 , &H00 , &H07 , &H06 , &H30 , &H00 , &H00, &H00 , &H00 , &H00 , &H0F , &HC3 , &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &H0C , &HF1 , &H8C , &H00 , &H00, &H00 , &H00 , &H00 , &H06 , &H3F , &H8C , &H00 , &H00 , &H00 , &H00 , &H00 , &H07 , &H0F , &H06 , &H00 , &H00, &H00 , &H00 , &H00 , &H03 , &HC0 , &H03 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &HE0 , &H01 , &H80 , &H00, &H03 , &H80 , &H00 , &H00 , &H7E , &H01 , &H80 , &H00 , &H07 , &HC0 , &H00 , &H00 , &H1F , &H80 , &HC0 , &H00, &H0c , &HC0 , &H00 , &H00 , &H01 , &HF0 , &H60 , &H00 , &H18 , &HC0 , &H00 , &H00 , &H00 , &H7C , &H38 , &H00, &H30 , &HC0 , &H00 , &H00 , &H00 , &H0C , &H1F , &H00 , &H30 , &HC0 , &H00 , &H00 , &H00 , &H0C , &H07 , &H80, &H70 , &HC0 , &H7F , &HC0 , &H00 , &H18 , &H00 , &HC0 , &H60 , &HC3 , &HFF , &HF0 , &H00 , &H30 , &H0C , &H60, &H60 , &HC7 , &HC0 , &H38 , &H00 , &H60 , &H12 , &H30 , &H60 , &HDC , &H00 , &H1F , &H00 , &HC0 , &H12 , &H30, &H30 , &HF8 , &H00 , &H03 , &H81 , &H80 , &H0C , &H18 , &H30 , &H60 , &H00 , &H01 , &HE3 , &H00 , &H00 , &H0C, &H18 , &H00 , &H00 , &H00 , &H7E , &H00 , &H00 , &H0C , &H0C , &H00 , &H00 , &H00 , &H3C , &H00 , &H00 , &H0C, &H1c , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H1C , &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H38, &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H30 , &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &H18 , &HE0, &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &H3F , &HC0 , &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &H67 , &H80, &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &HE0 , &H00 , &H18 , &H00 , &H00 , &H00 , &H00 , &H00 , &HC0 , &H00, &H0c , &H00 , &H00 , &H00 , &H00 , &H01 , &H80 , &H00 , &H06 , &H00 , &H00 , &H00 , &H00 , &H03 , &H00 , &H00, &H07 , &H00 , &H00 , &H00 , &H00 , &H03 , &H00 , &H00 , &H03 , &HF8 , &H03 , &HFF , &HFC , &H06 , &H00 , &H00, &H00 , &HFE , &H03 , &HFF , &HFC , &H0C , &H00 , &H00 , &H00 , &H07 , &H03 , &H00 , &H0C , &H18 , &H00 , &H00, &H00 , &H03 , &H03 , &H00 , &H0C , &H30 , &H00 , &H00 , &H00 , &H01 , &H83 , &H00 , &H0C , &H30 , &H00 , &H00, &H00 , &H00 , &HC1 , &H80 , &H0C , &H60 , &H00 , &H00 , &H00 , &H00 , &H61 , &H80 , &H08 , &H60 , &H00 , &H00, &H00 , &H00 , &H60 , &HC0 , &H18 , &H60 , &H00 , &H00 , &H00 , &H00 , &H30 , &H60 , &H30 , &HC0 , &H00 , &H00, &H00 , &H00 , &H18 , &H7F , &HF0 , &HC0 , &H00 , &H00 , &H00 , &H00 , &H18 , &H1F , &HF0 , &HC0 , &H00 , &H00, &H00 , &H00 , &H0C , &H00 , &H00 , &HE0 , &H00 , &H00 , &H00 , &H00 , &H07 , &H00 , &H00 , &H70 , &H00 , &H00, &H00 , &H00 , &H03 , &HFF , &H00 , &H30 , &H00 , &H00 , &H00 , &H00 , &H00 , &HFF , &H8F , &H18 , &H00 , &H00, &H00 , &H00 , &H00 , &H03 , &H0F , &HF8 , &H00 , &H00 , &H00 , &H00 , &H00 , &H06 , &H18 , &HF0 , &H00 , &H00, &H00 , &H00 , &H00 , &H0C , &H70 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H0D , &HE0 , &H00 , &H00 , &H00, &H00 , &H00 , &H00 , &H07 , &H80 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H03 , &H00 , &H00 , &H00 , &H00, &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00, &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H0 , &H00 , &H00, &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 , &H00 würde das passen? ich brauch doch jedes Byte nur 3x senden? Wigbert
Es sind zumindest 512 Bytes, könnte also passen. Die Daten musst du einfach nach dem Befehl senden, einfach alle Bytes so wie sie in der Tabelle stehen hinereinander, nicht 3x.
hier würden die Pixelzahl wohl auch stimmen Wigbert
Ja, und man kann den Hasen auch einigermaßen erkennen.
>einigermaßen
nun bin ich traurig, was der schon an Zeit gekostet hat.....
Wigbert
Angehängte Dateien:
-
Speedmod..gif
500 KB
also die Darstellung aufs Display ist OK , hier mal als Menueunterstützung, und den Einsatz von ein paar Grautöne. Wigbert
falls jemand Lust auf Bascom hat, der Codeauszug Sub Bild Local Count As Word Local B As Byte Printbin 16 ; 170 ; 29 ; 70 ; 8 ; 64 ; 0 ' Bildplatz If Wahl = 0 Then Restore Hase : 'if Wahl = 1 then Restore Testbild: For Count = 1 To 512 ' Byte müssen stimmen Read B Printbin B Next Count End Sub Hase: 'von oben Data ...... Wigbert
Hat eigentlich aktuell noch jemand eine oder sogar zwei Platinen übrig? MfG Flins
Würde mich auch interressieren ob das hier noch aktuel ist? wie sieht es mit der 8 graustufen version aus?gibts da ne ZIB mit Beispielen??? würde mich auch freuen wenn es noch eine platine geben würde lg chrissi
ok die 8 Graustufen Version hab ich gefunden
Hallo Benedikt, Wie schon oft bemerkt, tolles Projekt und vielen Dank auch fuer die Betreuung der Seite. Meine Frage, bringt ein Mega162 Vorteile? - mehr s-ram, neuerer Chip, Architektur? die Displayansteuerung ist ja wirklich ein Spezialgebiet. Mit avrs und Elektronik kenne ich mich ja etwas aus, doch programmiere ich fast nur in gcc- c, und habe mich bisher nicht so sehr fuer die Speicherverwaltung interessiert. Was muesste man aendern, wo konkret Adressen umschreiben, - bringt das was? vielen Dank philipp
Wirklich viel bringt der Controller nicht, nur mehr Flash (z.B. für zusätzliche Schriftarten) und mehr SRAM (für einen größeren UART Empfangspuffer). Geändert werden muss dazu nur die Zeile #define DDRAM 1024. Diese muss auf den Ende des internen und Beginn des externen RAMs also auf 0x500 = 1280 gesetzt werden.
Danke Benedikt für Deine schnelle und kompetente Antwort. So ungefähr, hatte ich gehofft, konnte auch nur die #define... finden, und mit den Wert hast Du mir auch geholfen. War mir aber unsicher, ob sich in dem asm Code noch Adressen ergeben. Da ich das Teil einlöten wollte, wäre es etwas nervig, es dann tauschen zu müssen. Den mega162 gibt es auch mal günstiger. Nochmal Danke, Danke. philipp
Vielleicht noch zu beachten: Der interne Adressraum darf nicht größer als 2k sein (2k SRAM ist schon zu viel) wenn man 8 Graustufen nutzen will. Bei 4/2 Graustufen kann man mit mehr internem SRAM halt nicht mehr den gesamten virtuellen Bildbereich verwenden. Aber der Mega162 hat ja nur 1kB Sebastian
Sebastian ... schrieb: > Vielleicht noch zu beachten: Der interne Adressraum darf nicht größer > als 2k sein Nicht ganz: Die theoretische Grenze liegt bei 4kByte, denn es werden 240x256 Bytes benötigt, also 61440 Bytes. Da allerdings der Wert 65536 nicht mehr in in den 16bit Adresszähler passt, funktionieren in der Praxis nur max 3840 Bytes ohne Anpassungen am Code. Mit den Graustufen sollte das wenig zu tun haben, denn die liegen alle in einer Zeile.
Du hast natürlich recht. Hab mich mit High- und Low- Byte und der ganzen Speicheraufteilung verhaun. Ist doch zu lang her, dass ich im Code rumgemacht hab. Im Endeffekt kann man dann halt Controller mit 2k SRAM noch nehmen, solche mit 4k nicht.
Hallo. Ich habe das Projekt nachgebaut, und nun das Problem, dass meine negative Spannung von etwa -21,8V auf -6,8V zusammenbricht, wenn ich das Display anschließe. Ferner habe ich den RAM "W24257AK-15" verwendet. Ansonsten ist es die von Benedikt angegebene Schaltung. Auf dem Display erscheint in der Mitte ein senkrecht unterbrochener "Block" (weiss) mit mehr oder weniger starker Pigmentierung. Kann dies ein Fehler der zu niedrigen Spannung sein? Den AVR (MEGA8515-16PU) habe ich mit AVR DUDE geflasht; hierbei habe ich die Fuses : hFuse: DF ; lFuse: FF gesetzt. Sind diese korrekt? Gibt es ein Funktionierendes *.hex, mit einem Beispielbild, um das Board ohne PC oder serielle Schnittstelle testen zu können? MfG Denis
Hatte auch Probleme mit der Stabilität der Kontrastspannung. Bei mir hats geholfen die Versorgungsspannung des Schaltreglers mit 100n direkt am Chip zu puffern. Gegen Masse gemessen sollte die Kontrastspannung im Betrieb bei ca. -17 Volt liegen. Die Software zeigt immer einen Startbildschirm an. Wenn du also nichts über die UART sendest solltest du was sehn (Ein paar Quadrate und ein kurzer Text). Gleich vorsorglich noch: Die erste Zip enthält einen fehlerhaften Schaltplan. Nimm am besten immer die aktuelle Version. Auch bei der Software. @Benedikt: Wollte mal mit der aktuellen Version im 4-Farb-Modus den virtuellen Bildbereich ausprobieren. Irgendwie hats nicht funktioniert. Auch wenn ich direkt im Controller die ensprechende Funkion aufgerufen hab hat sich nichts getan. Muss aber zugeben, dass ich das Problem nicht weiter untersucht habe, weils reine Neugier war. Gruß, Sebastian
WIeviel "Power" hat den der uC etwa noch frei? Könnte man noch eine Auswertung eines Touch und ein paar Tastern zusätzlich einbauen oder ist der Controller mit Bildausgaben vollauf beschäftigt?
Weiter oben hat Benedikt mal genaue Messungen und Berechnungen gepostet. Aber ich glaub, da gabs die 3-bit Version noch nicht. Grob überschlagen liegt die CPU-Last bei 50%. Von daher ist noch einiges drin. Das größere Problem dürften die anderen Ressourcen sein. Ram ist ziemlich voll. Flash weiß ich nicht. Timer müsste in der aktuellen Version einer frei sein, anfangs waren alle belegt. Wenn du signifikant CPU-Last hinzufügst musst du auch beachten, dass weniger Zeit für die Grafikberechnungen zur Verfügung steht. Bilder Laden, Rechtecke malen,... wird dann länger dauern. Eine Version mit 2*4 Tastenmatrix hab ich weiter oben mal gepostet. Funktioniert bei mir einwandfrei. Sebastian
Ich würde dann vieleicht auf den Mega162 umsteigen. Meine Idee ist das ich ein "Bedienpanel baue mit: - LCD320x240 + Touchpad - Drehencoder - 4 Tasten - RGB Status LED Alle Daten werden Zyklisch erfasst und ein weiterer AVR kann dann diese Daten abrufen und ggf. Sachen an das LCD zur Anzeige senden, die 3bit Variante wäre da schon nett :)
Cool,Touchpad und dann noch Tasten... Besser wäre es wohl, den GLCD-AVR in Ruhe zu lassen, und einen 2.AVR für den Rest zu nehmen. Wigbert
Wigbert Picht-dl1atw schrieb: > Cool,Touchpad und dann noch Tasten... Jupp, die Bedeutung der Tasten kann man erlernen und dann auch im Blindflug treffen, das Ganze soll ein AVR basiertes Navi/Mp3 Player sein, und wenn man während der Fahrt einfach ein Lied weiterschalten will soll man nicht erst auf dem Display die richtige Postion suchen müssen und dann irgenwo rauf-touchen. > Besser wäre es wohl, den GLCD-AVR in Ruhe zu lassen, und einen 2.AVR > für den Rest zu nehmen. Klar, aber dann muß ich schon mit mind. 2 AVRs kommunizieren, beide brauchen Ihre layouts und Außenbeschaltung ect...
>Jupp, die Bedeutung der Tasten kann man erlernen und dann auch im >Blindflug treffen na gut, mein Auto hat zusätzlich(vom Hersteller) auch zig Tasten am Lenkrad. >Klar, aber dann muß ich schon mit mind. 2 AVRs kommunizieren, beide >brauchen Ihre layouts und Außenbeschaltung ect... auch richtig, es gibt ja noch andere (leistungsstärkere usw.) Mikrocontroller. Viel Spass. Wigbert
Wie willst du das Touchpad auslesen? 8515 und 162 haben so weit ich das gesehen hab beide keinen ADC. Ich bin mitlerweile auch auf einen zweiten AVR ausgewichen, weil mein Display-AVR die Pins für Ram-Paging braucht. Ist zwar noch nicht implementiert, aber ich freu mich schon drauf auch bei 8 Graustufen keine Ladezeiten zu sehen.
Mist, du hast Recht :( Das war etwas zu kurz gedacht... naja.
Moin.
Nachdem ich dann die Pins am hc74 von 8 auf 9 geändert habe hat das
Signal am LCD anschluss schon besser ausgesehn. Nocheinmal die
Verkabelung zum Display geprüft... siehe da... LOAD und CP vertauscht...
. Jetzt klappt es. Die negative Spannung habe ich mit einer EF20.1
(516597 - 62) vom großen C ,für ca. 2,30€, in den Griff bekommen. Wen's
interresiert, ca. 20 bis 25 Windungen 0,2mm Kupferlackdraht aufgetragen,
die Ferritte eingesteckt und angelötet.
Nun habe ich noch 2 Fragen;
- Das Display hat horizontales Flimmern. Es sieht wie ein
"Lauflicht" nach unten aus. Was kann das sein?
- Die selbstgewickelte Spule Brummt sehr laut, hat damit jemand
Erfahrung und würde mir bitte sagen, wie ich das etwas eindämmen
kann?
Versucht habe ich es schon mit etwas Abstand zwichen den Ferritten,
leider ohne Erfolg.
MfG und vielen Dank schonmal für die Hilfe
Das Flimmern kommt durch die Graustufenerzeugung. Spiel mal mit dem Wert GRAYMOD etwas rum. Erlaubter Wertebereich steht im pdf aus der zip. Außerdem hab ich gemerkt, dass das Flimmern mit mehr abstand und geringerer Hintergrundbeleuchtung schwächer wird. Kenne deine Anwendung nicht, aber vielleicht ist es dadurch dann nicht mehr relevant. Wenn du keine großen gleichfarbigen Flächen hast wirst du das Flimmern auch nicht mehr merken. Wenn garnichts hilft kannst du auch die Framerate erhöhen, aber dann erhöht sich die Rechenlast des AVR und es dauert Länger bis Bilder und Grafiken angezeigt werden. Zu den Spulen hab ich mal gehort, man solle Sekundenkleber zwischen die Wicklungen ziehen lassen. Hab aber keine Ahnung, ob das hilft. Habs selbst nie probiert. Gruß, Sebastian
Mit GRAYMOD werd ich mal versuchen. Der TIP mit dem Kleber, erstklassig... ich habe die Wicklungen und die Zwichenräume des Ferritkerns mit 2 Komponenten Kleber (hatte keinen Sekundenkleber) "behandelt"; kein Brummen, Pfeiffen oder Zischen mehr. DANKE
Hallo Benedikt, Warum hast du CP2 mit dem /OE-Pin des RAMs und dem PD3-Pin des uCs mit einem NOR-Gate verbunden? Gruss
bernd schrieb: > Hallo Benedikt, > > Warum hast du CP2 mit dem /OE-Pin des RAMs und dem PD3-Pin des uCs mit > einem NOR-Gate verbunden? Das Frage ich mich auch gerade hat das eine Bewandtnis? Die Funktion des MUX umschaltens ist mir auch etwas unklar: Das invertierte LOAD Signal setzt das FF auf 0, und mit CLK setzt du es auf 1? Oder wird zwischendurch das FF auch mittels CLK getoggelt?
Hab es glaub rausgefunden: wenn der /OE-Pin auf low gezogen wird und anschliessend wieder auf high geht, wird am CP Pin der inverse Signalverlauf sein. Wenn das Byte vom Ram gelesen ist, wird ein Puls erzeugt. Da das Display auf die fallende Flanke die Daten einshiftet, funktioniert das gerade prima. ver-"nor"-t wird das mit einem portpin. Mit diesem Portpin kann man nun festlegen, ob ein Shift-clock erzeugt werden soll oder nicht. Wenn man das Display akutalisieren möchte (also in der Interrupt-routine) muss man diesen Portpin auf low legen. Wenn man einfach wahlweise Daten vom Ram lesen möchte, bleibt der Pin aber auf high, sodass keine Shift Clocks ausgelöst werden. Der MUX wird einfach bei jedem Shift Clock getoggelt, und falls er mal falsch initialisiert worden wäre, wird spätestens nach der ersten Zeile das FF geresetted, sodass er wieder mit den korrekten Daten beginnt. Halbwegs verständlich? gruss, bernd
Hallo, hat noch jemand 1 oder 2 Platinen übrig, vielleicht sogar noch so nen RAM? Gruß Patrick
Hallo,
ich möchte an dieser Schaltung das Glcd F-51154NF-FW-AA von Pollin
anschließen. Es hat die Größe 480x240 Pixel.
Anschlüsse:
4=Vdd (+5V)
5=D3
6=D2
7=D1
8=D0
9=Vss (GND)
10=Vee (-25V)
11=Display off (invertiert, also mit nem Pullup auf Vdd ziehen)
13=CP
14=LOAD
15=FRAME
Problem 1: Text und Grafik erscheinen doppelt.Einmal in der oberen
Hälfte des Display, und gleichzeitig in der unteren Hälfte.
Problem 2:Über UART kann ich nur Text anzeigen lassen. Das mit den
Steuerzeichen funktioniert bei mir nicht.In welchem Format werden die
Steuerzeichen gesendet.Sender ist ein Atmega 32.
Atmega 32 Atmega 8515
RDX--------------TDX
TDX--------------RDX
GND--------------GND
Hat jemand einen Tip für mich?
MfG
Karl
Welche Software-version verwendest du denn? Mit welchen Parametern? Poste am besten mal deine param.h und wenn du hast auch ein Datenblatt des Displays. Dein Display wird ohne ändern der Parameter nicht (sauber) laufen. Auch musst du auf 8 Graustufen verzichten, sonst reicht der Speicher nicht. Außerdem musst du mit einer deutlich höheren Prozessorauslastung wegen der größeren Auflösung rechnen. Das Rendern der Grafik dauert dann einfach länger. Du musst das RTS(BUSY)-Signal (PD2) noch zu deinem Master controller führen und dort Abfragen. Die TXD-leitung des Mega8515 kannst du dir dafür sparen (also die, auf der der Mega32 zuhört). Gruß, Sebastian
Hallo Sebastian >Welche Software-version verwendest du denn? Mit welchen Parametern? >Poste am besten mal deine param.h und wenn du hast auch ein Datenblatt >des Displays. LCD Controller für 320x240 LCD mit UART Version 1.11 >und wenn du hast auch ein Datenblatt Datenblatt habe ich leider nicht gefunden nur dass hier aus Tread Pollin Display Optrex F51154NF-FW-AA >Autor: Benedikt K. (benedikt) (Moderator) >Datum: 19.08.2009 11:55 >Die sichtbare Fläche beträgt übrigens etwa 160x69mm, also das Display >ist recht groß. >Hier gibts weitere Infos: >http://www.goldmine-elec-products.com/prodinfo.asp... >http://pccar.ru/showthread.php?t=9191 >Den 6x3 Treiber ICs nach (je 80 Ausgänge), hat das Display wie von mir >vermutet entweder 480x200 oder 480x240 Pixel. >Die Touchscreenmatrix müsste 12x8 Felder haben, wenn ich das richtig >sehe. >Da scheint wohl irgendwo ein Lager ausgeräumt worden zu sein, die Dinger >gibts überall. >Autor: Eike J. (Gast) >Datum: 30.11.2009 19:06 >nachdem ich mich nun lange genug mit der Ansteuerung des Displays >gequält habe, wollte ich es hier einmal kurz erläutern: >Wie Norbert schon geschrieben hat, sind die Anschlüsse: >4=Vdd (+5V) >5=X3 >6=X2 >7=X1 >8=X0 >9=Vss (GND) >10=Vee (-25V) >11=Display off (invertiert, also mit nem Pullup auf Vdd ziehen) >13=CP >14=LOAD >15=FRAME >Nun zur Ansteuerung mit einem Mikrocontroller. >1. die 4 Bit ausgeben (CP low, LOAD low, FRAME high) >2. CP high (die 4 Bit bleiben natürlich, LOAD low, FRAME high) >3. die nächsten 4 Bit ausgeben (CP low, LOAD low, FRAME high) >4. CP high (die 4 Bit bleiben natürlich, LOAD low, FRAME high) >das solange bis die zeile voll ist, also 120 mal, da es 480 Pixel sind. >Wenn die Zeile voll ist, wird nach den letzten 4 Bit CP auf high gezogen >und danach auch noch LOAD auf high (CP low, FRAME high). Dadurch springt >der "Cursor" in die nächste Zeile und ihr könnte die wieder >vollschreiben. >wenn alle 240 zeilen voll sind, muss wieder in die erste zeile >gesprungen werden, dazu wird FRAME auf low (rest auch auf low) gezogen. >ich hab bevor ich den frame auf low ziehe auch noch einen zeilenumbruch >gemacht, ob das nötig ist, weiß ich nicht, aber es stört auch nicht. >jetzt geht der spaß wieder von vorne los. >und zwischen jedem "schaltvorgang" hab ich 1 microsec delay zwischen, >ist aber nur ausprobiert, damit gehts aber auf jeden fall.. >ich hoffe mit dieser anleitung gehts bei euch etwas schneller als bei >mir..^^ >Gruß Eike Habe die Schaltung auf Lochrasterplatte aufgebaut, funktioniert bis auf die Auflösung(480X240Pixel werden angezeigt, aber die obere und untere Hälfte werden gleichzeitig beschrieben) und eben die Sache mit den Steuerzeichen. Ich habe bei meinen Schaltungen bis jetzt nur mit RXD und TXD gearbeitet. >Du musst das RTS(BUSY)-Signal (PD2) noch zu deinem Master controller >führen und dort Abfragen. Ich schalte also RTS auf TXD vom Master? Hast du für die Busy Abfrage einen Code-Schnipsel vieleicht mit ner kleinen Erklärug? Gruss Karl
Ganz kurz: Du musst mindestens Version 1.2 nehmen, nimm aber am besten die aktuelle. 8-Grastufen musst du dann halt in der param.h deaktivieren. So beim Überfliegen ist mir sonst nichts aufgefallen. Sebastian
So, jetzt hab ich wieder mehr zeit. RTS vom 8515 legst du auf einen beliebigen (als Eingang konfigurierten) Pin des Masters. Rx vom 8515 kommt auf Tx vom Master. Tx vom 8515 bleibt offen. Die Funktion von RTS ist im pdf aus der zip ganz gut erklärt: Hinweise zur Ansteuerung: Aufgrund der teilweise ziemlich rechenintensiven Grafikbefehle sollte der RTS/Busy Ausgang vor dem Senden eines Befehls abgefragt werden. Der Controller verfügt zwar über einen 256 Byte Befehlspuffer, aber auch dieser ist irgendwann voll, wenn mehrere aufwendige Befehle ohne Pause gesendet werden! Solange der RTS/Busy Pin Low ist, kann man gefahrlos mindestens 64 Bytes senden, da RTS/Busy aktiviert wird, wenn der Puffer zu ¾ gefüllt ist. Man braucht also nicht vor jedem Byte RTS/Busy zu prüfen, sondern es reicht einmal vor jedem Befehl (falls dieser kürzer als 64 Bytes ist.) Dein Display hat so weit ich das mitbekommen hab aber nur 200 Zeilen, also eine Auflösung von 200*480. Wenn ich nicht wieder nen Denkfehler drin hab ist deine Softwareversion wie gesagt zu alt. Du musst dann eine nehmen, die einen virtuellen Bildbereich unterstützt. In jedem Fall wird es nicht schaden, die aktuelle Version zu verwenden. #define GRAY8 musst du dann halt auskommentieren. Und schreib bitte, obs dann funktioniert. Am Besten mit Bild. Bin am Überlegen, ob das Display was für mich wäre. Gruß, Sebastian
>In jedem Fall wird es nicht schaden, die aktuelle Version zu verwenden. habe es mit der Vers. 1.2 und 1.3 versucht.Das Ergebnis ist das Gleiche.Dann bin ich beim Prüfen mit VSS an D0 gekommen.Das hat mich den BC327 und vermutlich das Display gekostet.Habe ein Neues bestellt.
Servus, nachdem mir das Bilder laden immer zu langsam ging, hab ich mal die Software noch ein wenig aufgebohrt. Ich muss zugeben, dass das ganze ein wenig aus dem Ruder gelaufen ist, denn die Timings sind jetzt schon sehr hart, aber ich wollte dann einfach sehn, was möglich ist. Mit der Angehängten Version kommt man bei 3 bit/Pixel Vollbildern auf sagenhafte 5 Frames pro Sekunde! Baudrate ist dabei 2MBaud. Die BSY-leitung verhält sich jetzt anders: Für jede fallenden Flanke von BSY muss man ein Byte senden. Das Byte muss nicht sofort kommen (sollte es aber), aber man darf auf keinen Fall eine Flanke übersehen. Zwischen zwei Flanken liegen mindestens 1,5µs, also 24 Takte bei 16MHz. Das kann man auch nicht wirklich durch den Master ausbremsen. Lediglich die Framerate sinkt, wenn man langsamer sendet. Im Mittel werden die Flanken auch seltener, aber mehr als 1,5µs kann man nicht garantieren. Außerdem muss man nach einem Bild mit 3 bit immer 2 Dummy-Bytes senden. Ich empfehle 0x0, dann auch gerne ein paar mehr Bytes (falls unterwegs was passiert sein sollte). Die Parameter der angehängten Version sollte man möglichst nicht ändern, insbesondere die Baudrate sollte wohl mindestens auf 1MBaud stehen. Zwar werden viele einstellungen funktioniere, ich hab mir aber keine Gedanken über andere Parameter gemacht, kann also nichts mit sicherheit sagen. Wie das ganze funktioniert? Der Software-Fifo ist ausgebaut worden. Statt dessen verlasse ich mich auf den Hardware-Puffer der USART. Im Normalen Betrieb wird immer ein Byte im Puffer vorgehalten. Ruft das Programm ein neues Byte aus dem Puffer ab, so wird direkt das nächste durch fallende Flanke auf BSY bestellt. Wenn der Controller zum Anzeigen eines 3-bit Bildes kommt, werden zuerst durch 2 fallende Flanken zwei weitere Bytes bestellt. Eines davon landet im zweiten Byte des Hardware-FIFO, das zweite bleibt im Shift-register. Durch die 3 Byte Puffer ist es möglich, die Zeit während dem Display-intterupt zum senden von 2-3 Byte zu nutzen. Zwischen 2 Interrupts werden dann nochmal 3-4 Bytes übertragen und 6 Bytes verarbeitet. Ungefähr - im Mittel. Wenn das Bild fertig übertragen ist muss noch der Puffer geleert werden. Man könnte natürlich "einfach" beim verarbeiten der letzten beiden Bytes keine Flanke erzeugen. Ich habs mir hier aber leicht gemacht und lese zwei Dummy-Bytes aus. Der inhalt ist egal, aber der Sender muss halt zwei zusätzliche Bytes senden. Viel Spass damit. Vielleicht kanns ja jemand gebrauchen. @Benedikt: Wenn du mir eine große Freude machen willst: Lass doch mal mit 5fps 3bit Farbe ne Filmsequenz über das Display laufen :-) Viele Grüße, Sebastian (der von den Graustufen :-)
Vielleicht noch als Hinweis für alle, die's mal ausprobieren wollen: Ich hab auf meinem Master einen Interrupt der auf fallende Flanke von BSY triggert. Das ist auch der einzige Interrupt am Master, sonst würden wohl die Latenzen zu groß. Bei jedem Auslösen zählt eine Variable um eins hoch, sie zählt also, wie viele Bytes zu senden sind. In der Main-loop schau ich dann, ob diese Variable Null ist. Wenn nicht, wird, sobald UDR leer ist, ein byte gesendet und die Interrupt-Variable wieder um eins verringert. Sonst passiert auf meinem Master auch nichts. Viel rechenzeit dürfte auch nicht mehr übrig sein ;-) Gruß, Sebastian (der sich auf Kommentare freut :-)
Ist ja ein super Projekt. Vielen Dank! Hat jemand noch Interesse an Leerplatinen (DIP4-Version)? Werde in Kürze welche in Auftrag geben. Preis dürfte so bei ca. 8 Euro pro Stück liegen + Versand. Schöne Grüsse
@Günter S. (varda) war die Platine hier schon mal ausgestellt? Brauche 2 Stück, allerdings sollte der S-Ram in SOJ 28 drauf. Also, wenn Du noch routest, steuere ich die S-Rams sogar bei. IS61C256AL 12ns. Wigbert
@Wigbert Die Platine wurde hier noch nicht ausgestellt. An der Platine selbst möchte ich selbst keine Änderungen vornehmen. (Möchte mich nicht extra in Eagle einarbeiten - mache alles in KICAD) Sollte sich jemand aber finden, der die Änderungen vornimmt wäre es auch ok! (hätte auch noch eine Änderung .... der 12 pol. Flexprintanschluss zusätzlich als Stiftleiste rausführen) Günter
Mist, Günter, ich dachte Du nimmst mir die Arbeit ab. Also meine Platine wäre 100x80 hätte zusätzlich eine Adapterplatine Stiftleiste-Flexprintstecker für NANYA. Allerdings muss ich den S-Ram noch routen. Könnte dann bei Interesse die S-Rams für 1 Euro zulegen. Um ein ordentlichen Preis zu erhalten sollten ca.20 Platinen zusammenkommen. Das ganze sähe dann etwa so aus, aber mit Lötstopplack Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Wigbert
Ist der Spannungswandler dan schon drauf, oder ist der auch zum aufstecken wie oben? Gruß, Jens
Hallo, ich würde auch noch eine nehmen Gruß Patrick
Hallo, Günter war zuerst da. Also steht ihm auch die Sammelbestellung zu. Ich wollte nur helfen, nicht wegnehmen. Mit dem Spannungsregler ist Ansichtssache. Hatte ich doch neulich ein Pollin GLCD mit 320x240 Pixel mit positiver Kontrastspannung. Da wäre es Sinnvoller die Kontrastspannung extern zu erzeugen. Raufpassen tut die Spannungsversorgung noch auf dem Board. Wäre kein Thema. Genauso das Adapterboard, das lässt sich dann an das GLCD anpassen. So, jetzt hat aber Günter erstmal das Wort. Wigbert
Ich sage mal so ... Änderungen am Layout bzw. Schaltung würden bestimmt einige Zeit in Anspruch nehmen. Jeder hat bestimmt so seine Änderungswünsche. Sind event. nicht leicht auf einen Nenner zu bringen. Ich denke mal, mit dem Layout und der Schaltung aus DIP4.zip dürften doch mehr oder minder alle zufinden sein.
@ Gunter S. wäre wohl da alles drauf.OK Kannst mich aber streichen. Ich mach dann mein eigenes Board. Wigbert
Hallo @ alle mal! Ich wuerde mir unheimlich gern diese Ansteuerung fuer das NANYA Display bauen. Es waere ideal wenn es dann im Endeffekt ueber Funk ansprechbar waere. Kann mir da jemand bitte helfen? 1) Welches Board Layout stimmt jetzt und ist bereit zum aetzen? (EAGLE 4.x) 2) Was benoetige ich alles fuer Bauteile? In den Beitraegen wurde die oefters ausgebessert... 3) Also kann man die CCFV Schaltung als Spannungsversorgung nehmen? 4) Ist es unabhaengig welchen SRAM man nimmt? Bei dem Layout kann man ja nur eine beschraenkte Anzahl an SRAMs nehemen oder? 5) Brauche ich sonst noch was? Ich bitte drum, kann mir wer bitte helfen? Oder bitte verweise auf die dateien oder so? Ich danke echt im Voraus!
Waere dieser SRAM Baustein passend? http://shop.conrad.at/ce/de/product/167193/UM61256K-2061256AK1261C256AH12NL/0205314 Thx im Voraus!!
Hey, genau den hab ich auch gefunden. Leider bin ich mit der Leiterplatte noch nicht so weit. Aber wenn der UM61256CK-20 gehen sollte wäre das echt prima. Habe da jetzt 10Stück rumliegen. Gerne auch ein paar zum Abgeben!
Hätte jemand noch eine Platine mit der DIP4 Version über ? Ich würde da noch gern 2 nehmen wenn es geht. Natürlich gegen Bezahlung. Danke !!!
Hallo, ich hab ein kleines Problem mit dem Code, wenn ich ihn im AVR Studio öffne und compilieren will scheinen die Funktionen welche die Ausgabe auf das Display steuern zu fehlen welche laut dem aller ersten Post in Assembler geschrieben sind, ich konnte jedoch auch keine Datei in dem Archiv finden welche Assebler-Kommandos (inline-Asselbler o.ä.) enthält. Muss ich diese Datei extra wo runterladen? oder handelt es sich bei der .bin evtl. um eine Precompiled Variante? Danke, Thomas
Hast du auch die letzte offizielle Version von hier Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" genommen? Da gibts ne .aps. Wenn du die im Studio öffnest sollte es eigentlich funktionieren. Die Software aus dem ersten Post ist mittlerweile veraltet und lässt sich nicht so schön einfach im Studio öffnen und compilieren. Sebastian
Danke, hatte wohl die falsche ZIP-Datei entpackt ;-)
Angehängte Dateien:
-
DSCF0113.JPG
900 KB -
DSCF0109.JPG
930 KB
Habe das Projekt in Kicad umgesetzt. Die Platinen sind zwischenzeitlich auch schon gekommen. Gestern gleich aufgebaut - Mit LCD von Pollin 480x200; geht wunderbar. Benedikt - einfach ein tolles Projekt von Dir ! Super
Ich finde das toll, was du da ihr da auf die Beine gestellt habt (besonders Benedikt)! Eine Frage: Funktioniert die Schaltung auch mit dem Display WINTEK WD-H3224V von Pollin (Best. Nr. 120 506)? Das hat doch eine positive Kontrastspannung, wie muss ich den Teil mit dem Schaltregler abändern, dass es funktioniert?
Hallo Günter, ich hätte Interesse an 2 Platinen.Hast du noch welche abzugeben? Wenn ja wie kommen wir dann zusammen?
Hallo Karl, schreibe mir halt eine Nachricht, dann können wir Email austauschen. Platine kostet 10 Euro pro Stück (mein Selbstkostenpreis) + Versand
Angehängte Dateien:
-
GLCD_Testb..jpg
370 KB -
Platine.JPG
53 KB
Hi, meine Version mit ein 12ns S-Ram. Teilweise in SMD. Eine Adapterplatine mit FFC-Buchse sorgt für ein ordentlichen NANYA-Displayanschluss. Wigbert
Hallo Wigbert, schöne Platine. Wegen RAM - Habe auf meiner Platine normale RAM mit 70 ns. Laufen auf ohne Waitstates. Sogar bis 20 MHz, wenn ich den AVR mit 20 MHz Quarz betreibe.
Hallo Günter Deine Platine muss sich aber auch nicht verstecken. Mein Board hätte vielleicht kleiner werden können. Wobei, in der Höhe stimmen die Befestigungslöcher mit dem Display. Bei S-Rams kann sicher etwas Glück hilfreich sein. Meine S-Rams sind so nun mal vorrätig. Die Platine lief sofort, und seltsamerweise stimmte sogar der Kontrast sofort mit meiner Widerstandsauswahl. Wigbert
Hallo, Ich wollte immer noch den mega162, statt dem mega8515 verwenden, da ich auch noch zufällig welche davon rumliegen habe (mal mit mega168 beim Bestellen verwechselt). Mit den zusätzlichen PWM Channels, wollte ich z.B. die LED Hintergrundbeleuchtung dimmen. Da ich SMDs verwende kann ich sie jedoch nicht einfach wechseln. Meine Frage: Wie kommt der Wert "DDRAM 1024" zustande? mega8515: "To the Application software, the external 32 KB memory will appear as one linear 32 KB address space from 0x0260 to 0x825F. This is illustrated in Figure 17." mega162: "To the Application software, the external 32 KB memory will appear as one linear 32 KB address space from 0x0460 to 0x845F." Zum Wechsel zwischen m8515/m162 hatte Benedikt geschrieben: "Geändert werden muss dazu nur die Zeile #define DDRAM 1024. Diese muss auf den Ende des internen und Beginn des externen RAMs also auf 0x500 = 1280 gesetzt werden." Also meine zweite Platine der Schaltung (bei Bilex machen lassen) ist fertig aufgebaut, und ich glaube auch nicht, dass durch einen falschen DDRAM -Wert die Hardware kaputt geht, aber ich trau mich nicht sie anzuschliessen, da ich auf der ersten auch einen mega162 aufgeloetet hatte, der wahrscheinlich schon defekt war. [ Habe schon so drei Dutzend mega8/48/32 "verarbeitet", doch dieser war mein erster kaputter, und das Smdteil wieder rauszukriegen macht die Platine nicht schöner.] Ich bezweifel ja auch nicht Benedikts Angabe, der 1024er Wert funktioniert ja bei mir mit dem sicherheitshalber eingesetzten mega8515 ja sehr gut - wie bei allen Anderen. DANKE für das tolle Projekt, doch verstehen tue ich auch den schon nicht, daher schon gar nicht den 1280er Wert. Kann mir da geholfen werden?? Ich programmiere ja nur in C, nicht Assembler, und Speicherverwaltung sollte man schon etwas kennen, konnte mich aber bisher davor drücken, und hatte auch nie Probleme bemerkt. Vielen Dank für eure Hilfe, tolles Forum, Philipp
Hallo allerseits. Wollte mal nachfragen, ob noch jemand eine Platine abzugeben hat? Danke. Gruß Jörg
Hallo, ich habe den Controller nachgebaut, leider sieht man auf dem angeschlossen Display garnichts. (Hitachi SP14Q006-T) Mit dem Oszi sieht man z.B. auf den SRAM-Leitungen Rechtecksignale, d.h. der Controller tut irgendwas. Ich erwarte eigentlich dieses Testbild, oder muss ich dem Display erst Daten senden? Außerdem bin ich mit bei der Verkabelung der Anschlüsse V0 und VEE nicht ganz sicher. Ich habe an VEE die -21 Volt angeschlossen, V0 ist über ein Poti als Spannungsteiler bei -17 V. Was muss ich mit der AC-Leitung des Controllers machen? Gruß, Alex
Im Datenblatt des SP14Q006-T habe ich eine VDD-V0 von +21V gelesen, allerdings ist weiter hinten eine Beispielschaltung mit einem Poti zwischen +5V und -22V (Mittelabgriff am V0). Hmm AC müßte eigentlich an FLM vom Display gehen.
Hallo Hab da mal ne Frage: Ist es auch möglich statt der UART-Schnittstelle eine parallele Schnittstelle zu integrieren? PortB ist ja rein theoretisch noch frei. Bin in C leider nicht wirklich involviert. Sonst hätt ich es schon geändert. Der Uart bremst die Anzeige meiner Meinung nach ganz schön aus. Ich benutze momentan die neuste Version (8-Graustufen) mit 666666Baud. LG Steffen
Sollte gehen. Du müsstest halt den UART-Fifo umbaun, so dass er sich die Daten vom Port holt. Statt dem UART-interrupt nutzt man dann den INT0 (wo momentan BSY drauf hängt. BSY müsste man halt auf PD0 oder PD1 verlegen. Im Interrupt muss du dann das Daten-senden auf jeden Fall gesperrt sein, sonst gehen daten verloren. Auch muss dein Master dann unverzüglich auf BSY reagieren, eben weil sonst daten im Interrupt verloren gehen. Was für eine Performance erwartest du denn? Und welche Version verwendest du genau? Die letzte von Benedikt? Die letzte von mir läuft auch mit 2MBaud. Mit 666666 Baud bist du über die UART ja schon auf 2.3 fps beschränkt. Mit meiner letzten schafft man ca. 5fps. Wenn dir das nicht reicht oder das Timing für den Master zu hart ist kann ich dir noch ne Version mit bis zu 7fps anbieten. Das ist dann das theoretische Maximum der UART. Allerdings hab ich die Anpassungen hier etwas inkonsequent vorgenommen. Was ich brauch funktioniert, für den rest kann ich nicht garantieren. Bei mir bremst mitlerweile auch der Master. 7fps schaff ich in der Praxis nicht. Vielleicht ginge mehr, wenn man einfach auf einen Port schreiben könnte, aber drauf zählen würde ich nicht, weil du dann wieder auf dein Display hören musst. Sebastian
Hi Sebastian Danke für die schnelle Antwort. Ich werd es mal versuchen, doch wie gesagt, meine C-Kentnisse sind sehr rarr. Hab gesehen dass der Grafikcontroller für die 640x480 LCD´s ja auch anfangs mit einer parallelen Schnittstelle versehen war. Wenn ich nicht weiter komme meld ich mich wieder.. LG Steffen
Ach ja, ich brauch ja eigentlich auch nur den Textmodus (möglichst in 8 Graustufen) und den Befehl 16 (Bild laden) in S/W. Vielleicht kann man ja die restlichen Funktionen entfernen.. Steffen
Der Textmodus wird aber doch nicht zu langsam sein, oder? Bei 666666Baud sind das immerhein 83 Displayseiten pro sekunde. Bzw. wenn das nicht erreichbar ist dann bringt auch ein paralleles interface nichts, weil einfach das Verarbeiten der Daten so lange dauert. Auch bei S/W-bildern kann man sich ausrechnen, dass rein von der UART her bei 666666Baud fast 7fps drin sein müssten. Die schafft man auch nicht, weil nämlich die datenverarbeitung zu langsam ist. Zumindest bei den Bildern könnte man die Verarbeitung verbessern. Das sind dann aber tiefgreifendere Änderungen. Jedenfalls wird dir das parallele Interface (wenn ich mich nicht verrechnet hab) nichts bringen solange du nicht teile der Datenverarbeitung grundlegend änderst. Sebastian
Angehängte Dateien:
-
pic01.jpg
190 KB
Ja, es ging mir hauptsächlich um den Grafikaufbau. Text ist kein Problem. Ich teste jetzt gerade mit einem Master mit 666666Baud. Das Resultat ist doch sehr gut. Nur mein später anvisierter Master läuft mit 10Mhz und da ist eine max. Baudrate von 250kBaud drin. Deswegen hatte ich den Parallelbetrieb angepeilt. Es soll übrigens mal ein 2-Kanal-DSO mit 2xADS831 werden. Mit dem AVR-eigenen ADC´s funktioniert es schon recht gut. Nur sind die nicht brauchbar für höhere Frequenzen. LG Steffen
Ich bin endlich auch einmal dazugekommen, die Schaltung nachzubauen. Ich verwende das Wintek-Display von Pollin (laut DB hat das eine positive Kontrastspannung, kann das sein?). Gibt es ein kleines Testprogramm für den Mega8515 (also den LCD-Controller selbst), mit dem ich die Funktion überprüfen kann? grüssse w.
Wegen der Kontrastspannung schau mal hier Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" da haben einige das Wintek display verbaut. Da hat sicher auch jemand über die Kontrastspannung geschhrieben. Die Firmware zeigt standartmäßig automatisch ein Startbild an. Wenn alles läuft sieht man also auch was, ohne dem Controller daten zu schicken. Dein Fehler könnte allerdings in der Schaltung an sich liegen. Die erste Zipdatai die hier hochgeladen ist enthält einen Fehler im Schaltplan. Nimm immer die letzte von Benedikt hochgeladene Version. Das ist im allgemeinen die mit den wenigsten Fehlern. Viele Grüße, Sebastian
Ich habe die aktuellste Version nachgebaut, ich hoffe, da sind keine Fehler mehr drin. Werde nochmal meinen Aufbau überprüfen.
Hallo nochmal. Ich bin nun wieder am Arbeiten an diesem Projekt... Die Textausgabe auf dem Display ist wirklich gut. Dennoch habe mit 3 Terminal Programmen versucht auf dem Display die im Beispiel genannten "Codes" probiert, leider ohne erfolg. -Bzw. je nach Daten sende Art auch mit Kryptischen Zeichen. Wie sind denn die Fusebits als Hex? Einen MEGA8515 habe ich schon verfust... Mit was sendet ihr die Daten auf den Controller? Gibt es eine Beispielschaltung, o.ä.? Mein Adapter besteht aus Serielle Schnittstelle -> MAX232 -> MEGA8515. Wenn ich das Display mit Zeichen fülle, ändert sich der Hintergrund. Sprich viele "O" und das Display wird dunkler, viele "i" oder "l" und das Display wird heller. Was kann ich dagegen tun? MfG Denis
Was genau funktioniert nicht? Kommt immer was falsches am Display an, oder nur, wenn du versuchst, die Grafik-funktionen zu nutzen? Allgemein macht mir dein Beitrag einen sehr kaotischen eindruck. Wenn das Testbild angezeigt wird passen die Fuses erstmal bzw. sind zumindest nicht vollkommen falsch. Wenn Text so angezeigt wird, wie du ihn sendest funktioniert auch die UART-kommunikation, dann liegt der Fehler daran, dass du die Kommandos falsch eingibts. Die Fuses sind eigentlich relativ unkritisch. Der AVR muss halt mit 16MHz laufen. Brown out kann man anschalten, wenn mans nicht tut läuft der Controller aber trotzdem, muss also nicht sein. So weit ich mich erinner wars das auch schon. Glaube aber, hier im Thread wurde schonmal über die Fuses geschrieben. Und die UART läuft halt mit 1 Startbit, 8 Datenbits, ohne Paritätsbit und ein oder zwei Stopbits - letzteres ist egal, da der AVR das zweite Stopbit einfach ignoriert. Mit den Einstellungen sollten eigenltich Daten am AVR ankommen. Wenn nicht schau mal in die Artikelsammlung. Da gibts so weit ich weiß ne Anleitung zum UART debuggen. Ich sende meine Daten von einem zweiten AVR aus zum Display. Funktioniert bei mir wunderbar. Sebastian
Hallo. Wenn ich Text eingebe, kommt der an, aber das Testbild verschwindet nicht. Dazu nutze ich HTERM. Ich sende die Daten in ASCII. Wie sende ich die befehle? Kommen irgendwelche Anführungszeichen oder Vorzeichen vor die Kommandos?? Gibt es für den Mega8 oder Konsorten ein kleines Beispielprogramm? MfG Denis
Na dann funktioniert doch alles. Fuses und UART einstellungen müssen zumindest halbwegs passen, sonst würde der Text doch nicht ankommen. Die Kommandos musst du als Zahlenwerte schicken. Ich kenne HTERM nicht, aber da kann man sicher irgendwo einstellen, dass es Dezimal/Hex/Binärwerte schicken soll. Und dann gibst du halt einfach die Zahlenwerte aus der Dokumentation ein. Dass der Startbilschirm nicht verschwindet ist normal. Der wird nur überschrieben. Wenn er komplett gelöscht werden soll musst du das über den passenden Befehl anweisen.
Hallo, würde nicht ein ATMega1284 besser sein? Ich Frage wegen SRAM und Speicher? Danke im voraus für Konstruktive Antworten.
Der mega1284 hat auch nur 16 kByte SRAM, ein 320x200 Bild mit 2 Bit Farbtiefe braucht genau diese Menge. Bleibt also nichts mehr fürs Programm übrig.
Angehängte Dateien:
-
LCD_Test.jpg
100 KB
Hallo Sebastian, ich hoffe Du schaust hier hin und wieder nochmal rein! Nach meiner Kalenderuhr (die übrigends in der Zwischenzeit ein Gehäuse bekommen hat und immer noch super läuft) versuche ich dieses Projekt zu verstehen und nachzubauen. Allerdings wie Du ja weißt, in Assembler. Wäre schön, wenn Du mir auch diesmal helfen könntest. Ich habe die Schaltung wie von Benedikt vorgegeben, nachgebaut (meine ich jedenfalls). Statt eines 8515 habe ich allerdings einen ATMega162 verbaut. Um mich der Sache langsam zu nähern, habe ich Benedikts Programm gnadenlos zusammengestrichen und nur das unbedigt Nötige behalten. Geändert habe ich natürlich YMin, da der interne Speicher des 162 bis 0x4FF geht. Angezeigt werden soll nur ein kleines Rechteck mit einem einzigen Farbton. Leider zeigt das Bild aber etwas anderes als erwartet und vor allem läuft es durch (siehe Bild). Hast Du dafür eine Erklärung??
Hat noch jemand eine Platine übrig? Würde sie gern kaufen.
@Spätkommender: Leider nicht. Hatte nie ne geätzte @Bruno >Ich habe die Schaltung wie von Benedikt vorgegeben, nachgebaut Gleich mal vorsorglich: Das im ersten Beitrag angehängte zip hat einen Fehler im Schaltplan. In der letzten Offiziellen Version gibts übrigens (neben einem korrekten Schaltplan) auch 8 Graustufen falls du das noch nicht gesehen hast. Heut ists bischen spät um mir das genauer anzuschaun (morgen dann), aber warum nutzt du nicht das Projekt einfach wie es ist als Grafikkarte und steuerst die über einen weiteren AVR per UART an? Das funktioniert sehr gut und du brauchst an diesem Projekt nichts mehr zu ändern. Alternativ wäre es doch eine gute Gelegenheit endlich mal C zu lernen. Früher oder später brauchst du es sowieso. Viele Grüße, Sebastian
Hallo Sebastian, super, daß du dich so schnell gemeldet hast!! Das mit dem Fehler im ersten Schaltplan hatte ich schon registriert. Da es mir in erster Linie darum geht, die Schaltung und das Programm richtig zu verstehen, hilft mir die Übernahme des kompletten Projektes wenig. Auch deine Version mit den 8 Graustufen habe ich gesehen, aber das wäre dann der nächste Schritt. Dein Hinweis auf C ist natürlich völlig richtig und mir wird wahrscheinlich gar nichts anderes übrig bleiben, wenn ich das gesamte Projekt verstehen will. Im Moment bin ich aber noch bei der LCD Routine (die ja sowieso in ASM geschrieben ist) und der trickreichen Ankopplung des externen RAM. Zu meinem Problem selbst noch der Hinweis, daß ich in der Zwischenzeit noch weitere XL und XH Werte getestet habe. Dabei sieht es so aus, als würde XL von der rechten Seite gezählt und nicht von der linken??? Wenn die Höhe des Rechtecks unter 10 Pixel liegt, dann sieht man einzelne Balken. Ich hoffe du kannst daraus irgendwelche Schlüsse ziehen. Schon im Voraus herzlichen Dank für die Mühe! Gruß Bruno
Hallo Sebastian, ich meine ich kann dir die Fehlersuche im Code ersparen. Ich habe jetzt meinen gesamten Programmteil weggelassen und nur aus der Routine von Benedikt heraus ein Pixel unmittelbar vor der Ausgabe auf 1 gesetzt. Da auch dann das Bild durchläuft, kann es meiner Meinung nach nur noch an der Hardware liegen. Ich werde jetzt mal alle ICs tauschen. Gruß Bruno
Ich glaube nicht, dass das ICs tauschen was hilft. Wenn du einen Hardware-fehler hast, dann wahrscheinlich in der Verdrahtung. Um das zu prüfen wird es aber geschickter sein, die Sourcen von Benedikt nur auf den anderen Controller anzupassen. Dann hat man eine ganze Menge mögliche Fehlerquellen weniger. Zu deinem Vorhaben den Code zu verstehen: Das aufregende ist sowieso alles in Assembler geschrieben. Die Ausgaberoutine hast du ja schon gesehen. Dann gibts noch ein paar Routinen um Daten in den RAM zu schreiben, die auch quasi alle in Assembler geschrieben sind. Was dann in C passiert sind höhere Aufgaben, wie z.B. der Bresenham-Algorithmus um linien zu zeichnen. Oder die UART-kommunikation. Aber das ist eigentlich alles nicht mehr so aufregend. => Lass die sourcen wie sie sind (abgesehen von der Anpassung auf den anderen Controller), versuch den ASM-teil zu verstehen, schau dir an was im C-Teil gemacht wird und überleg dann, welche Anpassungen du machen musst. Gruß, Sebastian
@Spätkommender Schick mir mal eine Mail Wigbert
Hallo Sebastian, wie du schon angekündigt hast, hat das tauschen der LCs nichts gebracht. Auch die Verdrahtung habe ich gründlich geprüft und nichts feststellen können. Auch in meinem ASM Code konnte ich bis jetzt keinen Fehler entdecken. So versuche ich deiner Empfehlung zu folgen, das Original C-Programm zum Laufen zu bringen. Für einen C Anfänger ist dieses komplexe Programm natürlich eine gewaltige Herausforderung. Da werde ich sicherlich kleiner anfangen müssen. Es ging schon damit los, daß ich die main.elf Datei zwar öffnen konnte, aber nicht bearbeiten (alle Dateien wurden als "read only" angezeigt). Das konnte ich durch Anlegen eines neuen Projektes und Einbinden der Orginaldateien lösen. Auch das Anpassen des Speichers durch eine Änderung des Parameters DDRAM bekam ich noch hin. (Wenn ich es richtig interpretiere hätte ich wahrscheinlich auch mit dem Ursprungswert leben können!). Beim Build and Run meckert er aber nun, daß RXCIE und RXEN nicht definiert sind. Wahrscheinlich hängt es damit zusammen, daß der AT162 zwei USARTs hat und der AT8515 nur einen. Wie und wo ich aber das ändern kann, habe ich wirklich keine Ahnung. Ich hoffe du kannst mir mit einem einfachen Hinweis weiterhelfen. Ich weiß natürlich auch nicht, ob der Debugger im weiteren Verlauf nicht noch neue Probleme findet. Schon mal herzlichen Dank für deine Hilfe! Gruß Bruno
Das includefile (m8515def.inc) hast du durch das für deinen Controller getauscht? Wenn 162er wirklich 2 uarts hat haben die UART-bits jeweiles noch ein 0bzw. 1 im namen. Aber eigentlich sollte die UART-lib das schon selbst abhandeln, wenn du das includefile getauscht hast. Wenn nicht (benedikt hat recht viel an der lib rumgebastelt), dann musst du halt die Bitnamen ändern. Der Compiler sagt dir ja eigentlich, wo es hakt.
Angehängte Dateien:
-
LCD.JPG
110 KB
Hallo Sebastian, mit jeweils einer 0 dahinter und einigen anderen Anpassungen habe ich tatsächlich eine hex Datei bekommen. So weit so gut. Jetzt weiß ich zumindest, daß es offensichtlich an der Hardware liegt. Nur leider finde ich nichts. Kann es daran liegen, daß ich als FlipFlop keinen HC Typ habe, sondern einen F? Oder kannst du aus dem Bild etwas anderes ableiten? Gruß Bruno
@Bruno >> Geändert werden muss dazu nur die Zeile #define DDRAM 1024. >> Diese muss auf den Ende des internen und Beginn des externen RAMs also >> auf 0x500 = 1280 gesetzt werden. Hast du das berücksichtigt ? Ich benutze auch einen M162 und es funktioniert mit Benedikt's code einwandfrei.
Hallo Helfender, herzlichen Dank für den Tip, aber das habe ich schon berücksichtigt. Ich habe sogar 0x600 genommen, da Benedikt auch etwas Luft gelassen hat. Der 8515 Speicher geht ja nur bis 0x260. Gut zu wissen ist aber, daß der 162 sonst keiner weiteren Einstellungen bedarf.
Sorry, ich habe mir nicht den ganzen Thread durchgelesen. Das FF als "F" kann laut Datenblatt 90MHz, dürfte also auf jeden Fall schnell genug sein. Aber irgendwie sieht es aus als ob dein Takt nicht stimmt. >> Pin1 vom HC157 an Pin9 des HC74 >> am hc74 pin8 und pin12 verbinden Diese Änderung hast du auch berücksichtigt ?
wie muss man das rechnen um auf diesen wert von 1280 zu kommen
>> auf 0x500 = 1280 gesetzt werden.
für eine antwort wäre ich dankbar
mfg
@ Helfender Ja, die Änderung habe ich berücksichtigt. Allerdings brauche ich keinen AC Anschluß und daher habe ich das erste FF mit entsprechend geänderten PinNr. benutzt. Pin5 (FF) an Pin1 (HC157) und Pin2 (FF) an Pin6 (FF). @ kay Die 0x500 ergeben sich aus dem Datenblatt des AT162. Der interne Speicher bei normaler Konfiguration (d.h. nicht im AT161er Modus) geht bis 0x4FF. Der externe Speicher kann also erst bei 0x500 beginnen.
hallo Bruno, Der externe Speicher kann also erst bei 0x500 beginnen. ja das ist mir klar ,nur ich meinte wie kommt ihr auf 1280 sind ja 0x500 bloss wie kommt mann auf die 1280 das ist mir nicht ganz klar mfg
Hallo kay,
>> wie kommt ihr auf 1280 sind ja 0x500
das 0x vor 500 sagt, daß es sich um einen hexadezimalen Wert handelt. Du
nimmst dir also einen Rechner, der hexadezimal rechnen kann, gibst 500
ein und wandelst es in dezimal um, dann bekommst du 1280.
@Bruno Ich hänge dir mal mein hex File für den M162 ran. Da sind keine Änderungen von mir drin, nur die Anpassung auf den M162.
Hallo Helfender, da ich im Moment unterwegs bin, kann ich erst zum Ende der Woche testen. Bis dahin schon mal herzlichen Dank.
Angehängte Dateien:
-
SANY0128.jpg
140 KB
Hallo Helfender, leider hat auch deine Datei keine Änderung gebracht. Es liegt also eindeutig an der Hardware. Ich weiß nur nicht, wo ich noch suchen könnte. Die Verdrahtung habe ich schon mindestens 5 mal geprüft. Auch die Signale habe ich schon mit dem Oszi getestet. FRM, LP und CLK zeigen den erwarteten Verlauf. Eigentlich müßte ja das Bild eindeutige Hinweise liefern, aber ich kann es leider nicht deuten. Fällt dir noch was ein?
Ist das Bild statisch, oder läuft das durch? Und welches LCD verwendest du? Datenblatt? Wie hast du es angeschlossen? Wenn deine Schaltung nach Plan stimmt kann es eigentlich nur am Anschluss des LCD liegen (oder eben doch an der Software, aber ich denke mal, dass das hexfile von Helfender passen sollte). Wie schnell taktet dein AVR eigentlich? Sebastian
Angehängte Dateien:
-
Pic1.png
15 KB
@Bruno ich habe bei mir mal zum Test einen MC74F74 eingesetzt und der funktioniert ebenfalls tadellos. Kannst du also 100% ausschliessen. Danach habe ich mal meinen LA an CP,LOAD,FRAME und eine Datenleitung geklemmt. Ablauf siehe Screenshoot. Load kommt ca. alle 41µs. Frame ist ca.26µs lang. In welchem Abstand kann ich nicht sagen, dafür ist der Samplespeicher zu begrenzt.
Angehängte Dateien:
Hallo, ich hab vor, nochmals ein paar Platinen anfertigen zu lassen und in einen Shop zu hinterlegen. Neu ist der V-Regler und die Bereitschaftsanzeige. Die Platine hat in Betrieb ca 85mA so das der V-Regler weitere Platinen versorgen kann. 5V kann an 3 Stellen abgenommen werden. Preisvostellungen: GLCD_32K Platine: 10 Euro. S-Ram + sämtliche SMD-Bauteile + Speicherspule: 1,50 Euro NANYA-Adapterplatine: 0,5 Euro FFC Buchse: 1,80 Euro Für eine Erstbestellung hätte ich gerne den Bedarf gewusst. Wer interesse hat, bitte eine Mail schicken. Wigbert
Angehängte Dateien:
-
Platine_Button.JPG
53 KB -
Platine_Top.JPG
50 KB
Hi, anbei mal die Platinen. Es wird sicher jeder verstehen, das ich die Position S-Ram+ SMD + Spule nur im Zusammenhang mit der GLCD Platine abgeben kann. Bestücken: Als erstes den S-Ram, dann die SMD-Bauteile, dann den Rest. Sämtliche ICs sind in der gleichen Richtung ausgerichtet. Wird der V-Regler nicht verwendet, die Anschlussbuchse rechts neben den V-Reg. Platz einlöten. Man kommt mit 8mm Abstandshülsen zw. dem NANYA-Adapter aus, wenn man Buchsenleiste +Stiftleiste (2,54mm) verwendet. Sinn des Adapters ist die Benutzung anderer controllerlosen GLCD's. Die Platine ist grosszügig aufgebaut, wobei die senkrechten Befestigungslöcher an das NANYA-Display angeglichen sind. Eine Rechnung mit ausgewiesener MwSt gibts dazu. Wigbert
Hallo Sebastian, hallo Helfender, Nach längerer Pause bin ich wieder dran. Vorab herzlichen Dank für eure Kommentare. @ Sebastian >>Ist das Bild statisch, oder läuft das durch? das Bild sieht zuerst statisch aus, wird dann aber auf der gesamten Fläche sehr unruhig und läuft -so weit ich es erkennen kann- durch. >>Und welches LCD verwendest du? Datenblatt? das übliche NANJA s/w Display. >>Wie hast du es angeschlossen? das Flachbandkabel am Ende aufgedröselt und in eine Steckerleiste gelötet. In der Zwischenzeit habe ich das LCD in einer anderen Schaltung getestet und es funktioniert einwandfrei. >>Wie schnell taktet dein AVR eigentlich? 16MHz @ Helfender LA besitze ich nicht, daher kein direkter Vergleich möglich. LP Frequenz ca. 24,4 kHz, das sind genau deine 41µs. FRAME Frequenz ca 100 Hz. PCLK zeigt Blocks von ca. 80 Takten und danach eine Pause. Die Takte haben allerdings nach oben und unten ziemliche Spitzen. Aus den Datensignalen kann ich nichts Eindeutiges ableiten. Gruß Bruno
Angehängte Dateien:
-
IMG_0.jpg
12 KB
Hallo Bruno, ich habe mal kurz dein asm Programm geflasht. Der Frameimpuls kommt wahrscheinlich exakt am LCD an, da keine Bauteile dazwischen sind. Also vermute ich, dass es an der Datenausgabe liegt. So wie es aussieht, kommen deine Daten zu spät. Aber gemessen am Frameimpuls immer an der gleichen Stelle. Wird dir nicht viel helfen, aber ich habe auch keine Idee mehr.
Hast du vielleicht irgendwo nen Kurzschluss in deinen Adressleitungen zum RAM? Mir kommt das komisch vor, dass auf dem ganzen LCD immer die gleichen 12 (oder so) zeilen angezeigt werden. Und das einzige was mir dazu einfällt ist, dass irgendwas an deinen Adressleitungen nicht passt.
Hallo Helfender, hallo Sebastian daß bei mir der senkrechte Balken rechts und das Rechteck bei dir links ist, hat nichts zu sagen. Ich hatte das LCD anfangs nur verkehrt rum aufgestellt. Eine letzte Frage an Helfender zur Vollständigkeit: Wie hast du die Fuses gesetzt? Ansonsten nochmals herzlichen Dank an euch beide für die Geduld. Sollte ich den Fehler noch finden, lasse ich es euch wissen.
Hallo Bruno, Fuses für ATMega162 im AVRStudio: EXTENDED 0xFF HIGH 0xD9 LOW 0xFF
Hallo Sebastian, hallo Helfender, ich hab's geschafft!!! Die Lösung war natürlich ganz simpel. Ich habe versuchsweise einmal das WAITSTATE Bit gesetzt, obwohl ich eigentlich schnelle RAMs habe(15ns bzw. 25ns). Das Problem ist wahrscheinlich mein großzügiger Schaltungsaufbau auf einer Lochrasterplatine. Gruß Bruno
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.