Hallo, ich arbeite derzeit an der Ansteuerung eines TFT-Displays mit einer maximalen Auflösung von 480x272 Pixeln (24-Bit RGB). Der Mikrocontroller (PSoC) und der Displaycontroller (SSD1963) sind vorgegeben. Für ein Vollbild bräuchte ich ja 391.68KB. Ich habe im Prinzip ein Hintergrundbild und einen Bereich, in dem ich die Zahlen von 0-9 Darstellen möchte. Da ich das erste Mal mit so großen TFTs arbeite, hätte ich nun noch ein paar Fragen. Ich werde vermutlich einen externen Flashspeicher brauchen. Kann ich auf diesen meine am PC vorgefertigten Bilder ablegen und nur noch bei Bedarf das benötigte Bild an den Displaycontroller senden? Die Bilder würde ich als Bitmaps am PC vorbereiten. Können diese einfach vom Mikrocontroller ausgelesen werden? Es steht ein per SPI angeschlossene SD Karte und externes RAM zur verfuegung. Zur Übertragung an das Display kommt ein 24 Bit breiter Bus mit zusätzlichen Steuerleitungen zum Einsatz. Um den Prozessor zu entlasten, wärde ich gerne per DMA auf die Bilddaten zugreifen und auf den Bus legen. Ist dies möglich oder stelle ich mir DMA da etwas zu einfach vor? Hoffe, ihr könnt mir bei meinem Problem auf die Sprünge helfen. Viele Grüße Hendrik
Vermutlich ein PSoC3 (steht leider noch nicht genau fest). Es koennte aber auch ein PSoC 4 oder 5LP werden. Es geht zunächst um die generelle Machbarkeit und die Theorie dahinter.
Hendrik B. schrieb: > Vermutlich ein PSoC3 (steht leider noch nicht genau fest). Es koennte > aber auch ein PSoC 4 oder 5LP werden. Unter PSoC 5LP würde ich garnicht weiterdenken. Kläre zunächst, was tatsächlich gebraucht wird und was es werden soll. Sollen es Standbilder sein oder ändern sich die Inhalte permanent?
Es sollen ausschließlich Standbilder sein. Beim Startup soll ein Bild geladen und dann nur noch auf die Touchoberfläche reagiert werden (zusätzlicher Touchcontroller ist vorhanden und löst einen Interrupt aus; danach können via SPI die Koordinaten ausgelesen werden). Optional sollen Zahlen in einer Ecke Angezeigt werden. Das sind die Anforderungen. Muss es denn ein PSoC 5 sein? Solche 5" Displays werden ja für Standbilder teilweise mit 8-Bit-AVRs angesteuert. Viele Grüße Hendrik PS: Warum kann ich denn nur alle zwei Stunden einen Post senden?
Der SSD1963 hat genug internes RAM, sodaß dort die Bilder abgelegt werden können. Die kleinen 8-Bitter brauchen (mir) einfach zu lange für die Übertragung der Daten. Die Bilddaten können auch nur in 8 Bit Häppchen geschreiben werden: pro Bildpunkt drei Byte nacheinander. DMA wird erst bei größeren µCs interessant, wenn nebenbei das eigentliche Programm weiterlaufen soll. Wenn aber gewartet werden muß, bis die Bilddaten in den SSD geschrieben wurden, nutzt es wenig. Wenn Dein Display feststeht, besorge Dir ein Muster und probiere aus, wie schnell es arbeitet.
Dies mag jetzt zwar etwas blöd klingen aber mir ist nicht ganz klar, wie ich die Bilddaten in den internen RAM bekomme? Ich dachte, dass der interne RAM des SSD dazu gedacht ist per paralleler Schnittstelle die Bilddaten zur Laufzeit zu empfangen und dann das Bild aus dem internen Ram auf das Display schiebt. Und wenn ich etwas am Bild ändern wollte, ich den Ram zumindest partiell neu beschreiben müsste. Aber irgendwo muss ich das Bild ja anfangs speichern; also bevor ich es in den RAM des SSD schiebe. Der interne RAM des PSoCs reicht hierzu ja nicht aus bzw. wäre ziemliche verschwendung von Resourcen, da ja auch noch etwas anderes gemacht werden soll, außer Display ansteuern. Ich hoffe ich habe mich verständlich ausgedrückt. Aber schonmal vielen Dank für deine Hilfe!
Ich find es immer wieder erstaunlich, dass Leute mit anscheinend Null Grundwissen gleich immer solch anspruchsvolle Projekte angehen wollen. Wie auch immer... Ja, auf ner SD-Karte kann man Daten und auch Bilder speichern. Ja, wenn die SD-Karte per SPI an den Microcontroller angeschlossen ist, kann man diese Daten auslesen. Wie kommen die Daten von der SD-Karte ins Display-RAM? Na, Bröckchen für Blöckchen. Einen Block (= 512 Byte) von der SD-Karte lesen und anschließend an den Display-Controller schicken. Das so oft, bis das gesamte Bild übertragen ist. Sowohl SD-Karte als auch Display-Controller haben Schreib-/Lese-Kommandos dafür. Aber du musst das alles steuern - von selbst passiert da nicht viel. Ob das per DMA klappen könnte? Eventuell - aber ein Anfänger wird sich daran die Zähne ausbeißen. Wozu aber auch, wenn das Bild doch eh nur einmal am Anfang geladen wird. Wie du zusätzlich noch Zahlen auf's Bild bekommst, wirst du dir, wenn du das bis dahin hinbekommen hast, auch selbst beantworten können.
asdfasd schrieb: > Ich find es immer wieder erstaunlich, dass Leute mit anscheinend Null > Grundwissen gleich immer solch anspruchsvolle Projekte angehen wollen. Ja, das ist schon komisch. > Wie kommen die Daten von der SD-Karte ins Display-RAM? Na, Bröckchen > für Blöckchen. Einen Block (= 512 Byte) von der SD-Karte lesen und > anschließend an den Display-Controller schicken. Das muß nichtmal über einen Buffer laufen. Man muß bloß langsamer von der Karte lesen, als man man Richtung Display wegschreiben kann, dann entfällt die Notwendigkeit für einen Buffer. Da man die Lesegeschwindigkeit von der Karte vollständig kontrollieren kann, sollte es also immer möglich sein, auf den Buffer zu verzichten. Aber natürlich: mit Buffer ist die Programmierung deutlich einfacher, da kann der beliebte "Copy&Paste-Algorithmus" angewandt werden...
Hendrik B. schrieb: > Dies mag jetzt zwar etwas blöd klingen aber mir ist nicht ganz klar, wie > ich die Bilddaten in den internen RAM bekomme? > Ich dachte, dass der interne RAM des SSD dazu gedacht ist per paralleler > Schnittstelle die Bilddaten zur Laufzeit zu empfangen und dann das Bild > aus dem internen Ram auf das Display schiebt. Und wenn ich etwas am Bild > ändern wollte, ich den Ram zumindest partiell neu beschreiben müsste. Ja. Wenn man nur einen Teil des Bildes, z. B. Text, ändern will, wird ein Schreibfenster im RAM definiert und dann beschrieben. > Aber irgendwo muss ich das Bild ja anfangs speichern; also bevor ich es > in den RAM des SSD schiebe. Nicht zwingend. Wenn dein Programm nur einen oder mehrere Buchstaben ausgeben will, dann ein Schreib-Fenster im RAM des SSD1963 definieren und direkt reinschreiben.
Danke für die Hinweise, allerdings weiß ich nicht, wo ich das Wissen denn her haben soll, wenn ich mich nun mal zum ersten Mal damit beschäftige; deswegen frage ich ja höflichst, um es zu lernen. Hinweise in was ich mich einlesen muss, würden mir ja schon reichen. Das ganze soll ja nicht bereits am Wochenende laufen, sondern ich möchte mich einfach nur mit der Materie beschäftigen. Die Kommunikation per SPI und dem Display selbst ist nicht unbedingt das Problem. Die Kommunikation per SPI steht und per DMA werden mitlerweile die Daten direkt beim Empfangen auf den Port geschrieben und ein Clock Signal ausgegeben. Mein Problem ist jetzt nur noch, dass ich den externen RAM zuvor mit Daten beschrieben und dann erst das auslesen begonnen habe. Sprich ich habe ein Array im internen RAM und verschiebe dies auf das Externe. Das kann ich später mit einem kompletten Bild ja nun nicht machen. Ich bräuchte doch also ein ROM oder ein Non-Volatile-RAM oder? Und dies müsste ich dann zuvor durch den PC mit den Bilddaten beschreiben? Ist dieses Vorgehen korrekt oder wird dies normalerweise anders umgesetzt? Vielen Dank für eure Mühen und Geduld! Edit: Ich möchte ja am Anfang ein komplettes Hintergrundbild laden und das will ja irgendwo gespeichert werden. Deswegen fragen ich nach externem Speicher.
:
Bearbeitet durch User
um Bilder dauerhaft zu speichern hast du zwei möglichkeiten : 1. wenn dein Flash der CPU groß genug ist, kannst du das Bild direkt im Flash speichern und von da aus beim start auf das LCD kopieren das Bild muss in diesem Fall als C- oder H-File in deinem Programm eingebunden werden. 2. du kannst das Bild per PC auf die SD-Karte kopieren, die SD-Karte in deinen SD-Slot vom Mikrocontroller stecken und beim start das Bild von SD-Karte laden und zum Display senden das externe RAM brauchst du in keinem der beiden Fälle...das SSD1964 hat internes RAM um die Daten von einem kompletten Screen zu speichern.
@ Hendrik B. (hendrik_ber) >vorgegeben. Für ein Vollbild bräuchte ich ja 391.68KB. Ich habe im >Prinzip ein Hintergrundbild und einen Bereich, in dem ich die Zahlen von >0-9 Darstellen möchte. Ist einfach. >Ich werde vermutlich einen externen Flashspeicher brauchen. Nein. > Kann ich auf >diesen meine am PC vorgefertigten Bilder ablegen und nur noch bei Bedarf >das benötigte Bild an den Displaycontroller senden? Kann man, braucht man hier aber nicht. >vom Mikrocontroller ausgelesen werden? Es steht ein per SPI >angeschlossene SD Karte und externes RAM zur verfuegung. Pack das Bild auf die SD-Karte. Einfach und preiswert. >Zur Übertragung an das Display kommt ein 24 Bit breiter Bus mit >zusätzlichen Steuerleitungen zum Einsatz. Um den Prozessor zu entlasten, >wärde ich gerne per DMA auf die Bilddaten zugreifen und auf den Bus >legen. Ist dies möglich Wenn es dein Prozessor und deine Software unterstützt. > oder stelle ich mir DMA da etwas zu einfach vor? Nein. Siehe DMA. >müsste ich dann zuvor durch den PC mit den Bilddaten beschreiben? Ist >dieses Vorgehen korrekt oder wird dies normalerweise anders umgesetzt? Wie bereits geschrieben kann man das Bild auch in den vorhandenen Flashspeicher schrieben. Man braucht dafür auch nicht 390kB, wenn man die Daten komprimiert. Dafür gibt es mehrere Möglichkeiten und für alle auch schon fertige Funktionen. Unkomprimierte BMP-Bildr speichert man nur sehr selten im Flash. Siehe Bildformate. Für dich wäre PNG oder JPG das Mittel der Wahl. >Edit: Ich möchte ja am Anfang ein komplettes Hintergrundbild laden und >das will ja irgendwo gespeichert werden. Deswegen fragen ich nach >externem Speicher. Wozu? Dein interner Flash reicht wahrscheinlich aus.
Hendrik B. schrieb: > ich arbeite derzeit an der Ansteuerung eines TFT-Displays mit einer > maximalen Auflösung von 480x272 Pixeln (24-Bit RGB). > Der Mikrocontroller (PSoC) und der Displaycontroller (SSD1963) sind > vorgegeben. Beiträge solcher Art lassen bei mir immer nen Brechreiz hochkommen. Warum bloß gibt es Leute, die ihren Entwicklern derartige Vorgaben machen und sie dann im Regen stehen lassen? So ein Controller von Solomon ist schwer zu kriegen, hierzulande m.W. allenfalls von Gleichmann und er kostet ja auch nicht nix. Dazu kommt, daß er wie fast alles von Solomon auf Portbetrieb ausgerichtet ist. Also keine Einbindung als Quasi-RAM, sondern für jeden Furz die CPU mit Load-Store anwerfen. Das gilt auch für das Einblenden von den genannten Zahlen, denn die sollen ja nicht in einem häßlichen schwarzen Viereck den Betrachter angrinsen. Also ist das Laden des betreffenden Hintergrund-Teiles fällig, dann Zahlendarstellung drauf, dann Load-Store oder wie wir hier das mal nennen wollen. Als nächstes braucht man kein Prophet zu sein, daß garantiert in 3 Wochen der Cheffe angerannt kommt und sich ne Animation wünscht oder mit sonstigen Zusätzen aufwartet - und da ist man bereits vom Systemdesign her schon an die Wand gerannt. Ein Gleiches gilt für dich Hendrik selbst: Ich glaube nicht, daß du mit rein statischen am PC gemalten Bildern froh wirst. Stattdessen wirst du ganz gewiß zu einer Zweiteilung übergehen: Hintergrundbild und darauf Icons gesetzt, die bei Berührung ein optisches Feedback für den Benutzer geben. Ohne Feedback ist das Ganze nämlich sehr unergonomisch und nicht wirklich gut benutzbar. Also denke gleich am Anfang daran, dann mußt du später nicht so viel Entwicklungsarbeit wegschmeißen. Wenn man dann dazu bedenkt, daß zumindest die größeren PSOC's angeblich freie programmierbare Logik enthalten, dann wäre es zumindest einen Versuch wert, zu überlegen, ob man denn nicht: 1. ohne SSD1963 auskommt 2. mit 16 Bit Farbtiefe auskommt 3. mit einem externen statischen 16 Bit breitem 512K großen RAM auskommt 4. die Displaylogik aus DMA und programmierbarer Logik im PSOC bilden kann 5. Bilder und anderes Zeugs entweder gepackt im Flash oder in einem billigen externen seriellen Flash unterbringt Natürlich gibt es noch ganz andere Denkmöglichkeiten: anderer µC, wo die ganze TFT-Bedienung bereits integriert ist und dazu nen ausreichenden externen RAM. In Summe dürfte das wohl günstiger kommen als die Kombi aus PSOC+SSD1963. Also mein Rat: nochmal gut nachdenken und ggf. bereits eingeschlagene mentale Pflöcke wieder herausziehen und woanders einschlagen. W.S.
W.S. schrieb: > Natürlich gibt es noch ganz andere Denkmöglichkeiten: anderer µC, wo die > ganze TFT-Bedienung bereits integriert ist und dazu nen ausreichenden > externen RAM. In Summe dürfte das wohl günstiger kommen als die Kombi > aus PSOC+SSD1963. Soweit ich das überblicke, steckt auf vielen Displays der SSD1963 schon mit auf der Ansteuerplatine. Ein Beispiel von Ramschikowski: http://www.buydisplay.com/default/4-3-lcd-touch-screen-module-display-tft-ssd1963-controller-mcu Die Schnittstelle nach außen ist dann 8 -> 24 Bit breit. Das ist natürlich erst einmal sehr verlockend. Andere Displays lassen sich auch per SPI betreiben, was für das Auslesen von Pixeln am 'optimalstesten' ist ;-)
Vielen Dank für die Einwände. Muss mir das wohl nochmal durch den Kopf gehen lassen. Könntet ihr sonst einen alternativen Display-Controller empfehlen (gerne auch seriell ansteuerbar)? Die größe des Displays soll 5" betragen. Die Farbtiefe sollte mit 16 Bit auch ausreichend sein. Vielen Dank für eure Hilfe!
Hendrik B. schrieb: > Könntet ihr sonst einen alternativen Display-Controller empfehlen (gerne > auch seriell ansteuerbar)? Die größe des Displays soll 5" betragen. Die > Farbtiefe sollte mit 16 Bit auch ausreichend sein. 5" Android Gerät mit USB-Host-Funktion, daran USB-seriell Wandler. done.
Tobias K. schrieb: > daran USB-seriell Wandler Nenn doch mal den Typ, der data, clock und strobe ausgibt.
Muss aus Einzelteilen bestehen. Also leider kein 5" Androidgerät möglich. ;) Mikrocontroller, ggf. Displaycontroller und Display. Alles einzeln beziehbar.
Hendrik B. schrieb: > Mikrocontroller, ggf. Displaycontroller und Display. Alles einzeln > beziehbar. Dann könntest Du z.B. mit einem fertigen Board anfangen, was wohl kurzfristig erhältlich ist: http://www.watterott.com/de/MOD-LCD43?x141a0=b86dea82ecd7c2efa7160c09ca18e9ff Andere µCs mit eingebautem LCD-Controller gibt es auch: z.B. STM32F429. Für einen kleinen Bildspeicher ginge auch ein schnelles statisches RAM 256kx16 mit 10 ns. Wenn man nicht extra externes RAM dazubauen möchte, gibt es schöne LCD-Controller von Epson: z.B. S1D13781 derzeit gut verfügbar bei digikey. Und wenn Du nicht auf höhere Farbtiefe angewiesen bist, braucht reicht das interne RAM eines µC dafür auch: Beitrag "TFT-direct-drive, WQVGA-TFT an STM32F4" Hier macht der DMA-Controller die ganze Arbeit ;-)
m.n. schrieb: > Die Schnittstelle nach außen ist dann 8 -> 24 Bit breit. Das ist > natürlich erst einmal sehr verlockend. jaja - weil die Leute dann glauben, daß sie ja bloß mal eben 8 Bit weise ihre Wunschdaten ins Display löffeln müssen und schon ist alles wunderfein. Im Prinzip machen es einem die Controller von Solomon ja auch so leicht wie nur möglich, indem sie das Definieren von BitBlt-Rechtecken gestatten - aber letztendlich ist das immer nur ein ziemlicher Krampf. Da wären die "EVE"-Chips von FTDI noch eher benutzbar. Die verstehen m.W. sowas wie "höhere" Grafikkommandos, womit das lowlevel-Gewusel im angeschlossenen µC vermutlich deutlich reduziert wird. Aber ein richtiger Ersatz für einen ausreichend groß dimensionierten µC (z.B. LPC4088 im 208er Gehäuse) ist das alles nicht. W.S.
Weil das die zu erzeugenden SPI-Signale sind, wenn Du USB->seriell umsetzen willst. Gemeint hast Du aber wohl einen seriell->USB-Wandler, der müßte dann die SPI-Signale verwerten können. Oder wolltest Du Bilddateien per RS232 übertragen? Na das kann dauern! Egal ;-) W.S. schrieb: > Aber ein richtiger Ersatz für einen ausreichend groß dimensionierten µC > (z.B. LPC4088 im 208er Gehäuse) ist das alles nicht. Vielleicht ist einer mit 256 Pins noch besser? Bleib mal auf dem Teppich, auch ein byteweiser Zugriff kann zügig gehen, sofern es sich nur um sequentielle Schreiboperationen handelt. Ferner hängt die Zugriffszeit auch vom TFT-Controller ab, wann und wie schnell er neue Daten in den Bildspeicher schreiben darf. Das pixelweise Zurücklesen ist aber schon deutlich langsamer und kann grenzwertig werden, wenn viele Pixel umgeschaufelt werden müssen, das Verschieben von Fenstern zum Beispiel. Das wird hier aber garnicht gebraucht. Welche Bauteile nun tatsächlich zwingend vorgegeben sind oder noch frei wählbar bleiben, ist mir nicht mehr so ganz klar. Wenn die Kosten für den µC nicht kritisch sind, würde ich einem (erfahrenen) Entwickler einen aktuellen µC nahelegen, der den kompletten Bildspeicher schon auf dem Chip hat. Ein STM32F7 könnte gehen, oder ganz edel ein RX64M. Aber wie oben geschrieben, ginge auch ein popeliger STM32F407 nebst ext. RAM. @Hendrik: besorge Dir meinetwegen ein Display mit eingebautem SSD1963 und spiele damit herum, oder sag mir, was Du brauchst, dann schraube ich Dir das zusammen ;-) Allerdings würde ich ein handelsübliches 4,3" Display bevorzugen. Ein 5" TFT ist schwerer beschaffbar, mit Sicherheit teurer und bietet von der Größe her kaum einen Vorteil.
m.n. schrieb: > Das pixelweise Zurücklesen ist aber schon deutlich langsamer und kann > grenzwertig werden, Ja, damit kommen wir dem Kern des Pudels ein Stück näher. Zum Schluß läuft es dann doch drauf hinaus, das Bild komplettiko im RAM aufzubauen und dann im Ganzen in's Display zu verfrachten. Ist übrigens gut für's "entflimmern", weil man in aller Ruhe den RAM ablöschen und neu aufsetzen kann, ohne das im Display vorhandene Bild zu beeinflussen. Und was hast du gegen einen 208 Pinner? Die löten sich genauso wie alles andere - außer BGA. Und so einer hat zumeist auch schon alles drin, was der TO für seinen eigentlichen Job ohnehin brauchen wird. Ach, macht doch wie ihr wollt... W.S.
W.S. schrieb: > Ach, macht doch wie ihr wollt... Sowieso. Aktuelle LCD-Controller bieten u.U. im eingeschränkten Umfang, eine Bild-in-Bild Funktion, die einen statischen Hintergrund und einen dynamischen Vordergrund erlaubt. Der neu zu schreibende Bereich ist damit klein und schnell separat gelöscht und neu beschrieben. Aber wie immer: es kommt darauf an, was gefordert wird.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.