Hi, I am using Atmel's AT91SAM7X256 development board and GCC compiler (latest version) / (The toolchain from Yagarto). I am making use of string constants in my code. Few words out of them are using the European characters (like the few shown at the end). I am printing these strings on the LCD. I am successfully able to print the characters having decimal values withing 127. But the same is not true for the european characters (ê, é, è etc.)(which are extended ASCII). Is my problem related to the compiler not supporting the characters? If yes, is there a way by which i can enable the GCC compiler to support it? "En-Tête", "Télécharg.En-Tête", "Création En-Tête", "Envoi En-Tête", "pour Impression", "Attente réception", "En-Tête du PC", "Réception En-Tête", "venant du PC", "Attente pour", "2ème/3ème",
No such thing like "extended ASCII". ASCII is ASCII, and is a 7-bit character set. Anything else has got different names. From just seeing your printed characters here in the forum, for example it's not clear whether you want to write them in ISO 8859-1 (aka. "Latin-1") or UTF-8. Anyway, GCC has a compiled in input character set, and execution character set. The man page says that the execution character set (i.e. how the characters are encoded in the compiled strings) is UTF-8, and the input character set is taken from the locale information, defaulting to UTF-8 in absence of locale information. Have a look at the options -fexec-charset=, -fwide-exec-charset=, and -finput-charset=. Keep in mind that the execution character set must match your LCD. It's unlikely your LCD would understand UTF-8, so the default is probably not a good idea. Well, most LCDs don't even understand ISO 8859-1 but use a homegrown character allocation. In that case, the probably only chance is to manually encode your non-ASCII characters, like
#define E_ACUTE "\xAB" // whatever your LCD encodes it ... "Attente r" E_ACUTE "ception" ...
Hi, thanks for the detailed description. I was able to solve the problem by manually encoding the European characters. That was the simple option. But for my knowledge i digged into the compiler option suggested by you and set them to 'ISO 8859-1' which support the western European characters. But as faced a compile time problem related to something called as 'iconv'. Following are the first few lines of error i got:
cc1.exe: no iconv implementation, cannot convert from ISO/IEC to UTF-8 cc1.exe: no iconv implementation, cannot convert from UTF-8 to ISO/IEC cc1.exe: no iconv implementation, cannot convert from UTF-8 to ISO/IEC ..\..\Application\Source\keypad.c:20:20: no iconv implementation, cannot convert from ISO/IEC to UTF-8
I tired to search this label in GCC manual but was not able to get anything useful. Also i did not find anything thing related to this in the GCC installation directory. Hence finally i have settled with the option of manually encoding.
GCC wants to use a library called libiconv to perform the character set translations requested. Consequently, it must be configured to find this library when compiling it. If your system doesn't have it, GCC is at a loss, and cannot perform any character set translations.
All the compiler knows about is character codes, not the glyph they relate to, and a character in this instance an eight bit integer. The compiler has no knowledge of what glyph a particular execution environment will display in response to a particular character, in your case I suggest that is entirely dependent upon the driver for your LCD. Typically in the simplest case the character code will be used to to index a lookup table of character bitmaps, that bitmap is part of your LCD driver library, not part of the compiler. A more complex driver might support different fonts and proportionally spaced characters. The platform upon which you develop your code is likely to have an entirely different extended character set than the target the code executes on, so you are often better off using the \xnn escape sequence to enter non-ASCII characters in hexadecimal. Of course since you appear to be able to define the glyphs, it is possible to design the set to match your development environment for convenience. A more sophisticated driver library might support locale specific code pages to set the character set or even Unicode to support all possible characters simultaneously. If you want to internationalise your application you will probably need code page or Unicode support. Clifford
Jörg Wunsch wrote: > GCC wants to use a library called libiconv to perform the character > set translations requested. Consequently, it must be configured to As mentioned in my first post, i have taken the pre-buit binary of tool-chain from Yagarto. Hence i did not had any control over the libiconv settings. But it is surprising to find that GCC is able to convert the normal characters (A-Z, 0-9 etc) into their ASCII code without me making any changes to the libiconv related settings. Should libiconv be a part of the prebuilt binary of GCC?
Clifford Slocombe wrote: > The compiler has no knowledge of what glyph a particular execution > environment will display in response to a particular character, in your > case I suggest that is entirely dependent upon the driver for your LCD. > > Typically in the simplest case the character code will be used to to > index a lookup table of character bitmaps, that bitmap is part of your > LCD driver library, not part of the compiler. A more complex driver > might support different fonts and proportionally spaced characters. > > Clifford You are right. But in my case, the LCD i am using simply requires a hex code to be sent to it. This code is compatible with the standard ASCII codes. Lookup is present as a part of the H/W in the LCD and doesnt require me to send the dot patterns for each character. After some browsing on the character encoding topic, i found that the french characters needed by me are present in the 'ISO 8859-1' encoding. But changing the GCC flags to change the encoding to ISO 8859-1 resulted in some errors mentioned in my 1st reply post of the topic. ~Vinit
Vinit Bidkar wrote: > But it is surprising to find that GCC is able to > convert the normal characters (A-Z, 0-9 etc) into their ASCII code There is no conversion involved: you type these characters as ASCII in your editor, and the compiler passes them on into the compiled strings as ASCII. The only conversion that would be needed here were to run the compilation result on a machine that doesn't understand ASCII (e.g. an EBCDIC IBM mainframe). > without me making any changes to the libiconv related settings. Should > libiconv be a part of the prebuilt binary of GCC? Well, it would obviously be helpful in cases like yours. I'm running GCC under different flavours of Unix; some include the iconv feature, some don't. > But in my case, the LCD i am using simply requires a hex > code to be sent to it. No, the LCD requires a binary bit pattern to be sent to it. This is usually ASCII for all characters in the range of 0x20 through 0x7E, but vendors often implement their own character tables outside that range. Many HD44780 controllers feature a mix of Japanese and Western European characters in the range above 0x80, where the Western European characters do not match the ISO 8859-1 positions.