Hallo an alle Forumsmitglieder,
ich beschäftige mich beharrlich mit einem EA DOGXL 240-7 und bin in C
noch nicht sehr erfahren. Gleichwohl interessiert und wissbegierig.
Ich bin inzwischen soweit, dass mein Display ASCII-Codes bis zum 96.
Zeichen (hex7F oder Dezimal 127) anzeigt. Für Zeichen grösser Dezimal
128 zeigt es Kauderwelsch.
Mein Code zwingt mich in der Funktion LCD_String für die ASCII-Zeichen
den Typ const char anzugeben, ansonsten meckert der Compiler folgenden
Fehler an: invalid conversion from 'const char*' to 'unsigned char*'
[-fpermissive] LCD_string(8,10,"2");
Ich denke, dass genau hier das Problem liegt, denn ein const char kann
nur den maximalen Wert 128 annehmen. Sehe ich das richtig?
Der pointer zeigt - in arrays bin ich noch nicht wirklich zuhause - auf
ein übliches font-array, dessed Anfang wie folgt aussieht und von EA
stammt.
/*-----------------------------------------------------------|
|File: font_6X8.h |
|Date: August 2011 |
|Author: ELECTRONIC ASSEMBLY |
|Description:File including font data |
| |
|The file is build with EA USBSTICK-FONT |
|for more information, please go to |
|http://www.lcd-module.com/eng/pdf/zubehoer/usbstick-font.pdf|
|------------------------------------------------------------*/
/* font_6X8.FV' as include
the array starts with a 8 byte header:
1st Byte: 'F' first 2 bytes are always FV
2nd Byte: 'V' for FONT VERTICAL
3rd Byte: First code to define
4th Byte: Last code to define
5th Byte: Width of character in dots
6th Byte: Height of character in dots
7th Byte: Height of character in bytes
8th Byte: Bytes needed for each character (1..255)
or 0 for big fonts calculate WidthInDots * HeightInBytes
After that font data will follow */
#ifndef _FONT_6x8_H
#define _FONT_6x8_H
unsigned char font_6x8[] =
{
70, 86, 32, 128, 6, 8, 1, 6,
0, 0, 0, 0, 0, 0,
0x00, 0x00, 0x5F, 0x00, 0x00, 0x00, // hex geht auch!
// 0, 0, 95, 0, 0, 0,
0, 7, 0, 7, 0, 0,
20,127, 20,127, 20, 0,
usw.
Um das 4th byte habe ich mich in meinen späteren Versuchen nicht mehr
gekümmert, da es m. E. in meinem C-Code keine Rolle spielt. Mit höheren,
an die jeweilige array-Grösse angepassten Werten des 4th byte, war die
Ausgabe ebenso fehlerhaft. Sowie ich in dem array mehr als 128 Zeichen
definiere, entsthet der Kauderwelsch (dann für alle Zeichen) auf dem
Display.
Im Folgenden mein C-Code, mit dem ich die Ausgabe steuere. Und wie
gesagt, bis ASCII 0-127 ist alles korrekt angezeigt.
//-----------------------------------------------------
//Func: LCD_data(data)
//Desc: sends data to display
//-----------------------------------------------------
void LCD_data(unsigned char *data, unsigned int len)
{
DOGDATA;
while(len--)
dogSPIout(*data++);
}
//-----------------------------------------------------
//Func: LCD_string
//Desc: shows ascii character on screen
//-----------------------------------------------------
void LCD_string(unsigned char column, unsigned char page, const char
*str)
{
unsigned int pos_array;
LCD_position(column, page);
while(*str!= 0)
{
//calculate positon of ascii character in font array
//bytes for header + (ascii - startcode) * bytes pro char)
pos_array = 8 + (unsigned int)(*str++ - font_6x8[2]) * font_6x8[7];
LCD_data(&font_6x8[pos_array], font_6x8[4]); //Argument 1: Data to
send; Argument 2: len = width of char
}
}
//----------------------------------------------------------------------
-------
int main()
{
// Init-Code
initDDRB();
initDDRD();
//-------------------------Reset display
_delay_ms(200);
DOGRESET;
_delay_ms(2);
DOGRESETOFF;
_delay_ms(150);
//-------------------------
//-------------------------communication test - all pixel to on
DOGENABLE;
DOGCOMMAND;
dogSPIout(0xA9); // display enable (20, 0xA8); b/w.mode (0xA8);
disp active (0xA9)
dogSPIout(0xA5); // set all pixel on (18, 0xA4): on (0xA5)
_delay_ms(50);
dogSPIout(0xA4); // set all pixel on (18, 0xA4): off (0xA4)
//-------------------------
//-------------------------initialize display
LCDinit();
LCDClear();
//-------------------------Ausgabe der Testdaten
LCD_string(8,10,"2");
while (true) // Mainloop
{
}
return 0;
}
//----------------------------------------------------------------------
-------
//-----------------------------------------------------
//Func: LCD_data(data)
//Desc: sends data to display
//-----------------------------------------------------
void LCD_data(unsigned char *data, unsigned int len)
{
DOGDATA;
while(len--)
dogSPIout(*data++);
}
//-----------------------------------------------------
//Func: LCD_string
//Desc: shows ascii character on screen
//-----------------------------------------------------
void LCD_string(unsigned char column, unsigned char page, const char
*str)
{
unsigned int pos_array;
LCD_position(column, page);
while(*str!= 0)
{
//calculate positon of ascii character in font array
//bytes for header + (ascii - startcode) * bytes pro char)
pos_array = 8 + (unsigned int)(*str++ - font_6x8[2]) * font_6x8[7];
LCD_data(&font_6x8[pos_array], font_6x8[4]); //Argument 1: Data to
send; Argument 2: len = width of char
}
}
//----------------------------------------------------------------------
-------
int main()
{
// Init-Code
initDDRB();
initDDRD();
//-------------------------Reset display
_delay_ms(200);
DOGRESET;
_delay_ms(2);
DOGRESETOFF;
_delay_ms(150);
//-------------------------
//-------------------------communication test - all pixel to on
DOGENABLE;
DOGCOMMAND;
dogSPIout(0xA9); // display enable (20, 0xA8); b/w.mode (0xA8);
disp active (0xA9)
dogSPIout(0xA5); // set all pixel on (18, 0xA4): on (0xA5)
_delay_ms(50);
dogSPIout(0xA4); // set all pixel on (18, 0xA4): off (0xA4)
//-------------------------
//-------------------------initialize display
LCDinit();
LCDClear();
//-------------------------Ausgabe der Testdaten
LCD_string(8,10,"2");
while (true) // Mainloop
{
}
return 0;
}
//----------------------------------------------------------------------
-------
Die "2" habe ich nur für meine letzten Tests benutzt, solange ich das
array nur bis zm 127. Zeichen fülle, zeigt das Display brav beliebige
strings korrekt an. Tja, nun die grosse Frage: Was mache ich verkehrt?
Ich danke für jede Hilfe, da ich nun selbst keine zündende Idee mehr
habe...
Gruß Bernd
Ändere erstmal von "const char" nach "const unsigned char" und die
Warnung sollte verschwinden. Ob ein "char" mit oder ohne Vorzeichen ist,
hängt von System und Compiler ab - definiere es einfach als "unsigned"
und gut ist (besser: nutze uint8_t aus <stdint.h>).
Bist du dir sicher, dass dein Font überhaupt mehr als 128 Zeichen
enthält? Wenn das Array nur 128 Einträge enthält, dann wird ein Zugriff
auf z.B. das 210. Zeichen irgendwo ins Leere gehen, die Daten als
Pixelwerte interpretieren und damit irgendwelchen Mist rendern.
Nachsatz:
Sehe gerade, dass die Funktion LCD_string zweimal in meinem Code
auftaucht, das entspringt wohl den vielen Versuchen, ist natürlich
Unsinn. Sorry dafür..
Hallo svenska,
den Versuch mit unsigned const char habe ich im Laufe meiner vielen
Versuche schon gemacht, die Compilermeldung bleibt, ausser das nun
unsigned const char angemeckert wird.
Das array umfasste ursprünglich alle Zeichen bis 255, habe lange
gebraucht, bis ich heraus hatte, dass es an dem zu grossen array liegt.
Danke für deine schnelle Reaktion.
Ich habe sowohl unsigned const char als auch const unsigned char bereits
gehabt. Der Compiler meldet beides als unzulässig.
Ich bin bisher davon ausgegangen, dass ich ASCII-Zeichen sowohl als
char, int oder andere Zahl verwenden kann, solange der Wertebereich
passt. Sehe ich das falsch?
ASCII ist nur bis 127 definiert. Alles darüber hinaus sind
Erweiterungen.
Du müsstest also erstmal wissen, welche Codierung das Display benutzt
und auch dein Entwicklungssystem.
Oft ist char als signed definiert. Reicht bei ASCII auch aus.
Wenn du dann einen Wert größer als 127 zuweist, wird das entsprechende
Bitmuster abgelegt. Bei 255 wäre das 0xFF. Als signed ist das -1.
Wenn du einem signed int ein char zuweist, ist der negativ.
Bernd G. schrieb:> Um das 4th byte habe ich mich in meinen späteren Versuchen nicht mehr> gekümmert, da es m. E. in meinem C-Code keine Rolle spielt. Mit höheren,> an die jeweilige array-Grösse angepassten Werten des 4th byte, war die> Ausgabe ebenso fehlerhaft.
Hast du die Werte im Array dann auch erweitert?
Moin Dirk,
Vielen Dank für deine Ausführungen.
Zu deinen Zweiten: ich habe bei meinen Versuchen das Array zunächst nur
mit dem ASCII-Code für das ! gefüllt und als 4th Byte 14 eingetragen für
die acht header Bytes plus sechs für das !. Dann habe ich das Array
immer 16-Zeichen-weise vergrößert, das vierte Byte ebenfalls erhöht und
hatte keine Fehler. Das Display hat brav angezeigt, was an pixelmuster
in der Font-Datei hinterlegt war. Das ging bis 127 gut.
An 128 Test dann der pixelsalat auf, obwohl auch für diese Positionen im
Array entsprechende pixelmuster existierten.
Das Display selbst hat keine ascii-Zeichen im RAM oder woanders, es
stellt nur die übertragenen pixelmuster dar. Und sie entstammen der
fontdatei (s. o).
Bernd G. schrieb:> Für Zeichen grösser Dezimal 128 zeigt es Kauderwelsch.
Kein Wunder, wenn du in deinem Array die Obergrenze auf 128dez setzt.
Bernd G. schrieb:> 70, 86, 32, 128, 6, 8, 1, 6,
Hast du es denn mal mit einer Zwangsumwandlung (innerhalb der Funktion)
probiert.
Mit einem cast sagst du dem Compiler, dass du weißt was du tust und es
gibt keine Warnung.
Kein Wunder, wenn du in deinem Array die Obergrenze auf 128dez setzt.
Die 128dez stehen da nur momentan. Ich hatte auch größere Werte dort
stehen. Dennoch konnte ich keine größeren ascii-Werte darstellen, was
mir auch logisch vorkam, solange ich -weil sonst der Compiler meckert -
nur const char verwenden konnte.
An Dirk:
Den Gedanken mit einer Umwandlung hatte ich auch schon, wusste aber
nicht, wie das korrekt geht. Stimmt also vielen Dank für deinen Code,
das werde ich später probieren, derzeit bin ich noch bei der Arbeit.
Hast du denn deine Idee, warum ich const char nehmen muss? Das sieht
doch für mich zumindest so aus, als würde
LCD_string(2,8,“2“);
Das erzwingen. Jedoch kann ich die erste 2 (column-wert) und die 8(page)
doch auch als integer weiter verarbeiten. Woher der Unterschied?
docbg schrieb:> Hast du denn deine Idee, warum ich const char nehmen muss? Das sieht> doch für mich zumindest so aus, als würde> LCD_string(2,8,“2“);> Das erzwingen.
Mit const versicherst du (als Programmierer), dass du an den Daten
nichts änderst.
Wenn du es doch machst, kann dich der Compiler warnen.
Ein Stringliteral (wie "2") sollte nunmal als nicht änderbar betrachtet
werden.
> Jedoch kann ich die erste 2 (column-wert) und die 8(page)> doch auch als integer weiter verarbeiten. Woher der Unterschied?
Das Font-Array ist doch unsigned char.
Lass dir mal bei deinem bisherigen Code vor dem Aufruf von
LCD_data(&font_6x8[pos_array], ... den Wert von pos_array ausgeben.
Und dann mit denm verbesserten Code.
Bernd G. schrieb:> Ich bin inzwischen soweit, dass mein Display ASCII-Codes bis zum 96.> Zeichen (hex7F oder Dezimal 127) anzeigt. Für Zeichen grösser Dezimal> 128 zeigt es Kauderwelsch.Bernd G. schrieb:> Mein Code zwingt mich in der Funktion LCD_String für die ASCII-Zeichen> den Typ const char anzugebenBernd G. schrieb:> denn ein const char kann> nur den maximalen Wert 128 annehmen.Bernd G. schrieb:> ich beschäftige mich beharrlich mit einem EA DOGXL
Ja ja ja ja ja...
Also....
Du pfriemelst beharrlich mit irgend einem Stück Treiber von EA herum,
ohne auch nur im geringsten zu wissen, was da überhaupt abgeht. Hast du
schon mal in die Quellen von EA geschaut? Weißt du übehaupt, was da für
ein Font drinsteckt und welche Zeichen dieser überhaupt enthält?
Nun hast du eine ganze Latte an deinem Quellcode gepostet - erwartest
du, daß da alle anderen Forenteilnehmer besser durchsehen als du? Oder
erwartest du, daß man ohne Kenntnis der Hintergründe wissen kann, was da
bei DOGDATA; passiert:
1
voidLCD_data(unsignedchar*data,unsignedintlen)
2
{DOGDATA;
3
while(len--)dogSPIout(*data++);
4
}
Da es einen Font zu geben scheint, nehme ich mal an, daß es sich um ein
grafisches Display handelt. Bei so etwas sollte es eine Funktion geben,
die an eine wählbare Stelle auf dem Display ein Zeichen in einem
wählbaren Font und in einer wählbaren Farbe hinschreibt. Sowas sollte
Teil der Grafik-Lib sein und NICHT die Teile der Firmware belästigen,
die das Display benutzen wollen.
Fazit: mir scheint der Krempel von EA ein ziemlicher Mist oder dessen
Dokumentation ein Mist zu sein oder du hast ihn nicht verstanden. Also
mach es anders. Anstatt dich mühsam durch schlechten Code und
unzureichende Fonts zu quälen, ohne das alles wirklich zu verstehen..
(!!! siehe "Um das 4th byte habe ich mich in meinen späteren Versuchen
nicht mehr gekümmert, da es m. E. in meinem C-Code keine Rolle spielt."
.. wobei das 4. Byte angibt, welches der höchste im Font vorkommende
Char ist, also GENAU DAS Problem, was du hier schilderst)
..solltest du anfangen, die Funktionalität von grafischen
Zeichenausgaben verstehen zu lernen:
1. Zum Benutzen braucht man eine Funktion, die so etwa so aussieht:
1
intZeichenausgabe(intX,// Pixel von links
2
intY,// Pixel von oben
3
charC,// das Zeichen
4
derFont,// Typ des Fonts je nach deinem Zeugs
5
dieFarbe);// Typ der Farbe je nach deinem Zeugs
Und alles Andere soll gefälligst im zugehörigen GDI abgehen, so daß man
sich beim benutzen nicht drum scheren muß. Bei einem monochromen Display
hat man bei den Farben nur schwarz, weiß und toggle.
2. Um flott arbeiten zu können, braucht man einen Canvas, also eine
Zeichenfläche im RAM mit je einem Bit (oder bei bunten Displays einem
Farbeintrag) je Pixel.
Hat man genug RAM für den Canvas, dann zeichnet man mit obiger Funktion
dort hinein und überträgt später den ganzen Canvas ins Display.
hat man nicht genug RAM für den Canvas, dann muß man sich jeweils einen
Mini-Canvas pro auszugebendem Zeichen anlegen, den vorherigen
Hintergrund aus dem Dislay lesen und hineintun, dann dort hineinzeichnen
und dann diesen Canvas wieder ins Display zurückschreiben. Ist mühsam
und langsam.
Mein Rat wäre wieder mal, die Dinge zu trennen. Das physische Ansteuern
eines Displays also trennen vom logischen Schreiben oder Zeichnen auf
einem Canvas. Ebenso sollten die Schreibroutinen selber mit dem
bezeichneten Font umgehen und nicht die benutzenden Teile deiner
Firmware damit belästigt werden.
W.S.
W.S. schrieb:> 1. Zum Benutzen braucht man eine Funktion, die so etwa so aussieht:int> Zeichenausgabe (int X, // Pixel von links> int Y, // Pixel von oben> char C, // das Zeichen> der Font, // Typ des Fonts je nach deinem Zeugs> die Farbe); // Typ der Farbe je nach deinem Zeugs
Sicher nicht. Von der Mixtur aus Deutsch und English, Grossschreibung
und Syntaxfehlern mal abgesehen, ist es unsinnig bei jedem Zeichen Font
und Farbe setzen zu wollen. Position ist auch sehr zweifelhaft, da meist
einfach von links nach rechts fortlaufend geschrieben wird. Ich will
sicher nicht die X-Position mitrechnen wollen.
> Mein Rat wäre wieder mal, die Dinge zu trennen.
Sag ich ja.
leo
leo schrieb:> Sicher nicht. Von der Mixtur aus Deutsch und English, Grossschreibung> und Syntaxfehlern mal abgesehen, ist es unsinnig bei jedem Zeichen Font> und Farbe setzen zu wollen. Position ist auch sehr zweifelhaft, da meist> einfach von links nach rechts fortlaufend geschrieben wird. Ich will> sicher nicht die X-Position mitrechnen wollen.
Hä?
Also mir scheint, du willst mit dem Grafikdiplay lediglich ein reines
Alpha-Text-Display nachbilden.
Und was Font und Farbe betrifft: da kann man auch mit einer Art
Device-kontext arbeiten. Das spart einerseits 2 Argumente, erfordert
aber ein zuvoriges Einstellen.
OK, wer ein Grafik-Display eigentlich gar nicht wirklich benutzen will,
also weder Grafik noch Fonts variabler Größe und Breite verwenden will,
sondern nur eben den Canvas in Stücke zu 6x8 oder 8x12 Pixel aufteilen
will, um dort Textzeichen zu plazieren, der kann das Ganze auch um
einiges primitiver gestalten.
Aber wozu kauft man sich dann dafür in der Apotheke EA ein grafisches
Display?
W.S.
W.S. schrieb:> 1. Zum Benutzen braucht man eine Funktion, die so etwa so aussieht:
Und wenn genau diese Funktion fehlerhaft ist?
Das ist der Part vom TO, der nicht funktioniert. Da ist es egal was da
noch drum herum gebastelt wird.
W.S. schrieb:> Also mir scheint, du willst mit dem Grafikdiplay lediglich ein reines> Alpha-Text-Display nachbilden.
Ich habe dein Interface kritisiert, welches genau 1 Zeichen Text
ausgab.
Von Grafik war nicht die Rede. BTW: bei einem S/W-Display die Textfarbe
mitzugeben ist auch total unsinnig.
leo
Nur mal zur Klarstellung, ich beschäftige mit einem Grafikdisplay, weil
ich - wenn ich alles so hin hab wie es soll - genau das darstellen will.
Am Ende soll das Ganze eine Windrose und eine grafische und numerische
Darstellung der Windgeschwindigkeit erledigen. Ich habe auch schon
Grafiken auf dem Display erzeugt, aber das war auch nicht meine Frage!
Ich komme lediglich mit den ascii-Zeichen jenseits der 128 nicht klar
und hatte die Hoffnung, dass jemand mehr Ahnung hat als ich und mir in
diesem einen Punkt weiter helfen kann.
Dass ich kein Experte in c bin, habe ich anfangs erwähnt. Aber ich habe
Spaß daran, mich mit solchen Dingen zu beschäftigen und gedenke, Neues
zu erlernen. Wenn es jemandem nicht passt, dass ich zu viel Code
gepostet habe: niemand ist gezwungen, meinen Text zu lesen!!!! Wenn ich
aber eine Frage stelle, gehören Informationen dazu. Und die wollte ich
geben.
docbg schrieb:> ascii-Zeichen jenseits der 128
Es gibt keine ASCII-Zeichen jenseits von 127.
Welche Fonts/Charsets hast du? Was sagt deine Doku dazu,
Stichwort: Charset
leo
Ich benutze Vorerst eine fontdatei von ea, die anscheinend relativ
verbreitet ist: font_6*8. einen Auszug habe ich ganz am Anfang gepostet.
Dabei will ich nicht bleiben, ich möchte auch andere Schriften einbauen,
aber soweit bin ich noch nicht.
NB: wie würdest du hier die Kopie meines Textes mit dem grünen Balken
davor? Das finde ich sehr nützlich.
docbg schrieb:> Bei NB sollte es nicht wie würdest du sondern wir erzeugst du... heißen.
„Markierten Text zitieren“ oder „Antwort mit Zitat“ unten rechts beim
Text.
docbg schrieb:> Ich benutze Vorerst eine fontdatei von ea, die anscheinend relativ> verbreitet ist: font_6*8.
Mann, wieviele Eintraege hat diese? Von 32-128, wie du definiert hast?
leo
Dirk B. schrieb:> Joachim B. schrieb:>> leo schrieb:>>> Mann, wieviele Eintraege hat diese?>> ist und bleibt sein Geheimnis, hat er im Eröffnungspost ja rausgekürzt
Kommt heute Nachmittag, ich kann berufsbedingt nicht jederzeit
schreiben,
Dirk B. schrieb:> Steht eigentlich da
du siehst die 128 Zeichen nach usw.?
Bernd G. schrieb:> unsigned char font_6x8[] => {> 70, 86, 32, 128, 6, 8, 1, 6,> 0, 0, 0, 0, 0, 0,> 0x00, 0x00, 0x5F, 0x00, 0x00, 0x00, // hex geht auch!> // 0, 0, 95, 0, 0, 0,> 0, 7, 0, 7, 0, 0,> 20,127, 20,127, 20, 0,> usw.docbg schrieb:> Kommt heute Nachmittag, ich kann berufsbedingt nicht jederzeit> schreiben,
lieber TO bitte den Code hochladen, so lang im Posting muss nicht sein!
leo schrieb:> Ich habe dein Interface kritisiert, welches genau 1 Zeichen Text> ausgab.> Von Grafik war nicht die Rede. BTW: bei einem S/W-Display die Textfarbe> mitzugeben ist auch total unsinnig.
Du springst ein zweitesmal zu kurz.
Auf einem Grafik-Display IST von Grafik die Rede - und zwar
ausschließlich Grafik. Nichts Anderes. Ein Textzeichen ist da nämlich
auch eine Grafik, die eben pixelweise auf der Glotze plaziert werden
muß. Und die ist regelmäßig in pixelweisen Koordinaten X und Y
organisiert. Wenn dir X und Y nicht gefallen, dann nenne das eben
Ottokar und Heinrich, aber merke dir was wer ist.
Und die Farbe ist auch auf einem monochromen Display ein Thema. Ich
schrieb's ja bereits: schwarz, weiß und invertierend.
Und bevor du hier was kritisierst, ohne selbst einen positiven Beitrag
zu liefern, lies mal zuvor, wie das z.B. in der Lernbetty gemacht worden
ist. Das dortige GDI kann nämlich mit Fonts aller Größe und fester und
variabler Breite umgehen und es kann die Texte an beliebige
X,Y-Positionen zeichnen. Und das Ganze ist bereits asbach uralt, sollte
also keine Neuigkeit für jemanden darstellen, der Grafik auf ein
grafisches LCD bringen will.
Und ehe du dich verwunderst, warum besagte Funktion nur ein Textzeichen
zeichnet, sei dir gesagt, daß man durch wiederholtes Aufrufen so einer
Funktion auch Zeicheketten darstellen kann. Zu diesem Zweck liefert die
Funktion nämlich die Zeichenbreite zurück, so daß man X entsprechend
erhöhen kann.
W.S.
W.S. schrieb:> Auf einem Grafik-Display IST von Grafik die Rede - und zwar> ausschließlich Grafik.
Aha. Das Lesen des Subjects ist aber nicht so deines.
> wie das z.B. in der Lernbetty gemacht worden ist.
Jaja. Mit der bist du schon oft hausieren gegangen und zu Recht
kritisiert worden.
leo
docbg schrieb:> Nur mal zur Klarstellung, ...> ... Ich habe auch schon Grafiken auf dem Display erzeugt...> Ich komme lediglich mit den ascii-Zeichen jenseits der 128 nicht klar> und hatte die Hoffnung, dass jemand mehr Ahnung hat als ich und mir in> diesem einen Punkt weiter helfen kann.
Also erstens: Ich und andere hatten vor vielen Jahren mit der Lernbetty
bereits die Ausgabe von Texten in verschiedenen Fonts, Linien und
Flächen den hiesigen Lesern vorgeturnt. Hier triffst du also auf Leute,
die dediziert mehr Ahnung haben von diesem spezielen Thema als du.
Man braucht das Zeugs aus der Lernbetty nur nachzumachen - aber man
sollte verstehen, was man da tut. Ich habe hier auch schon mal diverse
Fonts und einen kleinen Font-Compiler gepostet, mit dem man sich seine
eigenen Fonts oder Klein-Grafiken selber machen kann.
So. Du hast also nicht nachgeschaut, warum du bei Zeichen > 7Fh nur
Kauderwelsch kriegst. Und du hast dich auch nicht um die Grenzen im Font
gekümmert: (Zitat)"Um das 4th byte habe ich mich in meinen späteren
Versuchen nicht mehr gekümmert, da es m. E. in meinem C-Code keine Rolle
spielt". Ach so.
Also das 3. und 4. Byte sollen das kleinste und größte darstellbare
Zeichen anzeigen. Das ist offensichtlich dazu gedacht, daß man beim
Benutzen des Fonts eben NICHT über diese Grenzen hinaustanzt.
Und wenn du das 4. Byte erhöhst, dann mußt du eben auch die zugehörigen
Glyph-Daten in den Font einarbeiten. So etwas sollte dir eigentlich
bekannt sein.
Und: die konkrete Programmiersprache (hier: C) spielt für das
Verständnis der Algorithmen eines GDI und der Struktur eines Fonts keine
Rolle.
W.S.
guest schrieb:> Das Fontarray hat einen Header in dem> steht welche Zeichen es enthält (32-128)
das er schon geändert hat unabhängig davon ob überhaupt 32-128 Zeichen
defininiert sind!
Ich wollte die Zeichen wenigstens mal sehen und zählen und nicht um
seine Änderungen spekulieren
leo schrieb:> Es gibt keine ASCII-Zeichen jenseits von 127.> Welche Fonts/Charsets hast du? Was sagt deine Doku dazu,> Stichwort: Charset>> leo
Sorry, dass es so lange gedauert hat, die liebe Arbeit...
Dies ist die vollständige Originaldatei, die ich anfangs benutzt habe.
Wegen der beschriebenen Probleme habe ich im Weiteren das Original
gekürzt und herausgefunden, dass ich die Zeichen korrekt darstellen
kann, wenn ich nur die Zeichen bis hex7F in der font-Datei habe.
Die in der datei vollstaendig_font_6*8.h enthaltenen Zeichen sind in dem
pdf zu finden.
Bernd G. schrieb:> Wegen der beschriebenen Probleme habe ich im Weiteren das Original> gekürzt und herausgefunden, dass ich die Zeichen korrekt darstellen> kann, wenn ich nur die Zeichen bis hex7F in der font-Datei habe.> Die in der datei vollstaendig_font_6*8.h enthaltenen Zeichen sind in dem> pdf zu finden.
sehr merkwürdig, schliesslich gibt es Zeichen von 32 bis 255
warum also nur bis 127 (0x7F) funktionieren soll erklärt es nicht.
ich habe mal mit meinem Font verglichen
65 ist wirklich das große A und der Font reicht bis 255
Mist weder mit font.c oder font.txt weden die Zeilennummern gezeigt.
Ich hatte das so schön eingruppiert SPACE 32 Font bis 255
Bernd G. schrieb:> Wegen der beschriebenen Probleme habe ich im Weiteren das Original> gekürzt und herausgefunden, dass ich die Zeichen korrekt darstellen> kann, wenn ich nur die Zeichen bis hex7F in der font-Datei habe.
Na ja, die Fontdatei ist ok. Bleibt nur die Frage, wie du den Text, der
nicht funktionierte, dargestellt/eingegeben hast. Ich vermute mal, das
war Unicode.
leo
> Ich vermute mal, das war Unicode.
Ich rufe in der main() die Funktion LCD_string auf:
LCD_string(8,10,"Auszugender Text");
void LCD_string(unsigned char column, unsigned char page, const char
*str)
{
unsigned int pos_array;
LCD_position(column, page);
while(*str!= 0)
{
//calculate positon of ascii character in font array
//bytes for header + (ascii - startcode) * bytes pro char)
pos_array = 8 + (unsigned int)(*str++ - font_6x8[2]) * font_6x8[7];
// LCD_data(&font_6x8[pos_array], font_6x8[4]); //Argument 1: Data to
send; Argument 2: len = width of char
}
}
leo schrieb:> Na ja, die Fontdatei ist ok
dann kann man über char(127) statt ein Zeichen auch ein Byte an die
Ausgabe schicken.
statt
LCD_string(8,10,"2");
LCD_string(8,10,"\50\0");
eben
LCD_string(8,10,"\160\0"); oder so ähnlich, manchmal auch /
Bernd G. schrieb:> Ich rufe in der main() die Funktion LCD_string auf:> LCD_string(8,10,"Auszugender Text");
Hrmpf, das ist ASCII und macht keine Probleme. Muss man dir alles
vormalen?
e.g. ein Linux-Beispiel:
1
$ echo ü > ue.txt
2
$ xxd < ue.txt
3
00000000: c3bc 0a
Also Unicode. Was dein Editor macht solltest du schon wissen.
leo
Dirk B. schrieb:> Dann schau dir mal die Werte von pos_array für das Zeichen 127 und für> 128 an.>> Also vom Compiler ausgeben lassen.
Das werde ich morgen machen, gute Idee.
Gruß und danke
Bernd G. schrieb:> Dirk B. schrieb:>> Dann schau dir mal die Werte von pos_array für das Zeichen 127 und für>> 128 an.>> Also vom Compiler ausgeben lassen.>> Das werde ich morgen machen, gute Idee.> Gruß und danke
Hallo Dirk,
zur Zeit kann ich mein Projekt nicht weiter betreiben. Bin etwas knapp
in Zeit und brauche auch mal eine ‚schöpferische Pause‘.
Ich möchte aber nicht versäumen, dir für deine nette Unterstützung zu
danken. Deine Beiträge waren diejenigen, die mir die meisten Denkanstöße
gegeben haben und freundlich und sachlich waren. Dafür danke und alles
Gute für dich.
W.S. schrieb:> leo schrieb:>> Ich habe dein Interface kritisiert, welches genau 1 Zeichen Text>> ausgab. [...]>> Von Grafik war nicht die Rede. BTW: bei einem S/W-Display die Textfarbe>> mitzugeben ist auch total unsinnig.>> Auf einem Grafik-Display IST von Grafik die Rede - und zwar> ausschließlich Grafik. Nichts Anderes. Ein Textzeichen ist da nämlich> auch eine Grafik, die eben pixelweise auf der Glotze plaziert werden> muß.
Du willst leo einfach nicht verstehen. Das Interface Deiner tollen
Zeichen-Malfunktion ist einfach sch...lecht. Einzelzeichen-Ausgabe? Da
muss man ja in der Schicht darüber dauernd die Cursorposition
nachrechnen, wenn man mehrere Zeichen hintereinander ausgeben will. Bei
Proportionalschrift wirds dann richtig ätzend.
In der Regel gibt man Strings und nicht einzelne Zeichen aus. Dann kann
die Textausgabefunktion den virtuellen Cursor intern nachziehen und
Zeichen für Zeichen an der korrekten Position ausgeben, ohne dass man
sich darum auch noch kümmern muss.
Zudem ist es sinnvoll, auch Funktionen anzubieten, bei denen man
Cursor-Positionen und/oder Farben separat setzen kann. Das hat den
Vorteil, dass man Text auch in kleineren Portionen sukzessive
hintereinander ausgeben kann, falls dies notwendig sein sollte, ohne
sich um aktuelle virtuelle Cursorpositionen und aktuell eingestellte
Farben kümmern zu müssen.
Deine viel zu spezielle Funktion Zeichenausgabe() wäre dann einfach eine
High-Level-Funktion, welche die Low-Level-Funktionen für SetCursor() und
SetColor() und DrawText() nacheinander aufruft. Dann kann man DrawText()
auch mehrfach hintereinander aufrufen und der Text landet immer an der
richtigen Stelle, z.B.
1
SetCursor(300,150);
2
SetColor(COLOR_BLACK,COLOR_WHITE);
3
SetFont(ARIAL_12);
4
DrawText("Hello ");// wird an (300,150) ausgegeben
5
...
6
DrawText("World");// wird hinter "Hello " ausgegeben.
W.S. schrieb:> Man braucht das Zeugs aus der Lernbetty nur nachzumachen
Wenn Sie so programmiert wurde:
1
intZeichenausgabe(intX,// Pixel von links
2
intY,// Pixel von oben
3
charC,// das Zeichen
4
derFont,// Typ des Fonts je nach deinem Zeugs
5
dieFarbe);// Typ der Farbe je nach deinem Zeugs
dann sicher nicht.
Das wäre bei obigem wesentlich flexibleren Interface höchstens eine
Funktion (oder gar ein Macro), um das Ganze für Tippfaule abzukürzen.
Aber ganz gewiss wäre das nicht die zentrale Textausgabefunktion,
welche die Pixel auf dem Display setzt.
Frank M. schrieb:> Das Interface Deiner tollen> Zeichen-Malfunktion ist einfach sch...lecht. Einzelzeichen-Ausgabe? Da> muss man ja in der Schicht darüber dauernd die Cursorposition> nachrechnen, wenn man mehrere Zeichen hintereinander ausgeben will. Bei> Proportionalschrift wirds dann richtig ätzend.
Beim Lesen deiner Zeilen wird mir danach, ausgesprochen unhöflich zu
werden.
Also wenn du schon rein garnichts verstehst, dann lerne doch zuerst mal
etwas dazu, bevor du derartig unzutreffendes Zeugs von dir gibst.
Einzelzeichen-Ausgabe? Na selbstverständlich! Das ist die Grundlage für
alles Weitere. Die Stringausgabe setzt darauf auf. Du hast das ganze
bloß nicht verstanden.
Also hier noch mal zum Nachlesen für dich:
So sieht sauberes Programmieren aus: Die String-Funktion setzt auf die
Char-Funktion auf. Das schafft Klarheit in der Hierarchie und es
vermeidet zwei parallele Funktionalitäten, die ohnehin dasselbe tun
sollen.
Und - oh Wunder! - das ganze funktioniert auch mit proportionalen Fonts.
In der Lernbetty stecken nämlich einige proportionale Fonts.
Und - oh zweites Wunder! - wenn man den Returnwert von CgStr_at()
beachtet, dann kann man sogar mehrere Strings hintereinander ausgeben -
OHNE daß man zu diesem Zwecke noch irgend eine globale Variable im GDI
zum Speichern der X-Position vorhalten und initialisieren müßte (ohne
beim Schreiben des GDI zu wissen, ob diese später überhaupt gebraucht
wird).
Ich hatte die Struktur des GDI in der Lernbetty ganz bewußt einfach
gemacht, um die Lernwilligen nicht zu überfrachten. Ich hatte durchaus
überlegt, X und Y durch einen TPoint zu ersetzen, aber das macht sowohl
beim Code schreiben als auch in der Ausführung den gleichen Aufwand,
also hab ich's bei einzelnen Koordinaten belassen.
In meinen kommerziellen Projekten arbeite ich hingegen mit
Device-Kontexten. Da sieht die Funktion dann so aus:
Der Grund dafür ist, daß das GDI nicht nur auf verschiedenen TFT's
funktionieren soll, sondern eben auch die Ausgabe auf den Kassenbon und
für Doppelpufferungen in einen MemoryDC zu erledigen hat. Da ändern sich
je nach Device die Dimensionen, Farben etc.
Für die Lernbetty wäre das zuviel Overhead gewesen.
Und dein Vorschlag, das ganze auf 4 Funktionsaufrufe aufzublähen:
Position setzen, Farbe setzen, Schrift setzen, String ausgeben -
bedeutet eigentlich nur eines: gesteigerte Umständlichkeit. Nein, du
hast das nicht wirklich bis zum Ende durchdacht, sondern einfach nur
alles ignoriert, was dir nicht sofort in den Sinn gekommen ist, sondern
etwas gründlicheres Nachdenken erfordert hätte.
So, du Schlaumeier und Erfinder von MINOS, dem völlig spezialen OS, wird
dir jetzt ein wenig klarer, wie herum man sowas richtig macht?
W.S.
Bernd G. schrieb:> zur Zeit kann ich mein Projekt nicht weiter betreiben. Bin etwas knapp> in Zeit und brauche auch mal eine ‚schöpferische Pause‘.
Danke für die Rückmeldung.
Ich würde (irgendwann) aber doch gerne wissen woran es liegt.
W.S. schrieb:> Und - oh zweites Wunder! - wenn man den Returnwert von CgStr_at()> beachtet, dann kann man sogar mehrere Strings hintereinander ausgeben
Okay, dieses kleine Detail hattest Du leider bei Deiner ursprünglich
vorgestellten Funktion Zeichenausgabe() verschwiegen, nämlich dass Du
den neuen X-Offset als Return-Wert zurückgibst. Dann passt das
natürlich... in Deiner Welt.
Nichtsdestrotz kann man das auch anders aufziehen. Deshalb finde ich
persönlich Deine Darstellung "Nur ich machs richtig und alles andere ist
grundweg falsch" einfach zu großmäulig.
Frank M. schrieb:> Okay, dieses kleine Detail hattest Du leider bei Deiner ursprünglich> vorgestellten Funktion Zeichenausgabe() verschwiegen, nämlich dass Du> den neuen X-Offset als Return-Wert zurückgibst.
Was meinst du eigentlich, warum die Funktion int und nicht void ist?
Und warum weißt selbst du so viele Jahre nach der Lernbetty noch immer
nicht, wie man solche (und andere) Programmieraufgaben sinnvoll,
effektiv und einfach löst?
Ich werfe das einem Neuling nicht vor, schließlich haben wir alle mal
klein angefangen. En Neuling sollte deshalb als allererstes mal
dazulernen, wenn er vor einem Problem steht - und er sollte nicht ohne
zu lernen Ergebnisse haben wollen.
Aber jemandem wie dir werfe ich Ignoranz vor, denn du könntest (und
solltest) es von deiner Position her besser wissen.
Nochwas: Dein Spruch zum Schluß ist sowohl dumm als auch beleidigend. Du
bist es, den ich erst mit der Nase auf die Lösung habe stucken müssen.
Ich hingegen habe das alles schon vor Jahren gewußt und auch so
geschrieben und zum Lesen bekanntgegeben.
Natürlich kann man alles auch anders machen - aber so wie ich das
schon jahrelang mache, funktioniert es - und deshalb ist das meinerseits
eben nicht "großmäulig", sondern einfach nur sachlich richtig.
W.S.
W.S. schrieb:> Und warum weißt selbst du so viele Jahre nach der Lernbetty noch immer> nicht, wie man solche (und andere) Programmieraufgaben sinnvoll,> effektiv und einfach löst?
Weil deine Lernbetty niemanden interessiert!
Da gibts ein paar DLs in deinem Thread, aber keine Antworten.
Die Google und Forensuche nach Lernbetty sieht auch eher mau aus.
Das könnte an deinem Codingstyle liegen ;)
W.S. schrieb:> Aber jemandem wie dir werfe ich Ignoranz vor, denn du könntest (und> solltest) es von deiner Position her besser wissen.
Es gibt Sätze die sollte jemand nicht bringen der im Gegensatz zu Frank
M schon durch sehr viel dämliches Gelaber aufgefallen ist.
Wie dem Cortex-M4 ohne DSP Befehle LOL!
W.S. schrieb:> Was meinst du eigentlich, warum die Funktion int und nicht void ist?
Du hast es NICHT erklärt, was Deine Funktion zurückliefert. Hätte ja
auch ein Error-Code sein können, wie C-Funktionen im allgemeinen
Rückgabewerte behandeln. Ich hatte es jedenfalls nicht erraten können.
Es bleibt dabei: Ohne Deine Erklärung, was die Funktion
Zeichenausgabe() zurückliefert, ist diese Funktion zur Ausgabe von
Strings unbrauchbar. Diese Erklärung hattest Du nicht geliefert. Deshalb
habe ich es kritisiert.
Daraufhin hattest Du die Erklärung nachgeliefert und ich habe
Verständnis geübt. Was also willst Du noch von mir? Genugtuung?
> Und warum weißt selbst du so viele Jahre nach der Lernbetty noch immer> nicht, wie man solche (und andere) Programmieraufgaben sinnvoll,> effektiv und einfach löst?
Weil ich mir auch nach Jahren Deinen Lernbetty-Source nicht näher
angeschaut habe. Dieser interessiert mich auch nicht die Bohne.
Allerdings habe ich schon einige negative Kritiken zu Deinem Source
gelesen. Das hat mir gereicht, um zu wissen, dass ich mir Deinen
Lernbetty-Source, den Du bei allen Gelegenheiten anbietest wie sauer
Bier, nicht anschauen brauche.
Nein, ich werde Deinen Lernbetty-Source nicht lesen. Ja, ich habe das
Recht, Deinen Lernbetty-Source nicht zu lesen.
> Aber jemandem wie dir werfe ich Ignoranz vor, denn du könntest (und> solltest) es von deiner Position her besser wissen.
Ja, ich weiß es besser. ;-)
> Nochwas: Dein Spruch zum Schluß ist sowohl dumm als auch beleidigend.
Wer beleidigt mit "dumm" gerade wen?
> Du> bist es, den ich erst mit der Nase auf die Lösung habe stucken müssen.
Du meinst also, jeder andere der Leser hier konnte erraten, was die
Funktion Zeichenausgabe() zurückliefert? Nämlich einen x-Offset, den Du
beim nächsten Call von Zeichenausgabe() wieder reinstopfst?!?
> Ich hingegen habe das alles schon vor Jahren gewußt und auch so> geschrieben und zum Lesen bekanntgegeben.
Du bist einfach Klasse. Aber leider kein Gott. Amen.
> Natürlich kann man alles auch anders machen
Eben. Man kann es und vor allem: man darf es.
W.S. schrieb:> So, du Schlaumeier und Erfinder von MINOS
MINOS, die Sprache NIC und der NIC-Compiler stehen der Allgemeinheit
nicht mehr zur Verfügung - nämlich aufgrund der Borniertheit eines
Einzelnen im MINOS-Thread, der mal wieder meinte, wie in anderen
Projekte-&-Source-Threads anderen seinen Programmier-Stil aufzwingen zu
müssen und den TOs mitzuteilen, dass ihr Source einfach Scheiße ist.
Auf so einen Zoff habe ich keinen Bock. Ich muss mir ein
Open-Source-Projekt, welches ein Geschenk an die Allgemeinheit war,
nicht zerreissen lassen - aufgrund einer simplen
Taster-Polling-Funktion, die überhaupt nicht das MINOS-Projekt inkl.
NIC-Compiler repräsentiert. Nein, derjenige, der seine Religion in
diversen P&C-Threads vorbetet und dabei schon einige P&C-Threads
mutwillig gegen die Wand gefahren hat, hat MINOS noch nichtmals
ausprobiert. Warum also sollte ich mir das antun und Deinen
Lernbetty-Source lesen?!? Ganz im Gegenteil: Das schreckt ab!
Akzeptiere einfach: Jeder hat die Freiheit, seinen Source so zu
gestalten, wie er es selber will. Du darfst natürlich höflich Kritik
üben, aber nicht in dem großmäuligen Ton analog zu "Nur mein Source ist
die Wahrheit, alles andere ist Scheiße!".
Frank M. schrieb:> Nein, derjenige, der seine Religion in> diversen P&C-Threads vorbetet und dabei schon einige P&C-Threads> mutwillig gegen die Wand gefahren hat
Wobei ich mich da so langsam Frage wieso da nicht so langsam mal
konsequent gelöscht wird.
Es ist ja bekannt wos hinführt sobald das W.S. auftritt.
Bernd G. schrieb:> Dirk B. schrieb:>> Ich würde (irgendwann) aber doch gerne wissen woran es liegt.>> Bekommst du, versprochen
Hallo Dirk,
möchte gern mein Versprechen einlösen, habe aber noch keine Lösung, nur
Phänomene für dich.
Inzwischen habe ich ein (minimales) Testprogramm benutzt, um die in der
Funktion errechneten Werte auszugeben. Zur Sicherheit kurz der Code, die
Font-Datei kennst du sicher noch:
//-----------------------------------------------------
void LCD_string(char *str)
{
unsigned int pos_array;
while(*str!= 0)
{
//calculate positon of ascii character in font array
//bytes for header + (ascii - startcode) * bytes pro char)
pos_array = 8 + (unsigned int)(*str++ - font_6x8[2]) * font_6x8[7];
printf("%i \n", pos_array);
// LCD_data(&font_6x8[pos_array], font_6x8[4]); //Argument 1: Data to
send; Argument 2: len = width of char
}
}
int main()
{
LCD_string("~");
return 0;
}
Bis zum 126. ASCII-Zeichen (Tilde) ist alles gut, die
Array-Startposition wird mit 572 korrekt errechnet.
Das 127. Zeichen (⌂) ergibt drei Werte: -364, -880 und -940,
das 128. Zeichen (Ç) ergibt statt dem Soll-Wert 584 eine -526.
Bernd G. schrieb:> Das 127. Zeichen (⌂) ergibt drei Werte: -364, -880 und -940,> das 128. Zeichen (Ç) ergibt statt dem Soll-Wert 584 eine -526.
Das Problem wird sein, das char signed ist.
Da wird 128 zu -128.
Zwei mögliche Lösungen hatte ich schon gepostet:
Beitrag "Re: ASCII-Zeichen nach 128 in C auf DOGXL darstellen nicht möglich"
Wie hast du die Zeichen angegeben?
Als Hexcode oder als Zeichen im Editor?
Nur bei "\x7e\x7f\x80" kannst du sicher sein, dass du den richtigen Code
hast.
Bernd G. schrieb:> Bis zum 126. ASCII-Zeichen (Tilde) ist alles gut, die> Array-Startposition wird mit 572 korrekt errechnet.
Ehem: '572/6 + 32' = 127 # 6 bytes/char startend mit ASCII 32
> Das 127. Zeichen (⌂) ergibt drei Werte: -364, -880 und -940,
Das ergibt keinen Sinn.
> das 128. Zeichen (Ç) ergibt statt dem Soll-Wert 584
Und hier liegst du dann wieder ein Zeichen daneben.
Rechne noch mal nach, und wie schon eingeworfen signed vs. unsigned.
leo
leo schrieb:> Ehem: '572/6 + 32' = 127 # 6 bytes/char startend mit ASCII 32
Da fehlt noch die 8 als Offset für den Header (da wo die 32 und 6
stehen)
Dann passt das. Auch bei dem soll für 128
Ach und noch etwas
Bernd G. schrieb:> unsigned int pos_array;> ...> printf("%i \n", pos_array);
%i passt nicht zu einem unsigned int.
Da muss ein %u stehen.
Dann steht da auch wieder ein anderer Wert.
Der Compiler meckert das, bei entsprechender Warnstufe, auch an - als
Warnung, nicht als Fehler.
Dirk B. schrieb:> leo schrieb:>> Ehem: '572/6 + 32' = 127 # 6 bytes/char startend mit ASCII 32>> Da fehlt noch die 8 als Offset für den Header (da wo die 32 und 6> stehen)> Dann passt das. Auch bei dem soll für 128
Sorry, die 8 hatte ich tatsächlich vergessen
Dirk B. schrieb:> Das Problem wird sein, das char signed ist.> Da wird 128 zu -128.> Zwei mögliche Lösungen hatte ich schon gepostet:> Beitrag "Re: ASCII-Zeichen nach 128 in C auf DOGXL darstellen nicht> möglich"
In der Tat ist das (signed) char unbrauchbar. Habe jetzt unsigned char
draus gemacht. Wie du schriebst, bekoome ich dann eine Warnung vom
Compiler, die da lautet:
warning: pointer targets in passing argument 1 of 'LCD_string' differ in
signedness [-Wpointer-sign]
Dirk B. schrieb:> Wie hast du die Zeichen angegeben?> Als Hexcode oder als Zeichen im Editor?> Nur bei "\x7e\x7f\x80" kannst du sicher sein, dass du den richtigen Code> hast.
Ich arbeite mit Code::Blocks und habe die Zeichen in der main in den
Funktionsaufruf als Text (also beispielsweise LCD_string("ü");
eingegeben. Dann kommt als array-position 1328 heraus.
Gebe ich - wie von dir vorgeschlagen - das Zeichen als hex-wert ein
(also LCD_string("\x81");) kommt korrekt 590 heraus.
Bernd G. schrieb:> Habe jetzt unsigned char> draus gemacht. Wie du schriebst, bekoome ich dann eine Warnung vom> Compiler, ...
Ich hatte noch eine zweite Lösung, die einen internen unsigned char
Pointer nutzt. Durch den cast meckert der Compiler da nicht.
Bernd G. schrieb:> Dann kommt als array-position 1328 heraus.> Gebe ich - wie von dir vorgeschlagen - das Zeichen als hex-wert ein> (also LCD_string("\x81");) kommt korrekt 590 heraus.
Das Problem mit ungleichen Zeichensätzen gibt es aber auch schon bei
Windows alleine.
Der Editor hat einen anderen Zeichensatz als die Konsole (cmd.exe)
Das kannst du aber dem Compiler (irgendwie) mitteilen, dass er dann die
Strings anpasst.
Wie das beim gcc geht, kann ich dir leider nicht sagen.
Dirk B. schrieb:> Ich hatte noch eine zweite Lösung, die einen internen unsigned char> Pointer nutzt. Durch den cast meckert der Compiler da nicht.
Das hatte ich versucht, ich bekomme dann dieselbe compiler-Warnung.
Deine Tipps waren sehr hilfreich und haben mich der Lösung deutlich
näher gebracht. Dafür vielen Dank.
ICh werde noch etwas weiter experimentieren, denn ich möchte natürlich
auf 'direktem' Wege alle Zeichen eingeben können. Und ich merke, dass es
noch viel zu lernen gibt. Aber schliesslich ist das ja auch der Sinn
einer Freizeitbeschäftigung.
Bernd G. schrieb:> ICh werde noch etwas weiter experimentieren, denn ich möchte natürlich> auf 'direktem' Wege alle Zeichen eingeben können.
Du kannst auch den Zeichensatz vom LCD anpassen. ;-)
Bernd G. schrieb:> Das hatte ich versucht, ich bekomme dann dieselbe compiler-Warnung.
Hast du da auch den str in der Definition (und auch Deklaration) wieder
auf char gesetzt?
Dirk B. schrieb:> Du kannst auch den Zeichensatz vom LCD anpassen. ;-)
Das LCD hat keinen Zeichensatz, es ist eine reine Punktmatrix. Deswegen
ja das array, in dem die einzelnen Pixelmuster stehen.
Dirk B. schrieb:> Hast du da auch den str in der Definition (und auch Deklaration) wieder> auf char gesetzt?
Ich hatte unsigned angegeben.
Bernd G. schrieb:>> Hast du da auch den str in der Definition (und auch Deklaration) wieder>> auf char gesetzt?>> Ich hatte unsigned angegeben.
also ich meine unsigned char
Bernd G. schrieb:> Das LCD hat keinen Zeichensatz, es ist eine reine Punktmatrix. Deswegen> ja das array, in dem die einzelnen Pixelmuster stehen.
Das meinte ich. Du kannst das Array umsortieren.
Bernd G. schrieb:> Ich hatte unsigned angegeben.
Ja, daher kommt die Warnung.
Dirk B. schrieb:> Du kannst das Array umsortieren.
Wichtig ist dann trotzdem, dass zumindest der Quelltextes einen 8
Bit-Zeichensatz benutzt. UTF-8 wird die LCD-API garantiert nicht
fressen, aber das ließe sich ja anpassen (*).
(*) UTF 8-Decoder plus latin1-Mapping sind nicht schwer. Man muss ja
nicht gleich Arabisch und Aramäisch einbauen.
Thread beobachten
Seitenaufteilung abschalten