Hallo,
eine kurze Frage zum Thema Recherche. Ich bin auf der Suche nach einem
Grafik-Controller-Chip, vergleichbar diesem hier:
http://www.sitronix.com.tw/sitronix/product.nsf/Doc/ST7528?OpenDocument
Kurz gesagt: 160x32, geringer Stromverbrauch, usw...
Das Problem mit dem aktuellen Controller ist die fehlende horizontale
Scrollfunktion. Ich bräuchte ein Feature was in etwas folgendes erlaubt:
Sichtbare Pixel 160x32
Rand von 10 Pixels rechts (unsichtbar)
Schreibe Display voll (160 Pixel)
Scheibe nächsten Buchstaben in den 10 Pixel Buffer
Scrolle 10 Pixel nach links
Nun ein paar Fragen:
A) Gibt es für den Scrolling-Effekt einen Namen?
B) Macht es überhaupt Sinn selbst zu suchen (normalerweise ist das der
Job des Display-Herstellers, aber wir favorisieren grad einen Hersteller
in China, und der will einfach genau wissen "was er einsetzten soll")
C) Muß ich nach Controllers mit "mehr" Pixeln suchen, sprich z.B. 180 x
32 wenn ich dieses horizontale Scrolling haben will?
Alternativ könnten wir natürlich jemand damit "beauftragen", allerdings
ist es sauschwer bei sowas die benötigte Zeit zu schätzen, und damit zu
beurteilen ob ein Angebot für Recherche angemessen ist. Vielleicht weiß
ja auch hier jemand ne Hausnummer, wie lang recherchiert man für sowas.
Einen Mannntag?
Danke für jede Art von Feedback,
Christian
Hi,
danke fürs Feedback. Hab mal kurz reingeschaut, ich fürchte die Dinger
sind "zu gut", sprich zu teuer.
Unser aktueller Controller ist ein "Pfennigartikel" sprich das ganze
Display mit Glas und Controller kostet weniger als 3€.
Es sind ja auch "nur" 160x30 Pixel, SW, auf 8x2cm.
Ich suche nochmal weiter, aber im Augenblick siehts nicht gut aus.
Werden wohl Display-Hersteller direkt anfragen müssen, ne
Google-Recherche bringt bei so detaillierten Sachen irgendwie nix...
Christian
Man könnte das Problem auch in der Software lösen, mittels buffering.
Man legt zwei Buffer-Arrays an die jeweils so groß wie das gesamte Bild
sind.
Dann wird der erste mit dem aktuellen Bildschirminhalt gefüllt und
dieser dann ausgegeben.
Das nächste Frame (also Text z.B. ein Pixel weitergeschoben) in den
zweiten Buffer schreiben und den dann ausgeben. Dann nächsstes Frame in
den ersten Buffer, umschalten. So kriegt man recht einfach flüssige
Animationen hin, wenn das denn für Text wirklich nötig ist :P Man kann
natürlich auch gleich ein Zeichen weiterschreiben. Oder, falls der
gesamte Text vorher bekannt ist, einen großen Buffer anlegen, in dem der
gesamte Text enthalten ist und einen zweiten, der so groß ist wie das
Display. Dann immer ein Fenster aus dem ersten in den zweiten schreiben,
das anzeigen lassen und danach weiterschieben.
Falls ich das Problem falsch verstanden habe, einfach ignorieren :D
Grüße,
Christian
@Christian
Nein, grundsätzlich ist das auf jeden Fall möglich. Nur reicht dafür die
Geschwindigkeit nicht aus. Wir laufen auf Batterie, daher will ich den
MSP nicht auf 16MHZ takten.
Und bei deiner Lösung bleibt der "Flaschenhals" bestehen, d.h. ich muß
ja beim Scroll (selbst mit zwei Buffern) immer den gesamten Inhalt
übertragen. Wenn ich also 10 mal die Sekunde scrollen will sind das 10
volle Bildschirme pro Sekunde, und das krieg ich seriell mit 4MHZ leider
nicht mehr hin.
Wir werden zwar wohl auf paralell umstellen, aber auch dann heißt
Hardware-Scroll vermutlich nur 1/10 der nötigen Datenrate von
Software-Scroll.
Und falls hier jemand später mal mit dem gleichen Problem mitliest, hier
noch zwei Links die nützlich sein könnten:
http://www.interfacebus.com/LCD_LED_Driver_Manufacturers.htmlhttp://www.manufacturers.com.tw/electronics/lcd-controller.html
Verstehe... Was ist, wenn ihr einen separaten µC extra dafür abstellt?
Der könnte auch mit niedriger Frequenz betrieben noch ausreichend
schnell die Daten an das Display durchtickern wenn er "nur" z.B. per I²C
oder rs232 den Text empfangen und das Display bespaßen muss.
Der könnte per ext. Interrupt für eine Weile kontinuierlich wachgehalten
werden für die Datenübertragung und sonst z.B. nur mit z.B.
10Hz-Impulsen kurz aus dem sleep kommen um den Inhalt des Displays zu
aktualisieren.
Wenn man alle unnötigen Sachen abstellt könnte ein Attiny24/44 (ich
kenne mich leider nur mit AVRs halbwegs aus) oder vergleichbares
durchaus stromsparend genug aber vor allem leichter zu finden sein als
ein dedizierter Grafikcontroller der genau den Anforderungen entspricht.
Ansonsten fällt mir auch nichts brauchbares ein, leider.
Wenn man partout keinen Hammer findet kann man aber mal kurz mit der
Kombizange den kleinen Nagel reinklopfen, denke ich :D
Christian schrieb:> @Christian>> Nein, grundsätzlich ist das auf jeden Fall möglich. Nur reicht dafür die> Geschwindigkeit nicht aus. Wir laufen auf Batterie, daher will ich den> MSP nicht auf 16MHZ takten.>> Und bei deiner Lösung bleibt der "Flaschenhals" bestehen, d.h. ich muß> ja beim Scroll (selbst mit zwei Buffern) immer den gesamten Inhalt> übertragen. Wenn ich also 10 mal die Sekunde scrollen will sind das 10> volle Bildschirme pro Sekunde, und das krieg ich seriell mit 4MHZ leider> nicht mehr hin.
160x32 = 5120 Pixel = 640 Byte (SW) oder 2560 Bytes (16-Graustufen).
640 * 10 Hz = 6400 Bytes/s = 51200 Bit/s
2560 * 10 Hz = 25600 Bytes/s = 204800 Bit/s
Wenn der Speicher im Controller (MCU oder Display) reicht, ginge das
problemlos.
Der o.a. ST7528 hätte genug Speicher und kennt Set Initial Display Line
Register...
Hallo,
danke für die Beispielrechnung.
Wir suchen mal weiter nach einem Controller der das in Hardware kann,
ein zusätzlicher Chip passt nur schwer aufs Board und wär auch zuviel
Aufwand.
Dann schon eher die zweite Variante (doch Software-Seitig), leider muß
man auch wenn man nur SW überträgt die Graustufen setzen (sprich die
zweite Rechnung ist näher dran).
Und aktuell haben wir zu allem Überfluß auch noch ein Software-3-Wire
was viel zu lahm ist.
Gut, falls wir was finden melde ich mich nochmal..
Gruß,
Christian
