Da ich eine Alternative zum Beitrag "Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Controller suchte und noch einige D-Rams rum liegen hatte, kam das dabei raus. Das UART Protokoll ist dasselbe wie bei Benedikt, da der Code auf seinem basiert. Als MC dient ein mega88. Alternativ kann man aber auch einen mega8 verwenden. Der D-RAM sollte mindestens 100ns oder schneller sein und min 32k*4. Bei 20MHz und 65Hz beim LCD ist der MC zu ca. 40% ausgelastet. Da ich derzeit keine Displays habe die ein M/AC Takt brauchen, benutze ich den Pin als OnOff Signal. Wer mag kanns gerne testen. (Das Projekt wurde mit AVR Studio 5.0 geschrieben.) noch geplant: - erweiterung auf 4 Graustufen. - M/AC Takt
Alexej O. schrieb: > Der D-RAM sollte mindestens 100ns oder schneller sein und min 32k*4. Meinst du etwa SDRAM? Wenn ja, wie machst du das dann mit dem Refresh? Steffen
Steffen H. schrieb: > Meinst du etwa SDRAM? Wenn ja, wie machst du das dann mit dem Refresh? Nein keinen SDRAM sondern DRAM. Der Refresh wird durch die ständige ausgabe der Daten auf dem Display Realisiert. Er liegt etwa bei 16ms.
Alexej O. schrieb: > Nein keinen SDRAM sondern DRAM. Wo bekommt man sowas her? Auf irgend welchen alten RAM Riegeln für den Computer? Oder wo wurde sowas noch verwendet?
Genau. Alte Simm Module oder alte Grafikkarten. Pollin hat derzeit auch noch welche. Wobei das nur 1 Bit Module mit 120ns sind von dennen man dann 4 stück braucht.
Ich habe den Code ein wenig überarbeitet und erweitert. - Grafikmodus auf 4 Graustufen erweitert - M/AC Signal (noch nicht getestet) Im 4 Graustufen mode wird ein DRam mit min. 64k*4 benötigt. R2-R5 werden für die lcd_clear Funktion benötigt. Sie sollten einen wert um 10k-50k haben.
Vielen Dank für das tolle Projekt! Ich habe die Schaltung mal schnell auf Lochraster gebastelt. Den DRAM Baustein habe ich aus einem alten DIMM-Rigel ausgelötet und mit etwas Draht auf einen DIP IC-Sockel gelötet. Als Display verwende ich das Wintek WD-H3224V von Pollin (s/w, benötigt das M/AC Signal). Ich habe noch ein paar Anpassungen an der Timer-Initialisierung gemacht, damit der Code auf einem Mega8 lauffähig ist. Von den Displays habe ich mal 4 Stück bestellt. Wenn ich etwas Zeit habe werde ich versuchen die Touchscreen auswertung noch mit in den Controller zu integrieren (wird dann nur mangels IOs mit dem Mega8 nicht klappen) und alles auf eine Platine zu bringen. Gruß Benedikt Patt
Freut mich das es läuft. :-) Ich hatte den Controller zuerst mit einem 40 piner (mega644) sogar getestet. Die Adressierung des DRams war da sogar einfacher da ein ganzer Port zur Verfügung stand. Habe diese Woche dieselben Displays von pollin bekommen. Wenn ich nächste Woche ein wenig zeit finde werde ich das auf nen 40 piner umschreiben.
Das einzige was es in Verbindung mit diesem Display noch zu "bemängeln" gibt ist, dass es bei genauerem hinhören etwas pfeift. Das dürfte am M/AC Signal, oder? Nur noch so zur Info, falls du es noch nicht weißt. Als Kontrastspannung habe ich bei meinem Display 22,3V eingestellt. Pollin gibt glaube ich 32V an. Damit das Teil was anzeigt muss "Display off" auf 5V gesetzt werden. Wenn ich den Touchscreen in Betrieb nehme und einen Mega16 oder sowas als Controller nehme, wollte ich auch weg von der Ansteuerung über UART. Habe mir das noch nicht genauer überlegt, aber SPI ider I2C wäre ganz nett.
Ich wollte das lcd zuerst noch auf eine weiße Hintergrundbeleuchtung umbauen, bevor ich es zum Testen anschließe. Derzeit habe ich nur noch keine Projekt Idee, wo ich so ein großes Display benötige. Ich bin noch am überlegen ob ich den Code auf dem 40 piner mit oder ohne den bus transceiver realisieren soll. Mit: hätte es den Vorteil das noch ein Port + 5-6 Pins frei benutzbar sind. So könnte man manch ein Projekt ohne einen zweiten MC Realisieren. Ohne: würde ich alle Ports belegen und die freien Pins wären, bis auf 5, nur noch als Eingänge oder für PWM/SPI/UART/ADC zu gebrauchen.
Hallöchen, danke für die klasse Idee - ich werde versuchen dies auf einen ATMega1284P-PU zu adaptieren. Ich habe heute schon den ganzen Tag nach einem vernünftigen Datenblatt für "Wintek WD-H3224V von Pollin Best.-Nr 120506" gegoogelt, leider vergeblich. Da aber hier im Forum bereits mehrere das Display verwenden, hier meine Bitte - ich benötige die Pinbelegung sowie die Spannungswerte. Das Blatt von Pollin soll ja fehlerhaft sein und ich möchte ungern Display oder gar Controller himmeln. Schon jetzt großen Dank! Edgar
Diesen Betrag/Thread kennst du? Beitrag "Re: Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" habs mir nicht genau durchgelesen, aber da scheint man die anschlussbelegung rauslesen zu können. Jedenfalls kann ich mir nicht vorstellen, dass die Pinbelegung nicht in dem Thread steht. Dafür haben dort zu viele dieses Display verwendet ;) Gruß, Sebastian
Hallo zusammen Ich verfolge die Diskussion schon einige Zeit und habe zu dem Display eine frage: Könnte man nicht auch ein TFT aus einem alten Laptop dazu überreden? das wäre doch dann auch eine gute Recycling Möglichkeit die alten LCD´s und TFT´s wieder sinnvoll zu benutzen? Vielen Dank schonmal einen schönen Advent und Wochenende aus dem Sauerland PS:Ich bin noch nicht so "Fit" in der AVR Programmierung, ich Lerne noch :)
Norbert NoVeWa schrieb: > Könnte man nicht auch ein TFT aus einem alten Laptop dazu überreden? das > wäre doch dann auch eine gute Recycling Möglichkeit die alten LCD´s und > TFT´s wieder sinnvoll zu benutzen? Könnte man theoretisch. Praktisch haben diese Displays jedoch eine etwas komplexere Anschlussbelegung (sind ja i.d.R. Farbdisplays, Farbdaten werden pixelweise übergeben)) und durch die wesentlich höhere Auflösung ist der Mega8 massiv überfordert. Er müsste grob gerechnet einen Takt von 500MHz haben um auf einen XGA-Display was darstellen zu können. Dafür gibt es die Displaycontroller im TQFP-100 (oder schlimmer) Gehäuse :-((
Hi Agn zusammen Das ging ja echt schnell, sowas hatte ich mir schon gedacht, na schauen wir mal, ich habe noch URALT schleppy´s mit Echten LCD´s, ich werde mal einen daraus ausbauen und schauen :) Vielen Dank für die schnelle Antwort ein schönes Weekend und Advent de Norbert aus dem Sauerland :)
Hallo Sebastian, danke für die schnelle Antwort und den Link auf den anderen Thread! Diesen Tread hatte ich ignoriert, da mich doch die Grafik interessiert. Gruß Edgar
Norbert NoVeWa schrieb: > Vielen Dank für die schnelle Antwort ein schönes Weekend und Advent de > Norbert aus dem Sauerland :) Noch ein Sauerländer!!! (Ich Endschuldige mich aber mal, denn das hat nichts mit dem Thema zu tun....) Holger aus dem Sauerland ps. Bei mir läufts Display....
Hi zusammen :) Auch auf die Gefahr hin OFF TOPIC zu sein aber MUSS ich doch GLATT DRAUF ANTWORTEN :D Hai Holger Jou die Sauerländer sind wie immer im Rudel anzutreffen hihihi :D :) Bis denn einen schönen Advent wünscht der Norbert aus dem Nördlichsten Sauerland GG
hi, welchen dram könnte man denn von Reichelt verwenden,weil ich da noch bestellen muss vielen dank mfg
Norbert NoVeWa schrieb: > Bis denn einen schönen Advent wünscht der Norbert aus dem Nördlichsten > Sauerland GG Was bedeutet Nördlichsten Sauerland? Kreis Olpe ? Holger ps. Noch mal an alle Endschuldigung für das falsche Forum!!! ;-)
Hi zusammen.. Hi Holger "Falsches Forum nicht, aber falscher Thread" hi :) Nöö Olpe wäre ja Östlich, in der nähe von Warstein Hause ich :) So das war aber nun mein letztes Off Topic, ich bitte ebenfalls um Entschuldigung :) Viele Grüße aus nähe Warsteins und schönen Advent bald kommt ja das Männlein in der roten Kutte und macht HoohoHooo GRINS :)
@Bernd Bei Reichelt habe ich so direkt kein passendes DRAM Modul gefunden, da habe ich auch erst gesucht. Ich habe mir dann bei eBay für 1€ zwei SIMM Riegel mit insgesamt 16 passenden Modulen gekauft. Ist wahrscheinlich günstiger als bei Reichelt, falls es wirklich ein passendes Modul gibt.
Welche Grafikfunktionen sind den geplant? Kris? Dreieck? Rechteck? Zusätzlicher Textmodus wo man TEXT Editiern kann ohne dass man die ganze Grafik neu Schreiben Muss?
Bastler schrieb: > Welche Grafikfunktionen sind den geplant? > Kris? > Dreieck? > Rechteck? Ist alles da. Bastler schrieb: > Zusätzlicher Textmodus wo man TEXT Editiern kann ohne dass man die ganze > Grafik neu Schreiben Muss? Es ist möglich Text zu schreiben. Die Grafik wird dabei aber überschrieben. bernd schrieb: > hi, > welchen dram könnte man denn von Reichelt verwenden,weil ich da noch > bestellen muss > vielen dank > mfg Wie Benedikt Patt schon schrieb ist es günstiger bei EBay sich umzuschauen ober in den Bastelkisten zu hause (Simm module/ Alte Festplatten/CD-Rom/...). @Benedikt Patt (Gast) Ich habe den Code für den 40 Pinner vor wochen schon geschrieben. Kam leider bis heute noch nicht dazu die schaltung zum testen aufzubauen. Wenn du Interesse hast kann ich dir den Code gerne zum testen zur verfügung stellen.
Reichelt hat ja 128Kx8 SRAMs für unter 2 Euro, da ist DRAM (den die auch haben, aber über einen Euro für einen 4164) doch eigentlich Sport :) Ausser man hat eben gebrauchten in Massen rumliegen :)
Alexej O. schrieb: > Bastler schrieb: >> Zusätzlicher Textmodus wo man TEXT Editiern kann ohne dass man die ganze >> Grafik neu Schreiben Muss? > > Es ist möglich Text zu schreiben. Die Grafik wird dabei aber > überschrieben. Ich meinte das man den Text auch löschen kann ohne das man die dahinter befindliche Grafik neu schreiben muss.
@Alexej O. Wenn du willst kannst du mir den 40pinner Code mal zur Verfügung stellen, dann spare ich mir etwas Arbeit :-) Ich habe gestern Abend schonmal schnell einen Mega32, DRAM (habe mittlerweile sogar DIP DRAM gefunden) und ein Netzteil für die Kontrastspannung auf eine Platine gelötet. Heute geht's dann an's Programmieren. Ich habe das ganze schomal von UART auf SPI umgestellt und die Touchscreen Auswertung integriert. Danke!! Gruß Benedikt
@Benedikt Patt und @Alexej O. seid Ihr schon weiter gekommen mit dem Code für den 40pinner? Welchen AT benutzt Ihr - und werdet Ihr den Code Online stellen? Die Idee ist absolut Spitze - 3 Käfer und ein bisschen drumherum und schon funktioniert das - Danke!!! Gruss Edgar
Sorry war schon länger nicht mehr auf der Seite. Ich habe die Schaltung zum testen mal aufgebaut und die letzten Fehler korrigiert. Die Ports/Pins sind in der param.h frei wählbar. Wünsche schon mal viel Spaß beim aufbauen. Gruß NRG
Hallo, ich beobachte diesen Thread schon seit langem, und genauso lange wollte ich diesen bzw. einen seiner "Geschwister-Controller" hier im Forum nachbauen. Da ich wohl nicht dazu kommen werde verkauf ich nun meine LC-Displays mit Touchpanel. Vielleicht kann sie ja jemand von euch ehernvoll in Betrieb nehmen. Hab sie im Markt eingestellt (Beitrag "Verschenke/Verkaufe Touch LC-Displays, Textoolsockel, div. USB und Audio IC´s"). Philipp @Moderator: ich hoffe diese "Werbung" ist erlaubt, sonst bitte löschen.
So die V2.0 des Controllers ist endlich fertig. Erst mal ein Danke an Ralf-Peter G. für die Ideen und Tests. Zum Controller. - Unterstützte Mikrocontroller Mega16/164/32/324/644 - Schnittstelle: UART (Baudrate über 3 Jumper wählbar) - Grafikfunktionen (Pixel, Bilder, Linien, Rechtecke, Kreise, Invert) - 2,4 Graustufen (während der Laufzeit umschaltbar) virtuelle Auflösung von 1024x240 @1bpp, 512x240 @2bpp - 3 - 6 Fonts - Ein Benutzerzeichensatz - Touchpanel Unterstützung aktivierbar Das Projekt wurde mit "Atmel Studio 6.0" in C und Assembler geschrieben. Für nähere infos siehe pdf. Wünsche viel Spaß beim aufbau. Gruß Alexej O.
Erstmal muss ich sagen: Richtig geiles Projekt !!! Dann habe ich eine Verständnisfrage: Wie funktioniert das, dass man mit 9 Adressleitungen 256kx4 adressieren kann ?!?! Eigentlich dürften doch nur 2^9 = 512 adressierbar sein oder habe ich da was falsch verstanden? Bei dem Projekt mit SRAM waren auch nur 32K möglich, aber die hatten dort auch wesentlich mehr Adressleitungen dran hängen... MfG Waldemar
Du hast das Multipexing bei D-Rams vergessen. (RAS/CAS) Somit hast du statt 9 gleich 18 Adressleitungen. 2^18 = 256k
AAAAAAAAAAAAAAAAHHHHHHHHHHHHHHH (ein licht geht auf =) ) Das ist natürlich ne feine Sache dann mit den D-Rams !!! Eine Frage noch, wo bekommt ihr alle diese tollen D-Ram bausteine her?! Ich finde überall nur 64Kx1 oder sowas ?! MfG Waldemar
Hallo Waldemar, Hinweis zu DRAM's: LCD_Controller_320x240.pdf Seite 6 Ralf-Peter
Also wenn ich bei ebay PS/2 Ram eingebe, kommen ganz viele Ram Module mit 16MB kapazität und den DIP Bausteinen drauf, sind das die richtigen ??? Bei vielen steht auch EDO-Ram dabei!? Wäre über eine Hilfestellung echt dankbar, weiß ansonsten nicht welchen ich kaufen sollte... MfG Waldemar
Bei den PS/2 Simm Modulen gibt es verschiedene sorten. Es hängt immer davon ab welche Chips da verbaut sind. (4Mx4 - 1Mx1 - 4Mx16 ...) In der Regel sind 8MB und 16 MB module entweder mit 4Mx16 oder 1Mx4 Chips bestückt, die kleineren module können aber auch mit 1Mx1 Chips Bestückt sein, was dazu führt das du 4 chips für den Controller benutzen müstest. ob es sich um FPM oder EDO Module handelt spielt keine Rolle.
Also, ich war jetzt bei meinem Onkel der nen Schrottplatz hat und auch Elektroschrott sammelt, und habe mir ca 100 alte Ram Riegel mitgenommen, bzw nur die wo nur 3 Chips drauf waren, weil die ja fast alle 4Bit Chips haben. Ein paar sind 256Kx4Bit und die meisten sind 1Mx4Bit und ein paar wenige auch 4Mx4Bit, kann ich die mit dieser Software auch ansteuern? Bzw welche Teile der Software müsste ich ändern um es tun zu können ? Bin euch echt dankbar für eure Hilfe und falls einer von euch ein paar Chips brauchen sollte, dann würde ich auch ein paar abgeben... MfG Waldemar
Kannst alle benutzen. Die Übrigen Adressleitungen einfach auf GND legen. Falls du ein Baustein hast der mehr I/O Leitungen hat, einfach die zuvielen offen lassen.
Nach einer Pause habe ich das Projekt wieder aufgegriffen und fing es an weiter zu entwickeln. Derzeitiger stand: Ich konnte mit hilfe des Timer1/PWM die benötigte Rechenleistung für die Bildschirmausgabe deutlich reduzieren (von 450 auf ca 300 Takte pro Zeile). Dadurch konnte ich erste Experimente mit 8 und 16 Graustufen machen (siehe Bilder). Bis alles Fertig ist wird es aber noch eine weile dauern. Gruß Alexej
Guten Morgen. Ich bin Gestern dazu gekommen, die Schaltung auf dem Steckboard aufzubauen. Dein Controller funktioniert (fast) bestens!!! Besten Dank! Ich nutze den Mega32 und das Wintek WD-H3224. Den DRAM habe ich auf einer alten ISA Grafikkarte gefunden. Nur eine Sache bereitet mir noch Probleme. Und zwar bekomme ich keine sinnvollen Werte vom Touchscreen. Bei der Option "Touchscreentest" wird nur in der untersten Zeile "00001" anzeigt, welche zwischen 1 und 3 durchläuft wenn ich den Touchscreen berühre. Die vier Werte für die Position werden nicht angezeigt. Nichtmal "0". Im normalen Betriebsmodus kann ich über UART den Touchscreen aktivieren. Bei Berührung wird der Datensatz übertragen. (Analogwerte) Dieser besteht aus den Begin und Endmarkern und vier Touchscreendaten, wovon zwei immer 0 bzw annähernd 0 sind. Beim ersten übertragen von Pixelwerten waren diese alle fast 0. Nach einem Versuch Kalibrierwerte zu übertragen, zeigte sich auch in diesem Modus das gleiche Verhalten wie im "Analogwerte-Übertragungsmodus" Ohmisch durchgemessen habe ich ca. 250 Ohm und ca. 600 Ohm an den Touchscreenleitungen. Wenn ich die Leitungen gegeneinander Messe habe ich >10MOhm und bei berührung zwischen 400 Ohm und 1,2k Ohm (Je nach Stelle). Programmiert habe ich nur den Flash, nicht das EEPROM File. Bei den Fuses habe ich nur den extern Crystal aktiviert und JTAG deaktiviert. Die Software ist v2.0. Hat da jemand eine Idee? Viele Grüße! Sebastian
Noch ein Nachtrag. (Ist mir zu spät eingefallen) Was genau hat es sich mit den Werten Low und High auf sich? "Kalibrierwert für Xmin Xmin Low / Xmin High" Bzw „01, X Low, X High, Y Low, Y High“. VG!
Sebastian Engel schrieb: > Bei der Option "Touchscreentest" wird nur in der untersten Zeile "00001" > anzeigt, welche zwischen 1 und 3 durchläuft wenn ich den Touchscreen > berühre. > Die vier Werte für die Position werden nicht angezeigt. Nichtmal "0". Es scheint als wär bei dir der Touch Falsch angeschlossen. entweder du benutzt die Standart Beschaltung wie in der param.h geschrieben. #define T_Xre 2 // X+ #define T_Xli 0 // X- #define T_Yob 3 // Y+ #define T_Yun 1 // Y- oder du änderst die Pins entsprächend deiner beschaltung um. Die oberen 2 Werte sind die AD werte der Messung, der 3 und 4 wert gibt dir die Berechnete Pixel Position aus (wenn du das EEPROM file mit den Kalibrierwerten mit brennst). Die unterste Zeile beim Touchtest gibt dir nur den aktuellen Status wieder. 1 = gedrückt 2 oder 3 = nicht gedrückt Sebastian Engel schrieb: > Programmiert habe ich nur den Flash, nicht das EEPROM File. Das EEPROM file enthält die Kalibrierwerte für das Touchpad. ist aber nur wichtig für die ersten Tests. Wenn du neue Kalibrierwerte dem Controller sendest, werden die alten Werte Im EEPROM mit den neuen Werten überschrieben. Sebastian Engel schrieb: > Was genau hat es sich mit den Werten Low und High auf sich? > > "Kalibrierwert für Xmin > Xmin Low / Xmin High" > > Bzw „01, X Low, X High, Y Low, Y High“. Da die Analogen Werte 10 Bit Breit sind passen sie nicht in ein Byte rein. Soll eigentlich lauten X Low Byte , X High Byte... die 01 wird als Status für Touch ist gedrückt übertragen. Sobald das Touch losgelassen wird , wir 02 ein mal übertragen. Gruß Alexej
Guten Morgen! Danke erstmal für die Ausführliche erklärung! Jetzt wird mir schon manches klarer. ;-) Aber dann würde das Testprogramm bei mir sagen, das der Touch gedrückt ist, wenn ich nicht drücke und andersrum. Was darauf hindeutet das der Touch falsch verdrahtet ist. Das normale Programm allerdings sendet mir Daten, wenn ich den Touch berühre. Deutet also darauf hin, das höchstens X und Y verdreht sind. Und noch eine unklarheit: In deiner main.c Datei in der Funktion Touch_test() werden die gemessenen Werte nur angezeigt wenn (tprogpos == 0) erfüllt ist. Dies scheint bei mir nie der fall zu sein.
Hallo, Ich möchte mir auch diesen Controller nachbauen. Allerdings finde ich keinen passenden DRAM. Hat vielleicht noch irgendjemand so einen DRAM rumliegen, den er mir abtreten kann? Gruß Steffen
Sebastian Engel schrieb: > Aber dann würde das Testprogramm bei mir sagen, das der Touch gedrückt > ist, wenn ich nicht drücke und andersrum. > Was darauf hindeutet das der Touch falsch verdrahtet ist. > > Das normale Programm allerdings sendet mir Daten, wenn ich den Touch > berühre. > Deutet also darauf hin, das höchstens X und Y verdreht sind. Wenn das Touch falsch angeschlossen ist können da schon recht merkwürdige effekte auftretten. Sebastian Engel schrieb: > Und noch eine unklarheit: In deiner main.c Datei in der Funktion > Touch_test() werden die gemessenen Werte nur angezeigt wenn (tprogpos == > 0) erfüllt ist. Dies scheint bei mir nie der fall zu sein. tprogpos wird in der isr routine auf 0 gesetzt wenn die messung für X und Y komplett abgeschlossen ist. Das ist nur wenn der Touchtest mode aktiviert ist. Leider funktioniert es bei der Simulation nicht richtig. Wenn das Touch falsch angeschlossen ist wird nie eine Messung komplett ausgeführt. Steffen H. (avrsteffen) schrieb: > Ich möchte mir auch diesen Controller nachbauen. Allerdings finde ich > keinen passenden DRAM. > Hat vielleicht noch irgendjemand so einen DRAM rumliegen, den er mir > abtreten kann? Habe leider derzeit auch nicht mehr viele auf lager. Das einfachste ist bei E-Bay mal nach PS2 Simm modulen zu suchen. bekommt man schon für ein paar Euros. Gruß Alexej
Alexej O. schrieb: > Wenn das Touch falsch angeschlossen ist wird nie eine Messung komplett > ausgeführt. Dann werd ich da heute abend nochmal genau hingucken. Leider habe ich von dem Display keine genaue Pinbelegung von dem Touchscreen. Aber es gibt ja nur 4! mögliche Permutationen. :-) Und wenn ich die Messung richtig interpretiere reduziert es sich auf 4. Steffen H. (avrsteffen) schrieb: > Hat vielleicht noch irgendjemand so einen DRAM rumliegen, den er mir > abtreten kann? Da könnte ich weiterhelfen. Könnte da einen abtreten. Ist ein 256kx4 DRAM mit 80ns im DIP20 Gehäuse. Schick mir einfach eine PN
Sebastian Engel schrieb: > Da könnte ich weiterhelfen. Könnte da einen abtreten. > Ist ein 256kx4 DRAM mit 80ns im DIP20 Gehäuse. > Schick mir einfach eine PN Oh danke Sebastian. Schick ich dir, aber erst heut Abend. Gruß Steffen
Nun läufts!!! Vielen dank Alexej für die Bereitstellung und die Hilfestellung. Hab den Touch neu Angeschlossen und plötzlich machten die Werte sinn in HTerm. Nur der TouchTest läuft weiterhin nicht. Ist nun aber hinfällig. Nach richtiger Kalibrierung passen sogar die Pixelwerte. :-) Nun ist die Evoluation vorbei und ich kann Platinen erstellen. Einmal Lochraster für das Hitachi und einmal SMD für das Wintek. VG! Sebastian
Sebastian Engel schrieb: > Nun ist die Evoluation vorbei und ich kann Platinen erstellen. > Einmal Lochraster für das Hitachi und einmal SMD für das Wintek. wenn du noch ein wenig zeit hast mache ich am Wochenende die Version 2.1 endlich fertig. Sie hat eine Neue Hardware Beschaltung, wird aber mit der Späteren 8 und 16 Grauwerte Version kompatibel sein. Gruß Alexej
Alexej O. schrieb: > wenn du noch ein wenig zeit hast mache ich am Wochenende die Version 2.1 > endlich fertig. Das hört sich gut an. So viel Zeit hab ich auf alle Fälle. Würde eh erst frühestens Mitte oder Ende nächste Woche dazu kommen. VG! Sebastian
Guten Morgen! Ich habe gestern zum ersten mal Nutzdaten an den Controller gesendet. Einen Textstring und die aktuelle Uhrzeit. Die Schaltung ist noch, wie oben zu sehen, auf dem Steckboard gesteckt. Der Startbildschirm steht 1A still. Wenn ich jetzt aber Daten per UART (9600 Baud) an deinen Controller sende (Uhrzeit jede sekunde), passiert es manchmal das die koordinaten für den Text falsch ankommen. Der Text springt also quer über den Bildschirm. Und es geht so weit, das der Controller einfriert. Ich hoffe das es an dem Drahtigel (Steckboardaufbau) liegt. Bei der Signalgeschwindigkeit unterhalten sich bestimmt alle Leitungen untereinander. :-) Und noch ein Hinweis an alle einsteiger: Wenn ein Bild übertragen werden soll, unbedingt drauf aufpassen, das die richtige Anzahl an Bytes gesendet wird. Ich hatte erst einen Pixelbrei auf dem Bildschirm -> Zu wenig Bytes gesendet. Und nach dem Umschreiben meiner Routine sah ich kurz das Bild und dann spielte der Controller total verrückt. Problem: Ich hatte statt 1024 Bits, 1024 Bytes gesendet :-D Mfg Sebastian
Wertest du auch CTX(Busy) vom Grafikcontroller aus Mfg
nexus schrieb: > Wertest du auch CTX(Busy) vom Grafikcontroller aus Bisher nicht. Das sollte ich wohl mal implementieren :-) Aber das sollte bei meiner Uhrzeitdarstellung keine Rolle spielen. Da sende ich jede sekunde die Cursor Position und 8 Bytes an Daten.
Sebastian Engel schrieb: > Da könnte ich weiterhelfen. Könnte da einen abtreten. > Ist ein 256kx4 DRAM mit 80ns im DIP20 Gehäuse. > Schick mir einfach eine PN Danke Sebastian, dein DRAM ist heute unbeschadet angekommen. Nun warte ich mal noch auf Alexej's neuer Schaltung und dann probier ich es auch gleich mal aus. Gruß Steffen
Sebastian Engel (s-engel) schrieb: > Wenn ich jetzt aber Daten per UART (9600 Baud) an deinen Controller > sende (Uhrzeit jede sekunde), passiert es manchmal das die koordinaten > für den Text falsch ankommen. Ich habe das selbe Problem bei meinem Steckbrett aufbau. Bei der Fertigen Platine hatte ich aber keine Probleme. Ralf-Peter hatte damit längere Tests vor der veröffenlichung der v2.0 gemacht und keine Probleme festgestellt. Sebastian Engel (s-engel) schrieb: >> Wertest du auch CTX(Busy) vom Grafikcontroller aus > > Bisher nicht. Das sollte ich wohl mal implementieren :-) > > Aber das sollte bei meiner Uhrzeitdarstellung keine Rolle spielen. > Da sende ich jede sekunde die Cursor Position und 8 Bytes an Daten. Das CTX(Busy) wird erst bei Grafikfunktionnen oder den Großen Fonts intressant. Alles andere schreibt der Controller selbst bei 115k Baud schnell genug weg. Die Version 2.1 ist leider doch ein wenig aufwendiger als ich Dachte. Sie Läuft zwar schon, aber da ich in meinen eigenen Projekten nicht alle funktionnen brauchte, hatte ich sie nicht integriert. Zum Testen könnte ich dir aber schon die Beta per Mail senden. So könntest du die neue beschaltung schon mal testen. Gruß Alexej
Steffen H. schrieb: > dein DRAM ist heute unbeschadet angekommen. Sehr gut! Alexej O. schrieb: > Ich habe das selbe Problem bei meinem Steckbrett aufbau. Bei der > Fertigen Platine hatte ich aber keine Probleme. Ralf-Peter hatte damit > längere Tests vor der veröffenlichung der v2.0 gemacht und keine > Probleme festgestellt. Das beruhigt mich jetzt wirklich :-) Alexej O. schrieb: > Das CTX(Busy) wird erst bei Grafikfunktionnen oder den Großen Fonts > intressant. Alles andere schreibt der Controller selbst bei 115k Baud > schnell genug weg. Ich werds vorsichtshalber in meinem Projekt mit einplanen. Mein Testbildchen mit 40x40 Pixel hat der Controller dann wohl mit leichtigkeit verarbeitet. Alexej O. schrieb: > Zum Testen könnte > ich dir aber schon die Beta per Mail senden. So könntest du die neue > beschaltung schon mal testen. Ich würde mich auch gerne als Beta Tester anmelden ;-) Was hat sich denn in der neuen Version so getan? VG! Sebastian
Ich werde Morgen die erst Beta hochladen. Bin heute nicht mehr fertig geworden. Der Timer0 macht noch nicht das was er soll. Schon mal vorab die neue Pinbelegung für V2.1 Sebastian Engel schrieb: > Was hat sich denn in der neuen Version so getan? Der einzige unterschied zur v2.0 ist die verwendung des Timer1 (OC1A->CP/OC1B->CAS) um das refreshen einer Bildzeile mit Hilfe des Timers von ca. 450 Takten auf ca. 300 Takten zu reduzieren. Somit bleib mehr Rechenleistung für die Grfikbefehle bzw. die Framerate kann bis auf 120Hz erhöht werden, woduch bis zu 16 Grauwerte Realisierbar sind. Gruß Alexej
Mal ne Frage, @Alexej Hat das einen Grund, warum du auf einen ATmega644 umgestiegen bist? @Sebastian Hast du schon mit einem Layout zum neuen Schaltplan angefangen? Gruß Steffen
Hallo, Ich komme beim nachbau einfach nicht weiter weil ich nicht weiss was für ein ram benötigt wird. Der eine sagt hier mann braucht ein 256kx4bit dram ,der andere sagt 4Mx4Bit. Welcher wird denn nun benötigt und vorallem wo kann mann ihn kaufen. Für eine Detailierte Antwort währe ich sehr dankbar. Mfg
Steffen H. schrieb: > Hast du schon mit einem Layout zum neuen Schaltplan angefangen? Leider nein. Ich bin noch beim Lochraster Routing Versuch der V2.0 Schaltung für das SP14Q002. Erst wenn das durch ist, fang ich die V2.1 an. Die wollte ich komplett in SMD aufbauen. Die ZIF Stecker für das WD H3224 habe ich gestern schon bekommen. 10 Arbeitstage Versand aus China! :-) ralf schrieb: > Der eine sagt hier mann braucht ein 256kx4bit dram ,der andere sagt > 4Mx4Bit. Du brauchst mindestens einen 256kx4 DRAM um alle Funktionen nutzen zu können. Ein größerer Speicher geht auch. Die zusätzlichen Adressleitungen würden dann auf GND liegen, da der oberer Speicherbereich nie adressiert wird. Neu kaufen kann man AFAIK nicht mehr. Der DRAM wurde durch den SDRAM ersetzt. Gute Quellen sind alte RAM Riegel (DIMM, den vorgänger vom SDRAM) oder alte ISA Grafikkarten. Bei manchen Bildern auf e-Kauf kann man die Speicherbezeichnung lesen und nach Datenblättern suchen. Z.B. nach 10s suchen: http://www.ebay.de/itm/221159226840 -> Da sind 8 Stück 256kx4 DRAM (10ns Zugriffszeit) drauf. Um das ganze noch ein wenig komplizierter zu machen, muss der Speicher auch schnell genug sein. Details dazu findest du in Alexej's beschreibung als PDF.
Hatte heute endlich wieder ein wenig Zeit gefunden um die letzten Fehler zu beseitigen. Ein paar tests habe ich auf dem Mega644 schon gemacht waren aber nicht viele. Die Mega16/32 unterstützung habe zwar geschrieben, kann sie aber derzeit nicht testen da ich keinen mehr auf lager habe. Über eine Info ob alles geht oder es noch fehler gibt würde ich mich freuen. Zu den Änderungen: - HW Zeilenausgabe mit hilfe des Timer1 PWM mode integriert. - Viele kleine änderungen/optimierungen im Code Steffen H. schrieb: > Hat das einen Grund, warum du auf einen ATmega644 umgestiegen bist? Hatte nur einen Mega644 frei und da nur der Mega644 alle Funktionen/Fonts unterstützt teste immer zuerst mit dem. Er ist aber zum Mega32 Pin Kompatibel. Gruß Alexej
Hallo Bin gerade am Board-Design. >>@Sebastian Wenn du später das Layout alles in SMD machen willst, hast du schonmal DRAM in SMD gefunden? Ich bis jetzt nur als SOJ-Package. Das ist ja fast DIL-Size. >>Dann noch ein wichtiger Punkt: Ich hab mal noch eine Frage zum Touch-Controller. Mit welcher Referenz wird denn ausgewertet? Die internen 2,56V, internen 1,1V, AVCC oder exterer VREF Spannung? Gruß Steffen
Steffen H. schrieb: > Ich hab mal noch eine Frage zum Touch-Controller. Mit welcher Referenz > wird denn ausgewertet? > > Die internen 2,56V, internen 1,1V, AVCC oder exterer VREF Spannung? Mit AVCC. Da DRAM_A8 am PORT A geschaltet wird, brauche ich da die 5V. Falls du DRAM_A8 auf einen anderen Port legst, kannst du auch eine andere Externe Referenz Spannung benutzen. Die Interne dürfte zu schwach sein um den Touch zu betreiben. Gruß Alexej
So, ich teste gerade, wie man das mit der Kontrast-PWM und Vee lösen könnte. Hab mir die Schaltung oben dazu ausgedacht. Den Kondensator an Vo muss mit Sicherheit noch geändert werden. Genaue Werte muss ich dann experimentell bestimmen. Als Optokoppler habe ich in ersten Test auch einen MB104/4D ausprobiert (gibts bei Pollin). Der würde auch gehen. Habe allerdings einen Sharp SFH6156 verwendet, da ich diese noch rumliegen habe und diese in einem SMD-Package sind. Wie habt ihr das denn gelöst mit der PWM und den Kontrast? Gruß Steffen
Steffen H. schrieb: > Wie habt ihr das denn gelöst mit der PWM und den Kontrast? Bis jetzt hatte ich diese Funktion nicht benutzt, geschweige den getestet. Bei der der Version 2.1 kommt noch hinzu das die Kontrast PWM Steuerung nur beim Mega644 funktioniert. Der Mega 16/32 hat an diesem Pin keinen PWM Ausgang. Alternativ würde nur die möglichkeit bleiben die Kontrast PWM Steuerung auf Pin PB3 OC0(A) zu legen und die Hintergrund Beleuchtung dafür auf PB4 und über Software PWM zu schalten. Wär kein großer Aufwand das so zu Realisieren. Dann wär die Frequenz für die Kontrast Steuerung auch unabhängig. Die genauen PWM einstellungen müste wir aber noch testen. Gruß Alexej
Wie verbindet ihr eigentlich alle das LCD? Ich habe das Wintek-LCD von Pollin und scheitere irgentwie bei dem Versuch an die Stelle wo das Folienkabel angeschlossen ist, kleine Drähte anzulöten :( Irgentwelche Tipps? MfG Lampe
Steffen H. schrieb: > Wie habt ihr das denn gelöst mit der PWM und den Kontrast? Gar nicht. :-) Habe den Kontrast über ein Poti fest eingestellt. Ich hatte auch schon schwierigkeiten tiefer als -19V zu kommen. Erst mit externen Transistor hats funktioniert. Als Diode hatte ich allerdings nur eine 1N4148 drin. Was anderes hab ich grad nicht da. Kann denn die deutlich höhere Diffusionsspannung der 4148 dazu führen, das zu viel Spannung (>3V) verlohren geht? Steffen H. schrieb: >>>@Sebastian > Wenn du später das Layout alles in SMD machen willst, hast du schonmal > DRAM in SMD gefunden? Ich bis jetzt nur als SOJ-Package. Das ist ja fast > DIL-Size. Den DRAM in SMD habe ich nicht gefunden. Ich habe vor beim DIP die Pins bündig umzubiegen oder abzuschneiden. Bei so seltenen ICs muss man Improvisieren ;-) Lampe schrieb: > Wie verbindet ihr eigentlich alle das LCD? Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit D-RAM" Dazu brauchts dünnes Lötzinn, eine dünne Lötspitze, eine ruhige Hand und viel Gedult. Einen passenden Adapter von 24Polig 0,5mm Raster auf 2,54mm gibt es nicht.
Heyyy. Schönes Breakout-Board. Dann revidiere ich meine Aussage. Es gibt doch welche :-)
Hallo Ralf-Peter Grellmann, wo gibts den die Zif-Sockel 24 Pol. zu kaufen.
Hallo Sebastian, das Teil ist bei der Evaluierung Alexej's LCD-Controller entstanden, also nichts kommerzielles - geht trotzdem sehr gut. @Ron es gibt mehrere Distributoren, allerdings mit etwas unterschiedlichen Pinout, ich suche mal die von mir verwendeten raus - bitte um etwas Geduld Grelli
Hallo, Da ich ein NANYA LTBHBT357E2CK als Display habe brauche ich -23V Vee und demzufolge auch eine Kontrastpannung zwischen 0..-23V. Meine Kontrastpannung bei 25°C soll -18,2V sein. Der Strom laut Datasheet ist 7,6mA (max. 11,4mA) für Vee. Meine kleine Schaltung funktioniert. Ich habe bei vollem Kontrast noch -22,8V. Also alles prima. Jetzt geht es an die PWM um die Kontrastspannung regelbar zu machen. Ich werde definitiv einen ATmega644 verwenden. Wenn schon, denn schon.. @Alexej Ohne jetzt in deine Sourcen zu schauen: Mit welcher Frequenz hast du denn den Timer0 laufen? @Sebastian Ich werde es wohl auch so machen wie du. Denn das SOJ Package ist auch nicht kleiner. Und die meisten DRAM sind nun mal in DIL. Gruß Steffen
Hallo Ron, wie versprochen der Link http://de.farnell.com/hrs-hirose/fh12-24s-0-5sh-55/buchse-ffc-fpc-zif-0-5mm-24kont/dp/1324552?Ntt=132-4552 Gruß Grelli
Hallo Grelli Danke für die schnelle Antwort. Ich hatte bei Farnell den nachfolgenden connector gefunden. http://de.farnell.com/fci/10051922-2410elf/ffc-fpc-connector-receptacle-24pos/dp/1859543 Leider können hier nur Firmen einkaufen.
Hallo Ron, der von Dir gefundene Connector KÖNNTE ?! auch funktionieren. Für das WINTEK-LCD müssen die Kontakte im SMD-Connector unten sein ! Leider sind meine chinesisch Kenntnisse in Bezug, Technical Data Sheet für den von Dir gefundenen, sehr eingeschränkt. Es gibt Firmen die in Deinem Auftrag bei Farnell einkaufen (etwas teurer) - Google ist hier Dein Freund Gruß Grelli
Nachtrag auf Farnell-Seite Es fällt eine Pauschale (Verpackung, Verzollung, Versand) von €20,00 einmalig pro Auftrag an 3 Tage Lieferzeit
Ralf-Peter Grellmann schrieb: > Es gibt Firmen die in Deinem Auftrag bei Farnell einkaufen (etwas > teurer) - Google ist hier Dein Freund Versuch es mal hier: http://hbe-shop.de/Startseite Das ist für Privatkunden. Die haben nicht das ganze Angebot von Farnell, aber doch schon einiges. Gruß Steffen
Ich habe die 24 Poligen ZIF Buchsen bei e-Bucht aus China bestellt. 10 Stück 1,75$ inkl. Versand! (Suchen nach "ZIF 24") Damit es sich lohnt habe ich direkt noch weiße LEDs für den Umbau der Hintergrundbeleuchtung mitbestellt. Der Versand hat 10 Arbeitstage gedauert. Nun habe ich auch endlich mein Lochrasterlayout fertig gelötet und getestet. Und siehe da: Kein Übersprechen oder sonstige Effekte mehr da. :-) Wenn ich das unten stehende Problem beseitigt habe, lad ich das Layout hier noch hoch. Aber nun hab ich noch Kopfschmerzen was meine VEE Spannung angeht. Wie bekomme ich die Spannung passend dazugeschaltet, damit das Display nicht hopps geht? Für die ersten Versuche habe ich einfach das D_On/Off Signal über eine R/C kombination auf einen Optomosfet gegeben, welcher die -22V an VEE schaltet. Aber das gefällt mir nicht ganz so gut. ;-) Und was passiert beim Abschalten, wenn die VCC des Displays langsamer einbricht als die VEE? VG! Sebastian
Sebastian Engel (s-engel) schrieb: > Für die ersten Versuche habe ich einfach das D_On/Off Signal über eine > R/C kombination auf einen Optomosfet gegeben, welcher die -22V an VEE > schaltet. Warum hast du eine R/C Kombination benutzt? Willst du darüber die Zeitkonstante steuern? Bei meinem Display sagt das Datasheet: Display_ON/OFF soll frühstens 20ms nach anlegen von Vcc zugeschaltet werden. Für Vee gilt das gleiche. Deswegen steuere ich meine Vee über Display_ON/OFF. Für das Ausschalten hab ich auch noch keine Lösung. Gruß Steffen
Sehe sowohl beim Ein- wie auch beim Ausschalten keine Probleme. D_ON_OFF mit einem 10-50k Wiederstand gegen Ground schalten und der PIN ist kurz nach abschalten des Controllers auch auf Ground und somit auch Vee. Die rest Spannung des Kondensators versorgt dann das display noch ein paar ms. Brown-out sollte man dazu allerdings beim MC aktivieren damit er rechtzeitig abschaltet. Alternativ könnt ihr auch den Befehl 2 senden und dann die Spannung deaktivieren. Gruß Alexej
Steffen H. schrieb: > Warum hast du eine R/C Kombination benutzt? Willst du darüber die > Zeitkonstante steuern? Ja, genau. Beim Hitachi SP14Q002 sollen 50ms zwischen 5V und -22V Versorgung liegen. (siehe Timing Chart) Lässt sich das on/~off Signal im Controller verzögern? Bei der Lösung mit dem Kondensator habe ich das Problem, das die -22V zu langsam auf GND absinken. Hier sieht man beim Abschalten eine rote(?) linie auf dem Panel aufblitzen. -22V schalte ich so ein: Am on/~off Pin hängt über eine R/C kombination ein Optomosfet. Ich habe noch zwei Messungen angehängt. Kanal 1 (Gelb): 5V (direkt am Display) Kanal 2 (Blau): -22V (direkt am Display) 1. Bild: Einschalten ohne Kondensator -> on/~off Signal kommt nach ca. 7ms 2. Bild: Einschalten mit Kondensator -> on/~off Signal kommt nach 56ms Verwendet habe ich hier den Controller V2.0 VG! Sebastian
Hello again. Um mein on/off Signal zu verzögern, müsste ich doch nach dem "lcd_init();" 50ms warten (evtl ganz stumpf mit wait()) und dann das "PORTD=(1<<LCD_OnOff);" einfügen. Oder funktioniert sorum die Initialisierung nicht mehr richtig? Aus main.c der V2.0
1 | //...
|
2 | int main(void) |
3 | {
|
4 | unsigned char temp, c, ypos=0; |
5 | uint8_t xpos=0, xoffs=0; |
6 | uint16_t adtemp; |
7 | |
8 | PORTD=(1<<LCD_OnOff); |
9 | PORTC=C_norm; |
10 | PORTB=0; |
11 | PORTA=AD_P_noTouch; |
12 | |
13 | DDRA=AD_D_noTouch; |
14 | DDRB=0xFF; |
15 | DDRC=0xFF; |
16 | DDRD=0b11111100; |
17 | |
18 | // ADC aktivieren
|
19 | ADMUX = (1<<REFS0); // interne Referenzspannung nutzen |
20 | ADCSRA = (1<<ADPS2)|(1<<ADPS1) | (1<<ADPS0) | (1<<ADEN); // Frequenzvorteiler 128 / ADC aktivieren |
21 | ADCSRA |= (1<<ADSC); // eine ADC-Wandlung |
22 | while (ADCSRA & (1<<ADSC) ) {} |
23 | adtemp = ADCW; |
24 | |
25 | lcd_init(); // LCD Controller initialisieren |
26 | |
27 | //...
|
VG! Sebastian
Hallo Alexej, super interessantes Projekt, ich habe mir auch schon den ganzen Kram auf einem Steckbrett zusammengebaut, allerdings lässt sich das Programm bei mir auf dem AVR Studio 6 nicht kompilieren. Sowohl die Ver 2.0 als auch die Ver 2.1 machen mucken. Wenn ich den Fehler mit dem UART beseitige, spuckt der Compiler zwar immer noch jede menge Warnings aus, aber das Programm lässt sich wenigstens kompilieren. Aber leider läüft das auf dem ATMege 644P noch immer nicht. Ich kann mit dem Oszi die entsprechenden Signale sehen, aber scheinbar gibt es keinen anzeigbaren Font auf dem Controller, vermutlich wegen der Warnings. Könnte mir bitte jemand eine funtionierernde .hex Datei für den Mega 644P hochladen, damit ich wenigstens schonmal die Hardware überprüfen kann? Ausgabe von AVR Studio ist im Anhang, vielleicht hat jemand eine Idee. Gruß Frank
Hallo nochmal, hier noch ein Foto wie sich der Fehler bei mir darstellt. Interessanter weise lässt sich der Buchstabe "t" bei fast jedem schriftsatz erahnen. Gruß Frank
Sebastian Engel (s-engel) schrieb: > Hello again. > > Um mein on/off Signal zu verzögern, müsste ich doch nach dem > "lcd_init();" 50ms warten (evtl ganz stumpf mit wait()) und dann das > "PORTD=(1<<LCD_OnOff);" einfügen. > Oder funktioniert sorum die Initialisierung nicht mehr richtig? Hast schon die Richtige Stelle gefunden. PORTD=(1<<LCD_OnOff); in PORTD=(0<<LCD_OnOff); abändern es gibt noch eine zweite aktivierung am ende der lcd_init(); ENABLE_VLCD=1; am besten davor die verzögerung einbauen. Werde in der nächsten Version auch die Verzögerung einbauen. irgend ein Frank schrieb: > Hallo nochmal, > > hier noch ein Foto wie sich der Fehler bei mir darstellt. > Interessanter weise lässt sich der Buchstabe "t" bei fast jedem > schriftsatz erahnen. Das sieht nach einem Fehler bei der Beschaltung aus. überprüf am besten noch mal ob alles auch richtig verkabelt ist. Kann auf dem Steckbrett schnell passieren das man 2 Kabel vertauscht. Würde mit den Steuersignalen am DRam anfangen. noch ein wort zu den warnings zu 16x26_horizontal_MSB_1.h . hatte da keine lust ständig die datei zu ändern wegen der Array größe. Falls da jemand eine elegantere lösung kennt, so das keine warnigs mehr kommen, würde ich das gerne ändern. Gruß Alexej
Hallo Alexej, nun läufts bei mir auch, das DRAM war defekt, danke noch mal. Alexej O. schrieb: > noch ein wort zu den warnings zu 16x26_horizontal_MSB_1.h . > hatte da keine lust ständig die datei zu ändern wegen der Array größe. > Falls da jemand eine elegantere lösung kennt, so das keine warnigs mehr > kommen, würde ich das gerne ändern. Das einzige was mir einfällt wäre über #ifdef, sieht zwar nicht schön aus aber die warnings währen weg. Gruß Frank
Hallo Alexej, So, Layout und Leiterplatte sind fertig. Habe einen ATmega644 benutzt, der mit 16 MHz Takt läuft. Scheint erstmal alles soweit zu funktionieren, allerdings nur mit deinem HEX-File. Und das scheint ja für 20MHz und einen ATmega644P zu sein. Nun gut, wollt das Projekt neu kompilieren und das ging leider nicht. UMGEBUNG: AVR-Studio 4.13 mit WINAVR-20100110, AVR-GCC. Irgendwas haut mit den Inline-Assembler-Files unter AVR-Studio4 nicht hin! < Hier mal ein paar Fehlermeldungen > Error: constant value required Error: garbage at end of line Error: register name or number from 0 to 31 required Error: unknown opcode `lcd16bitou' .. .. Ich hab mal das ganze Fehlerlisting angehangen. Wer kann mir da helfen? Denn so kann ich die UART (Baud) nicht nutzen. Steffen braucht unbedingt Hilfe
Liest hier noch jemand mit? Nun ja, iich hab es selber hin bekommen. AVR-Studio-6 installiert, was bleib mir anderes übrig?!. Jetzt noch Fehler mit den USART-Interrupt-Namen beseitigt und nun lässt es sich wenigstens ohne Fehler kompilieren. Hab es Übrigens auch noch unter AVR-Studio4 hinbekommen. Das AVR Studio4 kann zwar mit den USART-Interrupt-Namen umgehen, allerdings nicht mit den Makros und den #includes(Assemblerfile.S) im Assemblerfile. Muss man erstmal drauf kommen.. Okay, da hab ich schon den ersten Fehler gefunden: - Der Command "5" <Backlight on> in main.c ging irgendwie daneben. Der muss geändert werden. alt:
1 | else if (c==5) // LCD LED on |
2 | {
|
3 | TCCR1A |= (1<<COM1A1); |
4 | }
|
neu:
1 | else if (c==5) // LCD LED on |
2 | {
|
3 | #ifdef megaXX4
|
4 | TCCR0A |= (1<<COM0A1); |
5 | LCD_LED_PIN=1; |
6 | #else
|
7 | TCCR0 |= (1<<COM01); |
8 | LCD_LED_PIN=1; |
9 | #endif
|
10 | }
|
- Da mein LCD mit einer LED Hintergrundbeleuchtung betrieben wird, musste ich die LED/Kontrast PWM-Frequenz von 250Hz auf ca. 1kHz erhöhen. Denn die Schrift und der halbdunkle Schrifthintergrund haben ganz schön geflackert. Da wirken die Backlight-LEDs wahrscheinlich wie ein Stroboskop auf die Kristalle des LCD. Dies geht durch Ändern des Prescallers von derzeit 256 auf 64. Weiteres muss ich nun erst noch testen. Gruß Steffen
Mitlesen ja, aber das problem mit AVR-Studio 4 hätte ich erst am we zuhause testen können. Kurz vor Weihnachten bleibt nicht viel Zeit für Hobbys. Den Fehler der Hintergrund Beleuchtung werde ich in der nächsten Version korrigieren. Danke noch mal. Bei der Frequenz werde ich mal schauen ob ich sie von vornerein auf 1kHz erhöhe. Derzeit bin ich noch mit der entwicklung der 8 Grauwerte Version beschäftigt. PS: Das Fertige Board sieht super aus. Gruß Alexej PPS: welche fehler gab es eigentlich bei den USART-Interrupt-Namen ?
Hallo Alexej, Alexej O. schrieb: > PPS: welche fehler gab es eigentlich bei den USART-Interrupt-Namen ? Der will beim ATMega 644 nicht die Signal-Variante: ...\uart.c(168,36): attempt to use poisoned "SIG_USART_RECV" ...\uart.c(169,36): attempt to use poisoned "SIG_USART1_RECV" ...\uart.c(170,36): attempt to use poisoned "SIG_USART_DATA" ...\uart.c(171,36): attempt to use poisoned "SIG_USART1_DATA" .././uart.c: In function 'SIG_USART_RECV': die muss dann geändert werden in: ISR (UART_RX_vect) und ISR (UART_TX_vect) ist jetzt so aus dem Kopf heraus, muss die genaue Syntax nacher noch mal nachschauen. Gruß Frank
Ich sehe das Problem. Beim ATmega644 ohne p will er die alte schreibweise nicht mehr. Werde die UART-Library in der nächsten Version aktualisieren. Danke dir für die Info. Gruß Alexej
irgend ein Frank schrieb: > Der will beim ATMega 644 nicht die Signal-Variante: > > ...\uart.c(168,36): attempt to use poisoned "SIG_USART_RECV" > ...\uart.c(169,36): attempt to use poisoned "SIG_USART1_RECV" > ...\uart.c(170,36): attempt to use poisoned "SIG_USART_DATA" > ...\uart.c(171,36): attempt to use poisoned "SIG_USART1_DATA" > .././uart.c: In function 'SIG_USART_RECV': > > die muss dann geändert werden in: > ISR (UART_RX_vect) und ISR (UART_TX_vect) Na danke schön, für die Info. Die hätte ich vor 3 Tagen gebrauchen können :) Der ATMega 644 ist generell in der uart.c nicht eingetragen. Der hat ja nur einen USART0. Das ist schonmal die 1. Änderung. Geändert muss es übrigens von/in: "SIG_USART_RECV" --> "USART0_RX_vect" "SIG_USART_DATA" --> "USART0_UDRE_vect" eingertagen hier: (uart.c)
1 | #elif
|
2 | defined(__AVR_ATmega48__) || defined(__AVR_ATmega88__) \ |
3 | ||defined(__AVR_ATmega168__) || defined(__AVR_ATmega644__) |
4 | #define ATMEGA_USART0
|
5 | #define RXCIE RXCIE0
|
6 | #define TXCIE TXCIE0
|
7 | #define RXEN RXEN0
|
8 | #define TXEN TXEN0
|
9 | #define UART0_RECEIVE_INTERRUPT USART0_RX_vect
|
10 | #define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
|
11 | #define UART0_STATUS UCSR0A
|
12 | #define UART0_CONTROL UCSR0B
|
13 | #define UART0_DATA UDR0
|
14 | #define UART0_UDRIE UDRIE0
|
Gruß Steffen
Hallo Alexej, Gibt es was neues von deiner 8/16 Graustufen Firmware? Bist du schon weitergekommen? Wenn das System stabil läuft, würde ich Leiterplatten fertigen lassen. Hier jedenfalls schonmal die Gerberfiles im Anhang. Gruß Steffen
Hallo Steffen, dein Layout gefällt mir sehr gut. Je nach Platinenpreis, hätte ich auch interesse an einem exemplar. Nun habe ich hier 5 WD-H3224V liegen, welche ich gerne mit dem Alexej Controller ausstatten möchte. @ Steffen: könntest du die Dateien rausgeben? Der Plan sieht nach Target3001 aus. Dann könnte ich deine Platine für das Wintek Display abändern. Also den MC330 als Boost beschalten und den 0,5mm Folienstecker mit integrierten Touch Leitungen einfügen. VG! Sebastian
Steffen H. schrieb: > Hallo Alexej, > > > > Gibt es was neues von deiner 8/16 Graustufen Firmware? Bist du schon > > weitergekommen? Wenn das System stabil läuft, würde ich Leiterplatten > > fertigen lassen. Bin noch nicht dazu gekommen die Software fertig zu schreiben. Ich werde es in 2 Versionen aufteilen. Erstmal eine 8 Graustufen Version und später erst eine 16 Graustufen version. Die 16 Graustufen Version macht derzeit noch Probleme durch zu starkes Flimmern. Die Hardware beschaltung wird wie bei Version 2.1 sein. Gibt es sonst noch Software seitige änderungs/verbesserungs/erweiterungs wünsche? Aktuelle Todo: - Routinnen auf 8GW erweitern. 80% fertig - Protokoll auf 8GW anpassen. - UART Lib aktualisieren. Gruß Alexej O.
Sebastian Engel (s-engel) schrieb: > Hallo Steffen, > > dein Layout gefällt mir sehr gut. Danke. Sebastian Engel (s-engel) schrieb: > Je nach Platinenpreis, hätte ich auch interesse an einem exemplar. Wenn, dann würde ich die beim Jacob machen lassen. Das wären dann ca. 15Euro/Platine Wenn du das Layout auf das Wintek WD-H3224V angepasst hast, dann könnte man diese ja auch gleich noch machen lassen. Daran hätt ich auch Interesse. Sebastian Engel (s-engel) schrieb: > @ Steffen: könntest du die Dateien rausgeben? Der Plan sieht nach > Target3001 aus. Fast.. Ist noch Target2001! Aber ich glaube man kann bei Target3001 die Datein von Target2001 einlesen und zu 3001er konvertieren. Du findest die Projektdatei im Anhang. Alexej O. schrieb: > Die 16 Graustufen Version macht > derzeit noch Probleme durch zu starkes Flimmern. Ich habe auch bei den 4 Graustufen ein flimmern in den Graufarben, sobald die Fläche dieser Groß genug ist. Oder könnte dies an meinen nur 16Mhz CPU Takt liegen? Kann mir dieses flimmern noch jemand anderes bestätigen? Hatte anfangs ja gedacht, es liegt an meiner LED Hintergrundbeleuchtung. In Benedikts 8 Graustufen Version hat er irgend einen Trick angewand, um solche Flimmereffekte zu unterbinden. Beitrag "Re: Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen" Gruß Steffen
Ein Graustufenbild kann man in mehrere Einzelbilder aufteilen, die schnell hintereinander gezeigt werden. Für 4 Graustufen hat man zum beispiel 2 Bilder. Das eine wird über das least significant bit bestimmt und 1/3 der Zeit angezeigt, das andere über das most significant bit und 2/3 der Zeit gezeigt. Soll ein Pixel schwarz sein, ist er in beiden Bildern dunkel und bleibt einfach aus. 33% Grau wäre dann weiß im 1/3-Bild und schwarz im 2/3-Bild. 66% Grau gibts mit weiß im 2/3-Bild und schwarz im 1/3-Bild. Weiß wird das Bild, wenn in beiden Teilbildern weiß abgelegt ist. Soweit sollte das ganze ja eh klar sein. Problem an der Sache: Die S/W-LCDs sind zwar meist schnarch-langsam, aber dann halt doch schnell genug, um zwischen den Einzelbildern leicht die Helligkeit zu ändern. Ist quasi wie eine PWM. Solange diese Schwankungen nur bei einzelnen Pixeln auftreten fällts nicht auf, wird die Fläche zu groß, dann sieht man ein Flackern. Benedikt hat jetzt zwei Tricks eingebaut: In Jeder Zeile wird ein anderes Teilbild angezeigt. Zeigt die erste Zeile gerade das 1/3-Bild, dann zeigt Zeile zwei das 2/3-Bild. Auf die Weise flackern große Flächen nicht mehr synchron, was das Problem deutlich entschärft. Das zweite ist, die Reihenfolge der Teilbilder zu optimieren. Bei 4 Graustufen hat man da keine Wahl, aber bei 8 oder 16 Graustufen gibt es Teilbilder, die sehr lange angezeigt werden. Teilt man diesen langen Zeitabschnitt auf und schiebt die anderen, kürzer angezeigten Bilder zwischenrein, dann lässt sich zumindest für manche Grauwerte das Flackerverhalten weiter verbessern. Bei der Konkreten Wahl der Einzelbildfolge (für beide Tricks) muss man Laut Benedikt rumspielen, da sich die LCDs unterschiedlich verhalten und so jedes bei einer anderen abfolge optimale Ergebnisse erzielt. Aber schaut doch einfach mal in die Assembler-datei von Benedikt. Da passiert die ganze Magie. Viele Grüße, Sebastian
Hallo zusammen, ich lese diesen interessanten Betrag nun seit Anfang Dezember mit und möchte Alexej für das tolle Projekt danken! Letztes WE habe die Schaltung erstmal auf einem Steckbrett aufgebaut. Als Display verwende ich das WD-H3324V. Leider zeigt das Display trotz mehrfacher Prüfung der kompletten Beschaltung nicht den Startbildschrim ab. Es tut sich einfach garnichts... Stromaufnahme ohne Display ca. 100 mA - mit Display ca. 250 mA. Zum Test des ATMEGA644 lud ich auch ein Testprogramm rein, welches einfach nur eine LED blinken lässt. Dies funktionierte fehlerfrei. Die Pinbelegung des WD-H3224V konnte ich anhand des klasse Adapterfotos von Ralf-Peter gut ablesen und auf dem Brett nachbilden: 1 = +5V 2, 9, 14, 16, 24 = GND 3 = Vee 4 = FLM = PB1 5 = Display off = PB0 6 = M/AC = PB7 7 = LOAD = PB5 8 = CP = PD5 10 - 13 = D0 - D3 15, 22 = NC 17 - 20 = Touch 0 - 3 21, 23 = Belecuhtung + Der Atmega läuft mit 16 MHz, interne Clockteilung und das JTAG ist ausgeschalten. Mit der Vee Spannung liege ich bei -25,7 V. Ein Ozzi zur genaueren Überprüfung habe ich leider nicht zur Verfügung. Im Moment weiß ich nicht mehr, wo ich noch den Fehler suchen soll und wäre für jeden Tipp sehr dankbar! @Steffen, wenn Du Platinen für das WD-H3224V fertigen lässt, hätte ich auch Interesse an 2 Stück. Vielen Dank an Euch alle. Grüße, Walter
Walter Wengler schrieb: > @Steffen, wenn Du Platinen für das WD-H3224V fertigen lässt, hätte ich > auch Interesse an 2 Stück. Das wollte Sebastian eventuell machen. Da dieses Display nichtmehr bei Pollin zu bekommen ist, benötige ich da auch keine Platine mehr von Sebatian. @Sebastian Hast du die Target2001 Datein eigentlich in Target3001 einlesen können? Gruß Steffen
Hallo, Die Datei konnte ich problemlos einlesen. Mal gucken ob das neu routen dann problemlos klappt :-) Allerdings ist zur Zeit klausurphase. Bin also nur noch amlernen. Aber in den Semesterferien könnte ich das angehen. Danke nochmal für dein projekt. Vg! Sebastian
Hallo Walter, die VEE Spannung, Pin 3, muss beim WD-H3224V positiv sein !!! Die Angaben im Datenblatt sind falsch. Bei mir ist sie, für optimalen Kontrast, zwischen +22,3V ..... +22,5V (wohl exemplarabhängig). Hast Du folgendes 1 = +5V 2, 9, 14, 16, 24 = GND 3 = Vee 4 = FLM = PB1 5 = Display off = PB0 6 = M/AC = PB7 7 = LOAD = PB5 8 = CP = PD5 10 - 13 = D0 - D3 15, 22 = NC 17 - 20 = Touch 0 - 3 21, 23 = Beleuchtung + auch in der PARAM.H angepasst ? Scheint mit der Schaltung D0-D3 zu kollidieren ? Poste mal Deine Schaltung, wäre jetzt hilfreich. Im Foto nicht zu sehen: Pin 22 ist GND Pin 15 Beleuchtung + Gruss Grelli
Hallo Grelli, herzlichen Dank für Deinen Tipp - kaum macht man es richtig, schon gehts auch ;-) Es lag wirklich "nur" an der VEE - ich bin jetzt bei +23,9V und bekomme den Startbildschrim angezeigt. Es sind zwar noch vertikale Streifen drin, doch ich denke, dass liegt zum Einen an der fliegenden Verdrahtung und zum Anderen an dem Poti für die VEE Spannung. Bitte von der Beschaltung des FFC Adapters nicht täuschen lassen. Meine Stecker sind oben kontaktiert, was ich aber erst nach dem Auflöten gemerkt hatte. Somit ist PIN 1 links unten, wo der schwarze Punkt auf der Lötfläche ist. Ich werde jetzt noch versuchen, die Einstellbarkeit der VEE feiner hinzubekommen und dann den MC34063 auf Lochstreifen löten. Vielleicht sind dann ja auch die Streifen weg. Grüße, Walter
Hallo zusammen, pe_wi hat mir gestern eine PM zum Thema geschickt, und ich denke, dass die Antwort für alle interessant sein könnte: Hallo Sebastian Du bist meine letze Hoffnung - es geht um "Grafikfähiger LCD Controller für 320x240 LCD mit D-RAM". Es funktioniert außer der 2bpp Bildübertragung alles. Bei 2bpp komme ich überhaupt nicht klar. Es wir nur ein gelöschter Bildteil ausgegeben. schräge Linie im Bsp. in PDF: 0 - wieso immer "0" wird da nicht der Grauwert codiert? 3 0 12 0 48 0 192 wie ist dieses Bildformat aufgebaut, mache ich etwas falsch (1bpp funktioniert aber) mfg Peter Zunächst möchte ich mal anmerken, dass ich DRAM-Versaion nie aufgebaut habe. Da der Code der DRAM-Version dann doch noch weiterentwickelt wurde, und sich durchaus von der SRAM-Version unterscheidet, bin ich mir nicht sicher, ob ich wirklich der Fähigste Helfer bin. Poste doch das nächste mal zuerst in den Thread. Wenn dort keiner Antwortet kannst du auch gerne einzelne Personen per PM anschreiben. Dein Beispiel kann ich nicht nachvollziehen. Im PDF ist das Beispiel für ein Graustufenbild 16 170 4 16 2 8 1 0 3 0 12 0 48 0 192 Das passt auch mit dem zusammen, was in der Doku steht und mit dem Code: 16 -> Bild-Modus 170 -> Sicherheitscode, um nicht versehentlich in den Bildmodus zu wechseln 4 -> position in x-richtung -> 4*4 Pixel nach rechts verschoben 16 -> position in y-richtung -> 16 Pixel nach unten verschoben 2 -> größe in x-richtung -> 2*4 Pixel Größe nach rechts 8 -> größe in y-richtung -> 8 Pixel Größe nach unten 1 -> 4 Graustufen modus 0 3 0 12 0 48 0 192 -> Bilddaten Ich bin zwar der Ansicht, dass in dem Beispiel zu wenig Bilddaten mitgesendet werden, ein Rechteck mit 8*4 Pixeln sollte aber trotzdem erscheinen. Wenn ddas so ist kannst du es mit dieser Folge versuchen: 16 170 4 16 2 8 1 0 3 0 12 0 48 0 192 0 3 0 12 0 48 0 192 Dann sollte auch ein 8*8 pixel großes Bild erscheinen und der Controller wartet nicht ewig auf die restlichen Daten. Hoffe es liegt wirklich nur an den falschen Eingangsdaten und wünsche dir viel Erfolg. Sebastian
Hallo Sebastian Dein Tipp, daß es zu wenig Daten sind war richtig. Mit den Daten: 16 170 4 16 2 8 1 0 3 0 12 0 48 0 192 werden 8x4 Pixel geschrieben. Ich habe dann mal: 16 170 4 16 2 8 1 0 3 0 12 0 48 0 192 0 3 0 12 0 48 0 192 eingegeben Jetzt werden 8x8 Pixel geschrieben! Es ist aber immer noch ein leeres Feld. Und nun bin ich wieder bei der Frage, wie das Format aufgebaut ist? Also hier (nur mal die Daten jetzt doppelt für 8x8 Pixel): 0 - wieso immer "0" wird da nicht der Grauwert codiert? 3 0 12 0 48 0 192 0 3 0 12 0 48 0 192 Gruß Peter
Ach jetzt versteh ichs erst! Die Zahlen die du mir gegeben hast sollen garnicht die ganze Sequenz sein, sondern nur die Bilddaten! Ok, mein Fehler. Hast du denn vorher den Farbmodus auf 4 Graustufen umgestllt? Habe ich gerade erst im Code entdeckt. In Benedikts original musste man sich zur Compile-Zeit für eine Farbtiefe entscheiden. Auf 4 Graustufen kannst du umstellen mit: 24 1 Die Führende Null bei den Beispielbilddaten ist übrigens mehr oder minder Zufall. Die ersten vier Pixel sind halt schwarz, dann ist auch das erste Byte Null. Sebastian
Das war ja mal fix. Wenn wir uns ranhalten bekommen wir das vielleicht heute noch hin ?! Die Funktion 24 ist in meiner software Version nicht verfügbar. Das Begrüßungsbild meldet sich aber in Graustufen, also gehe ich davon aus, daß der Modus stimmt. Ich habe gelesen, daß benachbarte Pixel (Graustufenversion) zusammengefaßt werden. Dann wäre das mit der Zahlenreihe klar. 0 3 0 12 0 48 0 192 Unklar die Nullen und die vielen Datenbytes. Gruß Peter
Also ich hab mal ein kleines Testprogramm geschrieben. Damit beschreibe ich den gesamten Bildbereich (Modus_1). Von 0, 1, 2....%FE, %FF und wieder von vorne, schicke ich die Zeichen zum Controller. Also ich denke irgend etwas müßte angezeigt werden. Es wird das gesamte Bild nur gelöscht und keine Anzeige. Vermutlich ist in meiner software Version ein Fehler im Modus_1. Aber weil ich von "C" überhaupt keinen Durchblick habe, ist das eine schwierige Sache. Vielleicht liegt der Fehler aber in der "lcdcon.S". Gruß Peter
Welche Software-Version verwendest du denn und wieso verwendest du nicht die aktuelle? Vielleicht ist in deiner Version ja einfach ein Bug... Die Nullen und die Zahl der Bytes sind doch logisch. Du hast 8*8 Pixel, je Pixel 2 bit, also brauchst du 8*8*2 bit also 128 bit oder 16 Byte. Die Daten der Pixel stehen dann der Reihe nach in den Bytes drin. Also das erste Byte codiert die ersten vier Pixel, das zweite Byte die nächsten vier. Das dritte Byte hat dann die dritten vier Pixel, also die ersten vier Pixel der zweiten Zeile. Und da die ersten Vier Pixel schwarz sind muss auch die erste Zahl Null sein.
Weil ich Minimalist bin verwende ich einen Atmega_8 (Display 480x 128). Ich habe die software vom atmega_88 angepaßt - timer und interrupt. Ich vermute der Fehler kommt aus der "write byteeg" routine. Diese ist in dieser Version vermutlich nicht getestet worden. Gruß Peter
Und mit dieser klitzekleinen Nebensächlichkeit kommst du jetzt? Wenn ich mal wieder zeit hab schau ich vielleicht in deinen Quellcode. Bis dahin geb ich nur die Empfehlung ab, die neueste Version dieses Projekts als Basis für deine Portierung zu verwenden... Sebstian
Tut mir leid - wegen der späten info! Gruß Peter
Hallo ich hoffe das liest noch einer...... Ich habe das Projekt nachgebaut und das Display zeigt auch den Begrüßungsbildschirm richtig an. Wenn ich aber über UART das Display anspreche zeigt es nur ein komplett Weißes Bild (über das gesammte LCD). Ich denke aber das die Hardware richtig arbeitet, da ja der Begrüßungsbildschirm angezeigt wird. Oder kann das trotzdem ein Fehler in der Schaltung sein? Für ein ansteuerungs Beispiel währe ich auch dankbar, muß aber nicht sein. Ich würde mich sehr freuen eine Antwort zu bekommen. Grüße Thomas
Läuft dein uart sender und empfänger synchron? Gruß Peter
Hallo Peter Vielen Dank für Deine Antwort. Habe verschiedene Baud Raten versucht, ohne Erfolg. So wie ich das Programm verstehe, kann ich eine Baud rate wählen und der LCD Contr. erkennt es automatisch. Der Sender läuft mit dem Controller von Benedikt aus dem Beitrag "Einfacher Low Cost LCD Controller für 320x240 LCD im Textmodus" einwandfrei, also kann es der Sender ja nicht sein. Ist Denn die Hardware OK wenn das Startbild kommt? Ich benutze die Version 2.1 mit Atmega 16, habe aber den Atmega 644P bestellt und werde es damit nochmal versuchen. Vielen Dank für Deine Mühe..... LG Thomas
Hallo Thomas Der Controller erkennt die baud_rate nicht automatisch. Diese mußt Du festlegen und in Deinem Sender auch. Ich glaube die Übertragung funktioniert, aber die beiden verstehen sich nicht. Denn es wird ja was empfangen (das Bild wird gelöscht)... Was sendest Du denn zum Controller? Gruß Peter
Hallo Sorry mein Fehler. Die Baudrate über Jumper einst. Ich sende mit Bascom die unten stehenden Befehle Wait 2 Do Printbin 12 Wait 1 Printbin 17 ; 1 ; 1 Print "Test" Printbin 3 Wait 1 Printbin 1 Wait 1 Printbin 2 Wait 1 Printbin 200 Wait 1 Printbin 20 Wait 1 Printbin 15 Wait 1 Printbin 17 ; 1 ; 1 Print "Test" Printbin 17 ; 2 ; 2 'Printbin 10 Print "Test" Loop Das sollte doch gehen. Hab alle Baudraten probiert, immer weißes Bild. Wenn ich die Waits vergrößer, dauert es auch länger bis die Begrüßung weg geht. Der LCD Contr. bekommt schon Daten. Thomas
Hallo Thomas Ich glaube Du gehst die Tests zu kompliziert an. 12, Bild löschen funktioniert ja Sende danach einfach nur mal ein Zeichen. Übrigens der Bildschirm muß nicht unbedingt gelöscht werden. 20, (Rechteck) - danach müssen 6 Parameter kommen! Gruß Peter
Hallo Alsooo....Hab es mit dem ATMEGA644P versucht, weil ich eh die großen Fonts haben wollte. Dann habe ich nochmal die Änderungen im Programm die Steffen H. weiter oben beschreibt überprüft und geändert. Die Fuse Bits habe ich nochmal geändert, da je nach Einstellung der Fuses auch ein Weißes oder Flackerndes Bild erscheint. FuseBits mit AVR Dude: Low EF High D9 Danach alles super. Funktioniert Prima nochmal vielen vielen Dank für Deine Hilfe. Grüsse Thomas
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.