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.
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 ...
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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;)
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.
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.
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.
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.
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 ?
