Hallo zusammen, Ich möchte ein Touchscreen-Display 5" mit 480x800 Pixeln mit einem eingebauten ssd1963 Controller (link eingefügt) https://eckstein-shop.de/50-MIT-Touchscreen-800480-MCU-Bus-TFT-LCD-Display-SSD1963-Kompatibel-Arduino Mit einem atmega32 steuern. Mir fehlt noch ein wenig die Erfahrung in Mikrocontrollern daher die Frage: Reicht die Rechenleistung aus, um mein Projekt umzusetzen? Danke schonmal für eure antworten!
Streno schrieb: > Reicht die Rechenleistung aus, um mein Projekt umzusetzen? Kommt drauf an was du erwartest. Im Prinzip ja. Framebuffer-Techniken wirst du aber nicht umsetzen können.
Streno schrieb: > Reicht die Rechenleistung aus, um mein Projekt umzusetzen? Zusatz: Dein Projekt kennen wir nicht. Meine Aussage war alleine für's Display gedacht.
Ich möchte Daten eines ekgs darstellen und mithilfe der touch Funktionen verschiedene Seiten anzeigen und start/stopp. Ebenso möchte ich die Daten auf einer sd Karte speichern
Hallo, Streno schrieb: > Ich möchte Daten eines ekgs darstellen und mithilfe der touch Funktionen > verschiedene Seiten anzeigen und start/stopp. Ebenso möchte ich die > Daten auf einer sd Karte speichern das wird mit dem Atmega32 nichts.. Das Display wird parallel angesteuert. 16 Daten Ports, etliche Steuerleitungen, SPI für Touch, SPI für SD-Card. Allein die Fonts belegen den ganzen Speicher! Schau dich nach einen ATmega um, der solche oder ähnliche Dimensionen wie der ATmega1280 hat. Gruß G.G.
Streno schrieb: > Ich möchte Daten eines ekgs darstellen und mithilfe der touch Funktionen > verschiedene Seiten anzeigen und start/stopp. Dann lieber gleich so: Beitrag "stm32_f4ve lcd für 16x2-Stiftleiste" oder auch ein STM Discovery Board.
Gerhard G. schrieb: > Schau dich nach einen ATmega um, der solche oder ähnliche Dimensionen > wie der ATmega1280 hat. Danke, so eine Antwort habe ich gebraucht. Was bedeutet ähnlich wie der atmega1280? Warum nicht der atmega 1280? Gibt es für den atmega ein geeignetes Evaluation?
Hallo, eigentlich wollte ich größer schreiben. Gemeint habe ich den ATmega2560-16AU. Den gibt es günstig z.B bei http://www.ebay.de/itm/like/291800602728?lpid=106&chn=ps&ul_noapp=true Der ATmega2560-16AU hat aber auch nur eine SPI-Schnittstelle. Das führt unweigerlich bei Touch und Sd-Card zu Problemen. Ein Atxmega128A3(1), oder ein kleiner ARM wäre die bessere Lösung. Ein kleinerer ARM hat zwar bis zu 3-4 SPI-Schnittstellen, dafür wird es mit den Port's knapp. Lösung wie oben beschrieben: STM32F4 Gruß G.G.
Gerhard G. schrieb: > Lösung wie oben beschrieben: STM32F4 Er wollte aber was anderes hören: Streno schrieb: > Danke, so eine Antwort habe ich gebraucht.
Arduinoquäler schrieb: > Er wollte aber was anderes hören: Das führt bei mir zu der Einschätzung: beratungsresistent. Denn er will ja eine positive Antwort/Bestätigung für das was er sowieso machen will.
Oder ein anderes TFT: http://www.hotmcu.com/5-graphical-lcd-capacitive-touch-screen-800x480-spi-ft811-p-301.html?cPath=6_16 Naja, statt des Mega32 kann es dann auch sicher nicht schaden einen Mega644 oder Mega1284 zu benutzen - wenn es denn AVR bleiben soll.
Rudolph R. schrieb: > sicher nicht schaden einen > Mega644 oder Mega1284 - Ein 1284 hat 128 kByte Flash, für ein Programm und ein paar Icons in Verbindung mit dem Display WÜRDE das reichen. - Ein 1284 hat 16 kByte Ram, reicht zum Puffern eines Bildschirminhaltes bei weitem NICHT aus, im besten Fall partiell für Bildschirmausschnitte (allerdings muss eine Ausgabe nicht zwingend gepuffert werden (bspw. wenn ich ein Bildschirminhalt in Tilesets aufteile) - Ein 1284 besitzt eine 20MHz / 8 Bit CPU !!!! Das ist für Bildschirmausgaben mit einer Auflösung von 800x480 ultraextrem viel. Im 16 Bit Farbenmodus benötigt es 750 kByte Datentransfer (768000 Bytes) um ein einzelnes Bild komplett aufzubauen. Das ist schnarchlangsam. Selbst mit einem STM32F401 / 84MHz (mit dem ich das Display hier ausprobiert habe) ist das für komplette Ausgaben nicht wirklich schnell und selbst mit dem F401 ist Framebuffering nicht machbar. Fazit: Ein so großes Display an einem Controller zu betreiben reicht im besten Fall, um Textausgaben oder auch (langsame) Graphen zu zeichnen. Sobald Icons und Bildchen zum Einsatz kommen ist ein wirklich mächtiger Controller mit einigem RAM und satter Taktfrequenz notwendig. Ich für mich würde ein solches Display NICHT an einem AVR laufen lassen. Im Moment betreibe ich es in Verbindung mit einem Nucleo STM32F746 (1 MByte Flash, 350 kByte RAM, 216 MHz) und auch da ist manches (bspw. Framebuffering) nicht machbar ! (Abgesehen davon, dass ich für dieses große Display nicht wirklich eine Anwendung habe)
Ralph S. schrieb: > - Ein 1284 besitzt eine 20MHz / 8 Bit CPU !!!! Das ist für > Bildschirmausgaben mit einer Auflösung von 800x480 ultraextrem viel. sorry, soll heißen: "ultraextrem wenig"
Arduinoquäler schrieb: > Arduinoquäler schrieb: > Er wollte aber was anderes hören: > > Das führt bei mir zu der Einschätzung: beratungsresistent. > > Denn er will ja eine positive Antwort/Bestätigung für das > was er sowieso machen will. Ich würde eben am liebsten mit einem avr arbeiten, da ich damit am meisten Erfahrung habe. Der atmega 2560 ist ja auch im arduino Mega verbaut. Dort habe ich viele Beispiele gesehen, dass es mit einem großen Display funktioniert. Generell bin ich aber auch für andere Controller offen. Das Display sollte 3 Graphen anzeigen. Komplexe Bilder möchte ich ohnehin nicht darstellen Danke für die vielen Vorschläge
Kontext und so, ich habe vor allem auch ein anderes TFT vorgeschlagen. Mit einem FT8xx basiertem Display und einem AVR kommt man für Benutzer-Oberflächen locker auf 50 Frames pro Sekunde, da man pro Frame nur so 500 bis 1000 Byte per SPI übertragen muss. Die Dinger arbeiten nämlich Objekt-orientiert statt Pixel für Pixel und kümmern sich auch gleich um den Touch. Mal hier durch blättern: Beitrag "FT800 / FT810 Library" Was mit den Dingern nicht geht und sowieso sicher nicht mit dem AVR ist eine Dia-Show bei der Auflösung, oder das Abspielen von Videos. Die Daten müssen ja irgendwoher kommen und die 1 MB Objekt-Speicher reichen gerade mal für ein Bild in voller Auflösung. https://www.mikrocontroller.net/attachment/314717/FT813_RVT70UQFNWC0x.jpg Das läuft auf 40 Frames pro Sekunde mit einem 90CAN64. Die Bilder können als .jpg oder .png an den FT81x geschickt werden, nehmen also lange nicht so viel Platz weg und man kann die im Controller speichern.
Streno schrieb: > Komplexe Bilder möchte ich ohnehin nicht darstellen Komplexe Bilder werden komplett an einem Stück in den Diyplaycontroller geschrieben und lassen sich vermutlich schneller anzeigen, als eine Zeichnung mit einzeladressierten Pixeln. Da 480x800 auf 5" eine sehr feine Auflösung hat, muß man Punkte und Linien teilweise vergrößert zeichnen. Mit einer 5x7 Schrift wird man viele, viele Zeichen auf dem Display anzeigen, aber nicht lesen können. > Das Display sollte 3 Graphen anzeigen. Und gerade dafür wird viel CPU-Leistung/Geschwindigkeit gebraucht. Vergiß den AVR oder nimm ein anderes Display mit 272x480 @ 4,3", oder gleich einen leistungsfähigen ARM. Rudolph R. schrieb: > Die Dinger (FT800) arbeiten nämlich Objekt-orientiert statt Pixel für > Pixel Das ist schön, wenn man Objekte hat, aber unschön, wenn man Pixel für Pixel zeichnen will oder muß.
m.n. schrieb: >> Die Dinger (FT800) arbeiten nämlich Objekt-orientiert statt Pixel für >> Pixel > > Das ist schön, wenn man Objekte hat, aber unschön, wenn man Pixel für > Pixel zeichnen will oder muß. Na so ein Glück, dass die FT8xx auch Linien, Rechtecke und Kreise malen können - mit Anti-Aliasing. Es gibt auch ein Bargraph Objekt, das habe ich nur noch nicht benutzt.
Angehängte Dateien:
-
Combinacion_Perfecta.jpg
91 KB
Streno schrieb: > Ich würde eben am liebsten mit einem avr arbeiten, da ich damit am > meisten Erfahrung habe. Der atmega 2560 ist ja auch im arduino Mega > verbaut. Dort habe ich viele Beispiele gesehen, dass es mit einem großen > Display funktioniert. Nimmst du einen Arduino Mega2560 und ein Shield und ein Display mit 2x20 Pins (jedes wird funktionieren) und werde glücklich.
"Einziger" Nachteil bei diesen blöden Shields ist dass man an die restlichen Pins so schwer drankommt. Aber a bisserl was geht immer, sagt schon der Monaco Franze ....
Rudolph schrieb: > Na so ein Glück, dass die FT8xx auch Linien, Rechtecke und Kreise malen > können - mit Anti-Aliasing. Das ist ja gut. Dann kann man ein Pixel zeichnen, indem man ein Rechteck aus einem Punkt malen läßt, anstatt mühevoll in den Bildspeicher des µC ein Byte zu schreiben. > Es gibt auch ein Bargraph Objekt, das habe ich nur noch nicht benutzt. Wenn man die angebotenen Vorgaben so mag, ist ja alles gut. Wenn man einen eigenen Geschmack hat oder Geschwindigkeit braucht: eher schlecht. Das muß jeder für sich entscheiden!
Angehängte Dateien:
-
DSC01380.JPG
38 KB
Hier, das hat ein Kollege mit meinem 7" TFT von Riverdi als Visualisierung für seine Master-Arbeit programmiert. Das läuft auf einem 90CAN64 mit 40 Frames pro Sekunde. Die Daten für den Sinus kommen über den CAN rein, die Fläche hat so 256x256 Pixel, der Graph besteht aus etwa 100 Linien-Segmenten. Das scrollt entweder durch oder wird immer wieder neu gezeichnet. Ein Dreieck oder Sägezahn geht so auch super, ein chaotisches Signal konnte ich gerade spontan nicht testen. Eine andere Anzeige könnte zum Beispiel auch mit Rechtecken arbeiten als Balken-Anzeige, da müsste man dann immer nur eine Kordinate ändern, um unterschiedlich lange Balken zu bekommen.
Ich habe in meinem Test-Projekt gerade mal eine Oszilloscope ähnliche Anzeige implementiert: https://www.mikrocontroller.net/attachment/324090/FT813_RVT70UQFNWC0x.jpg_2.JPG Das ist ein Linienzug aus 64 Punkten auf 256x256 Pixel Fläche. Einfach nur mal so hingeworfen mit statischen Daten. Nur dafür gehen alle 20ms so schlapp 500 Byte über den SPI, was bei 8 MHz ungefähr 0,5 ms dauert. Wobei meine "Library" für sowas ziemlich ineffizient ist, da könnte man noch etwas Overhead raus optimieren.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.