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.