Nokia-3310-Displays -Bestellung-

[Screaming_Rabbit]

Meine sind auch angekommen und sehen heil aus. - Nochmals vielen Dank.

mir ist beim Basteln eines über den Jordan gegangen

... deshalb habe ich 9 bestellt... einen Fehler erträgts bei mir :-)

Greets, Roger

[MTE]

Moin, leider nicht, ich müsste erst wieder 50 bestellen, habe aber grade kein Geld zum Vorstrecken :(

Sachmal wie invertiert man denn die Zeichen wie auf dem Foto zusehen ist ?

Grüße

[pay_c]

Ist händisch gemacht. Ich habe ein eigenes Proggi dazu angepasst. In meinem Proggi (ich habe *keine* Ahnung, ob das bei TK´s Treibern auch möglich ist) wird der komplette Display zunächst im RAM gespeichert (und außerdem pro Byte noch ein Flag "geändert"). Daher ist invertieren kein Problem, einfach einen XOR mit 0xFF über den entsprechenden RAM-Bereich laufen lassen. Ist alles erledigt, werden alle Bytes in einem Aufwasch ans LCD gesendet (bzw. nur die mit dem "geändert"-Flag). Spart eine Menge SPI-Akitivität ein.

Naja, die Displays bekommt man ja ohne Probs auf Ebay, werde mal schauen, ob ich wieder so nen Preis herbekomm... :)

[ilmenator]

Moin pay_c,

Die Ansteuerung ist anfangs etwas knifflig (vor Allem die korrekte SPI Konfiguration),

kannst du da noch ein bisschen mehr zu sagen? Ich habe mir vor langer Zeit an diesen Displays mal die Zähne ausgebissen und sie nicht zum Laufen gebracht - ich bin allerdings überzeugt davon, dass die nicht _alle_ kaputt gewesen sein können.

Vielleicht ein Eintrag im WIKI :D ??

Grüße und Dank, ilmenator

[pay_c]

Puh, Wiki wird hart, soweit bin ich sicherlich noch nicht, außerdem gibts *SEHR* interessante, andere Displays, an denen ich mir sehr viel mehr die Zähne ausbeisen *will*. :) Hier z.B. ein 6610er Display ebenfalls mit SPI Ansteuerung, allerdings 132x132 Pixeln und das Ganze mit 4096 FARBEN (!!!!!!!). Das geilste an diesem Display: 20 Öcken auf Ebay, ca. 3-5 Euro für einen passenden SMD-Stecker macht 25 Euro für einen Display, der sehr sehr sehr geil ist. Beispiele (nur exemplarisch) hierzu hier: http://thomaspfeifer.net/nokia_6100_display.htm http://www.e-dsp.com/controlling-a-color-graphic-lcd-epson-s1d15g10-controller-with-an-atmel-avr-atmega32l/ (PS: Die LCD´s mit den Lötpunkten auf der Rückseite gibts leider kaum noch, man kommt nur noch an welche ran mit nur dem Stecker) und hier http://www.sparkfun.com/commerce/product_info.php?products_id=569

Das sehr sehr schöne und angenehme an diesem Display: Ein Pixel benötigt 12 bit Farbinformation, d.h. es wird ein 8-bit SPI Befehl zum setzen des Pixels gesendet, anschließend 2 8-bit SPI´s mit den Farbinfos (wobei die letzten vier Bit automatisch auf das nächste Pixel übernommen werden *können*, muss aber nicht sein). Damit ist die Adressierung natürlich ein Kinderspiel und es ist kein 8-bit herumgerechne wie bei allen monochromen Displays nötig (jeder, der so etwas schon mal selbst programmiert hat, weiß was ich meine). Natürlich hat das Ganze einen krassen Nachteil: Um den gesamten Bildschirm zu beschriften, sind mindestens ~ 25k 8-bit SPI-Befehle nötig, das dauert locker mal eben 10 - 20 ms, in denen der Controller andauernd per SPI sendet. Glücklicherweise sendet man ja normalerweise nur die benötigten Sachen. /edit: Außerdem gibts noch einen 8-bit Modus, d.h. es ist nur ein 8-bit SPI-Befehl pro Pixel nötig, allerdings hat man dann "nur" 256 Farbstufen.

