Display-Ansteuerung

[surfer84]

Hallo,

ich will einen Display (möglichst graphisch, ansonsten alphanummerisch) ansteuern und weiß nicht, welcher Microcontroller sich dafür am besten eignet.
Gibt es noch spezielle Eigenschaften, die er hierfür können muss?

Wäre super, wenn ihr mir da weiterhelfen könntet.

Nils

[Vitis]

prinzipiell kannste die Displays mit Tastern und fliegenden Drähten ansteuern.
Da brauchts nicht besonders viel Rechenpower dafür.
GLCD haben aber naturgemäß recht viele IO-Leitungen.
Sinnvoll währe daher n µC mit ausreichend Ports um das LCD direkt
anzusteuern. Du kannst aber auch beispielsweise über Portexpander
für den I2C-Bus arbeiten, dann brauchst Du vom µC nur 2 Pins.
Kniffliger wirds da schon mit dem dargestellten Inhalt auf dem
GLCD. Da stellt sich dann die Frage, ob Dein auserwähltes auch
einen Zeichensatz für alphanumerische Darstellung hat oder der im
Programm drin stecken muss. Das hat dann direkt Auswirkung auf
den Flash-Bedarf des Prozessors.
Beschreib mal Dein Projekt und das LCD, das Du verwenden willst,
dann kann man die besser helfen.

[surfer84]

danke schonmal für die Antwort!
Ich hab jetzt ein Display gefunden: http://de.farnell.com/jsp/Optoelektronik/LCD+Displays/HITACHI/SX14Q004/displayProduct.jsp?sku=1082064
Habs bei ebay für 30 Euro bekommen :) Mit dem Datenblatt hab ich mich schon ein bischen vertraut gemacht und das dürfte auch nicht das Problem sein. Prkatisch wäre natürlich, wenn ich den PIC16F84A verwenden könnte, da ich mich mit dem schon halbwegs auskenne und er auch in der Abschlussprüfung verwendet wird. Aber für diese Auflösung wird wahrscheinlich der Speicher nicht reichen. Mit externen Speicherlösungen hab ich mich nur noch gar nicht befasst. Gibts da ein Tutorial dafür?

[Vitis]

für 30 Eu ist das recht günstig, kein schlechtes Geschäft.
Es hat nur einen Pferdefuß ... Du muss das Ding komplett
mit Daten versorgen, es hat keinen Controller eingebaut,
der Die Darstellung übernimmt. Also mal rechnen.
Das Ding hat 320 x 240 Dots, die mit 3 Byte RGB versorgt
werden müssen. Das sind dann über den Daumen
230400 Byte. Das ganze dann mit mindestens 24 Frames/sec
also mal 24 sind dann
5,529600 MByte je Sekunde, die natürlich auch noch sinnvoll
programmiert sein wollen, damit ja was dargestellt wird.
Na dann mal viel Freude beim Programmieren, keine Frage,
das die Geschichte auch noch zeitkritisch ist.
Nee du, Mit dem PIC16 wirst Du da nicht ganz hin kommen.
Ich tippe da eher auf ARM7TDMI so in etwa AT91SAM7S in der
Größenordnung wirds wohl eher hin kommen.
Oder der neue PIC32, klingt auch recht vielversprechend, wenns schon
PIC sein soll.

[surfer84]

das speicherproblem bleibt aber, oder sehe ich das falsch. Wenn ich bei der Auflösung zumindest mehrere Zeichen in den Display schreiben will, komm ich doch um externen speicher nicht drum rum!?
Dachte erst an Flash-Speicher, aber bei großen Datenmengen scheint das auslesen recht umständlich zu sein. Hatte mir da sowas gedacht:
http://www.cc5x.de/MMC
wäre eben sehr praktisch mit der Speicherkarte

[Vitis]

nee, du brauchst Speicher, auf den Du sehr schnell zugreifen
daten verändern oder auslesen kannst.
Du brauchst RAM, thats all.
SRAM, DRAM SDRAM EDORAM etc.
Flash nutzt Dir da nicht viel. Ist zwar n nichtflüchtiger Speicher,
aber für solche Anwendungen ist RAM das Wahre.
Wie viele Rechenoperation schafft dein PIC denn so
in der Sekunde und wie schnell ist er beim Zugriff auf seine
IOs ?

[surfer84]

die Info zum Speicher ist schonmal gut! Mit den Pics muss ich mich noch mehr beschäftigen. Der PIC32 sieht natürlich verlockend aus, aber über 500 Seiten Datenblatt......

[Vitis]

Ah halt, hab grad nochmal das Datenblatt studiert,
kann es sein, dass das Display nen Buffer hat, den
man beschreibt?
Dann ist das mit den 24 Frames natürlich Käse und auch
das Timing ist nicht mehr so kritisch.
Ja, dann kannst Du das Ding ohne weiteres mit dem PIC
ansteuern.
Der RAM wird ja nur kritisch, wenn Du das anzuzeigende Bild
vorher komplett generierst und dann komplett übertragen
willst.
Wenn Du nur ne generierte Oberfläche, beispielsweise n
Menü darstellen willst musst Du das ja nicht vorher
komplett generieren, sondern kannst es ja Stück für
Stück erzeugen und übertragen.
Es sind aber dennoch 230kB je Frame, die da rüber müssen,
das dauert n Momentchen.

[surfer84]

Ein Buffer wäre natürlich konfortabel, aber wo im Datenblatt würde das denn stehen? Hab da noch gar nichts in der Richtung gefunden.
Weißt du eigentlich, man das mit der Dummy-Data verstehen soll?

[Vitis]

hab mir das Datasheet nochmal angesehen,
Framebuffer ist Fehlanzeige.
Also für eine Zeile sind 24Bit Farbcode RGB,
also 960 Bit an Daten nötig und das dann in
~ 60µS, also 120Byte in 60µS sind dann
in der Sekunde
120 x 16666.666 = 2MB / Sekunde laut Datenblatt.
Sorry, aber das Timingdiargramm hab ich bisher
nicht so genau studiert, daher nun die Korrektur.
Also 2 Mio mal je Sekunde einen Port setzen und
einen Pin Togglen ... Bin mir jetzt nicht sicher, ob der
PIC das hni bekommt, beim AVR würds glaub ich nicht
reichen.
Per SBI / CBI komm ich beim AVR auf gerade mal
auf 7,5 kHz. Sind vermutlich noch n paar kHz drin,
aber bestimmt keine MHz.
Pin togglen im MHz-Bereich werden nicht so viele
µC hinbekommen sieht mir eher nach FPGA aus.
Auf alle Fälle vermute ich wird der Nutzen den Aufwand
nicht rechtfertigen.
Schau Dich eher mal nach nem GLCD Monochrom 64x128
mit KS0108 Controller um. Die sind deutlich einfacher
anzusteuern und erfüllen meist auch ihren Zweck.
Mit 30-50 Teuros bist Du da auch schon gut dabei und
vom Timing her sind die Dinger ziemlich unkritisch.