Forum: Mikrocontroller und Digitale Elektronik Suche Hardware mit CAN und GLCD (und OS)


von Daniel (Gast)


Lesenswert?

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!

von spess53 (Gast)


Lesenswert?


von Daniel (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Daniel (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.