Hmm, blöde Frage: TK, wie wäre hier das Interesse Deinerseits?

Zu der 3310er Ansteuerung habe ich dieses hier "missbraucht": http://www.microsyl.com/nokialcd/nokialcd.html Ich habe den Code kurzerhand auf AVR GCC konvertiert und dann lief alles. Dort kannst Du sicherlich einige Befehle mal rauslesen. Vor allem der etwas komplizierte Init ist böse ("Extended" Befehle ein, Kontrast setzen, Temperaturkoeffizient setzen, BIAS auf 48, korrekte Adressierung (horizontal) und dann zurück in den Normal Mode -> HEIEIEIEI... endlich fertig).

Hier gibts auch noch ne ganze Menge Info und weitere Links zu Sachen Ansteuerung: http://serdisplib.sourceforge.net/ser/pcd8544.html

Grüße!

PS: Sorry für den Roman und das teilweise Off-topic Gelabere. ;)

[ilmenator]

Farbdisplays sind nicht nur aus den von dir schon genannten Gründen für mich nicht wirklich interessant  :).

Ich habe den Code kurzerhand auf AVR GCC konvertiert

Was meinst du mit "kurzerhand konvertieren"? Was genau musstest du tun? Und wahrscheinlich soll das "nach PIC GCC" heissen, oder? Oder bist du jetzt auf AVR umgestiegen  ;D ?

Hast du das auf ucapps bereitgestellte Wiring-Diagramm benutzt, siehe  http://www.ucapps.de/mbhp/mbhp_lcd7_pcd8544_cheap_single.pdf ?

Grüße, ilmenator

[Jack]

Hallo pay_c,

ich könnte Dir ein S65 LS020 leihen inkl. einem meiner noch nicht funktionierenden Companion board (PIC18F4550). ;D

Best Regards

Jack

[pay_c]

@Jack: Danke für das echt nette Angebot, aber bin inzwischen auf AVR umgestiegen und habe mit dem Display auch einige Pläne, daher würd ich schon gern ein komplett eigenes Board entwerfen und nutzen (die Companion Boards sind ja stellenweise frech überteuert meiner Meinung nach). Außerdem habe ich schon zwei Displays da + Mikrocontroller, mir fehlen nur noch die Anschlussbuchsen, die sollten nächste Woche kommen (hoffe ich). Muss mal alles was ich bisher habe endlich in eine einigermaßen annehmbare Form bringen und ins Web stellen (Blog Addi habe ich schon, aber keine Zeit, alles zu dokumentieren). Danke auf jeden Fall, weiß ich zu schätzen!

@Illmenator: Hast Du noch weitere Gründe? Wenn ja, erzähl mal, fänd ich auch interessant (andere Sichtweisen! :) ). Das "konvertiert" bezog sich eher auf den C Interpreter. Die Software ist in IAR C geschrieben und ich nutze GCC C (weil´s das für lau gibt und direkt in die Programmiersoftware von Atmel integriert werden kann). Also: JEPP, bin voll auf AVR umgestiegen. Habe PIC´s, AVR´s und 8051er angeschaut und AVR´s sind von meinen Eindrücken her für DIY Apps ideal und bieten gegenüber PICs ein paar Vorteile (Betonung: ein paar). TK hat mir auch eher die AVR´s empfohlen. Vordergründiger Vorteil: Es gibt nicht *ein* Arbeitsregister (also einen Akku oder W-Register), sondern insgesamt 32 (von denen allerdings nicht alle alles machen können). Das macht progammiertechnisch türlich einiges sehr viel einfacher.

Jepp, habe das Wiring von ucapps übernommen. Andere Schaltungen sind übermäsig kompliziert (bspw. werden die 3,3 Volt per Spannungsregler erzeugt, obwohl der Displaycontroller weniger als 1 mA braucht und zudem 2,5 bis 3,5 Volt vollkommen aushält - sprich völliger Overkill), TK hat hier eine sehr einfache und trotzdem absolut funktionale Lösung bereit gestellt. Die 220 Öhmler sind meiner Meinung nach sehr wichtig (und eben auch nicht in jeder Schaltung vorhanden), so stellt man sicher, daß ein ISP (also ein "In System Programming") noch suaber funktioniert. Ich würde den Reset vom Display noch extra rausziehen und nicht fix auf +3,3 Volt ziehen, so kann man den Display kontrolliert per Software starten und muss nicht auf einen sauberen Reset bei Einschalten "hoffen". Aber das ist sicher Geschmackssache und bietet eher keine *echten* Vorteile.

