Hallo, da die preiswerten TFT-Displays >= 2,8" oft nur noch eine 18-Bit RGB/Sync Schnittstelle haben, möchte ich meine bisherige 18-Bit 8080-Interface-Lösung ersetzen. Also muss irgend jemand die Pixeldaten a tempo an den Display liefern. Nach einigem Blättern (mit der Maus :-)) kam mir die Idee, einen PIC32 zu verwenden, 128k RAM reichen als Bildspeicher aus und es ist noch Platz für die Funktionen, die bei der alten Lösung ein ATMega645 übernahm. Hat jemand so etwas schon einmal umgesetzt, oder bin ich total auf dem Holzweg? Preislich ist der PIC32 mit < 5,00€ OK. Ausserdem kommt für die übrigen Aufgaben noch ein kleinerer PIC32 dazu, der z.B. mit dem DSP kommuniziert. Grüße, Kurt
Geht und ist vermutlich schon in einem Microchip Beispiel so implementiert worden: http://www.microchip.com/pagehandler/en-us/technology/graphics/products/pic32lccg.html http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en555047
Hi, Kurt Harders schrieb: > Hat jemand so etwas schon einmal umgesetzt, oder bin ich total auf dem > Holzweg? Das ist schon vielfach so umgesetzt worden und der PIC32 ist dafür (wie allerdings viele andere 32Bit µC auch) durchaus eine gute Lösung. http://www.microchip.com/pagehandler/en-us/technology/graphics/ Es gibt dazu auch direkt von Microchip bereits eine fertige Library die viele der Grafikfunktionen bereits von sich aus bietet, sowie ein paar weitere SW Tools (Mit denen ich aber selbst noch nicht gearbeitet habe). http://www.microchip.com/pagehandler/en-us/technology/graphics/tools/software.html http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en543091 Neben dem PIC32 würden mir Alternative noch die diverse µC auf ARM Basis einfallen (ARM7, Cortex M3) wie sie viele Hersteller im Programm haben. Von der Leistung tn die sich nichts. Die Vorteile die mich aber immer wieder dazu bewegen den PIC32 zu wählen sind die niedrigen Kosten für die Entwicklungstools (Programmer mit DEBUGFUNKTION auch für gewerbliche Nutzer bereits ab ca 35 Euro. Alle Compiler OHNE Größenbeschränkung frei, lediglich etwas geringere Performance bei der Optimierung im vergleich zur Kostenpflichtigen Version ) Für manche ist es auch ein Vorteil das man eine Oberfläche für alle Familien hat (Egal ob 8Bit, 16Bit mit und Ohne DSP, oder der 32Bit. Alles die selbe IDE, alles die selbe Programmierhardware) Ausserdem gibt es für die PIC sehr viele Libs für alle möglichen Anwendungsfälle direkt von Microchip, fast alle auch bei kommerziellen Entwicklungen ohne Beschränkungen frei Einsetzbar. - Keine immer wieder aufkommenden Lizenzfragen wie sie bei Drittlösungen oft aufkommen. Zudem eine sehr gute Verfügbarkeit der Bauteile, egal ob als Einzelstück oder Kartonweise. Wirkliche Beschaffungsprobleme hatte ich da nie erlebt. Wenn mal 14 Tage Wartezeit waren dann war das schon sehr viel. Gruß Carsten
Kurt Harders schrieb: > kam mir die Idee, einen PIC32 zu verwenden, 128k RAM reichen Kopfschüttel.. Warum nur? So ein LCD-Controller für bunte QVGA-Displays und aufwärts ist doch geradezu ein Paradebeispiel für ein CPLD und ein Stück RAM dran. Mit 256K als 128Kx16 kommt man bequem bis 320x240 und für die recht üblichen 480x272 braucht man die nächstgrößere Stufe, also 512K als 256Kx16. Als CPLD reicht eines mit 144 MC völlig aus, wahrscheinlich tut's auch ein 128er. Wozu also so ein Krampf mit einem mißbrauchten µC? Weil der Einstieg in die CPLD-Programmierung zu schwer ist? Nun ja, wahrscheinlich. Aber man kann - zumindest bei Xilinx - das Ganze auch per Schematics erledigen. Ist zwar nicht komfortabel, aber geht. Derzeit läuft zu diesem Thema grad ne kontroverse Diskussion im FPGA&VHDL-Bereich. Die Alternative zu deinem Vorhaben wäre ein µC, der so eine Ansteuerung bereits drin hat, also z.B. ein LPC2478 oder seine pinkompatiblen neueren Brüder aus der Cortex-Branche. Die Dinger liegen m.W. unter 10 Euro, dazu noch ein billiges SDRAM und du hast von allem genug: nen leistungsfähigen µC, wo sich die HW um den Bildaufbau kümmert und der µC plenty Zeit hat, deine Vorhaben zu erledigen und RAM bis zum Abwinken. DAS wäre die wirklich sinnvollste Lösung, aber doch nicht so ein Krampf mit einem µC als LCD-Controller. Ich frag dich mal, was du da eigentlich auf dem Display darstellen willst? Ein Standbild in 256 Farben und langsamem Aufbau? W.S.
Ein FT800 wäre u.U. die zumindest stromsparendere Lösung, wenn die Auflösung reicht. Angesteuert wird das Teil mit SPI oder I²C... http://www.ftdichip.com/Products/ICs/FT800.html
W.S. schrieb: > Kurt Harders schrieb: >> kam mir die Idee, einen PIC32 zu verwenden, 128k RAM reichen > > Kopfschüttel.. > > Warum nur? So ein LCD-Controller für bunte QVGA-Displays und aufwärts > ist doch geradezu ein Paradebeispiel für ein CPLD und ein Stück RAM > dran. > > Mit 256K als 128Kx16 kommt man bequem bis 320x240 und für die recht > üblichen 480x272 braucht man die nächstgrößere Stufe, also 512K als > 256Kx16. Als CPLD reicht eines mit 144 MC völlig aus, wahrscheinlich > tut's auch ein 128er. Wenn er wirklich nur einen LCD Controller wollte dann ist ein CPLD wohl tatsächlich eine Überlegung wert. Aber so wie ich das hier verstehe will er die Daten nicht nur ans Display schicken sondern auch Aufbereiten. Und damit ist die CPLD Lösung dann wieder nur die zweitbeste Lösung da man dann mindestens zwei Programmierbare Bausteine braucht... einen CPLD mit minimum 144 MC (Bei kleiner Stückzahl um 4 Euro aufwärts) und der bisher verwendete µC ATMega645 der bei Mouser ab 6 Euro losgeht... Sind 10 Euro, falls er es noch nicht beherrscht die Notwendigkeit das ganze Thema CPLD erst einmal zu lernen, immer ZWEI Baustellen auf der selben Baugruppe offen zu haben (CPLD und µC) usw. usf. Für sich betrachtet mag die Lösung mit CPLD zwar gut klingen, in diesem Fall dürfte die aber einfach nur Umständlich und teuer sein. Zumal du scheinbar keine große erfahrung in der Grafikprogrammierung mit 32Bit µC hast und darum etwas wichtiges übersiehst - aber dazu weiter unten. > > Wozu also so ein Krampf mit einem mißbrauchten µC? Weil der Einstieg in > die CPLD-Programmierung zu schwer ist? Nun ja, wahrscheinlich. Aber man > kann - zumindest bei Xilinx - das Ganze auch per Schematics erledigen. > Ist zwar nicht komfortabel, aber geht. Derzeit läuft zu diesem Thema > grad ne kontroverse Diskussion im FPGA&VHDL-Bereich. Wie schon geschrieben, Selbst wenn jemand VHDL beherscht ist diese Lösung einfach Umständlicher als einen beliebigen, ausreichend Leistungsfähigen, µC dafür zu nehmen. OK, ab gewissen Anforderungen kommen die an ihre Grenzen, aber Video auf einem 3" TFT Display abspielen ist noch weit von der Grenze entfernt. > > Die Alternative zu deinem Vorhaben wäre ein µC, der so eine Ansteuerung > bereits drin hat, also z.B. ein LPC2478 oder seine pinkompatiblen > neueren Brüder aus der Cortex-Branche. Die Dinger liegen m.W. unter 10 > Euro, dazu noch ein billiges SDRAM und du hast von allem genug: nen > leistungsfähigen µC, wo sich die HW um den Bildaufbau kümmert und der µC > plenty Zeit hat, deine Vorhaben zu erledigen und RAM bis zum Abwinken. > DAS wäre die wirklich sinnvollste Lösung, aber doch nicht so ein Krampf > mit einem µC als LCD-Controller. Häh? Genau das was du da beschreibst (nur ohne Externen Ram) will er doch realisieren. Oder ziehst du dich an der beim LPC beworbenen TFT Ansteuerung hoch. Dann sei dir dazu gesagt das dies im grunde nichts weiter ist als ein zusätzlicher DMA Controller! Denn die Ausgabe von Videodaten wird wohl in 99% der Fälle einfach über DMA Zugriff realisiert, der µC Kern wird damit kaum belastet. der hat sich nur um die Aufbereitng/Aktualisierung zu kümmern. Der LPC und ähnliche haben halt einen speziell dafür reservierten zweiten DMA Controller. Alle anderen machen das mit dem "normalen" DMA Controller... Der Zweite DMA controller bringt dann vorteile wenn man neben der Videoausgabe noch so viele andere DMA Zugriffe hat das einem die Zeiten weglaufen. Das ist aber wohl ein seltener Spezialfall, weshalb viel Anbieter bei den "großen" µC das erst überhaupt nicht aufnehmen. (Bei den 16Bittern wo es mit DMA ja doch etwas anders aussieht als bei den 32ern hat Micrchip übrigends tatsächlich auch spezial µC) Ein geschickter umgang mit den DMA Zugriff bewirkt nämlich dasselbe als wenn man einem µC einen CPLD zur Seite stellt... der Kern muss sich überhaupt nicht groß um die Ausgabe scheeren. > > Ich frag dich mal, was du da eigentlich auf dem Display darstellen > willst? Ein Standbild in 256 Farben und langsamem Aufbau? Wie schon geschrieben - ein laufendes Videobild mit gleichzeitiger Tonausgabe sind auf EINEM "0815" PIC32 überhaupt kein Problem. (Bei den meisten Cortex M3/ARM7 auch ohne speziall TFT fähigkeiten im übrigen auch nicht) Ist alles eine Frage der Programmierung Gruß Carsten
W.S. schrieb: > Kurt Harders schrieb: >> kam mir die Idee, einen PIC32 zu verwenden, 128k RAM reichen > > Kopfschüttel.. Dann schüttel den Kopf mal kräftig weiter, bis er abfällt - und halt nen Mülleimer darunter ... Kurt Harders schrieb: > Hat jemand so etwas schon einmal umgesetzt, oder bin ich total auf dem > Holzweg? Mit dem Gedanken hatte ich auch schon gespielt, bis das STM32F4-Discovery-Board auf der Speisekarte erschien. Der STM32F4xx hat sogar genug RAM, um ein 4,3" TFT mit 480x272 anzusteuern - zumindest mit 256 Farben, was für viele Anwendungen völlig ausreicht. Meinen Ansatz findest Du hier: Beitrag "TFT-direct-drive, WQVGA-TFT an STM32F4" Neuerdings tauchen STM32F427 auf, die intern über noch mehr Speicher verfügen und den Betrieb eines QVGA-TFT mit 16-Bit Farbtiefe ermöglichen. Die µCs sind so schnell und die DMA-Ausgabe aufs Display benötigt fast keine Prozessorleistung, dass sich die Kostenrechnung dadurch verbessert, dass man keinen 2. Prozessor mehr braucht.
Microchip gibt sogar an wieviel Rechenleistung für das Display mit einem PIC32 per DMA drauf geht: 5 MIPS von den vorhandenen 80 MIPS. D.h. mehr oder weniger vernachlässigbar. Natürlich ist die Idee des Threadstarters quatsch einen PIC32 allein für das Display bereitzustellen und einen zweiten zum Daten aufbereiten zu verwenden. Ein einziger PIC32 reicht da allemal.
Arc Net schrieb: > Ein FT800 wäre u.U. die zumindest stromsparendere Lösung, wenn die > Auflösung reicht. Angesteuert wird das Teil mit SPI oder I²C... > http://www.ftdichip.com/Products/ICs/FT800.html Der FT800 wäre interessant. Allerdings übernimmt der µC auf meiner Display-Platine auch die Anwendungsschicht, also Slider, Radiobutton... Diese Aufteilung und die Kommunikation mit der DSP-Basisplatine haben sich bewährt und sollen inklusive Schnittstelle (SPI) erhalten bleiben. Der einzige Grund für ein Redesign mit RGB-Ansteuerung ist die Verfügbarkeit und Standardisierung des TFT-Interfaces. Gerade bei 2,8"-TFT wird schnell mal abgekündigt. Wenn man dann auf ein Ersatzdisplay ausweichen muss, das einen anderen Controller hat, ist der Aufwand zwar endlich aber spürbar. Da reicht schon, dass meist das Layout zu ändern ist. Grüße, Kurt
Frank M. schrieb: > Microchip gibt sogar an wieviel Rechenleistung für das Display mit einem > PIC32 per DMA drauf geht: 5 MIPS von den vorhandenen 80 MIPS. D.h. mehr > oder weniger vernachlässigbar. > > Natürlich ist die Idee des Threadstarters quatsch einen PIC32 allein für > das Display bereitzustellen und einen zweiten zum Daten aufbereiten zu > verwenden. Ein einziger PIC32 reicht da allemal. Hallo Frank, im Prinzip hast Du Recht :-). Allerdings brauche ich aus mechanischen Gründen zwei Platinen. Die derzeitige Schnittstelle zwischen Anwendung und Displayplatine hat sich bewährt und schon einen Displaytausch wegen Abkündigung schadlos überstanden :-). Da die Anwendungsplatine möglicherweise in verschiedenen Varianten gebaut wird, ist eine einheitliche Displayplatine bei Losgrößen von 100-200 von Vorteil. Grüße, Kurt
Hallo, Dank an alle, die mir bei der Entscheidungsfindung geholfen haben. Erste Sichtung der PICs ist abgeschlossen, andere µC werde ich mir auch noch anschauen. Grüße und Dank, Kurt
Kurt Harders schrieb: > Gerade bei > 2,8"-TFT wird schnell mal abgekündigt. Sei mir nicht böse, aber wozu sind diese Displays gut außer für Consumer-Zeug? Wofür verwendest Du sie? Richtig bedienen kann man (ich) sie nur per Stift und richtig ablesen nur mit Lupe. Preis-Leistung ist meines Erachtens momentan bei 4,3" WQVGA am besten.
m.n. schrieb: > Kurt Harders schrieb: >> Gerade bei >> 2,8"-TFT wird schnell mal abgekündigt. > > Sei mir nicht böse, aber wozu sind diese Displays gut außer für > Consumer-Zeug? Wofür verwendest Du sie? Die sind in einem Consumer-Gerät (Hörverstärker) eingesetzt. > Richtig bedienen kann man (ich) sie nur per Stift und richtig ablesen > nur mit Lupe. Bedient wird mit einem Kombiteil aus 5xTaste+Jogwheel. Touch scheidet aus, da zu klein :-). Lesen kann man das Display gut und für die Oberfläche bei Nutzung reicht die Größe sehr gut aus. > Preis-Leistung ist meines Erachtens momentan bei 4,3" WQVGA am besten. 4,3" sind schon zu groß, da das Display nur während der Parametrierung des Verstärkers grafische Informationen anzeigen muss. Für die Bedienung reichen 2,8" 240x320 gut aus. Preis-Leistung wird in der Überarbeitung optimiert :-). Grüße, Kurt
Kurt Harders schrieb: > Die sind in einem Consumer-Gerät (Hörverstärker) eingesetzt. Gut, dann muß es klein sein.
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.