16 Bit LCD mit I2C möglich?

Gast #5072442
Hallo,

ich baue gerade ein Gerät was ein Touchscreen 
(http://www.ebay.de/itm/272380783949) haben soll. Drinnen ist ein 
XMega256A3. Größerer Chip kommt nicht in Frage, ich möchte das noch ohne 
Stress löten können. Da sehr sehr sehr viel angeschlossen ist, habe ich 
ein Overkill gerade. Ich habe nicht genug Pins. Es muss was ausgelagert 
werden. Am Display ist jetzt nicht so eine große Regung/Änderung. 
Hauptsächlich werden Werte angezeigt, mann kann zwar Einstellungen 
vornehmen macht man aber ja nicht immer.

Meine Idee: LCD kommt via I²C an einen (oder 2) Portexpander. Gehen wird 
das bestimmt schätze ich, Frage ist nur reicht die Performance? Es 
sollte schon nicht so super langsam aufgebaut werden wie man das teils 
im Netz sieht wenn jmd. mit einem Arduino Mega irgendein Graphikdisplay 
betreibt. Meine CPU taktet bei 32Mhz. Ich habe (in einem anderen 
Projekt) ein anderes Graphik-Touch-LCD betrieben (Parallel, brauchte 
aber nur 8-Bit) das ging super.

Ich habe Angst das das über I²C zu langsam wird?!
Gast
>Meinst du denn das I²C zu langsam ist?

Kannst du dir doch ausrechnen.
400kBit/s auf I2C => knapp 45kB/s

Das Display hat 320x240 Pixel a 16Bit pro Pixel => 153kB

Ein komplettes Display zu füllen dauert dann fast 4s.
Gast
holger schrieb:
>>Meinst du denn das I²C zu langsam ist?
>
> Kannst du dir doch ausrechnen.
> 400kBit/s auf I2C => knapp 45kB/s
>
> Das Display hat 320x240 Pixel a 16Bit pro Pixel => 153kB
>
> Ein komplettes Display zu füllen dauert dann fast 4s.

Ohh natürlich, ich dachte auch an 3,2Mbit/s, habe aber auch gerade 
festgestellt, dass die XMega wohl nur 400kb/s können.

Ich habe gerade mal nach einem I/O Expander für SPI geguckt, der müsste 
das doch schaffen mit CPU 32Mhz, oder was sagst du dazu?
Persönliche Seite
MOBA 2. schrieb:
> Drinnen ist ein
> XMega256A3. Größerer Chip kommt nicht in Frage, ich möchte das noch ohne
> Stress löten können.
Definiere Stress. TQFP geht mit Flussmittelgel/ -Stift und Meißelspitze 
prima. Am besten an ein paar ähnlichen 74ern üben

> Da sehr sehr sehr viel angeschlossen ist, habe ich
> ein Overkill gerade.

Das spricht für mehr Details, vielleicht lässt sich das ein oder andere 
optimieren. Die vorhandenen Register/ Ports samt Touchscreen-Steuerung 
und noch bisserl Logik scheinen knackig kalkuliert.

Ein Grafik-Display ließe sich mit Sub-Controller, quasi Grafikprozessor, 
per I²C ansteuern. Ansonsten bleibt es bei der einfachen 
Durchsatzrechnung des Vorredners. Zudem ist das nur eine Nettopeilung, 
da I²C auch die Adresse und evtl. ein Steuerbyte mitliefern muss. 
Portexpander wollen ja nicht nur benannt, sondern auch instruiert 
werden. (Die gibt es übrigens auch in 16bit, bspw. MCP23017.
Gast
Es ist möglich die TFT Displays für die RaspBerrys (haben SPI)
zu verwenden. Die sind höher auflösend als die "kleinen"
Displays mit SPI (z.B. ILI9341) und können auch Touch.

z.B:
http://www.ebay.de/itm/3-5-Zoll-TFT-SPI-LCD-Touch-Screen-Display-Monitor-Modul-fur-Raspberry-Pi-2B-3B-/152289941365?hash=item2375301775:g:i88AAOSwYHxWJADr

Allerdings muss man evtl noch mit dem Pegel 5V vs 3.3V aufpassen.
Gast
Boris O. schrieb:
> MOBA 2. schrieb:
>> Drinnen ist ein
>> XMega256A3. Größerer Chip kommt nicht in Frage, ich möchte das noch ohne
>> Stress löten können.
> Definiere Stress. TQFP geht mit Flussmittelgel/ -Stift und Meißelspitze
> prima. Am besten an ein paar ähnlichen 74ern üben
>
>> Da sehr sehr sehr viel angeschlossen ist, habe ich
>> ein Overkill gerade.
>
> Das spricht für mehr Details, vielleicht lässt sich das ein oder andere
> optimieren. Die vorhandenen Register/ Ports samt Touchscreen-Steuerung
> und noch bisserl Logik scheinen knackig kalkuliert.

Ich habe noch 2 Strom und 2 Temperaturmessungen, LocoNet, XpressNet, 
S88N, WLAN, USB, 2x DCC Signalerzeugung (je 20 KHz), RFM12 Modul, Touch 
per SPI und div. Steuerleitungen dran (Enable, Inputs). Letztes wäre das 
einzige was man wirklich auf einen lahmen I²C Expander legen könnte, da 
das nicht zeitkritisch ist. Theoretisch könnte man den SPI vom RFM 
sharen mit dem Touch-SPI, ob das Sinn macht weiß ich noch nicht, aber 
sollte gehen da beide IRQ Leitungen haben. Dann käme ich hin.


> Ein Grafik-Display ließe sich mit Sub-Controller, quasi Grafikprozessor,
> per I²C ansteuern. Ansonsten bleibt es bei der einfachen
> Durchsatzrechnung des Vorredners. Zudem ist das nur eine Nettopeilung,
> da I²C auch die Adresse und evtl. ein Steuerbyte mitliefern muss.
> Portexpander wollen ja nicht nur benannt, sondern auch instruiert
> werden. (Die gibt es übrigens auch in 16bit, bspw. MCP23017.


Ja meine Idee war jetzt ein SPI 16 Bit Expander. Frage nur ob der 
schnell genug ist, oder ob es dann doch klüger wäre es wie oben 
beschriben zu machen?!
Gast
MOBA 2. schrieb:
> Ich habe gerade mal nach einem I/O Expander für SPI geguckt,

Für ein 16 Bit Display bräuchtest du 16+5 Leitungen, und je
nach Anordnung müsstest du dauernd 24 Bit übertragen, für
jeden WR toggle also 48 Bit.

Da hilft nur die Steuerleitungen (CS, C/D, RD, WR, Reset) auf
ein 8 Bit Register zu legen und separat anzusteuern. Oder
gleich direkt aus dem Mega256 heraus.

Die RaspBerry TFTs haben eine gewisse "Eigeninteligenz" (Logik
mit den Schieberegistern) die das Schreiben etwas erleichtern.
Dafür kann man sie nicht lesen.
Gast
Arduinoquäler schrieb:
> MOBA 2. schrieb:
>> Ich habe gerade mal nach einem I/O Expander für SPI geguckt,
>
> Für ein 16 Bit Display bräuchtest du 16+5 Leitungen, und je
> nach Anordnung müsstest du dauernd 24 Bit übertragen, für
> jeden WR toggle also 48 Bit.
Die Steuerleitungen bekomme ich noch unter.

> Da hilft nur die Steuerleitungen (CS, C/D, RD, WR, Reset) auf
> ein 8 Bit Register zu legen und separat anzusteuern. Oder
> gleich direkt aus dem Mega256 heraus.
XMega, kein Mega.

> Die RaspBerry TFTs haben eine gewisse "Eigeninteligenz" (Logik
> mit den Schieberegistern) die das Schreiben etwas erleichtern.
> Dafür kann man sie nicht lesen.
Sind zu teuer leider.

Mich würde wie gesagt nur interessieren, ob der SPI Expander das mit dem 
Display schaffen könnte.
Gast
MOBA 2. schrieb:
> Sind zu teuer leider.

Dann mach mal einen Preisvergleich. Wesentliche Unterschiede
sind das nicht, zumal du ja die externe Hardware noch
dazurechnen musst.

MOBA 2. schrieb:
> Mich würde wie gesagt nur interessieren, ob der SPI Expander das mit dem
> Display schaffen könnte.

Mit dem XMEGA kannst du ja 16MBit Datenrate fahren, da geht schon
was. Auf dem RaspBerry machen sie das nur so (ausser bei den
Higher-Level-Interfaces). Wenn du selbst programmierst kannst du
ja deutlich schneller sein als die Arduino Libs.
Gast
Arduinoquäler schrieb:
> MOBA 2. schrieb:
>> Ja meine Idee war jetzt ein SPI 16 Bit Expander.
>
> Vielleicht schaust auch mal auf die 8-Bit Displays
> wie hier (ein guter Kompromiss):
>
> Beitrag "LCD 480x320 mit wenig Aufwand zum Anbinden"
>
> Allerdings ist das Arbeiten mit dem nicht vorhandenen
> Touch-Controller kein Vergnügen ....


Ich hatte schon mal vor ein paar Jahren ein Display von LEDSEE 
(ähnliches) angesteuert. Auch 8 Bit, ohne Touch-Controller (kann man 
sich leicht mit 2 ADC Eingängen, ein Umschaltpin und ein paar Mosfets) 
selber bauen. Das hat super geklappt. Ich wollte mal das nutzen, weil es 
eine bessere Auflösung hat als das alte von mir. Das war 5" groß und 
äußerst verpixelt. Fand ich nicht so toll, ich hoffe auf was besseres. 
Hatte auch keine Farbe.


Hat deins Farbe? Woher hast du das?
Gast
Arduinoquäler schrieb:
> MOBA 2. schrieb:
>> Sind zu teuer leider.
>
> Dann mach mal einen Preisvergleich. Wesentliche Unterschiede
> sind das nicht, zumal du ja die externe Hardware noch
> dazurechnen musst.
>
> MOBA 2. schrieb:
>> Mich würde wie gesagt nur interessieren, ob der SPI Expander das mit dem
>> Display schaffen könnte.
>
> Mit dem XMEGA kannst du ja 16MBit Datenrate fahren, da geht schon
> was. Auf dem RaspBerry machen sie das nur so (ausser bei den
> Higher-Level-Interfaces). Wenn du selbst programmierst kannst du
> ja deutlich schneller sein als die Arduino Libs.


Arduino?! Habe ich was verpasst :D Sowas nutze ich nicht. Ist in nativem 
C oder C++ programmiert, kein Arduino-Framework-Zeugs. Void loop, void 
setup musste da mal was machen (für meinen Kumpel, studiert 
Produktdesign), finde das ist eher so eine Modeprogrammiersprache um 
schnell was ans Laufen zu bringen oder für Einsteiger evtl, dann muss 
man sich nicht mit Registern rumärgern, weiß aber auch nicht ob das 
lerntechnisch sinnvoll ist es erst so zu lernen und dann alles was man 
gelernt hat wieder umzukrämpeln.


Ich finde halt die Module für Arduino cool, gibt sehr sehr viele Sachen 
(Joysticks, LCDs, uvm) die man so super in sein Projekt stecken kann und 
billiger als die reinen Bauteile sind. Die Entwicklung auf der 
Hardwareseite finde ich klasse!
MOBA 2. schrieb:

> Ich habe noch 2 Strom und 2 Temperaturmessungen, LocoNet, XpressNet,
> S88N, WLAN, USB, 2x DCC Signalerzeugung (je 20 KHz), RFM12 Modul, Touch
> per SPI und div. Steuerleitungen dran (Enable, Inputs). Letztes wäre das
> einzige was man wirklich auf einen lahmen I²C Expander legen könnte, da
> das nicht zeitkritisch ist. Theoretisch könnte man den SPI vom RFM
> sharen mit dem Touch-SPI, ob das Sinn macht weiß ich noch nicht, aber
> sollte gehen da beide IRQ Leitungen haben. Dann käme ich hin.

Du hast Dich in eine Sackgasse manöveriert.

Für Dein Problem gibts bessere Lösungen, z.B. das hier:

http://www.microchip.com/wwwproducts/en/PIC32MZ2064DAH176

Zugegeben, das ist leistungsmäßig eine ganz andere Größenordnung. Damit 
kannst Du problemlos auch Displays mit 1024*768 Pixel in 24 Bit und 
Parallel RGB Input ansteuern, ohne dass Du Angst haben musst, dass das 
langsam wird. Genügend RAM für den Framebuffer im Hauptspeicher hat der 
Chip dafür eingebaut. Und ob Du nun 64 Pins oder 176 Pins lötest, ist 
egal. Mit "Drag Soldering" ist der Aufwand auch nicht viel größer.

fchk
Gast
Arduinoquäler schrieb:
> Hier eine deutsche Quelle. Sind aber meist Chinesen die
> dahinter stecken.
>
> Suche: 3.5 TFT
>
> 
http://www.ebay.de/itm/3-5inch-TFT-color-screen-module-320X480-ultra-HD-support-for-Arduino-for-UNO-ZZ-/142402294422?hash=item2127d69296:g:~NcAAOSw2xRYTRC7


Genau die 2 hatte ich sogar noch offen, aber dann dagegen entschieden, 
weil die keinen Touchdriver haben - das wäre ja, wie oben beschrieben 
nicht das Problem, aber so wie ich das gesehen habe, hatten die das 
nichtmal richtig rausgeführt, ist das richtig? Kannst du was dazu sagen?
Gast
MOBA 2. schrieb:
> hatten die das
> nichtmal richtig rausgeführt, ist das richtig? Kannst du was dazu sagen?

Die Touch Anschlüsse sind auf vier digital-Pins (Eingänge)
"gemultiplext" herausgeführt. Also verwenden kann man die schon.
Auch eine Arduino Lib ist dafür extra geschrieben.
Gast
Frank K. schrieb:
> MOBA 2. schrieb:
> Du hast Dich in eine Sackgasse manöveriert.
Ich versuche gearde zurückzurudern :D


> Für Dein Problem gibts bessere Lösungen, z.B. das hier:
>
> http://www.microchip.com/wwwproducts/en/PIC32MZ2064DAH176
>
> Zugegeben, das ist leistungsmäßig eine ganz andere Größenordnung. Damit
> kannst Du problemlos auch Displays mit 1024*768 Pixel in 24 Bit und
> Parallel RGB Input ansteuern, ohne dass Du Angst haben musst, dass das
> langsam wird. Genügend RAM für den Framebuffer im Hauptspeicher hat der
> Chip dafür eingebaut. Und ob Du nun 64 Pins oder 176 Pins lötest, ist
> egal. Mit "Drag Soldering" ist der Aufwand auch nicht viel größer.
>
> fchk


:D Ja okay das ist richtig. Aber ich habe kein Equipment für die PICs 
und 20$ für einen Chip ist heftig. Porto kommt auch noch hinzu, bisschen 
Overkill. Kann ich direkt nen Raspi nehmen.
MOBA 2. schrieb:

> :D Ja okay das ist richtig. Aber ich habe kein Equipment für die PICs
> und 20$ für einen Chip ist heftig. Porto kommt auch noch hinzu, bisschen
> Overkill. Kann ich direkt nen Raspi nehmen.

Gut, das war jetzt der größte aus der Serie, es gibt auch kleinere, die 
nur 1MB Flash und 256k RAM haben.

RasPi? Nicht unbedingt. Da hast Du Linux dazwischen und damit keine 
Echtzeit. Und die Zahl der IO-Pins ist auch sehr begrenzt.

Und zu den Kosten: Ich gehe nicht davon aus, dass Dein Gerät in Serie 
gehen wird - das sieht eher nach Einzelstück aus. Und da ist die 
Kostenkalkulation eh anders, und ob da ein Teil 10 oder 15 Euro kostet, 
ist im Prinzip egal.

fchk

PS: Einen PICKIT3-Clone, mit dem DU alle aktuellen PIC (8,16,32 Bit) 
flashen und debuggen kannst, gibt für 20€. Auch nicht die Welt.
Gast
nimm ein spi-tft. Für Text ist das ausreichend schnell. Wenn du für 
andere Peripherie auch spi einsetzt, brauchst du nur den cs-pin 
zusätzlich.
Persönliche Seite
Da das um den Preis geht und noch offen ist was Du nimmst, aber nur 
Atmeltools hast, als Denkanstoß:

- Der XMega-A3 kann twi nur mir 400kBit/s und ist ein Auslaufmodell.

- Den ATSAMD21 gibt es auch als TQFP64 (da das Deine Stressfreilötgrenze 
ist :-)) und er kann twi mit 3,4MBit/s. Den kannst Du auch mit dem ICE 
und Atmelstudio verwenden. Außerdem kostet der nur ein Fünftel des 
xmega-Preises.

16Bit pro Pixel und 320x240 über mehrere Portexpander die Du 
nacheinander ansteuerst klingt echt zäh. Man könnte auch noch einen 
günstigen weiteren µC als Treiber, an Stelle der Portexpander, nehmen 
und ein eigenes Protokoll, auf so vielen Leitungen wie man hat, 
verwenden.
Gast
Chris F. schrieb:
> Da das um den Preis geht und noch offen ist was Du nimmst, aber nur
> Atmeltools hast, als Denkanstoß:

... und warum redet keiner von einer sehr günstigen STM-Lösung?

ALle Tools umsonst und der Debugger/Programmer für unter 10 Euro.
Gast
Chris F. schrieb:
> Da das um den Preis geht und noch offen ist was Du nimmst, aber nur
> Atmeltools hast, als Denkanstoß:
>
> - Der XMega-A3 kann twi nur mir 400kBit/s und ist ein Auslaufmodell.
>
> - Den ATSAMD21 gibt es auch als TQFP64 (da das Deine Stressfreilötgrenze
> ist :-)) und er kann twi mit 3,4MBit/s. Den kannst Du auch mit dem ICE
> und Atmelstudio verwenden. Außerdem kostet der nur ein Fünftel des
> xmega-Preises.
Jetzt mal ohne Spaß: Das ist ein Auslaufmodell?! Ernsthaft? Wo finde ich 
die Info? Die gibt es doch noch gar nicht so lange, und außerdem wäre 
das echt schlecht da ich div. Geräte habe mit den Chips die ich tlws. 
auch noch nachproduziere.


> 16Bit pro Pixel und 320x240 über mehrere Portexpander die Du
> nacheinander ansteuerst klingt echt zäh. Man könnte auch noch einen
> günstigen weiteren µC als Treiber, an Stelle der Portexpander, nehmen
> und ein eigenes Protokoll, auf so vielen Leitungen wie man hat,
> verwenden.
MOBA 2. schrieb:
> Chris F. schrieb:
>> MOBA 2. schrieb:
>>> Jetzt mal ohne Spaß: Das ist ein Auslaufmodell?! Ernsthaft? Wo finde ich
>>> die Info?
>>
>>
> 
http://www.atmel.com/Images/Atmel-8068-8-and16-bit-AVR-XMEGA-A3-Microcontrollers_Datasheet.pdf
>
> Wo steht das in der anleitung sehe davon nichts.


"Not recommended for new designs -
Use XMEGA A3U series"

Das steht auf jeder Seite in in fetten Blau.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.