Was soll das?


Erstmal verschweigst du komplett, um welches Board und somit Controller es sich handelt. Weiterhin ist die Begrifflichkeit "Grafisches Display" sehr inexakt.
Zweitens bringst du eine völlig ungeeignete Sprache ins Spiel, vergiss Java und benutze was anständiges. Das ist aber auch abhängig davon, was es für ein Display ist: hat es einen Controller, und wenn ja, welche Art von Interface? Wie groß ist es und wieviel Bit Farbtiefe hat es? Wenn ein Framebuffer notwendig ist, hast du eine Ahnung, wie du das überhaupt machen musst?
Nachdem diese Fragen beantwortet sind, kann geklärt werden, welche Sprache und welcher µC dafür geeignet sind; grundsätzlich rate ich für solche Sachen von Java und ähnlichen Spielereien für Fünftklässler ab, von Basic mal ganz zu schweigen...

_________________

Zitat : DonComi hat am 29 Dez 2008 23:37 geschrieben :

Zweitens bringst du eine völlig ungeeignete Sprache ins Spiel, vergiss Java und benutze was anständiges.

Es gibt Sprachen, die wurden bestimmt nur von den CPU-Herstellern erfunden, damit sie nächstes Jahr wieder eine schnellere CPU auf den Markt bringen können.
Das mal für die, die alles mit Java erledigen wollen.

Na gut, Java kommt von Sun Microsystems und wurde als Plattform
übergreifende Sprache entwickelt.

Wenn Rambodischien unbedingt Java benutzen will, soll er es eben tun.
Jedem eben sein pläsierchen.

Für Java gibt es aber auch einige Prozessoren, die den Bytecode ausführen
können.

http://de.wikipedia.org/wiki/Java-Prozessor

Für die IP-Cores muss man sich vorher noch mit progammierbarer Logik
beschäftigen (FPGA).

MfG
Holger

_________________
George Orwell 1984 ist nichts gegen heute.
Der Überwachungsstaat ist schon da!

Leider lernen die Menschen nicht aus der Geschichte,
ansonsten würde sie sich nicht andauernd wiederholen.

Wir wissen ja bis jetzt nichtmal, welche Zielarchitektur und was drumrum laufen soll.
Ich habe auch nichts gegen Java gesagt, aber es ist für sowas hardwarenahes eher ungeeignet, auch wenn es Compiler gibt, die ausführbaren Code erzeugen können.

Für sowas existiert seit Jahrzehnten C als leicht abstrakte Assemblersprache. Wozu Java? Deren Existenz basiert wohl eher auf Scripten und Frontendanwendungen.

_________________

Ich vermute er meint das hier:
http://www.jcontrol.org/index_de.php

_________________

Hallo

Ich entschuldige mich für die chaotischen Angeben, war an diesem Tag ein wenig .

Ich wollte mir ein grafisches Display zulegen, jedoch vorher wissen ob das mit JAVA eine gute Idee ist (anscheinend nicht).

Ich habe keinerlei Erfahrung mit dem Programmieren eines grafischen Displays. Wie oben schon erwähnt möchte ich eigentlich wissen mit welcher Programmiersprache so ein Display am einfachsten zu Programmieren ist.

Geht das mit der Programmiersprache C?

Will zudem im laufe meiner Programmierkenntnisse ein Diagramm oder sogar einen Kompass oder ähnliches Ausgeben.

Danke und einen guten Rutsch ins neue Jahr!!!

_________________
Mfg Rambodischien

Heute wieder ein schlechter Tag, oder was?

Zitat :

was es für ein Display ist: hat es einen Controller, und wenn ja, welche Art von Interface? Wie groß ist es und wieviel Bit Farbtiefe hat es? Wir wissen ja bis jetzt nichtmal, welche Zielarchitektur und was drumrum laufen soll.

C geht sozusagen immer.
Die Frage ist nur, wie gut du C beherrscht umd effizienten, schnellen Kode zu kodieren und wie komplex das Display ist; es gibt ganz einfache mit z.B. 24*94 Pixeln á 1 Bit, also an oder aus pro Pixel. Das ist auch ein grafisches Display, genauso wie das 1024*768*8 Bit Farbauflösung... Daher die Frage.

Die Frage ist auch, wie gut der Controller mit eigenen Treibern kontrolliert wird und wie übersichtlich die Softwareschnittstelle zum Setzen eines Pixels, zum Senden von definierten Kommandos, zum rudimentären Zeichnen von Linien, Rechtecken und evtl. Kreisen.

Je nach Ressourcen lohnt es sich, eine Art Framebuffer anzulegen: Dazu wird das Bild im RAM zusammengesetzt, es muss nicht nach jeder Rechnung, wie Pixel für eine Linie von a nach b gesetzt werden müssen, das Display-RAM neubeschrieben werden, sondern erst im eigenen RAM alles berechnen und dann ausgeben (engl. flush). Ist aber die Farbtiefe groß und die Auflösung noch größer reicht AVR-RAM i.d.R. nicht mehr aus und man muss den Grafikspeicher jedes mal auslesen; es sei denn, er unterstützt schon solche Zeichenfunktionen. Daher ist die Frage nicht leicht zu beantworten, es kann sehr leicht bis sehr schwer werden...

Offtopic :

Edit: Ich bitte um Verzeihung, ab und zu fehlen mal Worte oder der Satz ist unvollständig. Habe sozusagen die Nacht durchrenoviert und war heute morgen schon früh auf den Beinen, um Gips und Feuerwerk zu kaufen...

