Hallo Zusammen, ich möchte mit einem STM32L452RET6 ein 3.5" Touch Display ansteuern. Das Display hat einen 16/18/24Bit Eingang. Nun habe ich auf dem MCU aber nicht genügend Pins, da ich noch andere dinge Ansteuern muss in diesem Projekt. In einem anderen Forum bin ich auf diesen interessanten Beitrag gestossen, wo jemand eine QSPI zu 8080 Parallel RGB Schnittstelle realisiert hat mit einem kleinen FPGA: https://forum.lvgl.io/t/qspi-to-parallel-converter-with-small-fpga/2944/7 Leider kann ich nicht den nächst grösseren 100-Pin MCU nehmen, weil dem wichtige Features (Externe SMPS) fehlen, die es nur im 64-Pin oder BGA (möchte für den ersten Prototypen nur ein LQFP-Gehäuse verwenden) Gehäuse gibt. Weiss aber jemand ob es dies als fertige Lösung gibt? Oder hat jemand schon mal etwas ähnliches gemacht?
Die Frage verstehe ich nicht so recht. Du hast keine QSPI-Schnittstelle verfügbar? Du willst das, was jemand mit einem FPGA angestellt hat, irgendwie anders hinbekommen? Was soll denn auf dem Display dargestellt werden? Video? Schnell wechselnde Inhalte (wie z.B. in einem Computerspiel), oder geht es nur um eine Menüsteuerung und ein paar Statusanzeigen? Letzteres kann auch ein Display mit integriertem Controller, dafür brauchst Du keine RGB-Ansteuerung und keinen Framebuffer im µC, sondern schickst dem Display nur Befehle, was es anzeigen soll. Und dafür reicht irgendeien serielle Schnittstelle aus, egal, ob SPI, I2C, normale UART ...
Harald K. schrieb: > Die Frage verstehe ich nicht so recht. Du hast keine QSPI-Schnittstelle > verfügbar? Nein, eine QSPI Schnittstelle hätte ich. >Du willst das, was jemand mit einem FPGA angestellt hat, > irgendwie anders hinbekommen? Ich suche einen fertigen chip, der das selbe macht wie der mit dem FPGA. Theoretisch würde ich auch das FPGA verwenden, in dem bin ich aber nicht so fit. > Was soll denn auf dem Display dargestellt werden? Video? Schnell > wechselnde Inhalte (wie z.B. in einem Computerspiel), oder geht es nur > um eine Menüsteuerung und ein paar Statusanzeigen? Es geht nur um eine Menü Steuerung, die ich mit LVGL oder TouchGFX darstellen möchte. Es muss demensprechend nicht so schnell sein. Wenn das auch mit Logik Bausteinen (Was ja in einem FPGA auch nicht anderst gemacht wird) möglich ist, würde ich auch das versuchen. > > Letzteres kann auch ein Display mit integriertem Controller, dafür > brauchst Du keine RGB-Ansteuerung und keinen Framebuffer im µC, sondern > schickst dem Display nur Befehle, was es anzeigen soll. Der Punkt ist, das Display habe ich schon. Das hat nur eine Parallele Schnittstelle.
Nun, Du könntest Dir den FT800 und seine Nachfolger/Geschwister ansehen. Das ist ein Displaycontroller von FTDI bzw. Bridgetek https://www.ftdichip.com/old2020/EVE.htm https://brtchip.com/ Hier in der Codesammlung hat sich auch schon mal jemand mit den Dingern beschäftigt: Beitrag "FT800 / FT810 Library"
Moot S. schrieb: > In einem anderen Forum bin ich auf diesen interessanten Beitrag > gestossen, wo jemand eine QSPI zu 8080 Parallel RGB Schnittstelle > realisiert hat mit einem kleinen FPGA: > https://forum.lvgl.io/t/qspi-to-parallel-converter-with-small-fpga/2944/7 Warum muss es QSPI sein? Wenn es nicht abartige schnell sein muss, reicht old school SPI und das macht man mit 1-3 74(A)HC595. Die Handshake Signale legt man direkt an die CPU, dann ist das schnell. Das kann man spielend mit 10MHz takten, damit dauern die 24 Bit "satte" 1,2us. Mit Handshake per CPU vielleicht 1,5us, macht ~600kB/s. Wenn man nicht gerade Video mit 30fps darstellen will, reicht das. Vermutlich kriegt man das auch per DMA hin, dann hat die CPU gar nichts zu tun, nicht mal für die Steuersignale.
Moot S. schrieb: >> Letzteres kann auch ein Display mit integriertem Controller, dafür >> brauchst Du keine RGB-Ansteuerung und keinen Framebuffer im µC, sondern >> schickst dem Display nur Befehle, was es anzeigen soll. > Der Punkt ist, das Display habe ich schon. Das hat nur eine Parallele > Schnittstelle. Du übersiehst dabei, dass ein passendes Display mit integriertem Speicher und Controller wahrscheinlich die günstigere Alternative ist. Das vorhandene Display wird sicher eines ohne Controller sein, das 60 mal in der Sekunde seinen kompletten Bildschirminhalt bekommen muss. Das schließt dann natürlich irgendwelche I2C- und SPI-GPIO-Extender komplett aus. Du warst ja nicht mal schlau genug, den EXAKTEN(!) Typ Deines Displays mitzuliefern. fchk PS: So etwas hilft bei controllerlosen Displays: https://vdc.epson.com/display-controllers/lcd-controllers/s1d13781
:
Bearbeitet durch User
Falk B. schrieb: > Warum muss es QSPI sein? Muss es nicht, SPI reicht auch aus. >Wenn es nicht abartige schnell sein muss, > reicht old school SPI und das macht man mit 1-3 74(A)HC595. Die > Handshake Signale legt man direkt an die CPU, dann ist das schnell. Das > kann man spielend mit 10MHz takten, damit dauern die 24 Bit "satte" > 1,2us. Ja danach Frage ich ja?
Moot S. schrieb: >> Wenn es nicht abartige schnell sein muss, >> reicht old school SPI und das macht man mit 1-3 74(A)HC595. Die >> Handshake Signale legt man direkt an die CPU, dann ist das schnell. Das >> kann man spielend mit 10MHz takten, damit dauern die 24 Bit "satte" >> 1,2us. > Ja danach Frage ich ja? Dann schau dir mal den Artikel AVR-Tutorial: Schieberegister an, da steht eigentlich alles zur Hardware. Die Software ist natürlich für AVR, sollte sich aber leicht auf den STM32 übertragen lassen. Man muss ja nur die Bytes über das Hardware-SPI an die 74HC595 ausgeben.
Frank K. schrieb: > Du warst ja nicht mal schlau genug, den EXAKTEN(!) Typ Deines Displays > mitzuliefern. Hat ja niemand gefragt. Display: PH320240T028-ZEA Display Treiber ist ein: ST7272A Schnittstelle: 24-Bit RGB Datenblatt liegt im Anhang. Problem: Ich habe nicht genügend Pins... Suche: Einen Chip, dem man Seriell Daten senden kann und diese auf Parallel ans Display weiter gibt. Immer noch unklar?
Moot S. schrieb: > Suche: Einen Chip, dem man Seriell Daten senden kann und diese auf > Parallel ans Display weiter gibt. Wie gesagt: drei kaskadierte 74HC595, angeschlossen an MISO, SCK sowie einen Ausgang für RCK (und evtl. ¬OE). Die machen genau das.
Harald K. schrieb: > Nun, Du könntest Dir den FT800 und seine Nachfolger/Geschwister ansehen. > Das ist ein Displaycontroller von FTDI bzw. Bridgetek Das sieht eigentlich genau nach dem aus, was sich suche.
Moot S. schrieb: > Frank K. schrieb: >> Du warst ja nicht mal schlau genug, den EXAKTEN(!) Typ Deines Displays >> mitzuliefern. > > Hat ja niemand gefragt. > > Display: PH320240T028-ZEA > Display Treiber ist ein: ST7272A > Schnittstelle: 24-Bit RGB Genau. Parallel RGB mit HSYNC/VSYNC und/oder DE und ohne integrierten Speicher. Vergiss das mit Schieberegisters. Bei einem Display mit 8080 Prozessorinterface wäre das gegangen, aber hier nicht. Schau mal hier: https://www.buydisplay.com/3-2-inch-tft-lcd-display-capacitive-touchscreen-st7789v-spi-240x320 Ansteuerbar per SPI, mit integriertem Bildschirmspeicher und wahlweise mit Touch. Für den Preis bekommst Du nicht mal den Bridgetek-Controllerchip. Allein der einzelne Chip liegt bei ca 15$. Also vergiss Dein Display und kauf was passendes. fchk PS: aus Deutschland: ebay #175544429395 als Beispiel.
Moot S. schrieb: > Frank K. schrieb: >> Du warst ja nicht mal schlau genug, den EXAKTEN(!) Typ Deines Displays >> mitzuliefern. > > Hat ja niemand gefragt. > > Display: PH320240T028-ZEA > Display Treiber ist ein: ST7272A > Schnittstelle: 24-Bit RGB > > Datenblatt liegt im Anhang. Naja, aber da sieht man schon das Problem. Das LCD ist "dumm", der Controller macht nicht sooo viel. Man muss es dauerhaft und auch relativ schnell mit Displaydaten füttern. Denn laut Datenblatt will es 5-8 MHz Takt an DCLK sehen. Man kann versuchen, das zuhacken und mit deutlich weniger zu betreiben, kann funktionieren. Muss nicht. > Suche: Einen Chip, dem man Seriell Daten senden kann und diese auf > Parallel ans Display weiter gibt. Das allein reicht nicht. Das Ding hat keinen Bildschirmspeicher, nur die TFT-Matrix und bissel Hilfslogik. Im Normalfall braucht man einen größeren Mikrocontroller, welcher die TFT-Ansteuerung per Hardware / Modul macht.
Frank K. schrieb: > Für den Preis bekommst Du nicht mal den Bridgetek-Controllerchip. Allein > der einzelne Chip liegt bei ca 15$. Also vergiss Dein Display und kauf > was passendes. Eben! Alles andere ist nur ein Krampf und kostet am Ende DEUTLICH mehr bei DEUTLICH schlechterem Ergebnis!
Falk B. schrieb: > Das allein reicht nicht. Das Ding hat keinen Bildschirmspeicher, nur die > TFT-Matrix und bissel Hilfslogik. Im Normalfall braucht man einen > größeren Mikrocontroller, welcher die TFT-Ansteuerung per Hardware / > Modul macht. Damit meinst du einen Kontroller mit integriertem Display Controller wie z.B. LDTC ?
Ne, der Controller ist mit drauf, aber anscheinend ziemlich doof.
Abdul K. schrieb: > Ne, der Controller ist mit drauf, aber anscheinend ziemlich doof. Es gibt Controller und Controller. Die einfachen wie beim OP wandeln nur einen parallelen, dauerhaften Datenstrom + Sync-Signale in die Ansteuersignale de TFT-Matrix incl. Helligkeiten etc. um. Die intelligenten haben einen Bildwiderholspeicher und ein serielles oder paralleles Interface nach "oben". Wenn einmal ein Bild dort gespeichert wurde, kann man sich alle Zeit der Welt lassen, neue Daten hochzuladen, die alten werden kontinuierlich dargestellt.
Frank K. schrieb: > Schau mal hier: > https://www.buydisplay.com/3-2-inch-tft-lcd-display-capacitive-touchscreen-st7789v-spi-240x320 Ich bezog mich auf diesen hier. Hat Bildspeicher. Vor Jahrzehnten hatte ich mich mal mit dem T6963C abgequält.
:
Bearbeitet durch User
Als LCD-Controller nimmt man einfach einen zweiten STM32L452RET6. Oder, wenn Mengenrabatt keine Rolle spielt, einen L451C oder noch kleiner. Die beiden könnte man per SPI verbinden, aber UART spart Pins und ist einfacher zu programmieren. Teilen und herrschen! Nieder mit den Exoten;)
:
Bearbeitet durch User
Bauform B. schrieb: > Als LCD-Controller nimmt man einfach einen zweiten STM32L452RET6. Oder, > wenn Mengenrabatt keine Rolle spielt, einen L451C oder noch kleiner. Die > beiden könnte man per SPI verbinden, aber UART spart Pins und ist > einfacher zu programmieren. Teilen und herrschen! Nieder mit den > Exoten;) Naja, aber dann musst du folgendes machen: - 2x Firmware programmieren - Beide müssen immer separat geflasht werden - Bei Firmware Update Riesen Aufwand - Musst noch irgend ein Fancy Protokoll erfinden zwischen diesen beiden chips Ich habe das Display zurück gesendet. Hab mich nun für eines entschieden, dass einen Ili9488 chip mit internem RAM. Mann muss auch aufgeben können, wenn man zum 5. mal in die Wand rennt.
Moot S. schrieb: > Ich habe das Display zurück gesendet Vernünftig, aber auch schade, ein Abenteuer weniger ;) > Bauform B. schrieb: >> Als LCD-Controller nimmt man einfach einen zweiten STM32L452RET6. > > Naja, aber dann musst du folgendes machen: > - 2x Firmware programmieren du musst die Schnittstelle zum Display auf jeden Fall verstehen. Plus entweder einen exotischen SPI/8080-Wandler oder dein eigenes Programm, auf einem STM32 den du sowieso gut kennst. Aber die Firmware für den eigentlichen Controller wird einfacher, keine zeitkritischen Low-Level Sachen mehr. > - Beide müssen immer separat geflasht werden > - Bei Firmware Update Riesen Aufwand Nein, es gibt 2 Programme, aber die werden in ein gemeinsames Hex-File gepackt. Vom Handling her ändert sich garnichts, es dauert nur 2 Sekunden länger. Der "große" kann nämlich den Display-Controller über die sowieso benutzte Schnittstelle flashen (UART oder SPI, plus 1 GPIO). > - Musst noch irgend ein Fancy Protokoll erfinden zwischen diesen > beiden chips OK, mit Fancy muss man aufpassen, damit kann man viele lange Winterabende verbringen ;) Man kann aber auch das Protokoll von einem "intelligenten" Display kopieren. Die FPGA-Lösung sieht ungefähr gleich aus (2x programmieren, 2x Firmware) -- aber nur, wenn du das schon gemacht hast und die Infrastruktur vorhanden ist! Also, für mich wäre das eine der leichtesten Entscheidungen.
Bauform B. schrieb: > Moot S. schrieb: >> Ich habe das Display zurück gesendet > > Vernünftig, aber auch schade, ein Abenteuer weniger ;) Ja meine Anwendung ist Batterie betrieben falls ich das noch nicht geschrieben habe. Da macht das selber Treiben aus dem Kontroller garkeinen Sinn. Vielleicht probiere ich es später mal wieder wenn der Stromverbrauch nicht relevant ist. >> Bauform B. schrieb: >>> Als LCD-Controller nimmt man einfach einen zweiten STM32L452RET6. >> >> Naja, aber dann musst du folgendes machen: >> - 2x Firmware programmieren > > du musst die Schnittstelle zum Display auf jeden Fall verstehen. Plus > entweder einen exotischen SPI/8080-Wandler oder dein eigenes Programm, > auf einem STM32 den du sowieso gut kennst. Aber die Firmware für den > eigentlichen Controller wird einfacher, keine zeitkritischen Low-Level > Sachen mehr. > >> - Beide müssen immer separat geflasht werden >> - Bei Firmware Update Riesen Aufwand > > Nein, es gibt 2 Programme, aber die werden in ein gemeinsames Hex-File > gepackt. Vom Handling her ändert sich garnichts, es dauert nur 2 > Sekunden länger. Der "große" kann nämlich den Display-Controller über > die sowieso benutzte Schnittstelle flashen (UART oder SPI, plus 1 GPIO). Das Muss dann aber zwischen gespeichert werden, sonst müllst du ja das Flash vom grossen Controller zu. Du Kannst das ja nicht direkt auf den kleinen flashen, dann müsste man ja den Speicher Bus miteinander verbinden können. Das können diese kleinen Kontroller aber nicht. Sich mit dem Linker File anlegen ist auch gewagt wenn man nicht direkt weiss was man braucht. >> - Musst noch irgend ein Fancy Protokoll erfinden zwischen diesen >> beiden chips > > OK, mit Fancy muss man aufpassen, damit kann man viele lange > Winterabende verbringen ;) Man kann aber auch das Protokoll von einem > "intelligenten" Display kopieren. Ja das stimmt. > Die FPGA-Lösung sieht ungefähr gleich aus (2x programmieren, 2x > Firmware) -- aber nur, wenn du das schon gemacht hast und die > Infrastruktur vorhanden ist! Also, für mich wäre das eine der > leichtesten Entscheidungen. Ja ist bei mir nicht vorhanden.
:
Bearbeitet durch User
Moot S. schrieb: >> Der "große" kann nämlich den Display-Controller über >> die sowieso benutzte Schnittstelle flashen. > > Das Muss dann aber zwischen gespeichert werden, sonst müllst du ja das > Flash vom grossen Controller zu. > Du Kannst das ja nicht direkt auf den kleinen flashen Naja, wie sonst soll ich die 512K voll bekommen ;) Für die Serie, und/oder wenn 512k nicht reichen, könnte man ein Hilfsprogramm ins RAM laden. Evt. passt das "kleine" Programm auch ins RAM vom Großen. > dann müsste man ja den Speicher Bus miteinander verbinden können. > Das können diese kleinen Kontroller aber nicht. Auch wenn sie könnten, soviel Pins hat niemand übrig. Das muss über die vorhandene Verbindung gehen, sonst ist es uninteressant. > Sich mit dem Linker File anlegen ist auch gewagt > wenn man nicht direkt weiss was man braucht. Aus der Sicht von Compiler und Linker können das völlig getrennte Programme sein. Ich flashe dann die einzelnen Hex-Files einfach nacheinander. Man kann zwei *.S19 auch in einer Datei hintereinander hängen. Evt. muss man beim ersten die letzte Zeile löschen. Aber ich hör' schon auf, ich will niemanden überreden.
Moot S. schrieb: > Weiss aber jemand ob es dies als fertige Lösung gibt? Wozu braucht dein uC denn die anderen 60 Pins, die du NICHT fur das Display nutzt ? Meinst du nicht, dass sich dort besser Pins sparen lassen, als gerade bei der Hochgeschwindigkeits-Schnittstelle zum Display ? Und wenn du schon seriell (SPI) von deinem uC zum Display senden willst, wäre es da nicht sinnvoller einen zweiten 40-pin uC aus seriellen Kurzkommandos 'zeiche Linie' 'zeichne Buchstabe A' die ständig refreshten Bilddaten erzeugen zu lassen ? Mit 8080 hat das übrigens wenig zu tun.
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.