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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.