Grüße! :)

[Jack]

Ich weiß, aber nicht wo das teuer herkommt.

Die platine mit allen bauteilen drauf kostet ca. 10€ und das Display kostet 10€.

Du meinst wahrscheinlich das companion board vom Ab***ker des 6100.

Ich meinte das companion board was ich für das S65 entwickelt habe.

PS:

Das S65 Display hat eine 1,5x so große Anzeigefläche wie das vom 6100.

Quelle:

http://www.superkranz.de/christian/S65_Display/DisplayIndex.html

Best Regards

Jack

[ilmenator]

Hast Du noch weitere Gründe? Wenn ja, erzähl mal, fänd ich auch interessant (andere Sichtweisen!)

Einer meiner Gründe ist, dass der Arbeitsabstand vom Display in den uns wahrscheinlich vorschwebenden Anwendungen deutlich grüßer ist als die übliche Distanz zwischen Augen und Handy. Das wiederum bedeutet, dass man die Schrift größer machen muss, womit der Vorteil der höheren Anzahl zur Verfügung stehender Pixel wieder futsch ist. Evtl. hilft hier der höhere Kontrast der modernen Displays etwas, aber das müsste man erstmal ausprobieren.

Dann ist da noch der Kostenfaktor: selbst wenn ich mich auf 8 Kanalzüge beschränke, komme ich auf eine eher abschreckende Summe allein für die Displays. Wobei die Zahlen von Jack ja schon wieder etwas freundlicher klingen...

/edit: Außerdem gibts noch einen 8-bit Modus, d.h. es ist nur ein 8-bit SPI-Befehl pro Pixel nötig, allerdings hat man dann "nur" 256 Farbstufen.

Hmmh, das klingt auch schon wieder etwas positiver... Ich denke, ich werde eure Aktivitäten hier auf alle Fälle beobachten  ;D.

Grüße, ilmenator

[pay_c]

@Jack: JA HOLLA!  ;D ;D ;D

Ok, mir bleibt nur eins zu sagen: DANKE DANKE DANKE! Werde mir die Infos dort gleich mal ordentlichst zu Gemüte führen! Hast Du das alles gemacht? Wenn ja: WOW, Haufen Arbeit.

Anscheinend hast Du ja beide Displays mal vergleichen können. Abgesehen von der Größe, wie schauts denn mit der Bildqualität aus? Sprich Kontrast, Blickwinkel, "schwarze Lücken" zwischen den Pixeln usw.? Vor allem Letzteres schaut auf den Bildern relativ krass aus.

Supi Seite auf jeden Fall! Warum verlinkst Du das nicht auf mikrocontroller.net und avrfreaks.com? Es gibt sicher eine MENGE Leute, die das interessieren würde! Einziger Minuspunkt an den Displays (wie so oft und auch bei den 6100ern): Drei verschiedene Controller... :P war ja klar... ;)

[Jack]

Noe die Seite ist nicht von mir.

Das ist von mir:

http://www.midibox.org/forum/index.php?topic=6064.0

Das ist der Thread von Christian:

http://www.mikrocontroller.net/forum/read-4-243641.html#new

Ich habe das CompanionBoard leider noch nicht zum laufen bekommen.  ???

Und wegen Zeitmangel konnte ich deshalb noch nicht prüfen, wie das Display funktioniert.  :'(

Deshalb bin auch wieder zurück geschwenkt zum 3310 Display.

Best Regards

Jack

[pay_c]

Vielleicht liegts ja echt an einem anderen Controller, weiß man ja nie so sicher. Aber wirst wahrscheinlich eh schon alles überprüft haben. Freu mich jedenfalls schon auf Deine Box, wird sicher ein Mörderteil (inklusive Mörderarbeit - klar).

