@Mods:
Bitte nach µC verschieben. Danke.
Edit: Danke Sam

@Topic
Hallo lord_fritte, erstmal willkommen im Forum .

Sowas ist machbar, wenn auch nur eingeschränkt.
Wenn du etwas vom Programmieren verstehst, z.B. im Mikrokontrollerbereich, dann ist das noch einfacher, als es diskret zu probieren.

Erstmal sind die Pixel nicht direkt ansteuerbar, da dieser Kontroller schon eine Ebene höher arbeitet und als Daten ASCII-Zeichen haben möchte. Die stellt er dann, anhand eines eigenen Char Generators (Zeichengenerator-ROM) auf dem Display dar.
Allerdings, und das dürfte dir in diesem Fall helfen, sind 8 Byte dieses Zeichengenerators in einem RAM gemappt, den man selbst beschreiben kann. Klartext: 8 Zeichen können definiert werden, und zwar mithilfe von Bitmustern. Setzt man dort eine 1 an einer bestimmten Position, wird das entspr. Pixel angeschaltet, andernsfalls bleibt es aus.


Mist, sobald man mal ausführlicher schreibt, sind andere schneller ...


_________________


[ Diese Nachricht wurde geändert von: DonComi am 21 Jun 2008 14:33 ]

Zitat :

Mist, sobald man mal ausführlicher schreibt, sind andere schneller ...

Dafür hat Deine Erklärung mehr Details

Hallo also ich habe vor einen Fortschrittsbalken in der 2. Zeile darzustellen.
Dazu habe ich vor einmal außenrum einen Rahmen darzustellen, dies soll den leeren Fortschrittsbalken darstellen:
#####....#####
# #
# #
#####....#####

Und je nachdem wie voll er wird, werden die Zeichen immer weiter augefüllt:
#####....#####
### #
### #
#####....#####

usw.

Aber wenn es nicht geht oder zu aufwendig ist, dann muss ich eben mit ASCII Zeichen arbeiten, sieht zwar nicht schön aus aber was will man machen.

[ Diese Nachricht wurde geändert von: lord_fritte am 21 Jun 2008 15:41 ]

Hallo genausowas habe ich grade gemacht.

Das Problem, dass du hast: es sind maximal 8 Bytes erlaubt.

Ich habe folgende Bytes genommen, damit es klappt:

1. [ Begrenzung auf einer Seite
2. ] Begrenzung auf der anderen Seite
3. Strich oben/unten, sonst leer
4. ein |
5. zwei ||
6. drei |||
7. vier ||||
8. fünf |||||

Damit habe ich eine ordentliche ProgressBar gezaubert. Allerdings läuft das Programmmodul dazu auf einem Prozessor, der hervorragend mit großen Zahlen rechnen kann, denn es sind Multiplikationen und Divisionen/Modulodivisionen notwendig.

Die kompliziertere Version bekommt nur noch eine struct, anhand derer sie dann die Progressbar auf dem Display zeichnet. Damit kann man viele machen, die auch die Skalierung selbstständig übernehmen.

Finde grade die Kamera nicht.

Edit

Zitat :

Aber wenn es nicht geht oder zu aufwendig ist, dann muss ich eben mit ASCII Zeichen arbeiten, sieht zwar nicht schön aus aber was will man machen.

Wieso, wir haben doch gesagt, dass es geht! Nur eben mit maximal 8 selbstdefinierten Zeichen.


So sehen die entsprechenden Daten dazu aus:

Code :

static const unsigned char prgData[] PROGMEM = { 0x1F,0x00,0x00,0x00,0x00,0x00,0x1F,0, 0x1F,0x00,0x10,0x10,0x10,0x00,0x1F,0, /* | */ 0x1F,0x00,0x18,0x18,0x18,0x00,0x1F,0, /* || */ 0x1F,0x00,0x1C,0x1C,0x1C,0x00,0x1F,0, /* ||| */ 0x1F,0x00,0x1E,0x1E,0x1E,0x00,0x1F,0, /* |||| */ 0x1F,0x00,0x1F,0x1F,0x1F,0x00,0x1F,0, /* ||||| */ 0x01,0x01,0x01,0x01,0x01,0x01,0x01,0, /*| */ 0x10,0x10,0x10,0x10,0x10,0x10,0x10,0 /* | */ };

_________________


[ Diese Nachricht wurde geändert von: DonComi am 21 Jun 2008 15:46 ]

Hier sieht man das, was ich meinte.
Edit: Die Software ist aber noch nicht fertig. Z.B. sind die "Grafiken" noch garnicht richtig beschriftet. Geht hier eher um die ProgressBar.
Eine einfacherere Version, die ohneviel Skalierung und Rechnerei auskommt, ist die, die nur exakt ein Balkendiagramm zeichnet. Dabei wird das meiste vom Präprozessor ausgerechnet, während hier der Prozessor erst zur Laufzeit die Grafik skaliert und berechnet. Wie gesagt, der Prozessor macht das mit links, aber die AVRs brauchen i.d.R. länger, wenn sie keine Hardwaremultiplikation erlauben.



