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?!
Joachim B. schrieb: > dann nimm SPI an Schieberegister Hat das Display das? Die sind noch nicht da, ich habe auch noch keine richtigen Unterlagen gefunden. Meinst du denn das I²C zu langsam ist?
>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.
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?
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.
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.
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?!
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.
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.
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 ....
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.
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?
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: > Hat deins Farbe? Logisch. MOBA 2. schrieb: > Woher hast du das? Das sind z.B. die hier: http://www.ebay.de/itm/3-5-Zoll-TFT-LCD-DISPLAY-SCREEN-MODUL-Fur-Arduino-UNO-R3-BOARD-PLUG-PLAY-/122414975547?hash=item1c80804a3b:g:uuEAAOSwWxNYyOCL Sind auch manchmal in Deutschland direkt zu bekommen. Display Controller ist ILI9488, der ist auch in den Raspberry TFTs drin.
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
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
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?
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.
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.
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.
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.
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.
Arduinoquäler schrieb: > 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. STM32 wäre echt eine Alternative, sehe ich auch so mittlerweile.
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.
Ich würde sowas nehmen: http://www.ebay.de/itm/Waveshare-3-5-inch-320x480-Touchscreen-TFT-LCD-Display-for-Raspberry-Pi-WS40003-/281842700934 Da wird sowohl das Display wie auch der Touch-Controller via SPI angesteuert. Das ist bei nahezu allen Raspberry Pi-Aufsteckdisplays so.
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
MOBA 2. schrieb: > STM32 wäre echt eine Alternative, sehe ich auch so mittlerweile. Ja, das geht auch. Aber wenn er schon die Atmelumgebung gewöhnt ist kann er auch den M0+ von denen nehmen. Nur eher in einem größeren Package damit das Display direkt angeschlossen wird.
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.
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.
Harry L. schrieb: > Ich würde sowas nehmen: > Ebay-Artikel Nr. 281842700934 Boooaaahhh eyy, Schlaumeier! Haste abgeschrieben wa? Hab ich alles schon geschrieben.
Uwe N. schrieb: > MOBA 2. schrieb: >> Chris F. schrieb: >>> MOBA 2. schrieb: >> 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. Blindfisch bin ich. Aber das ist ja nicht so schlimm, das ist ja trzd. das gleiche Teil. Ich dachte die Serie ist abgekündigt.
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.