Um den Beitrag "Re: China SUPER Bauteile-Schnäppchen Thread"
nicht weiter zu belasten:
Es geht um die Frage, mit welchem µC man ein Touch-TFT ansteuert, wenn
man ein "Wischen" wie beim Handy realisieren will.
Die genutzten 320*240px² Touch-TFTs sind Handy-Ersatzteile für ca. 3€
aus China:
Z.B.: http://www.aliexpress.com/item//1284532034.html
Gesucht wird für "Variante b)" (s.u.) eine Kombination aus µC + RAM mit
mindestens 512 kByte RAM. SMD-Pins mit weniger als 1,27mm Pitch zu löten
ist nicht drin, am besten wäre ein geeignetes Eval-Board für ca.
10..15€.
Die Variante a) ist bereits großteils umgesetzt:
¯¯¯¯¯¯¯¯¯¯¯
Beim Wischen wird einfach der vertikale Offset verändert, dadurch rollt
das Bild um die Anzahl der gewünschten Spalten z.B. nach rechts. Auf der
linken Seite rollen die Spalten wieder in das Bild hinein, werden aber
sofort vom µC durch schwarze Pixel überschrieben.
Ist der ganze Bildschirm schwarz, wird der neue Bildschirm aufgebaut,
was ca. 300-700ms dauert - mit einem 2€ preiswerten Arduino Pro Mini
328p (="APM").
Die Variante b) sähe aber schöner aus:
¯¯¯¯¯¯¯¯¯¯¯
Der µC hat ca. 700 kByte RAM und hält darin 3 Bildschirmseiten aktuell.
Beim "Wischen" werden die Spalten, die auf der linken Seite hinein
scrollen durch die Spalten der anderen Bildschirmseite aus dem RAM
überschrieben. Man kann dann auch etwas "hin und zurück" wischen und das
Bild bleibt dabei vollständig.
Bekannte Alternativen für Variante b)
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
- Für ca. 15€: Ein Arduino Mega mit so 'ner RAM-Erweiterung:
http://andybrown.me.uk/wk/2011/08/28/512kb-sram-expansion-for-the-arduino-mega-build/
- Für ca. 35€: Ein Raspberry Pi
- Für ca. 10€: Ein umgebauter WLAN-Router, z.B.
-> Ebay-Artikel Nr. 231118158116 oder
-> http://wiki.openwrt.org/toh/hilink/hlk-rm04
Letzterer hat mehr als genug RAM, aber zu wenige GPIOs.
Der RPi ist im Vergleich zum Display zu teuer.
Der Aufbau der Arduino RAM-Erweiterung ist aufwendig und 15€ sind im
Vergleich zum Display auch kein "Pappenstiel".
Tim schrieb im
Beitrag "Re: China SUPER Bauteile-Schnäppchen Thread"> Wenn Der Bildaufbau nicht extrem schnell sein muss, würde ja auch> SPI-Flash oder eine SD-Karte als Speicher reichen?
Es geht um's RAM, nicht um Flash.
Und 150ms zum Bildschirm löschen und 500ms zum zeichnen der Widgets sind
OK. Das geht mit dem APM. Langsamer wäre schlecht.
> Das Display-Interface> ist sowieso schon ein ziemliches Bottlenck.
Nicht unbedingt. Den Bildschirm mit einem Grauton zu löschen dauert nur
ca. 120ms:
LCD_WR_0;LCD_WR_1;// "LCD_height / 2" and "uint16_t i"
5
LCD_WR_0;LCD_WR_1;// is faster than "uint32_t i"
6
LCD_WR_0;LCD_WR_1;
7
LCD_WR_0;LCD_WR_1;
8
LCD_WR_0;LCD_WR_1;
9
LCD_WR_0;LCD_WR_1;
10
}
11
}else{…
> Wenn WLAN nicht> interessiert ist ein anderer Ansatz aber wohl eh besser.
Tja, die beiden anderen Ansätze (s.o.) sind halt vergleichswise teuer.
Geplante Stückzahl: ca. 12..20 Stück. Ich denke, ich verkrafte leiber
die "Variante a)".
Oder hat noch jemand 'ne Idee?
PIC24FJ256DA210 hat einen TFT Controller mit Speicher und mit der
Charge Time Measurement Unit kannst du kapazitiven Touch auswerten.
64 Pin im 0,5 oder 100 Pin im 0,4 Raster.
Gibts bei Microchip als Sample.
Hans-Georg Lehnard schrieb:> PIC24FJ256DA210
Aus dem Datenblatt:
> RAM Bytes 98,304
Das ist leider nur etwa ein Fünftel von dem, was man für 3
Bildschirmseiten (s.o.) benötigt. Schade.
> Direct Interface to Monochrome, C-STN, TFT …
Es geht um die oben verlinkten RGB TFTs.
> kapazitiven Touch auswerten
Die o.g. RGB TFTs haben resistiven Touch.
Für 10€ und mehr bekommt man auch andere TFTs, aber bei 20 Stück
sollen´s die für ca. 3€ sein.
Ein http://www.acmesystems.it/aria würde z.B. auch gehen. Aber ich
brauche kein LAN und keine 128MB RAM, sondern nur 0,5 .. 1MB.
Variante a) kostet 3 + 2 = 5€ mit Display. Bei 20 Stück sind das 100€.
Ein SRAM mit 512KB kostet ca. 2€. Also sollte das ganze in Variante b)
nicht mehr als 10€..15€ kosten, möglichst ohne SMD-löten. Das wären dann
20 x 15€ = 300€. Das ist teuer genug.
Die 100 Pin Version hat den Enhanced Parallel Master Port, da kannst du
bis zu 16MB externes Ram adressieren und als 65k Fenster jeweils
einblenden.
Leider hat Microchip bei diesem Controller die DMA eingespart.
10Bit AD WAndler gibt es auch ;)
Aber da ist nix mehr mit einfacher Adapterplatine ...
Die PIC32MZ haben 512kByte RAM, sind jedoch ganz neu und noch nicht
ausgereift.
Die sinnvollere Methode ist ein externes RAM zu verwenden.
Vor allem die ARM basierten Mikrocontroller scheinen dafür gut geeignet
zu sein, und STM bietet dafür wieder sehr viele Evaluation Kits zu
günstigen Preisen an, bei denen sogar schon ein vergleichbares Display
und einem 8 MByte SDRAM verbaut ist, damit du in alle Richtungen
scrollen kannst ^^:
http://de.farnell.com/stmicroelectronics/stm32f429i-disco/stm32f4-discovery-eval-board/dp/2355377
Torsten C. schrieb:> Es geht um die Frage, mit welchem µC man ein Touch-TFT ansteuert, wenn> man ein "Wischen" wie beim Handy realisieren will.
Auf dem Handy benötigst Du 25-50 Updates pro Sekunde und
Double-buffering damit es einigermassen flüssig aussieht. Das könnte man
z.B. mit einem FTDI EVE erreichen.
Bei einem SPI-Display wird es mit der verfügbaren Bandbreite aber
schwierig. Ich würde da lieber auf eine GUI-Lösung gehen, die keine
schnellen Bildupdates benötigt.
Deine Displays haben aber anscheinend auch ein direktes RGB-Interface?
Dann könnten sie tatsächlich von dem oben genannten EVE oder auch einem
STM32F429 ansteuerbar sein.
leicht OT: Man kann auch auf einem AVR ohne zusätzliches RAM schnelle
Graphik erzeugen.
https://www.youtube.com/watch?v=sNCqrylNY-0
Das ist eine Frage der gesamten Systemarchitektur. Die zu verschiebenden
Datenmengen müssen zu den Busbandbreiten passen.
Ich will kein Handy bauen und keine Videos abspielen. Nur Wischen!
Der Unterschied: Es werden keine Daten im Grafik-RAM verschoben, sondern
nur der Display-Offset (s.o.)! Also: Kein Double-buffering!
Das funktioniert ja auch schon für 5€, nur dass ich "schwarz" von der
Seite ins Bild schiebe und nicht die "Nachbarseite".
Tim schrieb:> Bei einem SPI-Display wird es mit der verfügbaren Bandbreite aber> schwierig
SPI-Displays wären eh teurer, die bekommt man nicht für 3€. Die o.g.
sind parallel (8 oder 16 Bit). Das RGB-Interface und SPI sind nicht
herausgeführt. Daher geht auch kein FTDI EVE mit den 3€-Displays.
Der FT800Q ist ein außerdem 48-VFQFN mit 0,5mm Pin-Pitch. :-(
Lothar schrieb:> etwas größer und teurer
Etwas? Ich bin ja mit der 5€-Lösung schon fast zufrieden. Es fehlt nur
RAM.
Aktuell "ruckelt" das Wischen mit dem 2€ preiswerten Arduino Pro Mini
natürlich ein wenig. Aber das stört nicht sehr und ist kein Grund den
Preis zu verzehnfachen oder noch mehr auszugeben.
Frank M. schrieb:> Die PIC32MZ haben 512kByte RAM, sind jedoch ganz neu und noch nicht> ausgereift.
Die schaue ich mir mal an, danke. :-)
> Die sinnvollere Methode ist ein externes RAM zu verwenden.
Warum? Das wäre viel löterei bei 20 Stück, die man sich sparen könnte.
Frank M. schrieb:> STM bietet dafür wieder sehr viele Evaluation Kits
Ein STM32F429I-DISCO habe ich zum ausprobieren schon lange hier herum
liegen. Das Board hinter dem Display ist mir zu groß. Es sollte hinter
dem Display verschwinden und möglichst wenig am Rand überstehen.
Bei 20 Stück wären das auch ca. 500 Euro. Etwas teuer im Vergleih zue
5€-Lösung mit dem APM^^.
Bei der Datenmenge, um die es geht, bezweifle ich sehr, dass klassische
8bit Mikrocontroller geeignet sind. Ich würde mich dazu auf den 32bit
Bereich konzentrieren.
Allerdings ist Dir der eigentlich spottbillige Raspberry Pi schon zu
teuer ... da fällt mir keine billigere Alternative ein.
Naja, im Grund scheinst Du Deine Randbedingunen und Dein Ziel ja schon
sehr genau festgelegt zu haben. Da kann man dann auch nicht mehr viel
beitragen :)
Man muss sich halt immer sehr genau überlegen, welche Komponenten das
System definieren. Hier sparst Du an den Displays und willst keine
Standardhardware verwenden, musst dafür aber an anderer Stelle Zeit und
Geld in eine Spezialllösung investieren für die das Display vielleicht
gar nicht ausgelegt ist. Als Bastellösung aber sicher kein Problem.
Wenn man halt ein performanteres System haben will, braucht man eben
bessere Hardware, die die Sache teurer macht.
Aber es geht auch noch anders:
Ich dachte erst dein Display sei nur das 'Glass' und habe keinen
Controller. Nachdem ich mir dein APM aber mal angesehen habe, wurde
klar, dass das nicht sein kann.
Da dein Display also ein GRAM hat, mit 173kByte, musst du diesen ja
nicht mehr im uC abspeichern. Dein Atmega ist langsam und hat so gut wie
keinen Speicher. Wenn du einen uC mit mindestens 173kByte verwendest,
welcher dann zwangsläufig auch um Größenordnungen schneller sein wird,
so kannst du den neuen Bildschirminhalt innerhalb weniger ms im RAM
zeichnen. Dann machst du das gleiche wie bisher, du schiebst das Bild im
GRAM und anstatt mit schwarz zu überzeichnen, überzeichnest du eben aus
deinem Buffer im uC. Somit brauchst du keinen uC mit mindestens 700kByte
RAM sondern mit mindestens 173kByte RAM, und davon gibt es Tausende.
Als KIT vermutlich nur das STM32F4DISCOVERY
Oder du baust es dir selbst, was du ja aber nicht so gernen machen
würdest, wobei du ja nur noch einen IC nun brauchst, mit gerade einmal
192kByte RAM.
Falls dir die 12 Euro zzgl. Mwst dann aber immer noch zu teuer sind,
dann musst du dich mit deiner bisherigen Lösung zufrieden geben, da du
eben keinen Spielraum hast.
Ich will nicht ausschließen, dass ich auf dem Holzweg bin, aber das kann
ich noch nicht erkennen.
Tim schrieb:> Hier sparst Du an den Displays und willst keine> Standardhardware verwenden
Die Displays sind billig, weil sie in Massen in Handys verbaut werden
oder wurden. Ist das etwa keine "Standardhardware"?
> musst dafür aber an anderer Stelle Zeit und> Geld in eine Spezialllösung investieren für die das Display vielleicht> gar nicht ausgelegt ist.
Das Display ist für "Wischen" ausgelegt, dafür hat der integrierte
Controller die Möglichkeit, den Display-Offset mit Gate Scan Control
VL[8..0] zwischen 0..320 zu verschieben. Siehe Seite 71ff:
https://github.com/TorstenC/A137_TouchTFT_320x240/blob/master/Datasheets/ILI9325.pdf?raw=true
Die "Speziallösung" bestände lediglich darin, dass der µC mehr RAM hat
als üblich. Das scheint das einzige Problem zu sein: Es gibt noch keine!
Ich denke, der PIC32MZ1024 scheint
> der richtige µC mit viel RAM für Touch TFT mit "Wischen"
zu werden. Er kostet deutlich unter 10€. Dann warte ich noch etwas. :-)
Danke, Frank! :-)
Torsten C. schrieb:> SPI-Displays wären eh teurer, die bekommt man nicht für 3€. Die o.g.> sind parallel (8 oder 16 Bit). Das RGB-Interface und SPI sind nicht> herausgeführt. Daher geht auch kein FTDI EVE mit den 3€-Displays.
Dann solltest Du einen AVR mit External Bus Interface benutzen. Das ist
die schnellste Methode, solche Displays anzusteuern, und zwar um einige
Faktoren bei der Datenübertragung. Immerhin musst Du !WR, !RD, CD und
!CS nicht mehr selber ansteuern, sondern das macht der AVR in Hardware.
fchk
Frank K. schrieb:> Dann solltest Du einen AVR mit External Bus Interface benutzen.
Da hast Du allerdings sehr Recht! Mein Problem: Das soll gehen, ohne
SMD-Pins mit weniger als 1,27mm Pitch zu löten.
Bei einem einzelnen Exemplar ginge das noch, aber bei 20 Stück oder zum
Nachbau als Open-Source-Projekt ist das unattraktiv.
Was bleibt?
Torsten C. schrieb:> - Für ca. 15€: Ein Arduino Mega mit so 'ner RAM-Erweiterung …http://andybrown.me.uk/wk/wp-content/images/xmem2/attached.jpg
Also so eine Platine, jedoch neu layoutet, so dass auch gleich die
Lötpads für's Display passen und das Display zusammen mit dem Speicher
per "External Bus Interface" angesteuert wird.
Nun ist der Arduino Mega leider größer als das Display, steht also am
Rand über (wie beim STM32F429I-DISCO) und kostet auch schon knapp 11€,
also ohne RAM-Erweiterung.
Und diese Teile sind noch teurer:
https://www.tindie.com/products/jkdevices/atmega2560-breakout-board-arduino-compatible-16mhz-5v/https://jkdevices.com/ATMEGA2560
Beim PIC32MZ1024 würde man natürlich auch das External Bus Interface
nehmen. Vorteil: Das RAM wäre kein separater Baustein, aber man müsste
SMD-Pins 0,5mm Pitch löten. Die Platine würde aber locker hinter's
Display passen, ohne am Rand über zu stehen.
Ich bin unentschlossen.
Torsten C. schrieb:> Frank K. schrieb:>> Dann solltest Du einen AVR mit External Bus Interface benutzen.>> Da hast Du allerdings sehr Recht! Mein Problem: Das soll gehen, ohne> SMD-Pins mit weniger als 1,27mm Pitch zu löten.
Feigling. 0.8mm sind auch kein Problem. Außerdem: wie lötest Du den
Stecker fürs Display? Das dürfe auch ein 0.5mm Raster sein.
> Bei einem einzelnen Exemplar ginge das noch, aber bei 20 Stück oder zum> Nachbau als Open-Source-Projekt ist das unattraktiv.>> Was bleibt?
Der Mega 162 hat auch ein EBI, aber nur 16k Flash.
fchk
Danke Frank, damit kommt man doch weiter. :-)
Den ATmega162 gibt's sogar
* mit e = 2,54mm als "PDIP-40" für 6,60€ und
* mit e = 0,80mm als "TQFP-44" für 5,90€
16KB sind aber echt wenig für Schriftarten und Widgets.
Den ATXMEGA128A gibt's mit e = 0,80mm und er hat 128KB Flash für 5€,
aber leider nicht mit e = 2,54mm.
Der ATXMEGA128A hat sogar eine "AES and DES cryptographic engine". Das
könnte bei der Crypto für den NRF24L01+ helfen.
Frank K. schrieb:> Feigling. …
Sag' das nicht mir. Es geht auch um den Nachbau als Open-Source-Projekt.
> wie lötest Du den Stecker fürs Display?
Das Ende von der Platine wird direkt auf die verzinnte Platine
aufgelötet. Wegen der Flexibilität der Platine geht das deutlich
einfacher als bei ICs: Verzinnen und Pin für Pin mit dem Lötkolben
andrücken. Wegen der Vias in den Pins geht die Wärme schnell auf die
Unterseite.
Bei 0,8mm habe ich die Lötbrücken trotz viel Flussmittel nicht immer mit
Entlötsauglitze entfernen können. Aber vielleicht lerne ich das noch.
Als RAM gibt's z.B. das AS6C4008A
* mit e = 2,54mm als 600mil DIP-32 für 3,40€
* mit e = 1,27mm als 450mil SOP-32 für 2,70€
Torsten C. schrieb:> Danke Frank, damit kommt man doch weiter. :-)>> Den ATmega162 gibt's sogar> * mit e = 2,54mm als "PDIP-40" für 6,60€ und> * mit e = 0,80mm als "TQFP-44" für 5,90€>> 16KB sind aber echt wenig für Schriftarten und Widgets.
Du kannst ja ein 512k SRAM anklemmen, Bankswitching machen, und beim
Booten Fonts und Grafiken von einem externen SPI-Flash wie zB einem
M25P80 (8MBit) reinladen.
> Bei 0,8mm habe ich die Lötbrücken trotz viel Flussmittel nicht immer mit> Entlötsauglitze entfernen können. Aber vielleicht lerne ich das noch.
Es kommt auf das Flussmittel an. Gelförmiges Flussmittel funktioniert
für mich am Besten. Probiere mal das hier:
http://www.reichelt.de/Flussmittel-Loetpasten/EDSYN-FL-22/3//index.html?ACTION=3&GROUPID=4132&ARTICLE=32673&SEARCH=FLUSSMITTEL&SHOW=1&OFFSET=500&;
fchk
@Frank: Du hast einen Gut! Da hätte ich eigentlich selbst drauf kommen
müssen! Bankswitching hätte ich eh machen müssen.
Da geht sogar eine Variante mit e=2,54mm auf einem Steckbrett, und wenn
alles fertig ist, macht man ein PCB mit e=0,80mm.
Und für "Feiglinge" ;-) könnte man bei Bedarf sogar noch ein teureres
PCB mit e=2,54mm machen.
Das ist es! :-) Und alle Bauteile gib's sogar bei Reichelt. :-)
Es kann "gewischt" werden. :-)
Das Flußmittelgel ist zwar teuer, aber ich probier's mal aus. Danke.
Wieviele ICs kann man mit 5ml verlöten?
Torsten C. schrieb:> Das Flußmittelgel ist zwar teuer, aber ich probier's mal aus. Danke.>> Wieviele ICs kann man mit 5ml verlöten?
Eine ganze Menge. Und durch den Klebeffekt (das Zeugs ist von der
Konsistenz wie Honig) werden die Bauteile auch noch etwas fixiert.
fchk
Frank M. schrieb:> Dann machst du das gleiche wie bisher, du schiebst das Bild im> GRAM und anstatt mit schwarz zu überzeichnen, überzeichnest du eben aus> deinem Buffer im uC. Somit brauchst du keinen uC mit mindestens 700kByte> RAM sondern mit mindestens 173kByte RAM, und davon gibt es Tausende.
Ah, sorry, darauf hatte ich nicht geantwortet.
Schau Dir mal das "Wischen" beim Handy an:
Etwas nach rechts: Von links kommt der rechte Rand der
linken Bildschirmseite rein.
Loslassen: Das Bild geht wieder zur mittleren Bildschirmseite.
Wenn man das für links und rechts macht, muss man 3 Seiten im RAM des µC
haben. Das GRAM des LCD kann man zwar auslesen, aber das wäre extrem
langsam. Dort macht der Grafik-Controller kein Auto-Increment der
GRAM-Adresse!
Bei 16 Bit Farbtiefe wären das 460 800 Bytes und
bei 18 Bit Farbtiefe 691 200 Bytes (1 Byte pro Farbe).
Bei 16 Bit Farbtiefe und 512KiB RAM hat man also noch 62KiB für Daten
aus dem SPI-Flash frei.
Der ATmega162 mit AVR-Core ist für über 5€ ziemlich langsam. Aber einen
ARM mit einem Pitch von mindestens e=0,80 finde ich nicht. Also bleibt´s
wohl beim ATmega162.
Der LPC1114 ist knapp dran, hat aber kein "External Bus Interface".
@holger: Ich sag'ja: ziemlich langsam. Aber kennst Du 'ne Alternative?
Ich habe bisher keine gefunden.
Ein ARM mit "External Bus Interface" wär' z.B. deutlich schneller. Aber
0,5mm SMD-Pins sind nun wirklich zu fein für ein Nachbau-Projekt.
Frank K. schrieb:> Das dürfe auch ein 0.5mm Raster sein.
Hab' gerade mal gescannt, weil mir der Händler die Pinbelegung noch
nicht geschickt hat: Das ist ein 0,8mm Raster.
Didi S. schrieb:> Ist mal eine Überlegung wert ....> vielleicht auch etwas für Dein Projekt mit den nRF24 ...
Hallo Didi,
ich will zwar eins nach dem anderen machen, aber für den übernächsten
Schritt:
Wir brauchen bei uns noch ca. 3 Einheiten mit 5"-Touch-TFT. Ich habe
diese hier gefunden:
http://www.aliexpress.com/item//1603691772.html (25€ mit Controller)
http://www.aliexpress.com/item//1582821072.html (14€ ohne Controller)
Meinst Du, das zweite würde mit dem FT800 funktionieren? Dann könnte ich
die 14€-Variante nehmen, müsste aber den FT800 im VQFN-48 mit 0,5mm
Pitch löten.
Ich tendiere daher zur 25€-Variante. Was meinst Du?
VG Torsten
Frank M. schrieb:> Also wischen kannst du mit dem Teil nicht realisieren, ohne extra> externen RAM.
Mit einem EVE geht "wischen" auch ohne externes RAM, da der EVE das Bild
über eine Displayliste in Echtzeit neu aufbaut und daher nur eine sehr
geringe Speicherbandbreite zwischen Graphikcontroller und CPU braucht.
Das sind Ansätze, wie sie in den 80er Jahren auch in den Spielekonsolen
verwendet worden. Dort konnte man auch mit 4kb RAM und einer 1.7 MHZ CPU
"Wischen" auf dem kompletten Bildschirm ermöglichen. Früher hat man das
übrigens als "Scrolling" bezeichnet :)
> Von daher wäre es praktischer einen uC mit einem passenden Interface zu> verwenden, an das du dann einen externen RAM anschließt. Dann sparst du> dir den FT800 und bist flexibler.
Der PIC enthält aber kein echten Grafikprozessor, wie den FT800, sondern
unterstützt nur einen Framebuffer. In Geschwindigkeit, und vor allem
Qualität, liegen dazwischen Welten. Ähnlich liegt der Chrome im
STM32F429, auch wenn der anscheinend schon etwas mehr kann.
(Pixelblending etc.)
Tim schrieb:> Mit einem EVE geht "wischen" auch ohne externes RAM, da der EVE das Bild> über eine Displayliste in Echtzeit neu aufbaut und daher nur eine sehr> geringe Speicherbandbreite zwischen Graphikcontroller und CPU braucht.
So ganz nachvollziehen kann ich das nun nicht, zumindenst stelle ich mir
dabei große Einschränkungen vor, vor allem bei dynamischen Inhalten.
Tim schrieb:> Der PIC enthält aber kein echten Grafikprozessor, wie den FT800, sondern> unterstützt nur einen Framebuffer. In Geschwindigkeit, und vor allem> Qualität, liegen dazwischen Welten. Ähnlich liegt der Chrome im> STM32F429, auch wenn der anscheinend schon etwas mehr kann.> (Pixelblending etc.)
Das mag zwar sein, aber nach Oben ist immer Luft. Und er will etwas
simples und preisgünstiges was leicht nachzubauen ist. Das kann ich mir
nur schwer vorstellen wenn er nun nach und nach Zusatzchips hinzufügt,
die zwar lauter Komfort-Funktionen bieten, aber mal ehrlich, momentan
kommt er mit einem winzigen 8-bit AVR aus.
Ich habe es nicht genau angeschaut ob es funktioniert, aber würde er
nicht schon alles ausreichend für seine Effekte schaffen mit bspw.
folgender Kombination eines PIC32MX130F064D und einem 8Mbit SRAM?
(beides gibt's auch in DIL falls er es mal testweise aufbauen will bevor
er eine Leiterplatte erstellen lässt). Das sind 3.60 Euro exkl. Mwst.
http://de.farnell.com/microchip/pic32mx130f064d-i-pt/ic-mcu-32bit-64kb-flash-44tqfp/dp/2097777http://de.farnell.com/alliance-memory/as6c1008-55sin/sram-1mb-2-7v-5-5v-128kx8-sop32/dp/1562898
Will er noch USB so muss er eben etwas tiefer in die Tasche greifen,
aber bleibt immer noch im Rahmen.
Frank M. schrieb:> Tim schrieb:>> Mit einem EVE geht "wischen" auch ohne externes RAM, da der EVE das Bild>> über eine Displayliste in Echtzeit neu aufbaut und daher nur eine sehr>> geringe Speicherbandbreite zwischen Graphikcontroller und CPU braucht.> So ganz nachvollziehen kann ich das nun nicht, zumindenst stelle ich mir> dabei große Einschränkungen vor, vor allem bei dynamischen Inhalten.
Gerade dafür ist der EVE ideal, da man statt Bildinhalten einfach nur
Koordinatenlisten verändern muss. Dafür funktioniert das Konzept bei
Anwendungen wie Video-Streaming nicht gut.
Torsten C. schrieb:> Ich habe diese hier gefunden:> http://www.aliexpress.com/item//1582821072.html (14€ ohne Controller)Frank M. schrieb:> Von daher wäre es praktischer einen uC mit einem passenden Interface zu> verwenden, … Bspw. ein PIC24FJxxxDA der eine GPU hat …
Also wenn ich das richtig verstehe, würde das "Graphics Controller
Module (GFX)" den SSD1963 in der 25€-Variante ersetzen. Das klingt gut,
weil die Scherben über 3,5 Zoll oft ohne Controller angeboten werden.
Ich denke mal laut:
Bei 480 x 272 Dots und mehr wären schon 1..2MiB und mehr angebracht. Da
der PIC24… kein SDRAM kann, machen größere Speicher keinen Sinn.
Und 0,5mm Pin-Pitch ist für ein Open-Source Nachbau-Projekt zu fein.
Ausweg: Eine Kleinserie in industrieller Fertigung.
Das Problem ist dabei, genügend Leute zusammen bekommen. Bei
"Speziallösungen" wird das sicher schwieriger als bei Allerwelts-µCs.
Zum Nachbau wäre der ATmega162 optimal,
aber dazu holger schrieb:> Schöner Griff ins Klo;)
Für eine Kleinserie finde ich die Varianten
* LPC1774 + SDRAM und
* ATXMEGA64A1U + SDRAM
attraktiver als die PIC-Lösungen mit (Pseudo-)SRAM.
Siehe auch Beitrag "[Sammelbestellung] µC-Board + RAM"
Hmmm ...
PS: Vielleicht ist das was für'ne Kleinserie?
http://atomsoft.wordpress.com/2013/08/22/ft800-breakouts/
Du schreibst immer nur, dass Du ein paar wenige Display Einheiten machen
musst. Dabei hast Du schon ein Display gekauft und suchst nun alles, was
dahinter passen könnte...
Was ist den auf der anderen Seite von dem Display-Modul? Also was soll
das Ding denn anzeigen oder steuern?
Bei einem resistive-touch wird es wohl was sein, was man auch mit einem
Stift oder Handschuh bedienen können muss.
Weil all das was Du machen willst, gibt es ja schon fertig zu kaufen.
Ein paar alte Odys Loox tablets mit toten Akkus lösen die meisten
Probleme bei einer stationären Verwendung. Akku raus, 10k Widerstand
rein. Konstant mit Netzteil versorgt und die eigene Logik oder den
Umsetzer für Daten oder ADC oder was auch immer per USB angeschlossen.
Wischen und so weiter kann dann das Android oder der Window-Manager für
ein picuntu u.s.w.
Aber ich weiß halt nicht was Du machen willst, ausser ein kleines
Display an einen viel zu kleinen uC anzuschließen...
Gruß
Ulrich
Ulrich P. schrieb:> Aber ich weiß halt nicht was Du machen willst,
Kleine Fernbedienungen und Lichtschalter mit Touch-TFT.
Wenn ich alle Funk-Lichtschalter im Haus ersetze, dann sind das 10..12
Displays. Dann noch die Fernbedienungen im Wohnzimmer und bei meinem
Sohn mit IRMP. Alles Mesh-vernetzt mit NRF24L01+.
Die Displays an der Haustür im Flur und im Wohnzimmer werden etwas
größer als die anderen.
> ausser ein kleines> Display an einen viel zu kleinen uC anzuschließen ...
So arbeiten Ingenieure: So klein wie möglich aber so groß wie nötig.
… zumindest bei dem, was Du mit "klein" und "groß" meinst.
Alles andere landet am Ende auf dem haufen der Dinge, die sich nicht
durchgesetzt haben.
Falls das alles "ganz toll" werden sollte - was sich erst zeigen
muss -, sollte alles einfach, schnell und billig nachbaubar sein.
PS:
Ulrich P. schrieb:> Ein paar alte Odys Loox tablets
Und falls mein Nachbar das toll findet und auch haben will: Wer baut
dann die ganzen Tablets um?
Torsten C. schrieb:> Ulrich P. schrieb:>> Aber ich weiß halt nicht was Du machen willst,>> Kleine Fernbedienungen und Lichtschalter mit Touch-TFT.
Das rückt Deine Anforderungen in ein komplett anderes Licht und setzt
dem ganzen einen völlig anderen Rahmen.
> So arbeiten Ingenieure: So klein wie möglich aber so groß wie nötig.> … zumindest bei dem, was Du mit "klein" und "groß" meinst.
Ja, und ziehen sich den Hals so zu, dass jede kleine Erweiterung eine
Neuentwicklung ist.
> Alles andere landet am Ende auf dem haufen der Dinge, die sich nicht> durchgesetzt haben.
Das ist weder wahr noch richtig, denn das was Du da machen willst gibt
es schon, und kann man z.B. in der ELV finden. Aber es kann halt nicht
wischen. Braucht wegen OLED aber wenig Strom.
> Falls das alles "ganz toll" werden sollte - was sich erst zeigen> muss -, sollte alles einfach, schnell und billig nachbaubar sein.
Die Sache an sich kann sicher toll werden, es hat sich aber gezeigt,
dass jeder Schalter schalten will, nicht wischen und schon garnicht
kuscheln, also wischen mit sanftem Druck (wegen resistive Touch).
Das soll Dich aber nicht aufhalten.
Ulrich P. schrieb:> es hat sich aber gezeigt,> dass jeder Schalter schalten will, nicht wischen
Klar:
Torsten C. schrieb im
Beitrag "Re: [S] 20 Stück "Touch LCDs (bunt)""> Konrad S. schrieb:>> Evtl. hat ja jemand ein Konzept realisiert, mit dem die ganze Familie>> gut zurechtkommt?!?>> Patscht man im Dunkeln drauf, geht das Licht an oder aus.>> Wischt man von oben nach unten, kommt Menü 1: Z.B. RGB-Anteile für die> Wandleuchte rechts vom Bücherregal.>> Wischt man von unten nach oben, kommt ein anderes Menü. Usw.Ulrich P. schrieb:> Ja, und ziehen sich den Hals so zu, dass jede kleine Erweiterung eine> Neuentwicklung ist.
Ich denke, Videos muss ich auf keinem Lichtschalter abspielen. Die
Ingenieur-Logik^^ macht für die Einschränkung der Grafik-Fähikeiten
schon Sinn.
Alles andere soll natürlich erweiterbar sein!
Torsten C. schrieb:> Ich denke mal laut:>> Bei 480 x 272 Dots und mehr wären schon 1..2MiB und mehr angebracht. Da> der PIC24… kein SDRAM kann, machen größere Speicher keinen Sinn.
Nein, nein und nochmals nein.
Wie oben schon angedeutet und in den 80ern/Anfang der 90er auf diversen
Homecomputern praktiziert, braucht es dafür definitiv nicht soviel
Speicher.
Der ILI9325 hat 172800 Byte RAM, bei 320 x 240 x 16BPP würden 153600
verwendet, bleiben somit 19200 Bytes übrig.
Wird mit den Features des ILI der angezeigte Teil verschoben, reicht es
- etwas intelligentere Grafikfunktionen vorausgesetzt - im momentan
nicht angezeigten Bereich des ILI-Speichers einen neuen "Streifen" zu
zeichnen.
Bspw. 16 Pixel x 320 Pixel x 16 BPP = 10240 Bytes und sowas geht auch
mit kleineren Controllern.
Ich glaube du verennst dich:
1. Wozu brauchst du SDRAM bei einer Fernbedienung?
2. Was spricht gegen den Vorschlag mit dem PIC32:
Beitrag "Re: µC mit viel RAM für Touch TFT mit "Wischen""
Damit kannst du sowohl eine Display mit Controller ansteuern und wenn du
ein Controllerloses Display hast, bestückst du noch den externen SRAM,
fertig.
3. Ein TFT ist absolut ungeeignet für eine Fernbedienung aufgrund der
Leistungsaufnahme. Warum wird man wohl sein Smartphone jeden Tag laden
müssen? Sei's drum. Achte wenigstens auf den uC, dass der im Sleep Mode
sehr wenig verbraucht. Da wird der PIC24FJxxxDA vermutlich besser
abschneiden (ist aber teurer).
3. Mal ehrlich, wozu musst du eine Funktion haben, bei der das Display
dem Finger folgt? Es reicht doch vollkommen wenn du die Geste 'links bzw
rechtswischen' erkennst und den Displayinhalt dann von links bzw. rechts
einschiebst. Kein Mensch braucht bei einer Fernbedienung einen sinnlosen
Effekt bei dem der Bildschirminhalt dem Finger exakt folgt. Somit
erübrigt sich der dreifache Buffer und du brauchst eigentlich nur einen
oder zwei für ein Controllerloses, bzw. keinen oder ein für eins mit
Controller.
4. Versuche doch erst einmal das Gerät zum laufen zu bringen bevor du da
in größeren Mengen denkst. Den PIC32 bspw. kannst du sogar auf einer
Lochrasterplatine aufbauen. Dann siehst du was machbar ist und was du
tatsächlich am Ende überhaupt brauchst.
Arc Net schrieb:> Wird mit den Features des ILI der angezeigte Teil verschoben, reicht es> - etwas intelligentere Grafikfunktionen vorausgesetzt - im momentan> nicht angezeigten Bereich des ILI-Speichers einen neuen "Streifen" zu> zeichnen.
Es gibt keinen "nicht angezeigten Bereich des ILI-Speichers". Mit dem
Prototyp (Variante a) ist die "Intelligenz der Grafikfunktionen"
ausgereizt, der Code ist optimiert usw. Alles andere wird zu langsam.
Punkt.
Frank M. schrieb:> Was spricht gegen den Vorschlag mit dem PIC32 …
Über den Stromverbrauch und eine PIC32-Lösung habe ich mir noch keine
Gedanken gemacht. Danke für die Hinweise, das werde ich nun tun.
Frank M. schrieb:> Ich glaube du verennst dich…
Das Risiko besteht, vielleicht hast Du sogar Recht,
aber dafür habe ich ja EUCH ! :-)
Nun haben wir schon viel debattiert, aber ich habe noch keine
Entscheidung gefunden. Da fällt mir das Seminar „Entscheidungen
zielsicher treffen” bei Prof. Wippich ein.
In der Phase ❸ „Muss- und Wunschkriterien klassifizieren” hatte ich das
Thema „Stromverbrauch” bisher vergessen. :-(
Variante ❶ (oben a) genannt) ist ja soweit fertig.
Frank M. schrieb:> Versuche doch erst einmal das Gerät zum laufen zu bringen
Hab ich ja, und damit wird auch erstmal Erfahrung gesammelt. Macht es
Sinn, für eine nächste Generation über stromsparende OLED-Touch-Displays
nachzudenken? Speziell bei der batteriebetriebenen Fernbedienung?
Ich bin Techniker, ein echtes „Handy Wischen” brauche ich nicht.
Andererseits (siehe iPhone & Co) gehört das vielleicht dazu, um Leute zu
begeistern.
Natürlich nicht um jeden Preis, aber ich will das Thema „Handy Wischen”
nicht aus dem Zielkatalog (Schritt ❷) streichen.
So, dann mache ich mal mit den "Fragezeichen" in der Grafik weiter …
Torsten C. schrieb:> Über den Stromverbrauch … habe ich mir noch keine> Gedanken gemacht …, das werde ich nun tun.
Ich denke, die zwei Themen "Stromsparen" und "Handy wischen" lasen sich
entkoppeln. Eine Lösung mit "RAM fürs Handy-Wischen" kann ich "eins zu
eins" von der alten Lösung übernehmen; der S6E63D6 und der ILI9325 sind
z.B. sehr ähnlich.
RS Components hat ein ganz nettes 2,83" Touch OLED mit 320x240 Pixeln
und dem S6E63D6-Controller:
http://de.rs-online.com/web/p/oled-displays/0554188/
Wenn man der dort verlinkten "AMOLEDPresentation" glaubt, spart OLED
gegenüber TFT etwa 50% Leistung: ca. 112 statt 224mW, je nach
Bildinhalt.
Der Treiber ist ganz gut dokumentiert:
http://appnote.avrportal.com/datasheets/TFT-Controller/S6E63D6X.pdf
Dieses hier ist der "kleine Bruder" und kostet 14,70€:
http://www.aliexpress.com/item//1615334512.html
Der 61-Pin-Anschluss ist leider sehr fein, also schwer zu löten,
Steckverbinder sind teuer und schwer zu finden.
Dafür wird aber ein "RGB interface for motion picture display" mit
VSYNC, HSYNC, and DOTCLK unterstützt. Nicht schlecht.
Für 112mA weniger zahlt man also einen Mehrpreis von ca. 11€. Sonst
bleibt alles andere fast gleich.
Fast alle µCs kann man stromsparend programmieren, der Unterschied ist
marginal.
SRAM, (P)SRAM und SDRAM habe ich noch nicht verglichen.
Oder meint jetzt einer, ich sei wieder auf dem Holzweg?
Torsten C. schrieb:> Es gibt keinen "nicht angezeigten Bereich des ILI-Speichers".
Wenn's unbedingt 18 BPP statt 16 BPP sein müssen, dann ja, ansonsten ist
Speicher über.
> Mit dem Prototyp (Variante a) ist die "Intelligenz der> Grafikfunktionen" ausgereizt, der Code ist optimiert usw. Alles andere> wird zu langsam. Punkt.
Definitiv nicht. Punkt. Been there, done that z.T. auf weitaus
langsameren Rechnern/Controllern. 16 BPP, 8 BPP, Display window kleiner
als 320x240 usw. usf.
> Hab ich ja, und damit wird auch erstmal Erfahrung gesammelt. Macht es> Sinn, für eine nächste Generation über stromsparende OLED-Touch-Displays> nachzudenken? Speziell bei der batteriebetriebenen Fernbedienung?
Nur, wenn der großteil des Displayinhalts schwarz ist, ansonsten ist der
Stromverbrauch (Ausnahmen bestätigen die Regel) höher.
Bspw. zieht das kleinere C0240QGLB von CMEL laut DB 260 mW typisch wenn
nur 30% der Pixel an sind.
TFT-Alternativen z.B. NHD-2.4-240320SF-CTXL (z.B. bei Mouser für 17,82 €
exkl., beim Hersteller $15.82
http://www.newhavendisplay.com/nhd24240320sfctxlftn1-p-7122.html)
oder z.B. DT024CTFT-TS (~16 € bei RS)
ich hatte mir da auch weitere Gedanken darum gemacht weil ich so eine FB
auch brauchbar finde:
- Stromverbrauch: das Display kann man abends/nachts abschalten und beim
ersten Touch wieder aktivieren, wieviel Strom braucht das wenn es
disabled ist?
- Wischen: hast du mal ausprobiert ob die billigen resistiven dafür
geeignet sind? Man muss ja etwas fester drücken, bei low cost
Smartphones fällt das schon negativ auf.
- Wischen und Bedienelemente: passt eventuell nicht zusammen, also z.B.
rechts/links Wischen und horizontale Slider.
- Wischen und Rendern: wie komplex sollen die Darstellungen sein? Wenn
man die Darstellung nicht als Bild im Speicher hält sondern 'on demand'
rendert kommt man mit wesentlich weniger Speicher aus. Da ist die Frage
ob die Rechenleistung reicht um z.B. eine Spalte in 1ms aufzubauen. 1ms
wenn man mit 320 ms Bildaufbau beim Wischen zufrieden ist, was aber
schon 240*16 Bit/Pixel / ms = 480.000 Byte/s sind.
- LPC1774 wäre gut, alternativ könnte man sogar bis LPC4088 bestücken,
Cortex-M4 mit viel Zubehör. Allerdings ist eine Kombi 'nur µC und RAM'
auch nicht gerade bastelfreundlich. Man hat sehr viele Anschlüsse für
ext. Display (wenn man Controller im µC nutzen möchte) oder kritische
Teile für Ethernet. In so einem Fall ist man sicher mit einem LPCXpresso
oder LPC4088QSB besser bedient. Also doch keine EWMS bauen und auf die
Kombi minimal Board + low Cost Display konzentrieren.
Nur mal meine zwei cent:
Ich frage mich, ob hier nicht gerade die eigentliche Funktion des zu
spezifizierenden Designs untergeht. "Wischen" ist ja nun wirklich eher
ein Gimmick. Das als Aufhängepunkt für das Systemdesign zu nehmen
scheint den Gaul von hinten aufzuzäumen.
Die anderen angedachten Funktionen sind auch nicht gerade Trivial -
Funknetzwerk, Interface zu irgendwelchen bestehenden Anlagen usw.
Sauber wäre es hier, GUI und Basisfunktionen zu trennen und diese
getrennt zu spezifizieren und zu entwickeln. Priorität hat hier
sicherlich nicht das User-Interface.
Übrigens kann ich mir auch den Hinweis auf den Fehlschluss, dass die
Existenz einer Entscheidungsvorschrift auch zu einer inhaltlich
korrekten Entscheidung führt, nicht Verkneifen.
Tamara Roll schrieb:> Sauber wäre es hier, GUI und Basisfunktionen zu trennen und diese> getrennt zu spezifizieren und zu entwickeln. Priorität hat hier> sicherlich nicht das User-Interface.
Der Thread-Titel legt nahe, dass es eben doch um ein User-Interface
geht. ("Wow, eine tolle Lösung! Wie war jetzt gleich nochmal der
Zusammenhang mit dem Problem?")
> Übrigens kann ich mir auch den Hinweis auf den Fehlschluss, dass die> Existenz einer Entscheidungsvorschrift auch zu einer inhaltlich> korrekten Entscheidung führt, nicht Verkneifen.Den merk' ich mir. :-)
Ulrich P. schrieb:> Braucht wegen OLED aber wenig Strom.Arc Net schrieb:> Nur, wenn der großteil des Displayinhalts schwarz ist,
Also war das Quatsch und OLED Braucht genauso viel Strom?
OK, aber warum sagst Du das nicht gleich!
Jojo S. schrieb:> wieviel Strom braucht das wenn es disabled ist?
Praktisch keinen, ggf. Leckstrom vom MOSFET.
Jojo S. schrieb:> hast du mal ausprobiert ob die billigen resistiven dafür> geeignet sind? Man muss ja etwas fester drücken, bei low cost> Smartphones fällt das schon negativ auf.
Das ist einer der wertvollsten Beiträge in diesem Thread, danke! :-)
Das probiere ich ASAP aus und werde berichten.
PS: Dann ist es bei 'low cost' vielleicht besser, das "Wischen" als
"Touch-Geste" (Neuaufbau ohne Scrollen) umzusetzen, ohne dabei den
Bildschirm zu scrollen.
Jojo S. schrieb:> Wischen und Bedienelemente: passt eventuell nicht zusammen
Und wie macht das das iPhone? Ich hab' mir das bei meinem Android-Handy
abgeschaut, da geht das auch.
Jojo S. schrieb:> Wenn man die Darstellung 'on demand' rendert kommt man mit wesentlich> weniger Speicher aus. Da ist die Frage ob die Rechenleistung reicht um> z.B. eine Spalte in 1ms aufzubauen.
Die Rechenleistung reicht, um eine Spalte in deutlich weniger als 1ms
vom externen RAM in das ILI9325 zu befördern.
Dann sind wir beim "Begeisterungsfaktor": Ich habe meinen Kompromiss aus
Rechenleistung und Screen-Design gefunden. Ich will beim Design auch
keine Abstriche machen.
'Spalte on demand' ist grenzwertig. Dann sähe man halt die Verzögerungen
und dann kann man statt "Handy-Wischen" lieber "einfaches Wischen" (mit
Schwarz) oder die "Touch-Geste" umsetzen.
Jojo S. schrieb:> Also doch keine EWMS bauen
Keinesfalls. Ich dachte an eine Kleinserie einer bastelfreundlichen
Kombi 'nur µC und RAM'.
Jojo S. schrieb:> Allerdings ist eine Kombi 'nur µC und RAM' auch nicht gerade> bastelfreundlich.
Ach. Und warum? "Sehr viele Anschlüsse" empfinde ich als Flexibilität.
Und was meinst Du mit "kritische Teile für Ethernet"?
Tamara Roll schrieb:> Sauber wäre es hier, GUI und Basisfunktionen zu trennen und diese> getrennt zu spezifizieren und zu entwickeln. Priorität hat hier> sicherlich nicht das User-Interface.
Sehe ich genau so. Mache ich auch so.
Absicht oder Missverständnis, Frau T.roll?
> Übrigens kann ich mir auch den Hinweis auf den Fehlschluss, dass die> Existenz einer Entscheidungsvorschrift auch zu einer inhaltlich> korrekten Entscheidung führt, nicht Verkneifen.
Die blosse Existenz? Sicher nicht. Ich befürchte, Prof. Dr. Ing. Klaus
Wippich liest hier nicht mit. Aber das würde sicher selbst er nicht
behaupten.
Arc Net schrieb:> Wird mit den Features des ILI der angezeigte Teil verschoben, reicht es> im momentan nicht angezeigten Bereich des ILI-Speichers einen neuen> "Streifen" zu zeichnen.
Ich nutze das Datenblatt V0.43 vom 10.09.2008. Die RAM-Adressen sind den
Pixeln fest zugeordnet. Wenn wegen geringerer Farbtiefe nicht alle Bits
pro RAM-Adresse genutzt werden, entsteht im ILI9325 dadurch kein "nicht
angezeigter Bereich".
Arc Net schrieb:>> Alles andere wird zu langsam. Punkt.> Definitiv nicht.
Das hängt von dem Screen-Design ab; Deins ist sicher anders. Ich habe
meinen Kompromiss gefunden.^^
Konrad S. schrieb:> "Wow, eine tolle Lösung! Wie war jetzt gleich nochmal der> Zusammenhang mit dem Problem?"
Wie gesagt: GUI und Basisfunktionen trennen! Die Basis-Funktionen lassen
sich sowohl mit "Simpel-GUIs" und "High-End-GUIs" bedienen. Optional
halt!
Konrad S. schrieb:> Der Thread-Titel legt nahe, dass es eben doch um ein User-Interface> geht.
Ja, genau, danke. Die Basis-Funktionen laufen in anderen Threads. Ich
bitte freudlich darum, hier On-Topic zu bleiben.
Torsten C. schrieb:> Ulrich P. schrieb:>> Braucht wegen OLED aber wenig Strom.> Arc Net schrieb:>> Nur, wenn der großteil des Displayinhalts schwarz ist,> Also war das Quatsch und OLED Braucht genauso viel Strom?> OK, aber warum sagst Du das nicht gleich!
Jein.
Wenn der Großteil der angezeigten Fläche Schwarz ist, dann braucht das
OlED weniger. D.h. bei weißem Text auf schwarzem Hintergrund braucht das
OLED weniger als ein LCD. Bei schwarzem Text auf weißen Hintergrund ist
es aber umgedreht.
D.h. wenn man seine Oberfläche so gestaltet, dass Schwarz die
Hintergrundfarbe ist (siehe Windows Phone 8 oder frühere Anroid
Interfaces) dann ist das OLED im Vorteil. Auch kann man sich damit Späße
wie dauernd dargestellte Info (irgendein Samsung Galaxy Smartphone hat
das) realisieren.
Thread beobachten
Seitenaufteilung abschalten