_________________


[ Diese Nachricht wurde geändert von: DonComi am 31 Dez 2008 13:09 ]

Erst einmal wünsche ich allen ein gutes neues Jahr 2009

So nun zum Thema.

Ich hätte nicht gedacht, dass das so kompliziert sein würde (deshalb die allgemeinen Fragen).

Ich werde mich ein wenig nach einem Display umsehen und dann die Fragen auf das Display beziehen.

Danke nochmals

_________________
Mfg Rambodischien

Ich glaube, daß Du die Frage ein bißchen falsch stellst!

Handelsübliche Displays, egal ob sie Text oder Punkte (=Grafik) darstellen, machen in der einfachsten Form nichts anderes als das was ihnen rübergeschickt wird auf dem Schirm darzustellen.

Dazu haben sie einen internen Speicher, der die Anzeigedaten enthält (machmal ist dieser auch etwas größer und man kann im Hintegrund noch eine oder einige Seiten speichern). Des weiteren eine definierte Schnittstelle über die die Daten in diesen Speicher gelangen. Bei den Graphikdisplays muß man meist jedes einzelne Pünktchen einzeln ansteuern, d.h. es ist oft nicht einmal ein Zeichensatz vorhanden.
Üblich sind auch noch einige Steuerkommandos um z.B. die Anzeige zu löschen usw.

Es geht also nicht darum, ein Display zu programmieren. Da ist meist nichts zu programmieren! Es geht viel mehr um eine Hardware und ein Programm zu erstellen, die dieses Display ansteuert! Dessen mußt Du Dir bewußt werden. Es ist dann so, wie es die anderen Kollegen schon beschrieben haben, daß Du im Speicher ein Feld aller Deiner dargestellten Punkte anlegen mußt, die Daten dort reinschreibst und sie ans Display schickst. Und wenn eben der Speicher nicht ausreicht, dann muß das eben in kleine nicht tödlichen Portionen passieren.

Kann sein, daß es mitlerweile einige Displays gibt, die einen Zeichensatz beinhalten und auch noch die eine oder andere Funktion zum Zeichen haben, aber grundsätzlich läuft es so wie geschildert.

Hätte ein s/w Graphikdisplay bei mir liegen. Hinten dran hängt noch eine kleine µC Steuerung für irgend ein Fitnessgerät. Ist aber so speziell, daß ich es in der Form zu nichts gebrauchen kann, obwohl es einige Digitale- und Analoge Ein- wie auch Ausgänge hätte, sowie eine serielle Schnittstelle. Wenn einer es schafft für den µC ein anderes Programm in den EPROM zu schreiben könnte man es sogar nutzen, ansonsten zumindest das Display.

Schöne Grüße Selfman

_________________
Traue keinem Ding, das du nicht selber vermurkst hast.

Hallo!

Hab mich selbst mal mit einem 128*64 LCD am 8031 beschäftigt, damals in Assembler. Auf dem Display sind 2 Controller, rechte und Linke Hälfte. Habe zuerst Routinen für Punktansteuerung entwickelt (Umschaltung zwischen den Controllern damit Pixel fortlaufend ansprechbar), darauf aufbauend für Linien, Recktecke leer und gefüllt,...
Zum Initialisieren, Löschen, Scrollen habe ich die Controller parallel beschrieben, das Auslesen, sofern nötig, muß natürlich einzeln erfolgen.

Es war kein Zeichensatz im Display vorhanden, den hab ich im Speicher Abgelegt wo die Umsetung von ASCII-Zeichen in Pixel erfolgte, welche mit zuerstgenannten Routinen direkt in den Displayspeicher geschrieben wurden. Extra Framebuffer im Controller war nicht sinnvoll, wegen einigen geänderten Pixel immer den ganzen Displayinhalt zu schreiben wäre zu langsam gewesen.

Hier mal was aus meiner Linksammlung:

LCD-Projekte
LCD Info

mfg lötfix

_________________
Haftungsausschluß:
Bei obigem Beitrag handelt es sich um meine private Meinung. Rechtsansprüche dürfen daraus nicht abgeleitet werden. Sicherheitsvorschriften beachten!


[ Diese Nachricht wurde geändert von: Lötfix am  1 Jan 2009 13:59 ]

Moin,

@Lötfix:
Ja, so ein Display habe ich auch; aus einem Kyocera-Drucker ausgebaut, mit EL-Hintergrundbeleuchtung.
Es besitzt auch zwei Controller, wie bei dir für links und rechts. Das Problem ist, dass man die Pixel nicht so schön linear beschreiben kann, man muss erstmal simple Basis-Routinen schreiben, die die automatische Selektion der Controller (also Displayhälften) und das lineare Beschreiben der Pixel möglich machen. Darauf basierend entstehen dann Funktionen, die Linien zeichnen können, indem sie die Pixel zwischen zwei Punkten interpolieren. Für sowas benötigt man nicht immer einen Framebuffer, denn wie gesagt dauert es lange, den kompletten Bildschirm rüberzukopieren, obwohl nur drei Pixel geändert wurden. Oft auch, weil die Schnittstellen ziemlich langsam sind. Viele vertragen nicht mehr als 2MHz Datenrate, was darin resultiert, dass man bei einigen Animationen nur bestimmte Frameraten erreichen kann.

Edit: Mit den 2MHz bin ich mir allerdings nicht so sicher... Kommt auf immer auf die Controller an.

_________________


[ Diese Nachricht wurde geändert von: DonComi am  2 Jan 2009 18:17 ]