Hallo zusammen,
ich suche nach einer fertigen Hardware oder einem Chip, der
CAN-Nachrichten empfangen und auf einer grafischen Oberfläche
visualisieren kann. Das ganze System muss sehr platzsparend sein und
sollte daher auch ein flaches TFT-Display mit parallelem Interface
(HSYNC, VSYNC, wie heißt das eigentlich wirklich?) haben.
Ich habe mich bereits mit dem LPC1788 versucht, was nie über einen
Schaltplan hinausging. Ich würde gerne ein Raspberry Pi (kein CAN, kein
LCD), ein BeagleBoard oder ein PandaBoard verwenden, allerdings scheint
alles nicht genau zu passen.
Ich habe mir mal einen HDMI-Converter-IC von Analog angesehen, das ist
aber auch heftig komplex. Lohnt sich das?
Ein fertiges Betriebssystem wäre wohl sehr hilfreich, oder?
Viele Grüße und Danke!
Danke für den Link, der mir gezeigt hat, dass ich mich genauer
ausdrücken muss. Tut mir leid.
Die Diagonale des Displays sollte mindestens 4,3" betragen, wobei 7"
auch schon wieder zu viel sind. Unabdingbar ist ein Touchpanel sowie
Darstellung in Farbe.
Das Display ist eigentlich gar nicht das Problem, ich habe hier auch
schon eines herumliegen (5,7" von Reichelt). Die Ansteuerung macht mir
mehr Sorgen. Da es solch kompakte Displays nicht mit integriertem HDMI
zu geben scheint (?), muss ich mit parallelem Interface arbeiten.
Um mir die Arbeit auf der Softwareseite zu erleichtern, wäre Linux oder
noch besser Android von immensem Vorteil. Allerdings scheint es hier
eben nicht so einfach zu sein, CAN und LCD einzubinden.
Der LPC1788 wäre toll gewesen, da NXP eine fertige Grafiklib anbietet.
Leider hat mich hier die Anbindung eines SDRAMS an meine Grenzen
gebracht. Die Entflechtung schien mir unmöglich.
Das ist dann leider ein Wunsch zu viel. In der gewünschten Displaygröße
gibts nur Displays ohne Speicher, die also 60 mal pro Sekunde wie ein
normaler Monitor ihre Bilddaten in 18 oder 24 Bit timinggerecht mit
HSYNC und VSYNC geliefert bekommen wollen.
Wenn Du bereit bist, auf ein Zoll Diagonale zu verzichten, wird die
gesamte Hardware SEHR(!!!) viel einfacher. In dieser Größe gibt es
nämlich Displays, die einen eingebauten Bildschirmspeicher haben. Diese
Displays kannst Du dann wie ein externes SRAM ansteuern. Die Auflösung
dieser Displays beträgt 320*240 Pixel mit 18 Bit Farbtiefe, es gibt sie
bis 3.2" oder 3.5", und mache haben auch ein resistives Touchpanel. Wenn
Du in einem Datenblatt als Controller irgendwas in der Richtung ILI9320,
ILI9325, ILI9328 findest, dann hast Du ein solches, einfach anzuwendenes
Display mit Speicher vor Dir. Wenn Du allerdings in der
Anschlussbelegung Signale wie HSYNC oder VSYNC oder DE oder PCLK
findest, dann ist das ein sicheres Anzeichen dafür, dass es ein Display
ohne Bildschirmspeicher ist, was dann eben bedeutend aufwendiger zu
handhaben ist.
HDMI vergisst Du am besten ganz schnell. Wenn Du bei SDRAM an Deine
Grenzen gekommen bist, wirst Du an HDMI garantiert scheitern.
fchk
Frank K. schrieb:> HDMI vergisst Du am besten ganz schnell. Wenn Du bei SDRAM an Deine> Grenzen gekommen bist, wirst Du an HDMI garantiert scheitern.
Ein solches Display hätte ich ja dann auch in Verbindung mit fertiger
Hardware (-> Raspberry Pi) verwendet. Dass ich das nicht selbst
entwickeln kann, war mir nach Durchsicht der Analog Devices Datenblätter
und User Guides durchaus klar. Ein HDMI Converter wäre wohl an der
Grenze des Machbaren (für mich).
Irgendwie ist das schon seltsam. Jeder Kaffeeautomat hat heute ein
rießiges Grafikdisplay und ich bekomme einfach keinen vernünftigen
Lösungsansatz dafür. Vielleicht war es auch naiv zu glauben, einen
LPC1788 mit 32Bit-SDRAM auf zwei Lagen zu bekommen? Vielleicht sollte
ich es nochmal mit einer vierlagigen Platine versuchen.
Weiß jemand vielleicht, ob NXP sein SDRAM-Interface für einen bestimmten
Speicherhersteller optimiert hat (also identische Pinouts) und so
einfachere Designs möglich sind?
Die Lösung mit integriertem Grafikspeicher behalte ich als Zweitlösung
auf jeden Fall im Hinterkopf. Aber eigentlich sind ja 5,7" geplant
gewesen. 4,3" waren jetzt schon ein "Entgegenkommen" und 3,5" sind dann
schon arg wenig, schließlich müssen sehr viele Messdaten meist als Text
visualisiert werden. Schon jetzt sind es 28, es werden aber wohl noch
deutlich mehr.
Daniel schrieb:> Irgendwie ist das schon seltsam. Jeder Kaffeeautomat hat heute ein> rießiges Grafikdisplay
Das sind Monochromdisplays mit integriertem Controller und Speicher.
Monochrom ist auch wieder einfacher, weil es weniger Speicher braucht.
Oft werden in solchen Geräten auch kundenspezifischen Segmentdisplays
eingesetzt, die in diesen Stückzahlen spottbillig sind und für die es
auch passende Microcontroller gibt.
> Vielleicht war es auch naiv zu glauben, einen> LPC1788 mit 32Bit-SDRAM auf zwei Lagen zu bekommen?
Korrekt. Ziemlich. Schau Dir existierende Designs an.
> Vielleicht sollte ich es nochmal mit einer vierlagigen Platine versuchen.
Mindestens.
Und mit dem passenden Layouttool. Eagle und Target kommen da schon an
ihre Grenzen. Das geht zwar, macht aber keinen Spaß.
> Weiß jemand vielleicht, ob NXP sein SDRAM-Interface für einen bestimmten> Speicherhersteller optimiert hat (also identische Pinouts) und so> einfachere Designs möglich sind?
Nö. Die Pinouts der SDRAMs sind standardisiert.
> Die Lösung mit integriertem Grafikspeicher behalte ich als Zweitlösung> auf jeden Fall im Hinterkopf. Aber eigentlich sind ja 5,7" geplant> gewesen. 4,3" waren jetzt schon ein "Entgegenkommen" und 3,5" sind dann> schon arg wenig, schließlich müssen sehr viele Messdaten meist als Text> visualisiert werden. Schon jetzt sind es 28, es werden aber wohl noch> deutlich mehr.
Geht es um die Größe oder um die Pixelanzahl?
Kannst Du nicht einfach zwei Displays nehmen? Wie gesagt, das ist das
einfachste.
Ansonsten nimm einen externen Grafikcontroller.
Vorschlag: Epson S1D13781: Hat den Speicher schon eingebaut und kann bis
zu 480x272@24bpp oder 800x480@8bpp. Du brauchst dafür ein 16 Bit
SRAM-Interface mit den Adressbits A0-A18. Nachteil: teuer und relativ
schwer hierzulande erhältlich.
fchk
Frank K. schrieb:>> Vielleicht sollte ich es nochmal mit einer vierlagigen Platine versuchen.>> Mindestens.> Und mit dem passenden Layouttool. Eagle und Target kommen da schon an> ihre Grenzen. Das geht zwar, macht aber keinen Spaß.
Wir haben hier eine Lizenz von Altium rumfahren, leider hat das noch
keiner von uns gemacht. Ich hatte ohnehin vor, mich da einzuarbeiten.
Frank K. schrieb:> Die Pinouts der SDRAMs sind standardisiert.
Schade, das war meine große Hoffnung ;-)
Frank K. schrieb:> Geht es um die Größe oder um die Pixelanzahl?> Kannst Du nicht einfach zwei Displays nehmen? Wie gesagt, das ist das> einfachste.>> Ansonsten nimm einen externen Grafikcontroller.> Vorschlag: Epson S1D13781: Hat den Speicher schon eingebaut und kann bis> zu 480x272@24bpp oder 800x480@8bpp. Du brauchst dafür ein 16 Bit> SRAM-Interface mit den Adressbits A0-A18. Nachteil: teuer und relativ> schwer hierzulande erhältlich.
Es geht mir eigentlich um beides. Möglichst viel Information möglichst
gut ablesbar anzubieten. Ich bin momentan am Überlegen, ob ich das
Display nach deinem Vorschlag mit 3,5" etwas kleiner gestalte und
einiges an nicht echtzeitkritischen Funktionen auf ein Android-Tablet
auslagere, wo die grafische Implementierung wohl weitaus einfacher
ausfällt und auch Power verfügbar ist. Scheinbar gute 7"-Tablets gibt's
ab 120€ bei Amazon, da wäre jede Eigenentwicklung überflüssig.
Den Epson bekomme ich bei Mouser für schlappe 6,80€. An SRAM kommt man
auch ran. Da das Gerät nur einmal gebraucht wird, spielt der Preis in
diesen Dimensionen keine Rolle.
Wie sieht es denn auf der Software-Seite aus? Was empfiehlt sich zum
Erstellen einer GUI? Jeder Halbleiterhersteller bietet ja eigene
Lösungen an, aber welche führt zu schnellen Ergebnissen? Micrium hat
dieses µC/GUI, lohnt sich soetwas? Oder geben sich all diese Lösungen eh
nicht so viel? Grafische Programmierung auf Android soll ja gar nicht so
wild sein, aber irgendwie muss ich die CAN-Nachrichten auf das Tablet
bekommen. Wifi oder Bluetooth würden sich hier anbieten.
