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.
1 | pos_array = 8 + (unsigned int)((unsigned char)*str++ - font_6x8[2]) * font_6x8[7]; |
oder
1 | unsigned char *ustr = (unsigned char*)str; |
am Anfang der Funktion und dann
1 | pos_array = 8 + (unsigned int)(*ustr++ - font_6x8[2]) * font_6x8[7]; |
Das const bleibt für dich ;-)
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.
:
Bearbeitet durch User
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 anzugeben Bernd 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 | void LCD_data(unsigned char *data, unsigned int len) |
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 | int Zeichenausgabe (int X, // Pixel von links |
2 | int Y, // Pixel von oben |
3 | char C, // das Zeichen |
4 | der Font, // Typ des Fonts je nach deinem Zeugs |
5 | die Farbe); // 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.
Sorry, ich schreibe vom Handy.. Bei NB sollte es nicht wie würdest du sondern wir erzeugst du... heißen.
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.
:
Bearbeitet durch User
Jede Zeile, die mit "> " beginnt, wird grün. Was manche umgebrochene
Formel etwas seltsam aussehen lässt.
Mal sehen:
> dies müsste grün geworden sein
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
leo schrieb: > Mann, wieviele Eintraege hat diese? ist und bleibt sein Geheimnis, hat er im Eröffnungspost ja rausgekürzt!
Joachim B. schrieb: > leo schrieb: >> Mann, wieviele Eintraege hat diese? > > ist und bleibt sein Geheimnis, hat er im Eröffnungspost ja rausgekürzt! Steht eigentlich da Beitrag "Re: ASCII-Zeichen nach 128 in C auf DOGXL darstellen nicht möglich"
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!
:
Bearbeitet durch User
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.
Joachim B. schrieb: > du siehst die 128 Zeichen nach usw.? Braucht man gar nicht unbedingt. Das Fontarray hat einen Header in dem steht welche Zeichen es enthält (32-128). Und in dem von Dirk verlinkten Beitrag (Beitrag "Re: ASCII-Zeichen nach 128 in C auf DOGXL darstellen nicht möglich") ist die 128 sogar extra fett hervorgehoben.
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
:
Bearbeitet durch User
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.
Beitrag #6141435 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
HI Die Beschreibung der Font-Dateien: http://www.lcd-module.de/fileadmin/eng/pdf/zubehoer/usbstick-font.pdf MfG Spess
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
Dann schau dir mal die Werte von pos_array für das Zeichen 127 und für 128 an. Also vom Compiler ausgeben lassen.
:
Bearbeitet durch User
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 | int Zeichenausgabe (int X, // Pixel von links |
2 | int Y, // Pixel von oben |
3 | char C, // das Zeichen |
4 | der Font, // Typ des Fonts je nach deinem Zeugs |
5 | die Farbe); // 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.
:
Bearbeitet durch Moderator
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:
1 | /***************************************************************
|
2 | Zeichnet einen String im aktuellen Font an der
|
3 | angegebenen Stelle und liefert die Breite des Strings
|
4 | ***************************************************************/
|
5 | int CgStr_at (int x, int y, char* P, word FontMode) |
6 | { int z; |
7 | while (*P) |
8 | { z = CgCh_at(x,y,*P++, FontMode); |
9 | x = x + z; |
10 | }
|
11 | return (x); |
12 | }
|
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:
1 | int CgCh_at (TDCB* DC, int X, int Y, char Ch); /* einzelnes Textzeichen zeichnen */ |
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.
Dirk B. schrieb: > Ich würde (irgendwann) aber doch gerne wissen woran es liegt. Bekommst du, versprochen
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.
W.S. schrieb:
> Man braucht das Zeugs aus der Lernbetty nur nachzumachen
Ne, das ist ein Beispiel wie mans NICHT macht.
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!".
:
Bearbeitet durch Moderator
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: > das 128. Zeichen (Ç) ergibt statt dem Soll-Wert 584 eine -526. In der Windows Code Page 1252 hat dieses Zeichen den Code 0xC7 = 0b11000111 = 199 (unsigned) = -57 (signed) https://de.wikipedia.org/wiki/Windows-1252
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 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.