Na, vielen Dank jedenfalls, werde mir die S65er Displays mal zu Gemüte führen (und mit den 6100ern vergleichen).

Dankö!

@MTE: Sorry fürs leichte Off-Topic, hat gerade gepasst.

[MTE]

@MTE: Sorry fürs leichte Off-Topic, hat gerade gepasst.

Prot a noblem, interessantes Input :) von dem ich jetz vielleicht 1/20tel verstanden hab  ;D

Dafür hat Stryd und meinereiner gestern den PCD-Treiber für C etwas umgeschrieben und ein Invert-Commando eingebaut  ;)

[MTE]

Ich beobachte bei mir seit Wochen das beim Einschalten nicht immer alle Displays angehen und zum Teil einige ausgehen, wenn sich auf schnelle Weise Messages darauf ändern

Habe für die Jogs jeweils die Anzeige für Richtungswechsel etc geschrieben, d.h. drehe ich das Jog im Pitchbend-Modus rechts, blinkt jeweils auf Display 2 "Pitchbend >" , und zwar immer nur solange, wie das Jog gedreht wird, das heisst wiederum, bei jedem Encoder-Klick wird die Message aufgetragen..... kapiert ?  ;D

Wenn ich das einige Zeit mache geht das Display aus, oder es kommen plötzlich wirre Zeichen zum Vorschein, was evtl. aber auch am Treiber selbst liegen kann.

Ich habe nun separate stabilisierte 5V/GND-Leitungen vom Trafo auf die 8er-Displayplatine gelegt, damit die Displays nicht den Strom aus dem Core ziehen und dachte, damit sei evtl. das Problem behoben, leider ohne Erfolg.

Ich tat das gleiche für meine DOUTs, da meine LEDs immer wieder mal flackerten, mit ner separaten Stromversorgung war dieses Problem aber behoben...

Mein Trafo dürfte so 1,5 A bringen, stammt aus ner alten C64-Floppy (weiss von dieser zufällig jemand das Datenblatt rumliegen ?)

Grüße

[pay_c]

Hmm, hört sich aber eher so an, als ob die SPI durcheinander kommt. Hast Du schon mal probiert, die Clock-Frequenz runter zu setzen (bspw. halbieren bzw. vierteln - bei Atmel AVR´s gehts bspw. nur in 4er Schritten runterwärts)? Ich kenn mich blöderweise bei Eurem Treiber nicht aus, aber das wäre mein erster Schuss. Und eine geringere Clockfrequenz sollte mal gar nix ausmachen, da das Display eh nur ein paar 10 Bytes zur Ansteuerung braucht.

@Jack: Nur, falls es für Dich interessant ist, habe heute ein S65er Display und ein 6100er direkt vergleichen können. Das 6100er hat einen besseren Kontrast und geringe "schwarze Lücken", aber das S65 trumpft eindeutig mit der puren Displaygröße. HG Beleuchtung ist bei beiden etwa gleich gut. Fazit: Gerade ein Display auf Eblöd bestellt. ;)  Werde mal schauen, wie ich die zich verschiedenen Spannungen herstelle (2,8V, 5V, 10V ... puh), wird sicher lustig. :)

[pay_c]

@Jack und Illemenator: Kleine Updates bezüglich der Farbdisplays, falls noch interessant für Euch:

Ich habe jetzt beide Displays am Laufen und ein Haufen Info oben drauf bekommen.

Das S65 kommt leider doch nicht mehr in Frage aus zwei Gründen: 1tens ist es stinkelahm (die 2 Bytes pro Pixel + die ca. 23k Pixel reduzieren die realistische Framerate bei kompletten Bildschirmrefresh & 8 MHz SPI Rate auf unter 10 fps, Augenkrebs mit einbegriffen, da man immer den Displayaufbau mit anschaut) und zweitens (wichtiger find ich) ist das Display am Auslaufen, d.h. es wird nur noch Restbestände geben, es wird gar nicht mehr neu hergestellt. Leider für µC Anwendungen (MIDI inkl.) beides Killerargumente.

