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
1
#define E_ACUTE "\xAB" // whatever your LCD encodes it
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:
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.