Hallo zusammen,
ich habe eine Frage an die Grafik-Experten unter euch.
Ich plane ein Gerät mit Grafikausgabe. Das TFT-Display soll eine Größe
von 5" bis 7" haben. Die Grafikausgabe muss nicht schnell sein. Im
Prinzip Darstellung einiger Symbole,die ab und zu wechseln.

Ich habe mich etwas umgesehen und bin einmal auf den AT91SAM9261
gestoßen, der ja einen LCD-Controller on Chip hat. Und dann gibt es ja
externe Controller, wie z.B. den S1D13506.

Jetzt zu meiner Frage:
Was ist mehr Programmieraufwand. ARM9 mit Controller inside, oder
externer Controller und evtl. nur einen ARM7 oder gar nur einen dicken
AVR.


Ich muss dazu sagen, das ich bisher mit ARM9 oder ext. Grafikcontrollern
noch nicht gearbeitet habe. AVR behersche ich ganz gut, ARM7 habe ich
mal reingeschnuppert. Sollte kein Problem sein.

Platinen erstellen ist jetzt mal noch kein Thema, ich verwende dann
erstmal fertige Module.

Ich wollte das Ganze in C schreiben. Ist das bei ARM9 sinnvoll, oder ist
es besser,oder gar ein Muss, da ein Linux drunter zu legen?



Ich hoffe es ist einiger Maßen rüber gekommen, was ich meine. Bin auf
Eure Antworten gespannt!

Gruß

Hallo,
ich möchte noch einmal einen Versuch starten, ein paar Ratschläge und
Tipps von euch zu erhalten.

Gruß

Man nehme einen ARM9 mit Display Controller, schließe hier 1-2MB RAM an
und konfiguriert den Display Controller.
Nun kann der RAM mit RGB-Farben für jedes Pixes beschrieben werden.

Rechenbeispiel:
640 x 480 Pixes x 3 Farben = 900KB.

Also um das Display ein mal neu zu bemalen müssen 900KB Daten
generiert/kopiert werden.

Ohne ordentliche Grafikbibliothek (die in Linux schon drin ist) geht das
gähn langsam.

Die günstigen Displays haben alle keinen eigenen Speicher, der Refresh
geht über das RAM des Prozessors wenn er es gerade nicht benutzen
möchte.

Mehr Infos habe ich auch nicht, da ich selbst noch nie sowas
programmiert habe, sollte aber für eine erste Entscheidung helfen.

Also das geht entweder mit einer optimierten Graphikbibliothek, die in
Linux NICHT drin ist oder mit entsprechender Rechenleistung und Linux.

Fuer kleine Stueckzahlen (z.B. 1 Stueck ;-) wuerde ich die Linux Loesung
mit einem 200 MHz oder mehr Prozessor vorschlagen, denn eine gute
Graphikbibliothek kostet auch etwas Geld. Fuer eine Serienproduktion
wuerde ich eher einen ARM7 bemuehen mit 90% weniger Speicherbedarf als
ein Linux System, einem kleinen RTOS und wirklich optimierten
Graphiklibraries. Kleiner Tip, ein 200 MHz ARM9 unter Linux ist fuer
graphische Darstellung von Messkurven unter Linux mehr belastet als ein
ARM7 mit 50 MHz unter einem kleinen RTOS und kompakten Graphiklibraries.

falls die optimierte professionelle Option wirklich interessant ist
(kostet zwischen 5-10k Euro Software) lass es mich wissen, ansonsten
moechte ich (mal) keine Werbung machen.

Robert

Ein Optimist rechnet anders:

240 x 320 x 1Byte sind 76800Byte. Ein Byte/Pixel reicht völlig aus.
Damit sollte die Grafikausgabe kein Problem sein.

Es gibt aber auch LCD-Controller, die schon 80kB Bildspeicher intern
eingebaut haben. Für einfache Anwendungen durchaus geeignet.

Danke für die Antworten.

Ihr schreibt von Linux und RTOS. Meint Ihr, das Projekt könnte man nur
mit einem OS verwirklichen?
Ich hatte mir das jetzt so vorgestellt, ohne jetzt bis ins Detail genau
recherchiert zu haben, ob das funktioniert:
Ich würde alles in C schreiben wollen, da ich mich mit OS (noch)nicht
aus kenne.

Da ich nur so eine Art Icons darstellen will, würde ich erst einmal den
TFT einfarbig als Hintergrund "füllen".
Dann hatte ich mir gedacht die einzelnen Icons erstmal im BMP Format auf
dem PC erstellen und mit SD-Karte zum µC System. Dann das Icon auf
Addresse "XY" im Bildspeicher ablegen.


Könnte das so, oder so ähnlich funktionieren?


Gruß

Ich setze ein Fujitsu MB91F467D 32-Bit Microcontroller zusammen mit
einem Fujitsu Lime Grafikcontroller ein.

Der Microcontroller läuft mit 96MHz hat neben 1MB internen Flash 8MB
SDRAM und 8MB Flash, der Grafikcontroller hat 133MHz und 8MB RAM.

Ich habe kein Betriebssystem darauf laufen sondern alles rein in
C-Programmiert vollkommen ohne jegliche Grafiklibaries. Fonts und
Bitmaps werden einfach in BitArray Konvertiert und können dann in den
Flash abgespeichert werden. Für die Kommunkiaktion zum Grafikcontroller
gibt es einen Treiber der viele rudimentäre Funktionen wie z.B.
Blittern, Antialiasing, Kreise, Polygone etc. Zeichenen hergibt und das
auf 6-Layern. Es können sogar zwei Display gleichzeitig mit
verschiedenen Inhalten benutzt werden. Zu dem gibt es noch einen Video
eingang.

In meinem Projekt ist ein 5,7" Display mit 320*240 Pixeln mit
intigriertem Touchpanel(4-Wire) angeschlossen. Insgesamt sind 10 320*240
Pixel Bitmaps im Flash gespeichert (ca.3,5MB) diese werden über das
Blittern auf einen Display Layer geschrieben und dienen als Hintergrund.
Auf einem vorderen Layer werden dann die Dynamischen Objekte wie
Balkendiagramme, Meßwerte oder Pushbutton dargestellt.

Der Bildwechsel ist jenachdem wie er programmiert ist sehr schnell.

Man muss sich natürlich in C sehr viele Gedanken machen wie etwas
funktioniert (z.B. Bildrefresh von Messwerten) damit alles wie gewohnt
funktioniert, aber generell Funktioniert es. Der Mikrocontroller ist bei
mir relativ stark belastet (ca.60%), da viele weitere Komponenten wie
3*RS232, 6*PWM, 12*ADC, 6*ReloadTimer, 3*FreeRunTimer, 1*RealTimeClock,
zwei DMA Kanäle aktiviert sind. Zudem belastet der Touchscreen, der auch
über 4 Ports angeschlossen ist zusätzlich.

Ich mache mir oft gedanken ob ein Linux System nicht besser gewesen wäre
und komme zu dem Schluss "Nein". Für diese kompakte Anwendung in der ich
keine Ethernet, Server funktionen, hochkomplexe 3D-Grafiken benötige,
reicht es vollkommen aus. Zudem bin ich auf hohe Abtastraten angewiesen
(20µs bei den AD-Wandlern). Entwicklungszeit waren ca. 4-Monate.

Schau dir mal das Lime-Controller Board von Glyn (EVB-LIME) an. Das ist
relativ gut designed und kostet ca. 80€. Mit dem 32-Bit Mikro kostet die
Entwicklungsumgebung ca. 700€.

mfg