Der 6100er Display macht nach wie vor den besten Eindruck. Einziges Problem bleiben die unterschiedlichen Controllervarianten für´s gleiche Display (etwa 7). Man kann die Ansteuerung allerdings auf zwei Hauptcodes herunterbrechen, also auch kein allzu großes Prob. Außerdem sind 80% aller heute verkauften Displays von einem bestimmten Controllertyp, der zudem mit dem zukünftigen Controller kompatibel bleiben wird (d.h. auch die Displays werden mind. 5 weitere Jahre produziert). Die Geschwindigkeit des Displays ist Dank 8bit Modus und "nur" 17k Pixel absolut in Ordnung (kompletter Bildschirmrefresh bei 8 MHz SPI mit etwa 20 fps und deutlich mehr möglich -> hier ist der µC der Flaschenhals!).

Also ich werd beim 6100er bleiben, ist am flexibelsten. Evtl. nutze ich in meiner Anwendung auch zwei davon, mal gucken. Code hätte ich zu beiden Displays, allerdings halt für AVR... lässt sich evtl. Dank AVR GCC relativ leicht in PIC ummodeln. Vllt gibts ja mal ne Midibox mit Farbdisplay? ;)

Grüße!

[TK.]

lässt sich evtl. Dank AVR GCC relativ leicht in PIC ummodeln.

Du programmierst den LCD Treiber in C und nicht in Assembler?

Die CPU scheint wohl ansonsten nicht ausgelastet zu sein... ;-)

Gruss, Thorsten.

[pay_c]

Najaaaaa, fürs erste Austesten halt schon einfacher.  ::) Ich gibs ja zu, bin faul...  ;)

Wenn der Treiber mal komplett steht, werd ich v.A. die direkten SPI Zugriffsroutinen auf Assembler ummünzen (und als .s includen). So Schmarrn wie bspw. Fonts oder Bitmaps schreiben mach ich dann doch ganz gern in C, ist eben sehr angenehm mit Pointern zu programmieren. Und was die Perfomance angeht nehmen sich C und Assembler bei AVR gar ned mal so dermaßen viel, was mich echt überrascht.

Wie wars denn bei Dir? Du hast doch MIOS in C umgeschrieben, oder? Gabs da Perfomance-Einbrüche?

[TK.]

Der Ansatz ist um Grunde richtig - erstmal alles in C einhacken, und die Performance kommt beim Buegeln. ;-)

MIOS ist nach wie vor komplett in Assembler geschrieben, das Interfacing zu SDCC erfolgt ueber einen Wrapper. Mit C kann man auf keinen Fall die gleiche Performance erwarten - vor allem das Stack- und Heaphandling wuerde sehr viel Zeit kosten, und es wuerde auch nur noch ein HW-Pointer zur Verfuegung stehen... beim AVR sieht das natuerlich anders aus, doch Wunder sind hier nicht zu erwarten. C Code baut nun mal auf bestimmte Methoden auf, die zwar universell, doch nicht immer optimal sind.

Gruss, Thorsten.

[pay_c]

...beim AVR sieht das natuerlich anders aus, doch Wunder sind hier nicht zu erwarten. C Code baut nun mal auf bestimmte Methoden auf, die zwar universell, doch nicht immer optimal sind.

Gruss, Thorsten.

Zuuuustimmung. Vor Allem kann man auch in C einen µC so dermaßen schlecht programmieren, daß es nicht mehr schön ist (bspw. ein volatile, static, enum, long, int, char oder sonst was vor bestimmten Variablen nicht gesetzt oder unnötig gesetzt und schon ist´s mit der Perfomance vorbei). In ASM *weiß* man halt, was der µC macht, das ist der entscheidende Vorteil. Ich wünscht halt nur ich könnt ASM so programmieren wie Du, MIOS ist schon echt irre, wenn man sich mal reindenkt. Wird halt mal so dermaßen elegant & effizient, wenn man sich tagtäglich damit beschäftigt (was ich mal gar nicht mache - mein Job geht in eine (fast) ganz andere Richtung).

So, genug off-topic Schleimerei für einen Tag. ;) ;) ;)

Grüße!

[TK.]

So, genug off-topic Schleimerei für einen Tag.

das reicht auch fuer diesen Monat! ;-)

Gruss, Thorsten.