Auf meinem Display (KS0108 an ATmega 32) kann ich Kreise, Linien usw.
anzeigen lassen aber bei der Darstellung von Texten komm ich einfach
nicht weiter. Um den Fehler zu finden müsste ich erst einmal wissen wie
so eine font-Datei funktioniert aber ich blicke da einfach nicht durch.
Wenn ich einen Text ausgeben will, kommt dieser an der richtigen
Position im Display aber statt Buchstaben nur irgendwelche Pixel. Aber
woher soll mein MC auch wissen wie z. B. ein "K" aussieht. Ist dafür die
font-datei zuständig? Oder hat der Controller intern eine ASCI-Tabelle
gespeichert und die font-Datei ist nur für die Schriftart? Sind die
Hexadezimalzahlen in der Font-Datei Koordinaten? Falls jemand den
Quellcode sehen möchte: Display.c ist meine main.c, in fontsoft.c ist
der Ausgabebefehl definiert und hercules ist eine meiner font-dateien.
...nimm dir mal eine Zeile (z.B. 31.) aus dem Array aus der Datei
hercules.c, schreibe die 16 Einträge als Binärzahlen untereinander...,
dann solltest du etwas erkennen...
dann schau dir das hier mal im Quellcode an
http://www.rinkydinkelectronics.com/library.php?id=45
es ist doch die Frage wieviele Pixel du für einen Buchstaben bereit
stellst und wie diese Pixel dann aufs Grafic Display gemalt werden
16x16 kommt mir ziemlich verschwenderich vor kann man machen bei sehr
vielen freien Pixeln, üblicherweise begrenzt man auf 5x8 Fonts.
Also ich versteh jetzt was die font-Datei bedeutet aber woher weiß der
MC auf welche Zeile er für welches Zeichen zugreifen muss. Z.B. dass
Zeile 20 ein "B" ist.
Matthias schrieb:> Danke schon mal für die schnellen Antworten aber ich weiß noch nicht so> ganz wie mich das jetzt weiterbringt.
An Font-Dateien gibt es viele - und es gibt ganz viele mehr oder weniger
gute Methoden, sowas aufzubauen. Also frag nicht "Wie ist eine
Fontdatei", sondern eher "Wie funktioniert genau DIESE Fontdatei".
Lade dir mal die Lernbetty von hier herunter. Dort kannst du sehen, wie
eine Font-Datei aufgebaut sein kann. Die funktioniert eben nur
zusammen mit den dazu passenden GDI, was du als Quelle dort auch
findest. Die Fonts, die ich der Lernbetty beigegeben habe, können
proportional sein, also ein 'i' ist schmaler als ein 'W' und trotzdem
ist solch ein Font relativ platzsparend. Ein passender Fontcompiler ist
übrigens auch dabei.
W.S.
Matthias schrieb:> aber woher weiß der MC auf welche Zeile er für welches Zeichen zugreifen > muss.
Z.B. dass Zeile 20 ein "B" ist.
B ist Ascii Zeichen 66. Wenn "B" auf Zeile 20 steht muss jedes Zeichen
mit einem Versatz von 46 zum Ascii-Code aufgerufen werden. Schau dir den
code an, der anhand des fonts ein einzelnes Zeichen malt. Er springt auf
den Anfang von Zeile 20 und setzt anhand von 2 for-Schleifen die 16 byte
in ein Zeichen auf dem display um.
Matthias schrieb:> Also ich versteh jetzt was die font-Datei bedeutet aber woher weiß der> MC auf welche Zeile er für welches Zeichen zugreifen muss. Z.B. dass> Zeile 20 ein "B" ist.
Die Zeichen sind im uC selbst als Folge von Binärzeichen gespeichert.
Die Zuordnung zwischen einer Folge von Binärzeichen ist willkürlich.
Dazu gibt es einen weit verbreiteten Standard namens "ASCII".
Das Zeichen 'B' z.B. hat die Bitfolge 01000010. Bitfolgen können aber
auch als Dezimal- oder Hexadezimalzahlen interpretiert werden. Das wäre
bei der gegebenen Bitfolge dezimal 66 oder 0x42.
Damit kann man einem Buchstaben eine Zahl zuordnen und umgekehrt.
Hosenmatz schrieb:> Die Zeichen sind im uC selbst als Folge von Binärzeichen gespeichert.> Die Zuordnung zwischen einer Folge von Binärzeichen ist willkürlich.> Dazu gibt es einen weit verbreiteten Standard namens "ASCII".>> Das Zeichen 'B' z.B. hat die Bitfolge 01000010. Bitfolgen können aber> auch als Dezimal- oder Hexadezimalzahlen interpretiert werden. Das wäre> bei der gegebenen Bitfolge dezimal 66 oder 0x42.>> Damit kann man einem Buchstaben eine Zahl zuordnen und umgekehrt.
damit malt man aber immer noch keine Pixel die wie ein 'B' aussehen auf
das Grafikdisplay.
Matthias schrieb:> Z.B. dass> Zeile 20 ein "B" ist.
...Zeile 20 ist kein "B"!
Matthias schrieb:> aber woher weiß der> MC auf welche Zeile er für welches Zeichen zugreifen muss.
...versuche die Funktion LCDSoftChar aus fontsoft.c zu verstehen -->
dort wird das Array mit den Bit-Mustern angesprochen. Es wird aus dem
ASCII des darzustellenden Zeichens der Start-Index für den Zugriff auf
das Array berechnet und dann das ganze Zeugs (für ein Zeichen)
ausgegeben.
Joachim B. schrieb:> Hosenmatz schrieb:>> Die Zeichen sind im uC selbst als Folge von Binärzeichen gespeichert.>> Die Zuordnung zwischen einer Folge von Binärzeichen ist willkürlich.>> Dazu gibt es einen weit verbreiteten Standard namens "ASCII".>>>> Das Zeichen 'B' z.B. hat die Bitfolge 01000010. Bitfolgen können aber>> auch als Dezimal- oder Hexadezimalzahlen interpretiert werden. Das wäre>> bei der gegebenen Bitfolge dezimal 66 oder 0x42.>>>> Damit kann man einem Buchstaben eine Zahl zuordnen und umgekehrt.>> damit malt man aber immer noch keine Pixel die wie ein 'B' aussehen auf> das Grafikdisplay.
Ja. Das hast Du ganz richtig festgestellt. Sehr gut!
Das alles hilft mir jetzt schon mal sehr das ganze zu verstehen. Vielen
Dank dafür. Aber falls noch jemand eine Idee hat warum bei mir die
Zeichen nicht richtig auf dem Display dargestellt werden wäre das super.
Mir wäre es zwar lieber den Fehler selbst zu finden aber einen kleinen
Schubbser in die richtige Richtung könnte ich gerade gut gebrauchen.
Da Du nun weißt, wie das mit den Fonts funktioniert, könntest Du die
Funktion im Debugger bis zu dem Schritt, bei dem die Pixel an das
Display weitergegeben werden, verfolgen.
Unklar ist, was Du nun tatsächlich auf dem Display siehst, wenn Du
"Hallo" ausgibst. Das könnte Hinweise geben.
Da Du Linien etc. korrekt zeichnen kannst, wird wohl die Schaltung in
Ordnung sein.
Damit wir gezielter Ratschläge geben können, wären mehr Informationen
hilfreich. Siehe den Artikel Netiquette. Lieber zuviel als zuwenig
Informationen.
Hosenmatz schrieb:> Da Du Linien etc. korrekt zeichnen kannst, wird wohl die Schaltung in> Ordnung sein.
...das wäre die nächste Frage, ob es wirklich so ist...?!
coder schrieb:> Hosenmatz schrieb:>> Da Du Linien etc. korrekt zeichnen kannst, wird wohl die Schaltung in>> Ordnung sein.>> ...das wäre die nächste Frage, ob es wirklich so ist...?!
Wieso die "nächste" Frage?. Sie ist ja in meinem Satz, den Du vor Deinem
zitierst, schon beantwortet. Warum die Frage zweimal stellen und
beantworten?
Falls Du aber sagen wolltest: "Das halte ich nicht für gegeben", dann
schreib das doch - und gib bitte die Gründe für Deine Skepsis an. Den
Grund, warum ich meine Aussage machte, habe ich ja auch angegeben. Kann
ja sein, dass Du konkrete Gründe für Deine Skepsis hast, die sich als
wahr herausstellen. Das Wort "wohl" relativiert meine Aussage ohnehin.
Im übrigen wirst Du bei nochmaligem Lesen des Beitrages feststellen,
dass ich, ausdrücklich mit Hinweis auf die Netiquette, um mehr
Informationen bat. Und in der Netiquette wird der Schaltplan
ausdrücklich erwähnt.
Was genau ist also der Sinn Deines Beitrages?
Hosenmatz schrieb:> Falls Du aber sagen wolltest: "Das halte ich nicht für gegeben", dann> schreib das doch
genau so ist meine Anmerkung zu verstehen!
Hosenmatz schrieb:> und gib bitte die Gründe für Deine Skepsis an.
im Quelltext sind zwar, einkommentiert, zwar die entsprechenden Befehle,
enthalten, aber der TO hat nicht geschrieben, dass er es auch wirklich
ausprobiert hat!
Da ich bei kurzem Überfliegen des Programms keinen offensichtlichen
Fehler sehe, sollte erst einmal dies ausprobiert werden, um sicher zu
gehen, dass die Hardware funktioniert...
Hosenmatz schrieb:> Das Wort "wohl" relativiert meine Aussage ohnehin.
die Ironie, die in diesem "wohl" steckt, habe ich schon bemerkt und
wollte den TO noch einmal mit der Nase darauf stoßen!
