Hallo, weiß jemand, wie die LEDs im Display geschaltet sind (reihe, parallel)? Woher stammen die bisher verwendeten Werte? Reichen 5V aus? danke, leif
Hi Leif, du kannst auch mit 1 Volt betreiben, allerdings bleibts dann dunkel. Die Werte stammen aus den inoffiziellen Supportdokumentationen zum Nokia Handy. In denen ist der Schaltplan mit einigen technischen Werten verzeichnet. Dort wird 6.4 Volt und 30mA angegeben. Nun, eine weiße LED kann heutzutage 30mA ohne Probleme ziehen, bei ca. 1.25 bis 3.2 Volt. Somit sind die LEDs des Displays mit hoher Wahrscheinlichkeit in Reihe geschaltet. Gruß Hagen
Angehängte Dateien:
-
LCD-pins.jpg
25 KB
AHH, danke Hagen :-) wie kommen denn "inoffiziellen Supportdokumentationen" in Umlauf, fragt sich der Leser. Und wie kann sowas inoffiziell sein..Naja. bleibt dunkel..ich wollte doch nur in erfahrung bringen, ab wann die dinger 'zünden'. werde mich nochmal schlau machen, mit welcher methode man mit weniger bauteilen wegkommt, vielleicht mach ich's dir ja doch nach.. anbei nochmal ein scan von den LCD anschlüssen..wenn du lustig bist, kannst du's zu deiner lib packen, falls da nicht schon sowas drin ist. wie läuft's mit dem wecker? -leif
übrigens ist mir mal aufgefallen, daß mein nokia 6610 wirklich schwarz anzeigt. könnte die aufgetretene blaufärbung evtl. was mit der ansteuerung der leds zu tun haben? und, ich habe den eindruck, daß mit eingeschaltetem blacklight auf einmal alles recht unscharf erscheint. geht euch das auch so? -leif
die 30mA sind übrigens als maximum angegeben und als empfohlen nur 15 wenn ich mich jetzt nich täusche auf jedenfall is die Helligkeitszunehme zwischen 15 und 30mA Stromaufnahme nich mehr der Rede wert und mit 15 dürfte die Lebensdauer wohl erheblich höher liegen
>wie kommen denn "inoffiziellen Supportdokumentationen" in Umlauf, >fragt sich der Leser. Und wie kann sowas inoffiziell sein..Naja. Nokia muß ja Support bieten, und dazu benötigen die Fremd-Support-Firmen auch Dokumentationen. Sogesehen bringt Nokia die Dokus selber in Umlauf. In den meisten Dokus findet man dann auch Bemerkungen das diese Dokus nicht veröffentlicht weren dürfen. Es gibt aber nun einige Menschen die sich nicht daran halten und diese Dokus ins WEB stellen. Inoffiziell bezieht sich also nur darauf das Nokia diese Dokus nicht offiziell für den Nicht-Support-Bereich veröffentlicht hat. @Leif, vielleicht könntest du ja mal ein Foto hier rein stellen. Ich hatte den Eindruck das bei mir eventuell die silberen Reflexionsfolie daran schuld sein könnte. Gruß Hagen
Danke für die Aufklärung :-) Ich hab leider noch keine Kamera, auf der man das erkennen könnte.. Du meinst, das sich das von hinten beleuchtete Bild nochmal in der Folie reflektiert? Aber wieso tritt dann kein ähnlicher Effekt bei Tageslichtbeleuchtung ein? -leif
Nee, ich habe mein Flachbandkabel an die Silberfolie geklebt. Dadurch kann es vorkommen das die Silberfolie nicht mehr exakt am LCD anliegt. Allerdings habe ich nach einigen Test mit angedrückter Folie keinen Unterschied bemerken können. Bei mir bleibt das Schwarz immer bläulich. Es könnte nun nur am Hersteller liegen, wo hast du dein LCD her ? Gruß Hagen
na ich weiß nicht. das original nokia display (in meinem 6610 drin, grüne flexplatte) hat das ja auch, genau wie die über ebay ersteigerten. und bei beiden ist schwarz gleich schwarz, und blau gleich blau. dann vermute ich, daß die verschiedenen glas schichten was damit zu tun haben. aber rausfinden wird wohl nicht lohnen, weil man dann eh nix ändern kann.. -leif
Wie sieht denn bei euch die Displayfarbe aus, wenn ihr nur die Hintergrundbeleuchtung einschaltet? Also bei mir sieht sie bläulich aus. Wenn ich aber schwarzen Text mit weißem Hintergrund habe, so sieht für mich die Textfarbe rein schwarz aus. MartinK
Stark bläulich, und der schwarze Text erscheint deshalb schwarz weil nur wenige Pixel "blau" sind. Nimmt man zb. 40x40 große Zeichen so wird aus dem schwarz ein blau, eben weil die "schwarze" Pixelfläche nun wesentlich größer ist. Wenn das Display leicht bläulich leuchtet obwohl alle Pixel schwarz sind (vom RGB Wert her gesehen) dann ist schwarz auch immer leicht bläulich. Es erscheint bei normalgroßem Text eben nur als Schwarz. Das Problem dürfte in der LCD Technologie liegen, die eben bei schwarzen Pixeln das Backlight das durch das LCD dringt nicht 100%'tig abdunkeln kann. Deshalb hat mich ja Leif's Aussage so verwundert und ich dachte ich habe ein minderwertiges LCD. Gruß Hagen
Hallo Hagen, ich hab da mal zwei Fragen: Und zwar zum Hardware Reset für das Display. Könntest Du so nett sein, und mir das Timing vom Hardware Reset des LCD Controllers kurz erläutern? Im Datenblatt vom Controller steht ja, dass nach power up auf jeden fall ein reset durchgeführt werden muss; könnte man den power-up reset nicht über ein rc-glied durchführen? Ansonsten kann man ja per software reset'en. Setzt du in der library den hard- oder softwarereset ein? Und die zweite Frage ist auch zum Thema: Ist es machbar, über pwm eine konstante spannung zu erzeugen; bzw. wie ist es möglich, das so hinzubekommen, das der MAX1848 (der den LED Strom regelt) ein möglichst gleichförmiges Steuersignal bekommt? Wie sähe so ein Filter aus? Besten Dank schonmal :-) -leif
Hi Leif, Zur PWM des Backlights: Du musst keinerlei Filterung bauen. Wenn die Frequenz hoch genug ist dann benötigt man für LED's keine extra Glättung der Spannung mehr. Das Auge kann bei zB. 1KHz PWM keinerlei Flickern der LEDs wahrnehmen. Es ist also unnötig die Spannung zu glätten. In meinem Weckerprojekt arbeite ich sogar mit 36KHz PWM, aber das liegt daran das diese PWM auch für meine IR Reflexionslichtschranke mitbenutzt wird. Die LED's sind so schnell und verlustarm mit PWM's das man keine Glätung per RC Glied mehr benötigt, sondern nur entsprechend hohe PWM Frequenzen. Dies geht nur bei LED's aber zB. nicht bei induktiven Lasten. Das einzigste was man beachten muß ist das die psychlogische Helligkeit der LED's die unser Auge empfindet NICHT linear zur Pulsbreite der PWM verläuft. D.h. die Pulsweite der PWM muß nichtlinear eingestellt werden. Meistens wird behauptet das eine Logarithmische Scalierung der Pulsbreite der psychologischen Helligkeitsempfindlichkeit unserer Augen entspricht. Bei meinen Experimenten konnte ich dies so nicht bestätigen. Bei mir ist es eher so das eine lineare Änderung der PWM dazu führt das die LED's von Dunkel nach Halbhell langsam immer schneller heller weren, und ebenso von Ganzhell nach Mittelhell der gleiche Effekt auftritt. Dieses würde bedeuten das die PWM Pulsbreite nicht logarithmisch sondern in einer Parabel logarithmisch eingestellt werden müsste. Nungut, in meinem Projekt habe ich auf diesen zusätzlichen Aufwand verzichtet und stelle die Pulsweite der PWM innerhalb von 2 Sekunden von 25% auf 0% = Dunkel ein. Die sich daraus ergebende ungleichmäßige Helligkeitsänderung erscheint dann so als ob das LCD sein Backlight von langsam immer schneller werdend abdimmt bzw. einschaltet. Ich finde dies sieht sogar besser aus als eine lineare Helligkeitsab-/zu-nahme. Reset: Der Reset in der GLCD wird Hardware- und Softwaremäßig durchgeführt. Beide Reset's des LCD's sind absolut notwendig. Wichtig ist auch das in meinen Experimenten es sich zeigte das beide Resets zeitlich korrekt nacheinander durchgeführt werden müssen. Es wäre schön wenn man die HW-Reset Leitung einsparen könnte, durch externe Hardware. So bekäme man eine Pin des AVR's frei, der eben nur einmalig zur Initialisierung des LCD benötigt wird. Im späteren Verlauf der Ansteuerung des Displays wird diese Leistung eigentlich nicht mehr benötigt. Allerdings ich selber habe noch nicht soviel Ahnung von solchen Hardwarelösungen. Das Reset Timing ist in den Datenblättern beschrieben, schau am besten dort mal nach, da ich das hier im Forum ohne Diagramme schlecht erklären kann. Nachdem man das HW-Reset des LCD's durchgeführt hat kann man beliebig oft einen SW-Reset durchführen. Allerdings muß man danach immer auch die Farbtabelle für's Mapping von 8bit zu 12Bit Farben neu initialisieren. Dies steht so nirgends in den Datenblättern und ist ein Erfahrungswert von mir. Macht man dies nicht so zeigt das LCD immer nur blau an, so als ob es nicht funktionieren würde. Laut Datenblättern wäre es aber so das diese Tabelle nach einem SW-Reset mit den Defaultwerte initialisiert wäre, es ist aber nicht so. Auf AVR Seite ist es wichtig zu wissen wie das SPI arbeitet. Wird Zb. der ~SS Pin = Slave Select nicht als Ausgang definiert, so kann es vorkommen das der SPI Kontroller des AVR's übe diesen ~SS Eingang in den Slave Mode des SPI's umschaltet. Ab diesem Moment funktioniert aber die Ansteuerung des LCD's durch die GLCD nicht mehr. Ich habe diesen Fall NICHT berücksichtigt. Aus diesem Grunde empfehle ich auch den ~SS Pin auf Ausgang zu schalten und als Chip Select = CS für das LCD zu benutzen. Wird das LCD so angeschlossen, was in der GLCD per default der Fall ist, kann es nicht zu diesem SPI - "Problem" kommen. Gruß Hagen
Hallo Hagen, vielen Dank für Deine ausführliche Antwort!! Backlight: Vielleicht hätte ich etwas direkter auf den MAXIM IC hinweisen sollen - der übernimmt nämlich die komplette Stromregelung der LEDs, wird aber über einen Analogeingang angesteuert. Und soweit ich das beurteilen kann, ist dieser Analogeingang recht empfindlich. Deswegen die Frage nach dem glätten per Filter. Aber trotzdem danke für die Informationen. Reset: D.h., Du führst nur 1x am Anfang zur Initialisierung einen HW Reset durch, und wärend des Programmablaufes per SW? Da wäre doch ein elektronischer Reset sehr brauchbar (in den Application Notes von VLSI ist so ein RC-Glied für den MP3 Decoder als Beispiel; den kann man aber leider nicht per Software in den Power-down Modus setzen). Die Frage ist dann aber wieder, ob das mit dem geforderten Timing, das ich nicht verstehe, auch funktioniert. Muss man einen Reset Impuls verwenden, oder reicht es, den an/auszuschalten. Falls ein Impuls benötigt wird, bedeutet das für mich zuviel Hardware-Aufwand. Na, ich versuch nochmal das Timing nachzuvollziehen. bis bald, -leif
Das Problem dürfte entstehen dadurch das man das CS ebenfalls zum HW Reset ausführen muß. D.h. innerhalb des HW Resets am Pin muß das CS gesetzt werden und der AVR darf seine SW Reset und BoosterUp nicht vor dem HW Reset tätigen. Somit benötigt man eine Synchronisation des AVR's mit dem HW Reset des Displays. Den Pin den man durch externe HW ersetzen würde benötigte man dann wiederum um die externe Reset-HW synchron zu bekommen. In den Datenblättern zum Nokia Handy wurde ebenfalls der HW-Reset-Eingang des LCD's über digitale Leitungen angeschlossen. D.h. auch dort übernimmt die Softare den HW Reset. Im Datenblatt des MAX1848 auf Seite 6 steht das am CTRL Eingang entweder eine DAC = Analoge Spannung oder aber eine digitale PWM angelegt werden kann, wenn ich bei Überfliegen des Datenblattes nichts falsch verstanden habe :) Gruß Hagen
Aha, dann brauch ich also doch zwei Reset-Leitungen. Danke. Zum MAX1848..ich weiß aber nicht, ob die unter "simple logic-level on/off control" auch pwm verstehen. dafür wär dann doch eigentlich der dac eingang da. nee, ich glaube, das klappt nicht. die schreiben auch was von einem soft-start, der fast 1ms braucht. tjaa. einen pwm steuerbaren baustein hab ich bei maxim auch vergeblich gesucht. steht da was in deinen dokus, wie nokia das macht? werd ich wohl mal nach einem geeigneten filter ausschau halten. andererseits nimmt das dann wieder zusätzlichen platz weg. mhh. ich weiß auch nicht. na denn, bis später -leif
> dann brauch ich also doch zwei Reset-Leitungen Stopp, wieso ZWEI Reset Leitungen ? Das LCD hat nur einen ~RESET und einen ~CS Pin. Den ~CS Pin benötigst du permanent. Am Anfang der GLCD habe ich das Chip Select so gebaut das es das LCD nur einmalig selektiert hatte und dann selektiert blieb. Dies hatte aber zur Konsequenz das die Störanfälligkeit der SPI Kommunikation zum LCD über lange leitungen enorm zunahm. "Abstürze" des LCD's waren also sehr wahrscheinlich. Die neue GLCD setzt nun das ~CS Signal nach Beendigung der SPI Kommunikation automatisch zurück. Somit bleibt das LCD nur solange wie Daten gesendet oder gelesen werden selektiert. Dies reduzierte die Störanfälligkeit des SPI's drastisch. Bei 50cm Zuleitungen traten dann keinerlei Aussetzer mehr auf. In der Schematik des Nokias ist ein 8Pin Chip eingezeichnet mit der Bezeichnung TK11851L der ein DC-DC Booster mit Induktivität sein muß. In der Partlist wird er angeben als Bauteil N300, DC/DC Converter 350MA TK11851 SSOP8, also im SOT32L_8 Gehäuse. Aber, soviel ich weis werden beim Nokia die LED's nicht stufenlos gedimmt. D.h. dein MAXIM müsste ebenfalls gehen, aber eben nur im EIN/AUS Modus, ohne Analoges Signal oder eben dimmbare Helligkeit der LEDs. Du kennst meine Lösung mit dem MAX3224 RS232 Treiber Baustein ja. Der würde deine Probleme lösen und eben noch eine RS232 zusätzlich bieten. Gruß Hagen
Man könnte die RESET Leitung aber tatsächlich per HW steuern lassen. Der jetzige Pin für's Reset am AVR würde dann als Spannungsversorgung des LCD-Controllers benutzt. An dieser Leitung würde deine zusätzliche Reset HW sitzen. Sobald das LCD über diesen Pin mit Strom versorgt wird würde das LCD über die extra Hardware zurückgesetzt. Der Vorteil wäre das du nun direkt über die Software das LCD mit Strom versorgen könntest. Normalerweise zieht der Controller des LCD's nur 0.9mA, also erträglich wenig für den Pin. Somit hättest du eine Möglichkeit das LCD komplett abzuschalten was bei Batteriebetrieb die Lebenszeit erhöht und hast denoch die volle Softarekontrolle über die zeitlich korrekte Initialiserung des LCDs. Gruß hagen
Hi Leif, warum hast du dich für den MAX1848 statt dem MAX1553/54 oder MAX1689 entschieden ?? Bei den letztgenannten Typen kannst du auf http://para.maxim-ic.com:80/compare.asp?Fam=whiteLED&Tree=Display&HP=Display.cfm&ln=&SORD=1135&FT_1135=13058&ITEMLIST=114697,114699,128273,128274,128318,128319,133982 nachlesen das deren Operation Frequency NICHT fixiert sondern variabel ist, in der obigen Tabelle als PFM bezeichnet. Diese Typen haben einen extra PWM Eingang um die Uout zu regulieren. Gruß Hagen
Guten Morgen Hagen, das habe ich gemacht, da mir das eine Package zu schwierig zum Löten erschien, und der andere einen externen FET hat (soweit ich mich erinnere). Aber ich hab mich nochmal umgesehen, der MAX1599 scheint auch eine gute Wahl. Ich seh's mir aber in Ruhe nochmal an, danke! Wahnsinn, was die Leute alles in einem Handy unterbringen! 8D -leif
Hm, glaubst du das du das TDFN Package des MAX1599 löten kanst ? Immerhin ist das Ding nur 3x3x0.9 mm groß. Gruß Hagen
Alles geht, wenn man nur will :-) Habe schonmal QSOP mit ner viel zu großen Lötspitze an Slberdrähte auf Lochraster gelötet; aber wenn man ein pcb hat, und eine lötnadel mit 0,4mm, und ne lupe, und viel zeit, dann sollte das doch eigentlich gehen..hoffe ich zumindest. aber vielleicht gibt's ja noch ne andere lösung, die mit noch weniger externen bauteilen auskommt. We'll see. -leif
Rein theoretisch kann der AVR die gleiche Aufgabe übernehmen die der externe Chip erledigt. Dazu benötigte er auch nur die Diode, Kondesatoren und die Induktivität. Der AVR würde dann ebenfalls per PWM die Spannung pumpen. Irgendwo im WEB hatte ich mal so'n Schaltplan gesehen. Die Strombegrenzung wäre natürlich nicht inklusive. Gruß Hagen
Oh, ich seh jetzt erst daß ich deine Beiträge gar nicht mitbekommen habe.. 'Tschuldigung, ich meinte zwei Resets für meine 'applikation', 1 für lcd und ein für Mp3 Decoder. Aber das Display komplett auszuschalten ist auch eine interessante Lösung. Die Ladungspumpe selbst zu bauen, finde ich ein wenig zu komplex.. -leif
Angehängte Dateien:
-
VBAlpha_332.gif
3,2 KB
Hallo Hagen, ich hoffe, Maxim sind so nett, und stellen mir den MAX1561 zur Verfügung. Der braucht nicht mehr externe Bauteile als der MAX1848, ist in einem klasse Bereich PWM fähig und schaltet sich weitestgehend ab, wenn das PWM Signal low ist. Wie das mit dem Löten ist, werde ich dann ja sehen (müssen). Nachdem ich mir gestern vergeblich überlegt hatte, wie ich ohne größeren Aufwand die Farbpalette im 256 Farb Modus generieren könnte, hab ich eben folgendes gesucht und gefunden: http://www.ur.co.nz/static/default_typeid_3_dataid_371.htm Sicherheitshalber die Datei im Anhang. Jetzt steht dem GUI Design Nix mehr im Wege. Planst Du eigentlich eine Funktion für BMP printing? Naja, das hat noch Zeit..und kostet Resourcen. Was macht dein Wecker, und wie sieht er aus? Schönen Gruß, Leif
Hi Leif, > Planst Du eigentlich eine Funktion für BMP printing? Eigentlich nicht. Es stehen dir aber drei Wege offen. 1.) mit glcdDisplayBuffer() und glcdSetAddr(). Dabei wird als erstes mit glcdSetAddr() ein Displaybereich ausgewählt der exakt so breit und hoch ist wie die Bitmap. Danach kannst du mit glcdDisplayBuffer() die 8Bit Farbdaten des Bitmaps direkt in einem Rutsch ans Display senden. Die Umbrüche in der Y Richtung macht der Kontroller automatisch. D.h. deine eigene Bitmap muß die Pixel als 8Bit Werte sequentiell von links oben nach rechts unten im Speicher ablegen. Einfach als eindimensionales oder zweidimensionales Bytearray. Der Nachteil ist aber das die Farbinformationen von vornherein auf das LCD abgestimmt sein müssen, und das eben keine Transparenz möglich ist. Ebenso sind die Daten nicht komprimiert und verbrauchen eventuell zu viel Platz. 2.) so wie 1.) aber du baust mit glcdPutPixel() oder glcdDisplayData() deine eigene glcdDisplayBuffer() Funktion. In diesem Moment hast du die freie Wahl wie du die Bitmaps speicherst, ob sie transparent sein können oder nicht. 3.) oder du benutzt die Fonts. Dabei werden die Bitmaps als Fonts gespeichert. Als erstes musst du dann das glcdColors[] array in der Größe anpassen. Dazu wird das DEFINE COLOR_TABLE_BITS == 8 gesetzt, also 256 Farbeinträge im Array. Diese verbraucht dann aber schon 256 Bytes RAM. glcdColors[] dient als Farbtabelle der Fontdaten, d.h. durch ändern der Werte in dieser Tabelle kann das gleiche Zeichen unterschiedlich farbig gezeichnet werden. Zudem wird damit auch eine variable Transparenz der Zeichen erreicht. Nachdem du glcdColors[] angepasst hast müssen jetzt einige Änderungen im Fonteditor erfolgen. Denn auch dieser muß neucompiliert werden damit er 256 Farb Symbole unterstützt. Angedacht war dann das man Bitmaps so wie Windowsfonts importieren kann. Dabei wird beim Import der Bitmaps oder Icons die Farbpallette ermittelt und auf einen gemeinsammen Nenner gebracht. D.h. alle Bitmaps/Icons/Symbols im Font benutzen die gleichen Farbinformationen. Diese Farbtabelle müsste vom Editor separat gespeichert werden, entweder als Erweiterung zum Font oder eben separat. Wichtig ist aber das man nun nur noch EINEN Code zum darstellen von Fonts/Bitmaps/Icons benötigte statt verschiedene. Und das der Font selber eine relativ effiziente Komprimierung enthält. Zudem wäre nun die Flexibilität in der Anzeiger der Bitsmaps höher. Erstens eben durch die Farbtabelle was eine Virtualisierung der Farbpixel zuließe, statt einer 1 zu 1 Anzeige, und zweitens in der Ausgabe dieser Bitmaps. Denn da in einem Font mehrere Bitmaps gespeichert wären, würde das Zeichen das man mit glcdDrawChar() zeichnet als Index in unserer Bitmap/Icon Liste dienen. Nachteilig bei der Sache ist aber das man in einem Font nur Zeichen/Bitmaps speichern kann die ALLE die gleiche Pixelhöhe besitzen. Dies dürfte aber für die meisten Zwecke weniger hinderlich sein als erwartet. Auf alle Fälle würde dieser Weg der einfachste und flexibelste sein. Nun, das was dir aber fehlt sind die Sourcen des Fonteditors. Ich habe ihn mit Delphi5 programmiert, falls du dich also mit D5 auskennst kann ich dir die Sourcen zur Verfügung stellen. > Was macht dein Wecker, und wie sieht er aus? Er dümpelt und liegt erstmal auf Eis. Meine Deadline war der 29.5. und die konnte ich nicht einhalten. Der wichtigste Grund war der Fakt das ich noch keine Platinen ätzen und sie nicht selber erzeugen kann. Dies ist ja gerade der Punkt an dem ich noch Werzeuge und das entsprechende material anschaffen muss. Ein weiteres Problem ist das Gehäuse. Leider finde ich keinerlei Infos oder Erfahrungsberichte im WEB die diese Problematik abhandelt. Mich würde es schon interessieren wie ein Amateur gut und professionell erscheinende Gehäuse selber baut. Gruß hagen
Hallo Hagen, wiederum verbindlichsten Dank für Deine ausführlichen Tipps! Schon allein deswegen fühle ich mich ja gezwungen, ein sauberes Projekt auf die Beine zu stellen, und Dir als Ergebnis zu präsentieren :-) Schade, daß es mit dem Geburtstag nicht geklappt hat, aber gute Geschenke lassen sich ja nicht nur zu Feiertagen an die Frau bringen.. Mann kann sich ja nicht jedesmal selbst übertreffen.. Delphi und sonstige Windowsprogrammierung habe ich noch nicht drauf, aber das kann ja irgendwann nochmal werden. Sämtlich hier von mir gemachten Überlegungen sind ja zugegebenermaßen rein theoretisch, an die Software werd ich mich wohl erst begeben können, wenn die Hardware steht. Und damit ich dann keine bösen Überraschungen erlebe, versuch ich mich halt so gut es geht vorher zu informieren, und hoffe aufs Beste. Richtig 'mitreden' werd ich wohl erst in ein paar Wochen können, wenn die Plattform erfolgreich zusammengelötet ist. Vorher muß ich noch mit Eagle kämpfen. Dann werde ich mir wohl erstmal von Dir den Code schnappen, und das Display als Debug-Window benutzen. Oder RS232 über IR (deswegen brauch ich eigentlich keinen max232..). Wird schon klappen! Also hier nochmal der eindeutige Beweis, daß ich mich nicht geirrt habe; meine Displays zeigen ein 'astreines' Schwarz! Also sowohl das im 6610 verbaute (grün), als auch die über Ebay ersteigerten (braun). Das ich mich geirrt haben sollte (aufgrund des Konstrastes) kam mir eh schon komisch vor, schließlich hatte ich auch blaue Vergleichsobjekte auf dem Display. Habe zum Testen mal ein Bild auf mein Handy geladen, mit einem großen schwarzen Block: schwarz. Und zwar bei allen Displays. Allerdings mußte ich feststellen, daß mein Rumspieldisplay (das gescannte) einen total schlechten Kontrast hat, und weil ich beide nach Erhalt schonmal getestet habe, fürchte ich, daß ich das Ding beschädigt habe. Fluch! Vielleicht hab ich das beim Durchklingeln geschrottet? Oder ESD? (mir fällt gerade ein, daß ich trottel das display ohne isoliertape ins handy gebaut hab, vielleicht ist es ja doch nicht schrott, sondern war irgendwohin kurzgeschlossen..). Aber nochmal ne Frage an Dich: Du kannst Doch bestimmt rausfinden, was die Anschlüsse der Handybatterie sind, und wo die hingehen? Oder ich such selber mal sowas zum 6610. Vielleicht läßt sich über den batterie-bus ja was über die Restkapazität rausfinden. Oder schätzt man das anhand der laufzeit und der spannung ab? Zum Gehäuse: Such Dir doch jemanden mit CNC Fräse, oder jemanden mit viel Zeit und Fräse. Und dann laß Dir das Gehäuse für einen Kasten Bier oder so aus Kunstoff/Alu fräsen, bei den Maßen ist das ja noch machbar. Einziges Manko (meines Wissens) ist, daß man wohl keine exakten Winkel innen fräsen kann, weil die Werkzeuge ja einen Durchmesser haben; also Platine an den Ecken abrunden. Hast Du eigentlich eine Möglichkeit, Dein Menü mal der öffentlichkeit zu präsentieren? Ich überlege nämlich, wieviel Spielraum mir für das Menü und die anderen Funktionen bleibt, während ich den Decoder mit mp3 daten versorge. und was man da alles schönes umsetzen könnte. aber bei 4mhz spi takt und 256kbit/s mmc->avr->mp3 ist da doch eigentlich noch massig luft fürs display. Gespannt, Leif
Tja, ich Trottel hab wohl das eine Display beschädigt; auch mit Isolierung läuft es nicht mehr mit ausreichendem Kontrast :-( Vorsicht Strom, Leif
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.