Ich wollte den Bereich der HD44780 kompatiblen Displays verlassen und mal erste Erfahrungen mit den "richtigen" Displays sammeln. Dazu habe ich ein 420x272 mit 24bit Farbtiefe von Sharp rausgesucht (das LK043T1DG02, Datenblatt unter [1]).
Nur habe ich zur Zeit noch überhaupt so keinen Plan, wie das angesteuert werden muss. Gibt es da eine ähnliche Kompatibilität wie bei den Zeichendisplays? Aus dem Datenblatt werde ich nicht schlau wie das funktioniert. Kennt ihr Quellen oder Beispielprojekte?
Weiterführend sind dann die Fragen worauf ich bei der Auswahl eines geeigneten Controllers wert legen sollte. Ich denke hier sollte ich mich bei so einem Teil wohl von der 8bit µC-Reihe von Atmel verabschieden.
Seiten 12-14 im Datenblatt sagen ja quasi alles. Im Groben, wenn ich das richtig sehe: Das Display geht mit 3x8Bit (Farbinformationen) + CLK + HSYNC + VSYNC an den Controller. Man zieht einmal VSYNC (Sprung an Anfang der Seite) Dann HSYNC, tackert dann 480 Datensätze raus (=eine Zeile), wieder HSYNC.... das Ganze 272 Mal für alle Zeilen. Gewünschte Frequenz für den CLK sind 9MHz, die restlichen Timings kann man dann ableiten.
Ein schneller. Du musst mit 9MHz jeweils 24Datenbits erzeugen, ein AVR wäre da "leicht" überlastet, und evtl. soll der ja auch noch was anderes nebenher arbeiten. Aus dem Bauch raus würd ich mal bei den ARM schauen, da gibts sicher was passendes.
Das steht hinreichend genau im Datenblatt. Hint: Es handelt sich hierbei NICHT um eine Mikroprozessorschnittstelle, sondern um eine Art Videointerface, bei dem ein externer Controllerchip die Bilddaten fortwährend zeilenweise an das Display senden muss. Ähnlich VGA, nur eben mit digitalen statt analogen RGB-Signalen.
Ja, die Displays sind sich alle recht ähnlich.
Zumindest wüsste ich keinen 8Bit-Atmel, der einen geeigneten Display- Controller on-chip hätte. Rein in Software kannst du ein solches Display nicht ansteuern, der Pixeltakt beträgt immerhin 9MHz.
Eine 8 Bit CPU kannst Du dafür in jeder Hinsicht vergessen, die wäre noch nicht mal tauglich, wenn Du einen externen Display-Controller hättest, der das Timing organisiert.
Selbst wenn Du die Farbtiefe auf 8 Bit _gesamt_ pro Pixel reduzieren würdest, so ergibt doch 420 x 272 nach Adam Riese immer noch 114240 Byte, das ist weit mehr Speicher, als so ein 8 Bit uC vernünftig adressieren kann, von dem Aufwand bei der Arithmetik, jeden Zugriff über eine Vielzahl von 8 Bit Befehlen zu synthetisieren, mal ganz zu schweigen.
Eigentlich will man das auch nicht mit einem 16 Bit Controller machen, denn auch der wird Schwierigkeiten mit der Adressierung bekommen, wenn man nicht trickst. Dann kann man aber auch gleich was Gescheites hernehmen und wird mit vernünftigen Bildaufbauzeiten belohnt.
Vorschläge:
- DSP: Analog Devices Blackfin hat eine schnelle interne DMA und spezielle Parallelports und ist hervorragend dafür geeignet. Die großen Modelle aus der TMS320F28 Serie können es auch, die haben dto. 32 Bit Register und Arithmetik und einen großen Adressraum. Allerdings benötigst Du dann einen externen Controller, der z.B. per FPGA realisiert sein könnte.
- "normale CPUs": Die Üblichen Verdächtigen aus der PDA Welt, die nicht ganz so aufgeblasen sind wir "große" PC CPU's, also ARM und MIPS, sind sicher gut geeignet. Für die kontinuierliche Versorgung des Displays mit Daten wird auch ein FPGA oder Spezialcontroller herhalten dürfen.
Rechne bitte schon damit, dass Du bei der Leiterkarte nicht unter Multilayer auskommen wirst, die Daten fließen hier so schnell, dass man zwar noch keine impedanzkontrollierten Leitungen braucht, aber sehr wohl eine vernünftige Terminierung und eine Masse/VCC Fläche unterhalb der Leiterbahnen. Ohne diese wird es nicht vernünftig spielen, die unkompensierte Induktivität der Leitungen ist sonst zu hoch. Die entsprechenden CPU-IC's sind (vielleicht mit Ausnahme der TI DSPs) durchweg BGA-Bausteine, die ebenfalls gut mit Strom versorgt sein wollen.
"David Pritzkau" schrieb im Newsbeitrag news: snipped-for-privacy@mid.dfncis.de...
Es gibt eine ganze Menge Moeglichkeiten, dieses Display anzusteuern, je nach dem, woher deine Daten kommen. Im Prinzip ist es ein digitales RGB Display. Der minimalste Auswand entsteht an einem Display Controller wie er in einem Laptop verbaut wird, dort kommen die Daten bei passende Initailisierung direkt raus. Mit geringem Aufwand (deserializer) kann es auch an ein DVI-Kabel aus der Graphikkarte eines PC angeschlossen werden. Fehlt dir die Graphikkarte (kein Laptop, kein PC) kannst du eine Graphikkarte mit Graphikcontroller nehmen, je nach gewuenschtem Businterface so was wie Chips & Technologies 65550, je nach gewuenschter Zeichen-Geschwindigkeit bis hin zur GeForce. Diese Controller machen ueblicherweise 'graphic acceleration', zeichnen also Linien, machen Flaechenfuellung und sogar 3-dimensionale Bilder hardwareunterstuetzt. Den passenden Softwaretreiber ist zu schreiben und nicht-trivial. Wenn das LCD nur an einen Prozessor soll, der den Speicher selbst mit den passenden Bildern und Schriften bemalt, reicht zyklisches auslesen dieses Bildspeichers, das machte frueher ein CRT Controller (MC6845) und heute ein Teil eines CPLD/FPGA, aus immerhin ueber 256kByte Bildspeicher, oder der Prozessor mit eingebautem LCD-Interface selber.
Die Algorithmen zum Zeichnen einer Linie, eines Buchstabens, muss dann dein Prozessor ausfuehren, das ist beim 8 bit Prozessor sicher langweilig mitanzusehen (er kann gar nicht 330k adressieren, muesste also den Bildspeicher extern ueber Ports adressieren, alleine das Loeschen oder Scrollen des Bildes braucht dann 1 Sekunde) dennoch sieht man solche Anwendungen bei manchen Informationsdisplays, wo man beim Schreiben mit zusehen kann (werden aber meist 16 bit uC sein in C programmiert damit sie so langsam wie 8 bit sind)
Ueblicherweise verwendet man also Prozessoren, wie sie in Palmtops drin sind, meist ARM-basiert wie TI OMAP1510 (kann nur 16bit/Pixel). Dann kann man statt einem rohen Display aber auch gleich einen Palmtop kaufen.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Das Verdikt "In jeder Hinsicht" hab ich ja verstanden aber der Teil nach "wenn" ist mir nicht ganz klar.
Warum sollte ein einfacher Controller ausscheiden wenn ein anderer Chip die Ansteuerung komplett übernimmt (wie man es von den HD-Dings Teilen sowieso gewöhnt ist) *und* insgesamt kein schneller Bildaufbau nötig ist (Z.B. für sich relativ langsam ändernde Anzeigen wie bei Anwendungen für Barographen bzw. Messgeräte allgemein etwa)?
Addressieren übernimmt natürlich auch ein anderer chip, siehe mein Vorschlag weiter unten...
ja, ein zweiter "externer" (extern?) Controller z.B. per FPGA ist wohl generell keine falsche Idee hier. Egal ob man nun blackfin oder 12F508 bevorzugt :)
Spezialcontroller herhalten dürfen.
In dieser Vorschlagsliste haben wir ja mal wieder alles beisammen, was der Hobbybastler so liebt: Multilayer, BGA, hohe Kosten falls überhaupt beschaffbar. Und auch gleich miteingebaut ein hoher Strombedarf, den jeder halbwegs sensibilisierte Entwickler und besonders dann der Gerätebenutzer so sehr liebt.
Alternativvorschlag:
Im Zentrum ausreichend Speicher, sagen wir mal 512kB (mit Schatten- speicher dann) SRAM wäre naheliegend. Den periodisch angesteuert, beschrieben und ausgelesen von einem kleinen CPLD (FPGA ist overkill, da brauchts nur ausreichend Takt, ein paar Zähler und etwas glue. Vielleicht noch refresh, falls mehr billiger Speicher und DRAM gewünscht). Der CPLD bekommt zusätzlich einen 8-bit Datenport I/O nebst Steuerleitungen, an dem hängt dann ein passend kleiner Controller als Master, je nach Anforderungen an Bildaufbau Geschwindigkeit e.t.c. natürlich.
Für die meisten Messgeräteapplikationen sollte das allemal reichen/sinnvoll sein: Einmal Achsen zeichnen und dann Messkurve laufend aktualisieren; da gähnt so ein 8-bitter auch nur... :-o
Beispiel: Pro Sekunde eine Messkurve aktualisieren (Bode-plot z.B. für nen kleinen Wobbler a la FA-NWT, sekündlich, meinetwegen halbsekündlich aktualisiert sollte für Filterabgleich u.Ä. reichen) bedeutet für den Controller nur, vielleicht 640 Werte pro Sekunde auszugeben, mit Adressinfo 32bit und Farbinfo 24bit ergeben das bei unintelligenter (d.h. für die Anwendung viel zu allgemeiner) Ansteuerung vielleicht einen Datenstrom von 8kB/s. Die paar kS/s schafft der eingebaute AD ja vielleicht auch noch zur Datenbeschaffung, falls überhaupt nötig, wo also ist das Problem?
Für *sowas* blackfin, Multilayer, BGA, hoher Stromverbrauch?
Gebastelt (alles DIL&Draht, PCB einseitig mit Masselayer oben) könnte so ein "uC-VGA-Controller" z.B. so oder ähnlich aussehen:
Nunja, Du kannst natürlich auch Deinen PC per Lochstreifen füttern, warum sollte das nicht möglich sein.
Jeweils eine Lochreihe ist dann ein Zeichen und kurze
3km Lochstreifenlänge weiter ist die Miniaturausgabe von Open Office dann sicher geladen ;-)
Je nach Farbauflösung sind jedenfalls sechsstellige Pixel-Zahlen für einen Bildaufbau zu bedienen, wenn das Controllerle eine gute zweistellige Zahl von Zyklen pro Pixel braucht - was absolut realistisch ist- , dann liegt der Bildaufbau irgendwo im Bereich von Sekunden.
Vorausgesetzt, man möchte die Möglichkeiten des Displays nutzen. Du willst das ja eher nicht, siehe Dein "Alternativvorschlag".
Wenn das Spass macht: Ok, bittschön, siehe Lochstreifen ;-)
Der Blackfin hat halt im Gegensatz zu Deinem Vorschlag die nötige Hardware on Board, um den Datenstrom direkt per DMA und PPI kontinuierlich bereitzustellen.
Das FPGA fällt dann sehr klein aus, es kann im Prinzip sogar ein GAL sein, wenn man die Timerausgänge des DSP richtig benutzt.
Bei Deinem 12F508 sieht dös eher nicht so günstig aus ;-)
Der Strombedarf ist beim Blackfin sehr gering, viel geringer als bei Deinem "Alternativvorschlag". Beschaffbar ist er auch sehr gut und es gibt mit uC Linux einen Betriebssystemport.
Und es gibt auch preiswerte Demo-Boards mit rausgeführtem PPI, fix und fertig für wenig Geld z.B. bei Farnell.
Siehe: ADDS-BF533-STAMP, Nr. 8546185, ab Lager 136,50 ? und das uC Linux ist bereits portiert und ein LAN ist auch on Board.
Ich halte die Wahrscheinlichkeit, dass eine TFT Ergänzung zu diesem Board nicht in Frust endet, gegenüber gewissen "Alternativen" für deutlich erhöht.
Fangen wir mal bei den 512kB SRAM an: a) Wo bekommst Du die _als_Bastler_ her ;-) b) Wieviel Strom zieht es, vorallem beim Schaltvorgang ? c) Was kostet es ? d) Wer macht die Zwischenspeicherung, das Display hätte gerne 24 Bit ?
Meinst Du nicht, dass wenn man eh' schon VHDL programmieren darf (was bei CPLD wie FPGA Standard ist), dass es dann nicht sinnvoll wäre, einen leistungsfähigen Baustein zu nehmen, der auch nicht mehr kostet und wenigstens genügend Pufferspeicher für DRAM etc. on Board hat, damit man die problematische Verdrahtung Richtung RAM entschärfen kann ?
Garkein Thema, ich täte die Messdaten vorher noch über ein serielles Interface schicken, damit der Streifenstanzer in jedem Fall parallel mit kontaktiert werden kann.
Im übrigen kannst Du Dir, wenn Du die Bandbreite eh' auf ein Pixel pro Displayzeile beschränken willst, das man pro Sekunde updaten kann, das Leben viel einfacher machen:
Nimm halt doch das FPGA und ein internes RAM, welches pro Zeile bzw. Spalte angibt, an welcher Koordinate der Einzelpixel aufleuchten soll. Ein simpler Index-Counter und Comparator gibt dann im geeigneten Moment die richtigen Daten aus. Das geht beim mir dann übrigens auch mit vier Pixeln, weil soviel SRAM hat auch das Billisch-FPGA, oder sogar mit acht, wenn man es dual-ported ausliest. Dazu noch ein hardcodiertes Text-Area und gut ist. Ein schnöder Spartan 3 vom Dandler um die Ecke packt das locker.
Die Lösung ist 100 x schneller als Dein Ansatz, der auch nicht mehr als einen Pixel pro Zeile realistisch bedienen kann. Nur geht hier der Screen-Clear _viel_ schneller.
Du scheinst mir der absolute Profi zu sein, alleine schon Deine Einschätzung zum Blackfin Stromverbrauch spricht dafür.
Nur zur Info: Wir setzen in einem Projekt die Dual Core Version ein, also gleich 2 CPU Kerne, und das Ding wird aus einem Steckernetzteil gespeist. Das TFT Backlight braucht übrigens auch Strom.
Aber selbst dieses Projekt braucht schon ueber 32. Die schicksten Gehaeuse waren immer 100 pol TQFP. Was dem DSP in so einem Geaheuse meist fehlt, ist genug interner Speicher, sowohl RAM als auch ROM, und geeignete I/O-Hardware.
Was fast eine Frechheit bei den PDA-Prozessoren (und LCD-Controllern) ist, ist die mickrige Zukunftssicherheit: Unterstuetzen nur 3 oder 4 LCDs in genau einer Aufloesung und genau einer Farbtiefe, dabei sind RGB Panel mit Megalpixelgroesse bereits erfunden gewesen. Einen Chip, der einfach
6 MB Display-RAM, 3 * 6 bit RGB Ausgang, und SYNCleitungen hat und damit jedes Display ansteuern kann, gibt es scheinbar nicht. AMD Elan SC400 hatte eingebautes LCD-Interface, aber kein Wunder, dass der Chip heute nicht mehr fuer neue Designs empfohlen wird. Die Displays gibt es einfach nicht mehr. Wie kann ein Hersteller so bloed sein, solche Crippleware ueberhaupt zu entwickeln.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Sonderentwicklung für eine bestimmtes, einst in grossen Stückzahlen hergestelltes Produkt, Offenheit bewusst unterwünscht? Intellectual Property ist ja soooo modern...
Stellt doch einen Antrag auf Änderung der physikalischen Gesetze ;-)
Vorschlag: Gesetz zur Änderung der Maxwellschen Gesetze und der Gesetze für Elementarteilchen:
§1: Zur Unterstützung von Elektronik-Bastlern wird festgelegt, dass in farblich blau-grün gekennzeichneten Drähten, insbesondere Fädeldrähten, nur blaue Elektronen fließen dürfen, für welche die Nieder-Selbstinduktionsregeln nach §2 gelten. In allen anderen Drähten dürfen nur gewöhnliche rote Elektronen fließen.
§2: Blaue Elektronen koppeln mit elektromagnetischen Feldern gemäß der Maxwellschen Gesetze nur so, dass sich eine um den Faktor 10 reduzierte Selbstinduktion ergibt.
§3: Bussgeldvorschrift: Sofern rote oder blaue Elektronen gegen die §1 und §2 verstoßen, kann für jedes einzelne Elektron ein durch dieses sofort zahlbares Bussgeld in Höhe von 10 bis 1000 Euro festgesetzt werden.
Begründung: Mit diesem Gesetz sollen erhebliche Kosteneinsparungen bei Elektronikbastlern erzielt und neue Bastelprojekte ermöglicht werden. Aufgrund des grassierenden Fachkräftemangels in der Elektronik- industrie und der Vermutung, dass aus der Menge gerade junger Elektronikbastler sich künftig neue Elektronik-Fachkräfte resultieren können, was im Interesse der Industrie liegt, ist eine Förderung von Elektronikbastlern volkswirtschaftlich wünschenswert. Die Wirtschaft und Bastler können mit diesem Gesetz dadurch gefördert werden, dass die Fädeltechnik mit blau-grünen Drähten nunmehr bis zu einer Grenzfrequenz von über 100 MHz ermöglicht wird, ohne dass hierzu teure Multilayer-Leiterplatten notwendig werden. Die Bussgeldvorschriften ergeben sich aus der Erfahrung, dass Elektronen sich häufig nicht an Vorgaben der humanen Exekutive halten, eine Erfahrungstatsache, die nahezu jeder Elektronikbastler nach Inbetriebnahme neuer Schaltungen zu bestätigen weiß.
Gibt es, schaust Du dsPIC30F1010 ff. Hat halt nur nicht den großen Markt, man braucht immer mehr I/O Ports, egal wieviele man schon hat ;-)
Das andere Thema für BGA & Co ist natürlich die Impedanz der Stromversorgungszuführung, siehe oben. Solange man nicht blau-grüne Bonddrähte ;-) hernimmt, haben die Drähtchen halt schon eine merkliche Induktivität, ergo braucht man sehr viele von denen parallelgeschaltet, was sich neben Multi- Bonds pro Pin auch in einer Vielzahl von Pins nur für VCC und Ground äußert. Mit FlipChip läßt sich diese Impedanz deutlich reduzieren.
Im übrigen sind BGA in einer eingespielten Produktion viel angenehmer als TQFP, denn wo keine Beinchen sind, können auch keine Beinchen verbogen werden oder sein.
Kein Problem. Heizungen mit einem Wirkungsgrad von über 100% dürfen auch beworben werden.
Gott hat mich vor der Benutzung von PICs verschont. Gottseidank! Ich erwarte mir von dsPIC nichts besseres. Darfst mich aber gerne eines besseren belehren.
Ich muß dir allerdings beim zweiten Punkt widersprechen: Ich brauche seltens viele Pins. Und wenn, dann sind die immer irgendwie lokal und werden dann auch LOKAL erzeugt. z.B. Display, Frontplatten-Taster.
(Ich hatte genug mit Bausteinen mit über 200 Pins zu tun. Viel Spaß beim Zählen, wenns nicht gar sowieso BGA ist)
Für Großserie sicher. Solche Leute tummeln sich aber weniger in der NG.
|> Ich muß dir allerdings beim zweiten Punkt widersprechen: Ich brauche |> seltens viele Pins. Und wenn, dann sind die immer irgendwie lokal und |> werden dann auch LOKAL erzeugt. z.B. Display, Frontplatten-Taster.
Dann kann ich dir ja mal was von meiner Krankheit abgeben. Mir gehen schon seit GAL-Zeiten immer die Pins aus und es muss getrickst werden. Da denkt man, 250I/Os eines Xilinx-FPGAs reichen ewig und layoutet mal munter drauf los. Bis man entdeckt, dass davon 56 Input-Only sind und das nicht bei allen offensichtlich ist. Sowas kann einem den Tag verderben...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Sag das bitte dem TCAM Speicher, der 72 Bus-Leitungen mit irgendwas um die 10 GBit/s Bandbreite in Summe reinbekommt, selbstverfreilich mit Latenzzeitanforderung => Minimal (nix 8B10B Serdes).
Die dsPICs sind offensichtlich eine ganz andere Klasse von Prozessoren als des "Kleinzeug" vom Microchip. Der Core ist wohl original nicht von Microchip, sondern ein MIPS (?), gut abgehangen, aber im Verhältnis zu den 18er oder gar 16er PICs geradezu ultramodern.
Und auch was den Compiler angeht, hat Microchip dazugelernt: sie bieten einen an der auf dem gcc beruht.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.