_________________


[ Diese Nachricht wurde geändert von: DonComi am 21 Jun 2008 15:58 ]

Hallo, danke das werde ich mir mal ansehen.
Also ich mache die Programmierung eh Software technisch unter Windows mit einem 2GHz DualCore, also sollte die Prozessorleistung kein Problem darstellen.

EDIT: Genau so stelle ich mir das auch vor.

[ Diese Nachricht wurde geändert von: lord_fritte am 21 Jun 2008 15:56 ]

Na dann ist das ja kein Problem. Hier steuert halt kein 2GHz Dualkoreprozessor das Display sondern ein kleiner Mikroprozessor...

_________________

Oder ich überlege ob ich nicht doch schon eine fertig Software wie LCDSmartie verwende.

Wenn die alles kann, was man will, könnte man drüber nachdenken.
Ich würde es selbst machen, aber das ist Einstellungssache.

_________________

Zitat : DonComi hat am 21 Jun 2008 16:10 geschrieben :

Wenn die alles kann, was man will, könnte man drüber nachdenken. Ich würde es selbst machen, aber das ist Einstellungssache.

Ja ich hatte mich schon bisschen damit beschäftigt, aber mit C# bekomme ich reingarnichts auf Display, keine Ahnung warum.

Mit C# kenn ich micht nicht aus.

Ich würde einen Treiber unter Windows benutzen, den in ein C++-Programm einbinden und alles in C++ schreiben, oder eben in C. Aber C macht eigentlich keinen Sinn, wenn man eine Oberfläche zur Verfügung hat, es sei denn, man benutzt Unix oder ähnliche.


_________________

Also C# ist eigentlich eine ganz schöne Sprache, ist im Grunde C++ ziemlich ähnlich.
Mit DLLImport kann ich auch die dlportio.dll nutzen.
Aber hast du vielleicht auch ein kleines Beispiel wie man deinen prgData Array benutzt?

Hallo,

Das sind die Bitmuster, die benutzt werden, um die ProgressBar (Balkendiagramm hätte man vor zehn Jahren gesagt zeichenweise zeichnen zu können.

Schau dir mal im Datenblatt an, was die einzelnen Bytes jeweils zu sagen haben:


0x1F ist binär (000)11111 als Byte. Die Adressen für je ein neues Zeichen sind jeweils immer 8 Bit von der vorherigen vorhanden, also Zeichen 0 liegt im RAM von 0x00 bis 0x07. Ab 0x08 folgen dann die nächsten Bytes für das nächste Zeichen.

Der Übersicht und Sauberkeit halber habe ich je 8 Bytes jeweils in eine Zeile geschrieben, am Anfang jeder Zeile ist das Bitmuster für die erste Reihe eines Zeichens:
0x1F ist binär 11111, und wie oben erwähnt bedeutet eine 1 ein angeschaltetes Pixel.
0x00 heißt alle Pixel aus. Die oberen drei Bits sind egal, da ja pro Zeile nur 5 Pixel vorhanden sind.

Um dann diese definierten Zeichen auch ausgeben zu können, schreibt man entsprechende Zeichen mit den Codes 0 - 7, und erhält dann diese Bitmuster auf dem Display.

Einen Quelltext kann ich dir sinnigerweise nicht geben, aber es müssen erstmal Routinen her, die das Display unter Kontrolle haben. In meinem Fall gibts also eine Routine, selbstgeschrieben, die lcdPut(char *, unsigned char); genannt wurde.
Sie akzeptiert binäre Daten bzw. orientiert sich nicht an Terminatoren (wioe es im Fall des Zeichenkodes 0 der Fall wäre) sondern an der Länge der Daten.

Bevor man die 64 Bytes in einem Rutsch in den Zeichengenerator schreibst, muss man vorher aber festlegen, dass die folgenden Daten dort hinkommen.
Dazu führt man einen entsprechenden Befehl aus, in meinem Triber heißt der lcdCommand(SET_GC_ADDR). Dann werden die 64 Byte geschrieben
lcdPut(prgData, 64);
und danach wird wieder in den normalen Modus umgeschaltet.

Achso, lass dich nicht von den anderen Angaben wie static und PROGMEM beeinflussen, die sind bei AVRs dann notwendig, wenn man aus dem Flash lesen will. Das ist hier aber nicht der Fall, das PROGMEM nur ein Leermakro.

Edit: Verzeih die kleineren Fehlerchen - komme grad von nem Ball wieder und bin dermaßen müde...

_________________


[ Diese Nachricht wurde geändert von: DonComi am 22 Jun 2008  0:49 ]