mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega mit mehr Leistung?


Autor: AVRli .. (avrli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

seit gut 18 Jahren programmiere ich nun die ATMEL 8 Biter, angefangen 
beim AT2313 bis heute zum ATmega2560.

Bei meinem neuen Projekt soll ein 7" Touch Display eingesetzt werden. 
Die CPU ist derzeit ein ATmega 2560 mit 16 MHz.

Sollte die Ausgabegeschwindigkeit zu langsam sein, welche CPU wäre denn 
ein sinnvoller Nachfolger, wenn ich die Umgebung ATMEL Studio und mein 
JTAG MK II weiter nutzen möchte?

Gruß AVRli...

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nenne doch mal mehr Anforderungen, was der Controller sonst so tun soll. 
Die Größe des Displays ist ziemlich irrelevant; wichtig wäre die 
Auflösung und das Protokoll zur Ansteuerung.

Autor: Kim P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was spricht gegen den XMega?

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATXmega, die haben doppelte Taktfrequenz und ggf. DMA. Aber so ganz 
sinnvoll ist das auch nicht unbedingt, bestenfalls, wenn das Display 
viel Eigenintelligenz hat und dein AVR nicht allzuviel leisten muß.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Kim P. schrieb:
> was spricht gegen den XMega?

Was spricht gegen das Reiten von toten Pferden? Die Liste ist ähnlich.

Autor: Kim P. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
"Nenne doch mal mehr Anforderungen"
Wozu?
Er braucht was leistungsfähigeres und will das Atmel Equipement weiter 
nutze.
Die Frage ist doch recht eindeutig.
Entweder ein schnellen Mega..da bin ich gerade nicht auf dem laufenden, 
aber dann eben gleich XMEGA, die sind super und er kann alles weiter 
nutzen und muss sich nicht groß umgewöhnen.

Ansonsten natürlich STM32..aber die schiden aus wenn amn sich nicht 
komplett umgewöhnen will und erst recht wenn man das Atmestudio etc 
beibehalten will

Autor: Kim P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Cyblord
O Du hast die Frage verstanden
x ich bin nicht aufmerksam und gehe nicht auf die eigentlich Frage ein, 
laber aber gerne rum

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Kim P. schrieb:
> Wozu?

Insbesondere um einen Controller mit entsprechendem LCD-Interface zu 
wählen. Handelt es sich um ein "nacktes" LCD mit Parallel-RGB-Display 
wird ein Controller gebraucht welcher dieses Signal erzeugen kann. 
Einige STM32 können das; auf dem STM32F429-Discovery und dem 
STM32F746-Discovery ist das schon fertig aufgebaut. Ist aber kein 7".

Das Waveshare Board kommt mit 7"-Display:
https://www.amazon.de/dp/B00MJOCU2Q
Aber nicht ganz billig.

Interessant wären auch die Anforderungen bzgl. Echtzeit und sonstigen 
Interfaces. Wenn die nicht allzu hoch sind wäre ein R-PI mit zugehörigem 
Display eine Option. Der hat auch genug Leistung für anspruchsvolle 
GUIs.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Kim P. schrieb:
> @ Cyblord
> O Du hast die Frage verstanden
> x ich bin nicht aufmerksam und gehe nicht auf die eigentlich Frage ein,
> laber aber gerne rum

Du kannst dir deine XMega so lange schön reden wie du willst, und auch 
gerne weiter rumzicken wie ein kleines Mädchen. Das ändert aber nichts 
an den Tatsachen.

Autor: Kim P. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
schön das Du sachlich arguementierst..Deine Vorschläge gefallen mir gut.
Viele andere sagen labern immer nur rum..sagen das alles doof ist und 
quatsch..Du dagegen argumentierst mit Hand und Fuss, daumen nach oben 
dafür von mir. TOP
In diesem Forum gibt es so gut wie niemanden, der so viel zu Themen 
beiträgt wie Du
Kompliment

Autor: AVRli .. (avrli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der µC soll einige Eingänge überwachen, PWM auf 4 Ausgängen per HArdware 
erzeugen, Pin Change Interrupts auf 4 Eingängen bieten. Min. 10 ADC 
Kanäle mit min. 11 Bit Auflösung bei 5V. Alles Sachen die nicht sooo 
aufregend sind.

Das Display hat eine Auflösung von 800x480 und wird 16Bit parralel 
angesteuert.

Derzeit habe ich ein 480x320 Pixel Display an einem ATmega 2560. Die 
Ausgabe funktioniert soweit flüssig ABER wenn ich die Ansichten komplett 
umschalte, merkt man das schon. Das dauert etwas...

Eigene Intelligenz haben diese Display-Controller nicht. Es gibt die 7" 
Displays mit dem SSD1963 Chip oder dem MD070SD.

Der MD070SD bietet wohl speicher für 8 Ansichten, welche auch mit einem 
Kommando umgeschalten werden können.

Autor: Kim P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Einige STM32"
sidn aber kein AVR und untersützen weder das MK2 noch das Atmelstudio.
Dann bliebe eher der ATSAM..nur auch da geh das MK2 nicht mehr

Also bliebe nur der gesamt Umsteig aus STm32 und Atolic True Studio

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kim P. schrieb:
> Ansonsten natürlich STM32..aber die schiden aus wenn amn sich nicht
> komplett umgewöhnen will und erst recht wenn man das Atmestudio etc
> beibehalten will

Dafür steht ihm aber die komplette Palette an Atmel, ähem, Verzeihung, 
Microchip ARMs offen. Einzig das JTAGICEmkII tut's dann nicht mehr, das 
wäre mit den Xmegas in der Tat am Ende der Fahnenstange angelangt. 
Entweder ablösen durch ein AtmelICE (könnte man auch als nacktes PCB 
kaufen, wenn man sich das Gefummel mit den Anschlüssen selbst antun 
wöllte). Alternativ könnte man ein SAMD10 Xplained Mini kaufen und 
sehen, ob man das zum externen Programmer für andere SAMDs 
umfunktionieren kann.

ST sind ja beileibe nicht die einzigen, die ARMs herstellen.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Kim P. schrieb:
> schön das Du sachlich arguementierst..

Du kommst mir in der Tat vor wie jemand der noch versucht sachlich zu 
argumentieren und fleißig mit Verbesserungsvorschlägen aufwartet, wenn 
er jemanden sieht der versucht ein totes Pferd zu reiten.
Ja so ein Typ bist du.

Ich hingegen sage halt was Sache ist.

> In diesem Forum gibt es so gut wie niemanden, der so viel zu Themen
> beiträgt wie Du

Genau aus diesem Grund. Manchmal muss man Klartext reden. Irgendwann 
kapiert auch mal ein Spaten was los ist. Mit Geschwurbel klappt das nie.

: Bearbeitet durch User
Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
AVRli .. schrieb:
> Hallo,
>
> seit gut 18 Jahren programmiere ich nun die ATMEL 8 Biter, angefangen
> beim AT2313 bis heute zum ATmega2560.
>
> Bei meinem neuen Projekt soll ein 7" Touch Display eingesetzt werden.
> Die CPU ist derzeit ein ATmega 2560 mit 16 MHz.

Bei üblichen Displayauflösungen ist das schon ziemlich sportlich.

> Sollte die Ausgabegeschwindigkeit zu langsam sein, welche CPU wäre denn
> ein sinnvoller Nachfolger, wenn ich die Umgebung ATMEL Studio und mein
> JTAG MK II weiter nutzen möchte?

Wenn ich von üblichen 800x480 Pixeln ausgehe, dann sind das für 60Hz 
bereits über 23MHz(!) Pixeltakt, d.h. selbst ein xmega wird da auch mit 
DMA schon ziemlich dicke Backen machen. An eine hohe Farbauflösung 
(24-Bit RGB) ist schon gar nicht zu denken.

Wenn Du bei AVR bleiben willst (STM32F429 etc. wurden ja schon genannt), 
dann führt wohl kein Weg an einem externen Grafikkontroller vorbei 
(bspw. SSD1963). Dessen RAM kannst Du dann "in Ruhe" beschreiben und er 
erledigt den Rest der Displayansteuerung für Dich.  Es gibt dafür auch 
schon fertige 7"-Module.

Dank Smartphones dürfte es auch noch deutlich leistungsfähigere 
Controller mit 2D-Fähigkeiten geben.

Edit: hat sich überschnitten :-)

: Bearbeitet durch Moderator
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Manchmal muss man Klartext reden.

Konstruktive Vorschläge sehen dennoch anders aus als das, was du bislang 
in diesem Thread von dir gegeben hast. Du hast nämlich lediglich 
genannt, was deiner Meinung nach nicht funktionieren würde, und selbst 
das komplett begründungslos.

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Cyblord -. schrieb:
>> Manchmal muss man Klartext reden.
>
> Konstruktive Vorschläge sehen dennoch anders aus als das, was du bislang
> in diesem Thread von dir gegeben hast. Du hast nämlich lediglich
> genannt, was deiner Meinung nach nicht funktionieren würde, und selbst
> das komplett begründungslos.

Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits 
mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle 
anderen.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:
> Eigene Intelligenz haben diese Display-Controller nicht.

Es hat einen SRAM und erzeugt das LCD-Signal selbst. Also durchaus 
Intelligenz.

AVRli .. schrieb:
> Sollte die Ausgabegeschwindigkeit zu langsam sein, welche CPU wäre denn
> ein sinnvoller Nachfolger, wenn ich die Umgebung ATMEL Studio und mein
> JTAG MK II weiter nutzen möchte?

Wenn das eine harte Anforderung ist, ist die Antwort eigentlich klar - 
es gehen nur Xmega, AVR32 und AVR. Wenn es auch ein anderer Debugger 
sein darf, kämen die Atmel Cortex-M Controller (ATSAMx) in Frage. Wenn 
es auch eine andere IDE sein darf, kommt alles in Frage. JTAG-Debugger 
sind nicht teuer und viele IDEs gratis; daher kann man sich diese 
Anforderung noch mal überlegen.

AVRli .. schrieb:
> Das dauert etwas...

Für echt flüssige GUIs musst du den intelligenten Controller (alles was 
eigenen RAM hat) weglassen und das Signal direkt durch 
Controller-Hardware erzeugen lassen. Von den AVR's kann das m.W. keiner. 
Auf die Schnelle hab ich auch keinen anderen Atmel-Controller mit 
LCD-Interface gefunden. Daher wird das mit den gewünschten Anforderungen 
schwierig.

Daher wie gesagt z.B. STM32, da haben das manche. Viele Boards haben 
auch den Debugger direkt inklusive.

: Bearbeitet durch User
Autor: Der Andere (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Ich hingegen sage halt was Sache ist.

Nö, du hast in dem ganzen Thread nicht ein sachliches Wort fallen 
lassen.
Du darfst mich gerne des Irrtums überführen, zeig mir wo du sochlich für 
eine Prozessorfamilie argumentiert hast oder auh nur ein 
Prozessor/Familienname genannt hast.

Autor: Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Der Andere schrieb:
> Du darfst mich gerne des Irrtums überführen, zeig mir wo du sochlich für
> eine Prozessorfamilie argumentiert hast oder auh nur ein
> Prozessor/Familienname genannt hast.

Immerhin hat er sich indirekt dafür ausgesprochen, lebendige Pferde zu 
reiten. Ich empfinde das durchaus als hilfreich.

Autor: STM32Fanboy (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
STM32 ist der Beste überhaupt, weil er von ARM ist. Das ist Standart, 
darum ist alles Andere total schlecht.

Autor: AVRli .. (avrli)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also das Display hat entweder ein SSD1963 oder ein MD070SD Controller On 
Board. Die möchte ich schon einsetzen und mir war nicht bewusst das es 
schon als intelligent gilt.

Richtig ist, dass man diesen Cotroller sagt was er machen soll und der 
dann das Display entsprechend ansteuert.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:
> Die möchte ich schon einsetzen und mir war nicht bewusst das es
> schon als intelligent gilt.

Dann musst du immer mit etwas Latenz bei der Anzeige rechnen. Dann schau 
dir die ATSAM-Controller an, die gehen mit Atmel Studio, brauchen aber 
einen anderen JTAG-Debugger. Achte darauf, einen mit genug RAM für die 
Anzeige zu nehmen.

Autor: Konrad Duden (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
STM32Fanboy schrieb:
> Das ist Standart,
> darum ist alles Andere total schlecht.

Plakative Behauptungen mit einem dicken Rechtschreibfehler sind wenig 
überzeugend.

Autor: Framulestigo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits
> mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle
> anderen.

Warum musst Du dann überhaupt schreiben?

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Framulestigo schrieb:
> Cyblord -. schrieb:
>> Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits
>> mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle
>> anderen.
>
> Warum musst Du dann überhaupt schreiben?

Unsinnige Frage. Nur weil man nicht genau das schreibt, was alle anderen 
schreiben sollte man gar nichts schreiben? Was ist das für eine kausale 
Kette? Ordne mal deine Gedanken bevor du mit mir kommunizierst.

Autor: STM32Fanboy (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Framulestigo schrieb:
> Cyblord -. schrieb:
>> Umstieg auf ARM ist natürlich obligatorisch. STM32 wurde hier bereits
>> mehrfach genannt. Ich muss nicht nochmal dasselbe schreiben wie alle
>> anderen.
>
> Warum musst Du dann überhaupt schreiben?

https://de.wikipedia.org/wiki/Persiflage

Es ging hier um ATMEGA, lesen tut man "STM32 ist toll".

"Woran erkennt man, dass jemand ein STM32-Fanboy ist?"
...
...
...
"er wird es dir schon sagen".

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:
> Also das Display hat entweder ein SSD1963 oder ein MD070SD Controller On
> Board. Die möchte ich schon einsetzen und mir war nicht bewusst das es
> schon als intelligent gilt.

Die sind auch nicht intelligent. Die schaufeln lediglich die Bilddaten 
aus dem internen RAM zur Anzeige.
Folglich brauchst Du einen schnellen µC, der zum einen ein schnelles 
Interface für einen 16 Bit Datenbus und zum anderen hohe Rechenleistung 
hat, damit Schrift und Grafik zügig erzeugt werden können. Eine 5 x 8 
Schrift würde zwar noch schnell angezeigt werden, nur wird sie viel zu 
klein geraten, um lesbar zu sein. Folglich ist das nichts mehr für AVR8.

Such Dir einen 32 Bit µC aus: PIC, RX, ARM M3/M4/M7 (NXP, STM, o.ä.), 
wobei die Taktfrequenz >= 100 MHz liegen sollte.

AVRli .. schrieb:
> ein MD070SD Controller

Davon scheint es kein aussagekräftiges Datenblatt geben. Die 7" Module, 
die damit angeboten werden, erscheinen mir Auslaufmodelle zu sein 
("sale").

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:
> bei 5V

ATSAMC21
Kein AVR, aber immerhin vom gleichen Hersteller -> Atmel Studio
Nur wie weiter oben schon erwähnt, ein Atmel ICE braucht es dann schon, 
zumindest solange Microchip mit dem MPLAB-X und dem SNAP nicht weiter 
ist.

> Das Display hat eine Auflösung von 800x480 und wird 16Bit parralel
> angesteuert.

Autsch.
Mit einem Display-Controller ist das so viel einfacher.
Ob nun integriert in einem deutlich dickeren Controller, oder extern.

Und es gibt inzwischen mehrere da draussen unter denen man wählen kann, 
ich beschäftige mich mit den EVE von FDTI/BRT.

Das hier ist ein 7", 800x480 von einem AT90CAN angesteuert:
https://www.mikrocontroller.net/attachment/preview/324090.jpg

Das ist ein EVE2, genauer ein FT813 in dem Display.
Beitrag "FT800 / FT810 Library"

Hier noch ein Bild von einem EVE2-35G Modul mit AT90CAN Platine daneben:
https://www.mikrocontroller.net/attachment/363141/EVE2-35G_EVE2-38_FT813.JPG

Die 595µs im Bild sind die Zeit die Daten für ein Bild aufzubereiten und 
die 232 Bytes per 8MHz SPI an das Display zu schicken.

Für eine richtige Oberfläche mit mehreren Bildern, Rahmen, Tastern und 
so weiter bin ich gerade bei 1,7ms angekommen.
Allerdings auf dem SAMC21 mit dem SPI auf 12MHz.

Und um den Touch kümmert sich EVE auch noch, statt nur Koordinaten 
bekommt man die Information, welche Objekt-Gruppe berührt wurde.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Min. 10 ADC Kanäle mit min. 11 Bit Auflösung bei 5V.
Schlecht und schon verloren. Der ATMega kommt über 10 Bit nicht hinaus.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
>> Min. 10 ADC Kanäle mit min. 11 Bit Auflösung bei 5V.
> Schlecht und schon verloren. Der ATMega kommt über 10 Bit nicht hinaus.

Da nimmt man doch sowieso externe ADCs.

Autor: Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Unsinnige Frage. Nur weil man nicht genau das schreibt, was alle anderen
> schreiben sollte man gar nichts schreiben? Was ist das für eine kausale
> Kette? Ordne mal deine Gedanken bevor du mit mir kommunizierst.

In deinem ersten Beitrag hast du allerdings von toten Pferden 
geschrieben. Du hast demzufolge vorausgesehen, daß von anderen noch 
etwas Sinnvolles kommt. Respekt.

Autor: Framulestigo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Unsinnige Frage. Nur weil man nicht genau das schreibt, was alle anderen
> schreiben sollte man gar nichts schreiben? Was ist das für eine kausale
> Kette? Ordne mal deine Gedanken bevor du mit mir kommunizierst.

Bla bla.

Bemüh mal die Forensuche. Seit mindestens acht Jahren zerreißt sich 
dieses Forum das Maul über Sinn und Unsinn der XMega-Reihe.
Dein Beitrag: Unausgegorenes Nachplappern von Meinungen.
Einziger Fakt: Es gibt sie immer noch.

Da ist nix schreiben definitiv besser.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
AVRli .. schrieb:
> wenn ich die Umgebung ATMEL Studio und mein
> JTAG MK II weiter nutzen möchte?

Da würde ich zuerst in die Kompatibilitätsliste des JTAG MK II schauen. 
Ich glaube, der kann nur klassische AVRs mit ISP oder JTAG, keine 
XMEGAs, keine ARM.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Detlev T. schrieb:
> Da würde ich zuerst in die Kompatibilitätsliste des JTAG MK II schauen.
> Ich glaube, der kann nur klassische AVRs mit ISP oder JTAG, keine
> XMEGAs, keine ARM.

Ab Hardware revision B kann er auch ATxmega mit PDI.

Mehr aber wirklich nicht.

STM32Fanboy schrieb:
> STM32 ist der Beste überhaupt, weil er von ARM ist.

Ist er natürlich nicht – aber was soll man von jemanden mit diesem 
Pseudonym schon an Korrektheit erwarten …

Die Zeiten, da Acorn noch selbst Chips produzieren lassen hat, sind 
schon eine Weile vorbei.

Autor: Crazy H. (crazy_h)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
XMega384A3U @ 64MHz ..... läuft!

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:

> Sollte die Ausgabegeschwindigkeit zu langsam sein

Wieso sollte sie? Der 2560@16MHz schafft eine Busbandbreite von ca. 
5MBytes/s. D.h.: selbst ein kompletter Ersatz des Displayinhalts würde 
bei einem 800x480-Display mit z.B. 16 Farben nur ca. 40ms dauern.

Das entspricht der Framerate von PAL-Video...

Und außerdem: wann muss für eine typische µC-Anwendung schon der 
komplette Screeninhalt erneuert werden? Das ist doch eher selten.

Es sei denn, man baut damit ein Terminal und läßt das dann scanlineweise 
scrollen. Dann sollte man halt auch ein Terminal nehmen und keine 
Vollgrafik...

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> 800x480-Display mit z.B. 16 Farben
Das sind 192kByte Bilddaten.
Da bin ich sehr gespannt, wo die herkommen sollen.

Beitrag #5732371 wurde von einem Moderator gelöscht.
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:

>> 800x480-Display mit z.B. 16 Farben
> Das sind 192kByte Bilddaten.
> Da bin ich sehr gespannt, wo die herkommen sollen.

Das kann uns wohl nur der TO sagen...

Beitrag #5732380 wurde von einem Moderator gelöscht.
Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein STMnucleo kostet keine 10€ und ist ein brauchbarer JTAG-Adapter 
inklusive Evalboard.

Ob man nun AVR mag oder ARM oder nicht. Ich hab mich auch lange gewehrt 
und mit ATmegas und xmegas weitergemacht, aber letztlich bleibt gegen 
einen kleinen STM32F1 kaum was an Argumenten übrig. Der STM ist schon in 
kleinen Stückzahlen oft billiger als ein AVR in ähnlicher Ausstattung. 
Und das Debugging mit der ITM möchte ich auch nicht mehr missen.

Aber was ich überhaupt nicht verstehe, ist, dass jemand ernsthaft das 
Atmel-Studio als Argument aufbringt.

Ich habe selten mit einer rotzigeren IDE gearbeitet, als mit 
VisualStudio. Abgesehen von fast 800MB Arbeitsspeicherverbrauch im 
Leerlauf(!) ist am AtmelStudio echt alles Müll.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Abgesehen von fast 800MB Arbeitsspeicherverbrauch im Leerlauf(!)
Voll das schlagende Argument, wenn schon mein Laptop 16GB RAM hat ...

Ich komme mit dem AVR-Studio jedenfalls gut zurecht.

Beitrag #5732450 wurde von einem Moderator gelöscht.
Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> AVRli .. schrieb:
>
>> Sollte die Ausgabegeschwindigkeit zu langsam sein
>
> Wieso sollte sie? Der 2560@16MHz schafft eine Busbandbreite von ca.
> 5MBytes/s. D.h.: selbst ein kompletter Ersatz des Displayinhalts würde
> bei einem 800x480-Display mit z.B. 16 Farben nur ca. 40ms dauern.

Heute ist doch weder Freitag noch der 1. April? Dann kann diese Rechnung 
ja nur bösartig gemeint sein.

Wenn man mal ein bisschen Text auf Grafik Displays geschrieben hat, dann 
weiß man, daß das Setzen eines Punktes nur ein einziger Befehl ist. Um 
aber die richtige Adresse zu treffen, wo der Punkt landen soll, kommen 
noch einmal 30 - 50 Befehle dazu: bei einem AVR noch viel mehr, da er in 
einer Welt jenseits von 256 bzw. 65536 möglichen Adressen völlig 
verloren ist.

Da ich davon ausgehe, daß das Display nicht nur ständig mit farbigen 
Flächen gefüllt werden soll, schlage ich den Faktor 50 - 100 vor, um 
obige Zeitangabe auf einen realen Wert zu bringen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ben B. schrieb:
>> Abgesehen von fast 800MB Arbeitsspeicherverbrauch im Leerlauf(!)
> Voll das schlagende Argument, wenn schon mein Laptop 16GB RAM hat ...
Jo klar. Und das wiederum ist voll das schlagende Argument dafür, 
Bloatware noch weiter aufzublasen.

Autor: c-hater (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
m.n. schrieb:

> Wenn man mal ein bisschen Text auf Grafik Displays geschrieben hat, dann
> weiß man, daß das Setzen eines Punktes nur ein einziger Befehl ist. Um
> aber die richtige Adresse zu treffen, wo der Punkt landen soll, kommen
> noch einmal 30 - 50 Befehle dazu: bei einem AVR noch viel mehr, da er in
> einer Welt jenseits von 256 bzw. 65536 möglichen Adressen völlig
> verloren ist.

Hmm, wenn die Bilanz bei dir wirklich derart Scheiße ist, dann bist du 
schlicht ein völlig unfähiger Programmierer.

Nur zur Erinnerung: die Homecomputer der späten 80er hatten auch nur 
8Bitter, auch nur ein paar Dutzend k Ram, mussten auch mit Bankswitching 
klarkommen, haben aber trotzdem teils recht faszinierende animierte 
Grafik in Echtzeit hinbekommen. Es gibt keinen technischen Grund, der es 
einem (viel schnelleren) AVR8 verbieten würde, heute dasselbe zu 
leisten.

Nur völlig unfähige Programmierer könnten das effektiv verhindern. Leute 
wie du halt...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ben B. schrieb:
> Voll das schlagende Argument, wenn schon mein Laptop 16GB RAM hat

Es ist mehr eine Frage der Geschwindigkeit. Große Programme neigen dazu, 
langsam zu sein. Das Atmel Studio ist so eins.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jo klar. Und das wiederum ist voll das schlagende Argument dafür,
> Bloatware noch weiter aufzublasen.
Nö, das ist nur das schlagende Argument dafür, daß ich mich um solche 
Details nicht kümmere solange das Ding zufriedenstellend funktioniert.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
>> Jo klar. Und das wiederum ist voll das schlagende Argument dafür,
>> Bloatware noch weiter aufzublasen.

Ben B. schrieb:
> Nö, das ist nur das schlagende Argument dafür, daß ich mich um solche
> Details nicht kümmere solange das Ding zufriedenstellend funktioniert.

Vernünftig. Ich war jedenfalls nicht zufrieden. Mein Dual-Core Laptop 
mit 2,2GHz und 8GB war damit überfordert. Das Programm lief unerträglich 
langsam. Auf dem neuen Laptop mit Core i7 mit 4/8 Kernen geht es so 
gerade eben.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versteh ich ehrlich gesagt nicht. Das hier ist auch nur ein i7-2670qm 
und ich habe keine Probleme mit der Geschwindigkeit. Um welchen Teil des 
AVR-Studios geht es Dir, wo Du mit der Geschwindigkeit unzufrieden bist?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ben B. schrieb:
> Versteh ich ehrlich gesagt nicht. Das hier ist auch nur ein
> i7-2670qm
> und ich habe keine Probleme mit der Geschwindigkeit. Um welchen Teil des
> AVR-Studios geht es Dir, wo Du mit der Geschwindigkeit unzufrieden bist?

Mit dem AVR Studio komme ich gut klar. Das Atmel Studio ist lahm.

> Um welchen Teil ... geht es Dir?

Alles. Fängt schon beim Start an, und beim Tippen bin ich zeitweise 
schneller, als der (alte) Rechner mit kommt.

Autor: Ben B. (Firma: Funkenflug Industries) (stromkraft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay sorry dann habe ich das falsch verstanden. Ich dachte es geht um 
das AVR-Studio, wenn es da noch ein Atmel-Studio gibt, verwende ich das 
nicht.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
>> Jo klar. Und das wiederum ist voll das schlagende Argument dafür,
>> Bloatware noch weiter aufzublasen.
> Nö, das ist nur das schlagende Argument dafür, daß ich mich um solche
> Details nicht kümmere solange das Ding zufriedenstellend funktioniert.
Das tun leider viele. Und wenn sich mal zwei treffen, dann knallts.

Darum kann ja heute auch kaum mehr jemand "richtig" programmieren(tm), 
wenn man das mal so überspitzt darstellen darf.
Das "pad left"-Drama finde ich da ganz repräsentativ[1].

Auch wenn ich den STM32, wie ich oben ja schrieb, dem AVR aus vielen 
Gründen vorziehen würde, muss ich ja trotzdem nicht mit dessen 
Ressourcen arg verschwenderisch umgehen.


[1] 
https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/

Autor: AVRli .. (avrli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke für alle konstruktiven Antworten!
Wie schon geschrieben wurde, wird natürlich nicht immer der gesamte 
Bildschirminhalt aktualisiert. Bei der Umschaltung der Ansicht natürlich 
schon. Wenn die Ansicht dann gezeichnet ist, sind es nur noch die 
Bereiche, welche auch Änderungen enthalten.  Es sind Teilbereiche. 
Derzeit liegt die Ausgabegeschwindigkeit bei den Werten mit einer 
Bargraph- Anzeige bei 8ms.

Vielleicht habe ich einfach etwas zu viel Panik und das ganze hält sich 
auch bei dem größeren Display noch in Grenzen.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:
> Derzeit liegt die Ausgabegeschwindigkeit bei den Werten mit einer
> Bargraph- Anzeige bei 8ms.

Dafür braucht man ein 7" TFT?

> Vielleicht habe ich einfach etwas zu viel Panik und das ganze hält sich
> auch bei dem größeren Display noch in Grenzen.

Du kannst Dir ja einen Treiber für AVR schreiben und dann sehen, welche 
Zeit bei 800 x 480 Bildpunkten benötigt wird:
1. für das Löschen des Bildes
2. Zeichnen von Buchstaben im lesbaren Format (z.B. 16 x 32)
3. Textausgabe als Terminal inkl. 'scrolling', wenn die unterste Zeile 
vollgeschrieben ist.

Welche Farbtiefe willst Du denn verwenden? 16 Bit? Dann sorge für zwei 
freie Ports, damit die Daten auch parallel ausgegeben werden können.

Wenn Du ein guter Programmierer bist, schaffst Du auch locker die 
vorgegebenen 5 MB/s. Und nicht vergessen, zu jedem Bildpunkt zuvor die 
Zeile und die Spalte auszugeben.
Vielleicht wird Dir dann klar, was an Prozessorleistung benötigt wird.

Autor: AVRli .. (avrli)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Dafür braucht man ein 7" TFT?

Ja! Wenn man nicht mehr richtig sehen kann, muss alles etwas größer 
ausfallen.

m.n. schrieb:
> Welche Farbtiefe willst Du denn verwenden? 16 Bit?

Ja dieses 5-5-6 Format. Zwei freie Ports nur für das Display sind 
vorhanden.

m.n. schrieb:
> Du kannst Dir ja einen Treiber für AVR schreiben und dann sehen, welche
> Zeit bei 800 x 480 Bildpunkten benötigt wird:

Ich glaube das ist der richtige Ansatz! Das werde ich beherzigen und 
dann sehen ob ich mich habe von einen "Leistungswahn" habe verrückt 
machen lassen oder ob ich wirklich mehr LEistung benötige.

m.n. schrieb:
> Und nicht vergessen, zu jedem Bildpunkt zuvor die
> Zeile und die Spalte auszugeben.

Hmm, beide favorisierten Chips haben wenigstens ein Auto- Inkrement, 
damit sollte ich hier einen Geschwindigkeitsvorteil haben, weil die 
Position-Information nicht bei jeder Pixelausgabe benötigt wird.

Ich organisiere mir mal so ein 7" Display um genaueres sagen zu können.

Gruß AVRli...

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein 7" Display direkt mit einem AVR ansteuern zu wollen ist natürlich 
völliger Quatsch. Vielleicht kriegt man es hin, dass da mal ein Bild 
angezeigt wird, aber man wird sich immer einen Krampf programmieren 
müssen, damit es stabil funktioniert und am Schluss wird der 
Bildschirminhalt so aussehen wie eine Webseite aus den 90er Jahren. 
Sprich, sowas will kein Mensch haben.

Wenn Du das unbedingt mit einem AVR machen willst, dann brauchst Du ein 
"ingelligentes" Display, also z.B. sowas 
https://www.glyn.de/Produkte/Mikrocontroller/A-D-A-M-Intelligentes-Display
welches die ganze Schwerarbeit selber erledigt. Dieses arbeitet mit dem 
FTDI EVE Chip.
https://www.ftdichip.com/EVE.htm

Aber wie viele hier schon berichtet haben; es empfiehlt sich für solche 
Anwendungen, einen besseren Mikrocontroller zu benutzen.
Als Einstieg wäre sowas sicher nicht schlecht:
https://www.glyn.de/Produkte/Displays/Smart-Embedded
Auf diesem Eval-Kit ist ein STM32F746 verbaut.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVRli .. schrieb:
> Ja! Wenn man nicht mehr richtig sehen kann, muss alles etwas größer
> ausfallen.

Da sind wir doch beim Thema ;-)
Beachte bitte, daß ein 7" TFT unabhängig von der höheren Auflösung etwa 
die gleiche Höhe wie ein 5,7" (QVGA 320 x 240) hat, nur eben breiter 
ist. Was bei Displays geringer Auflösung noch schnell geht, da diese gut 
ablesbar sind, braucht bei feinerer Auflösung deutlich mehr Zeit.
Um ein gesetztes Pixel von einem Staubkorn zu unterscheiden, ist es 
daher sinnvoll, es auf 2x2 oder 3x3 'aufzupusten', wenn man keine Lupe 
zur Hand hat.
Auf einem 12" Monitor bei 256 x 192 Pixel Auflösung ist ein einzelnes 
Pixel schon größer, wenn man sich an die alten Zeiten erinnern mag ;-)

Das von Dir angesprochene MD070SD benötigt allein zur Ausgabe der 
Adresse neun Ausgaben ans Display, die im "Datenblatt" als Beispiel 
für den 8051 als Funktionsaufrufe aufgeführt sind. Das dauert doch ewig!
Natürlich wird man die Ausgabe nach Möglichkeit so organisieren, daß 
nachfolgende Pixel mit Autoinkrement ausgegeben werden, aber dennoch 
werden z.B. bei Schriftzeichen immer wieder neue Zeilen angewählt werden 
müssen, die eine komplette Adressvorgabe benötigen.

Besser sieht erst dann aus, wenn ein Controller wie der oben genante 
FT8xx verwendet wird. Der hat interne Schriften in diverser Größe, die 
er eigenständig zeichnet. Das geht dann auch mit einem 8 Bitter halbwegs 
schnell. Mir persönlich gefallen diese Teile nicht, da der Zeichensatz 
nicht vollständig ist und die vorhandenen Symbole 'weichgepült' 
aussehen. Beispiel Einkaufszentren: kennst'e eins, kennst'e alle.

Johnny B. schrieb:
> Als Einstieg wäre sowas sicher nicht schlecht:
> https://www.glyn.de/Produkte/Displays/Smart-Embedded
> Auf diesem Eval-Kit ist ein STM32F746 verbaut.

Verrate uns noch den Preis.
Ich plane gerade eine Leiterplatte mit STM32H750. Da reicht der interne 
Speicher auch für 800 x 480.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Johnny B. schrieb:
>> Als Einstieg wäre sowas sicher nicht schlecht:
>> https://www.glyn.de/Produkte/Displays/Smart-Embedded
>> Auf diesem Eval-Kit ist ein STM32F746 verbaut.
>
> Verrate uns noch den Preis.
> Ich plane gerade eine Leiterplatte mit STM32H750. Da reicht der interne
> Speicher auch für 800 x 480.

Den Preis kenne ich nicht, aber wahrscheinlich als Eval-Kit nicht ganz 
so günstig. Ich frage mal an, es interessiert mich selber.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Den Preis kenne ich nicht, aber wahrscheinlich als Eval-Kit nicht ganz
> so günstig. Ich frage mal an, es interessiert mich selber.

Frag auch gleich mal, wo man das bekommt, Glyn macht eher nur B2B.

Ich arbeite gerade mit so einem:
https://www.digikey.de/products/de?keywords=EVE2-70G

Klar schreckt der Preis erstmal ab, das ist aber auch ein ganz anderer 
Level an Qualität als der China-Ramsch mit resistiv-touch.

Autor: Michael K. (Firma: Knoelke Elektronik) (knoelke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> ist aber auch ein ganz anderer
> Level an Qualität als der China-Ramsch

Das wird nämlich im Schwarzwald von hochqualifizierten Dipl. 
Kuckuksuhrbauern in Handarbeit hergestellt ...

Aufwachen bitte.
Fast alles von dem Kram kommt bereits aus China.
Das wir so geizig sind deren Ausschussproduktion über Alibaba 
abzukaufen, statt qualitätsgeprüfter Distributionsware, dafür können die 
nix.

Schau Dir China mal genauer an.
Da bleibt Dir das Lachen im Hals stecken wenn du siehst mit welchem 
Investitionvolumen die in Richtung Technologie und Qualität preschen.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
m.n. schrieb:
> Dafür braucht man ein 7" TFT?

Natürlich! Manche aktuelle Navis haben schließlich auch 17" Displays. 
Wenn wir schon untergehen, dann möglichst dekadent.

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Das wir so geizig sind deren Ausschussproduktion über Alibaba
> abzukaufen,

Na, das meinte ich doch mit China-Ramsch, die Reste vom Grabbeltisch, 
übrig gebliebene Ware von vor X Jahren.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph schrieb:
> Johnny B. schrieb:
>> Den Preis kenne ich nicht, aber wahrscheinlich als Eval-Kit nicht ganz
>> so günstig. Ich frage mal an, es interessiert mich selber.
>
> Frag auch gleich mal, wo man das bekommt, Glyn macht eher nur B2B.

Ich denke diese wurden speziell für Glyn entwickelt und sind nicht über 
andere Kanäle erhältlich.

Also das 7" Evalkit kostet um die USD 310.-
Wenn man ein paar hundert Stück abnimmt kosten die dann etwa die hälfte 
davon.

> Klar schreckt der Preis erstmal ab, das ist aber auch ein ganz anderer
> Level an Qualität als der China-Ramsch mit resistiv-touch.

Aus Fernost kommt eh alles, aber Du hast recht. Vorallem die lange 
Verfügbarkeit kostet richtig Geld. Aber es lohnt sich, wenn man ein 
langlebiges Produkt für die Industrie entwickelt.

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Also das 7" Evalkit kostet um die USD 310.-

Wenn man ohne große Vorarbeit (Layout) mit der Programmentwicklung 
beginnen möchte, ist der Preis doch kein Problem.
In der Serie wird man sich das Board auf die eigenen Bedürfnisse 
anpassen, wobei Glyn dann gerne die TFTs verkauft. Diese sind so 
angelegt, daß von 3,5" - 7" die gleiche 40-pol. Steckverbindung 
verwendet wird. Gleiche Schaltung, anders Display: kein Problem.

Rudolph schrieb:
> Ich arbeite gerade mit so einem:
> https://www.digikey.de/products/de?keywords=EVE2-70G
>
> Klar schreckt der Preis erstmal ab,

Auch der Preis schreckt nicht ab, wenn man µCs kleinerer Leistung 
verwendet und ein gebrauchsfertiges Modul (inkl. Frontrahmen) benötigt. 
Die Dokumentation dazu fehlt wohl noch?

Autor: Rudolph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
>> Klar schreckt der Preis erstmal ab,
>
> Auch der Preis schreckt nicht ab, wenn man µCs kleinerer Leistung
> verwendet und ein gebrauchsfertiges Modul (inkl. Frontrahmen) benötigt.

Aber schon, wenn man glaubt das geht für unter 20 Euro.

> Die Dokumentation dazu fehlt wohl noch?

Hmm, okay, da hat Digi-Key wohl versagt.

https://www.matrixorbital.com/ftdi-eve/eve-ft812
https://www.matrixorbital.com/ftdi-eve/eve-ft812/eve2-70g
https://brtchip.com/ft81x/

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich halte diese "intelligenten" Display-Controller (FT81x, Nextion, ...) 
mit integrierter Rendering-Funktion für ziemliche Krücken - nur dazu da, 
um auf leistungsschwachen Controllern Grafikfunktion nachrüsten zu 
können. Diese intelligenten Displays enthalten ja dann doch einen 
ausreichend leistungsfähigen Prozessor für die Grafikfunktion, welchen 
man dann vom schwachen Controller aus ansteuert. Warum nicht alles 
zusammen auf einen großen, leistungsfähigen Controller integrieren? Eine 
Software auf zwei Controller aufzuteilen ist m.M.n in vielen Fällen eine 
Kapitulation vor der Software-Integration - wenn man es nicht schafft 
Grafik-Rendering und sonstige Anwendung in eine Software zu integrieren, 
behilft man sich durch Kauf eines Controllers mit vorhandener Software.

Die optimale Lösung ist hier ein Controller welcher direkt ein 
paralleles LCD-Interface ("RGB") bietet, wie die genannten STM32 und 
auch viele SoC. Hierbei kann man in der eigenen Software das Bild in den 
internen SRAM, oder ggf. externen SDRAM rendern. Der LCD-Controller gibt 
dieses Bild gleichzeitig und kontinuierlich auf dem LCD-Interface aus, 
mit "beliebigem" Pixeltakt (z.B. bis 54 MHz bei 24bit RGB-Farbe beim 
STM32F429). Solange sich das Bild nicht ändert, verursacht dies 
keinerlei Prozessorlast. Man kann mit großer Geschwindigkeit neue 
Bildinhalte berechnen und flüssige GUIs und sogar auch Videos ausgeben. 
Man ist letztlich nur durch den internen Prozessorbus und den 
Prozessortakt beschränkt - aber die sind skalierbar durch Auswahl 
größerer Prozessoren, d.h. dieser Ansatz skaliert quasi beliebig.

Das einzige Problem ist hierbei, dass man eine Software braucht um die 
GUI (und Schriften) darzustellen. Das kann man selber machen (schöne 
Übung) oder auch eine fertige Bibliothek benutzen (z.B. emWin, Qt, ...). 
Letztlich erhält man so:
- Maximale Flexibilität - man kann die gesamte Software nach eigenen 
Wünschen anpassen, und nahezu beliebige Panels nutzen; es gibt sogar 
Adapter-ICs auf MIPI-DSI oder HDMI, man ist nicht auf einen 
intelligenten Controller festgenagelt; durch Austausch des 
Low-Level-Treibers (ca. 200 LoC) kann man das ganze System simpel auf 
komplett andere Controller und komplett andere Displays portieren
- Maximale Performance - Bildinhalte lassen sich so schnell ändern wie 
das LCD-Panel erlaubt, es entfallen alle Wrapper für den externen Bus, 
das Setzen eines Pixels ist äquivalent mit dem Schreiben von 24bits in 
den RAM (1 Speicherzugriff)
- Wahrscheinlich auch noch geringster Preis - externer Controller 
entfällt, SDRAM ist billig
Das funktioniert nur dann nicht, wenn man spezielle Anforderungen an den 
Controller hat, welche von LCD-fähigen Controllern wie dem STM32F429 
nicht erfüllt werden. Die Verwendung des LCD-Interface ist überraschend 
simpel, vielleicht sogar simpler als die Ansteuerung von SSD1963 o.ä.

In Zeiten günstiger und für Bastler verfügbarer leistungsfähiger 
Controller wie eben STM32 sollte man sich so etwas nochmal überlegen.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Das einzige Problem ist hierbei, dass man eine Software braucht um die
> GUI (und Schriften) darzustellen.

ST hat sich kürzlich die Firma einverleibt, welche TouchGFX entwickelt 
und vertrieben hat. Es ist nun kostenlos verfügbar:
https://www.touchgfx.com/
Habs aber selber noch nie eingesetzt. Hat jemand von Euch Erfahrungen 
damit?

Autor: m.n. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Diese intelligenten Displays enthalten ja dann doch einen
> ausreichend leistungsfähigen Prozessor für die Grafikfunktion, welchen
> man dann vom schwachen Controller aus ansteuert. Warum nicht alles
> zusammen auf einen großen, leistungsfähigen Controller integrieren?

Ganz einfach: bei Einzel- und Kleinstückzahlen hat man kalkulierbare und 
niedrige Kosten. Daß mir diese FT8xx nicht gefallen, sagte ich ja 
bereits. Aber wenn ein Kunde auf die Schnelle ein hochaufgelöstes TFT 
für Datenausgabe und grafische Darstellung braucht, hätte ich damit 
keine Berührungsängste. Der steuernde Prozessor kann ja trotzdem ein 
M4/M7/H7 sein.

Dann gibt es noch einen Punkt, warum ein separates Display vorteilhaft 
sein kann: Bei einer Steuerung wird man den µC nebst Peripherie 
möglichst auf einer Leiterplatte unterbringen und in ein Gehäuse packen, 
welches günstig im Gerät platziert wird.
Das Display (Bedienteil) muß für den Benutzer günstig angeordnet werden, 
was durchaus mit 1 m Leitung von der eigentlichen Steuerung entfernt 
sein kann. Mit einer schnellen seriellen Verbindung hat man keine 
Probleme diese Strecke zu überbrücken. Das TFT über das parallele 
Interface anzusteuern wäre ungeschickt.

Autor: FloMann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte FTDI's Eve weiterhin von Interesse sein werfe mal ein Blick
auf die Displays von newhaven (bei Mouser zu bekommen).
Hab mir dieses zugelegt, MVA Panel, noch gut hell, Kapazitiver Touch.
https://www.mouser.de/ProductDetail/Newhaven-Display/NHD-70-800480FT-CSXV-CTP?qs=sGAEpiMZZMve4%2fbfQkoj%252bFsUY5UPqiIIl6FeNDbTLR0%3d

War es mir soweit auch Wert gibt aber auch etwas preiswertere 
Alternativen
mit einfachen TN Panel und oder Resitiven Touch.

Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Ganz einfach: bei Einzel- und Kleinstückzahlen hat man kalkulierbare und
> niedrige Kosten.

Und bei Parallel-RGB-Displays nicht? Auch da gibt es fix und fertig 
aufgebaute Eval-Boards. Man muss nur 1x den Treiber für den 
LCD-Controller und eine Grafikbibliothek einbinden. Erlernen muss man 
den Umgang mit der Bibliothek genauso wie den Umgang mit FT8xx. Für 
letzteren braucht es ja sogar auch eine Bibliothek, die aber nichts 
selber tut sondern nur weiter reicht.

m.n. schrieb:
> Das TFT über das parallele
> Interface anzusteuern wäre ungeschickt.

Das stimmt. Aber auch hier kann man einen eigenen Controller direkt ans 
Display anbinden und beide Controller per UART u.ä. verbinden. Dann kann 
man die GUI beliebig selbst gestalten - mit Bibliothek oder ohne - und 
tauscht über die serielle dann nur noch die Nutzdaten aus. Das ist sogar 
effizienter, denn man muss die Nutzdaten nicht mehr in Grafikbefehle 
verpacken. Man kann so beliebig flüssige und anspruchsvolle GUIs auf dem 
eigenen Grafik-Controller umsetzen deren Geschwindigkeit von der 
seriellen Schnittstelle komplett unabhängig ist. Der Prozess-Controller 
"im" Gerät kann dann je nach Bedarf auch ein sehr kleiner oder 
spezieller sein; er braucht nur eine serielle Schnittstelle, aber 
nichtmal genug RAM um komplexe Grafikbefehle abzulegen bzw. 
zusammenzubauen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.