How can I use GNU compiler in Keil uVision3 evaluation version?

 How can I use GNU compiler in Keil uVision3 evaluation version?

Hi to all,

Can somebody answer please how can I use GNU compiler in Keil uVision3 evaluation version? Just I need for it because of code limitation. As I am aware to get a compiled unlimited code is possible by configuring the Keil uVision for GNU compiler. Also I'll need for using of GNU libs. Tell me please who knows how to do it.
Thanks.

 RE: How can I use GNU compiler in Keil uVision3 evaluation version?

You need just to download the GNU compiler from http://www.keil.com/demo.

Examples are in the folder:
C:\Keil\ARM\GNU

 Corrected Link

The correct link is http://www.keil.com/demo - without the '.' at the end!

 RE: Corrected Link

Thank you for your replies.

I forgot tell you that of course I already have been downloaded the GNU compiler for Keil uVicsion. It has been integrated in Keil uMision3 V3.53 evaluation version.

Just my question is: how can I setup the uVision3 to use a GNU compiler for building a project ( with including the supplied GNU libs )?
If there is an example point me please the link?
Thanks.

With best regards,
Arthur Khachatryan.

 RE: GNU

http://www.keil.com/arm/gnu.asp

http://www.keil.com/support/docs/3127.htm

And, as Reinhard Keil posted,

"Examples are in the folder:
C:\Keil\ARM\GNU"

 RE: GNU

Thank you very much for a quick reply.
Just I have tried according to your posted recommendations and got the following error messages after doing a "rebuild all target files" command in uVision3 ( it looks like the assembler code doesn't recognized by GNU compiler ):

...
Startup.s(37): error: bad instruction 'standard definitions of Mode bits and Interrupt(I&F)flags in PSRs'
Startup.s(39): error: bad instruction 'mode_usr EQU 0x10'
Startup.s(40): error: bad instruction 'mode_fiq EQU 0x11'
Startup.s(41): error: bad instruction 'mode_irq EQU 0x12'
Startup.s(42): error: bad instruction 'mode_svc EQU 0x13'
....

The related source code is the following:

37: ; Standard definitions of Mode bits and Interrupt (I & F) flags in PSRs
38:
39: Mode_USR EQU 0x10
40: Mode_FIQ EQU 0x11
41: Mode_IRQ EQU 0x12
42: Mode_SVC EQU 0x13
...

Thanks.

 RE: GNU

"it looks like the assembler code doesn't recognized by GNU compiler"

Of course it isn't!
A 'C' Compiler - any 'C' compiler - recognises only 'C' source text!

Presumably, you haven't correctly configured your file extensions so that .s files get translated by the GNU Assembler?

http://www.keil.com/support/man/docs/uv3/uv3_dg_prjfoldext.htm

For specific information about the GNU tools, start here: http://gcc.gnu.org/

The GCC Documentation is available online here: http://gcc.gnu.org/onlinedocs/

 RE: GNU. Assembler code translation

Thank you for your detailed response.
I found that there are differences in tranlator directives and comments. For example for GNU assembler in *.s source file for comments you should type # instead of ; . Also there are differences in constant declarations: you should type a translator directive
.equ Mode_USR, 0x10

for declaration of Mode_USR constant with initialized 10, instead of

Mode_USR EQU 0x10

while using in Keil's Real View compiler.
I just replaced the auto-generated Startup.S file from supplied examples for GNU compiler.
Thanks.

 RE: GNU. Assembler code translation

"I found that there are differences in tranlator directives and comments."

Yes, of course there are!

There is no "standard" for assemblers - every one is different!

Even 'C' compilers have their implementation-specific features!

 RE: GNU. Linker problem

Dear Andy,

I meet to linker problem. Here are the compilation result messages while I was building the project:

Build target 'LPC2148'
assembling Startup.s...
compiling Demo.c...
linking...
/cygdrive/c/Cygnus/Arm-Tools/Bin/../lib/gcc-lib/arm-thumb-elf/3.3.1/../../../../arm-thumb-elf/bin/ld: warning: cannot find entry symbol _start; defaulting to 00008000
startup.o(.text+0x12c):/cygdrive/c/Keil/ARM/Examples/LCD2x16 - 4 Bit/Startup.s:400: undefined reference to '_start'
startup.o(.text+0x140):/cygdrive/c/Keil/ARM/Examples/LCD2x16 - 4 Bit/Startup.s:400: undefined reference to '_data'
collect2: ld returned 1 exit status
Target not created

Meanwhile here is a copy from the Satrtup.S file

....

LDR R2, =__bss_end__
LoopZI: CMP R1, R2 STRLO R0, [R1], #4 BLO LoopZI

# Enter the C code
B _start

.size _startup, . - _startup .endfunc .end

Could you give me please your comments?
Thanks.

 Read & Think

Read the messages, and think what they are telling you:

"cannot find entry symbol _start"

You've used a symbol called '_start', but the linker can't find a definition for it.

Have you (correctly) defined it?

"undefined reference to '_start'"

Same again

"undefined reference to '_data'"

Similarly.

 RE: Read & Think

I see that there are two undefined references. But as you may see in copied section from Startup.S file I have provided, there is the following assembler command at the end of code:

B _start

That means an uncoditional branch to _start ( i.e. to the start section of C code, so I mean defining a _start pointer as the start address of the C code section is under responsibility of linker ).
Am I right?

 Am I right?

I don't know - does GCC claim to provide a '_start' symbol?

Apparently not!

 the GNU compiler the generated hex file size is 2.3 times greater

Dear Reinhard and Andy,


Thank you for your replies.


Andy: I solved the problem related to undefined symbol _start and _data. All that were related to linker's script file ( named Target.ld ) I found in your Keil's supplied GNU/examples and have copied to the project's root folder. It solved the problem.


To Reinhard and Andy:


Many thanks for supplied examples. They were very helpful.


Now another question. Please anybody answer to this one:

For now I found that by configuring the uVision to use the GNU compiler the generated hex file size was 2.3 times greater than the same project which was built by using of the Keil integrated compiler.


Is there a clear explanation on this matter please?


Thanks.

 RE: Hex file size

"... GNU compiler the generated hex file size was 2.3 times greater than the same project which was built by using of the Keil integrated compiler."

First of all, the size of the Hex file is not necessarily much of an indication of the size of the actual execuatable image; eg, if GNU uses shorter lines in its hex files, that will increase the overhead for the same executable code size!

For a meaningful comparison, you need to look at the actual execuatable image sizes.

Anyhow, if we assume that the GNU-generated code really is significantly larger than Keil's then, obviously, Keil would point to this as justification for the price of their tools!

As the saying goes, "You get what you pay for"!

But are you sure that the options you have specificed for Keil are comparable to the options you have specified for Keil?

Obviously, if you set Keil to maximum optimisations, and GNU to none, you would expect the GNU-generated code to be larger, wouldn't you?!

Then again, code size is not the only issue - maybe GNU gives faster code, or better data usage, or...?

 Typo

"But are you sure that the options you have specificed for Keil are comparable to the options you have specified for Keil?"

That should say:

"But are you sure that the options you have specificed for GNU are comparable to the options you have specified for Keil?"

 RE: Typo

I set the following options for GNU:
in the "Options for target" window's linker's tab I have not selected any check box. That means:
- do not collect garbage

- use Standard System Startup File

- use Standard System Libraries

- do not use math labriaries

Size for the same project with GNU compiler is 23 668 bytes.
Size for the same project with Keil compiler is 10 700 bytes.

Even setting the code optimization into "Level 2(size)" doesn't make any changes.

 Optimisation

The GCC and Keil compilers are completely different products from completely different sources - so they are never going to give exactly the same results!

Even "Level 2(size)" will almost certainly mean different things to Keil and GCC.

If this really matters to you, you are going to have to dig deeply into both the Keil and GCC manuals, examine the generated code, etc, etc.

A crude comparison of file sizes has little value.

If you still can't find a set of options that brings the GCC code size down to an "acceptable" level for your requirements, then you are just going to have to pay-up and buy a Keil licence!

Remember, "GCC" is the GNU Compiler Collection - it is a whole range of compilers supporting many different languages and many different targets;
Keil, on the other hand, is specifically targetted directly for the ARM architecture alone. One would therefore hope that the Keil compiler would, indeed, give "better" results than the more generalist GCC...

 RE: Optimisation

I recommend to read the following link:

http://www.compuphase.com/dhrystone.htm

Although the old version of Keil tool is referenced, information about GNU ARM based tools are still relevant and I think very useful.

Proper setting of GNU compiler is very important. Then you can expect also very good results from GNU based compilers. Of course, linking some standard functions (e.g. printf) significantly increase the final image.

 RE: Optimisation

Thank you for your given link. Unfortunately I couldn't find any useful thing regarding the GNU compiler properly configuration in Keil IDE tool.
You have mentioned in your post that GNU compiler can make an effective size code while it has been configured properly. Could you tell me please how can we achieve that results? Thanks.

 RE: GNU support

For GCC support, you'd probably be better going to a GCC forum

 RE: GNU support

Dear Andy,

I think this issue could be discussed in Keil forum more comprehencive than in GNU forum because this issue
is related to Keil's IDE configurations to use the GNU compiler. OK, let me ask anoder one question: below I give two configurations for Keil IDE for the same project:

1. GNU-Tool-Prefix: arm-uclibc- Cygnus Folder: C:\Cygnus

2. GNU-Tool-Prefix: arm-elf- Cygnus Folder: C:\Program Files\GNUARM\

For the 1-st configuration compilation and linking passes OK, no warnings.

For the 2-nd configuration I see in Keils IDE output window the following error messages:

/cygdrive/c/Program Files/GNUARM/Bin/../lib/gcc/arm-elf/4.2.0/../../../../arm-elf/bin/ld: ERROR: startup.o uses hardware FP, whereas LCD_GNU.elf uses software FP

/cygdrive/c/Program Files/GNUARM/Bin/../lib/gcc/arm-elf/4.2.0/../../../../arm-elf/bin/ld: failed to merge target specific data of file startup.o

Could anybody give me please a clarification on this matter?
Thanks.

 Spaces in filename!

"2. GNU-Tool-Prefix: arm-elf- Cygnus Folder: C:\Program Files\GNUARM\"

Cygnus cannot work with spaces in folder names!

Remember: Cygnus is basically unix for windows - and unix doesn't support spaces in filenames

 RE: Spaces in filename!

unix doesn't support spaces in filenames

On the contrary. Unix has supported blanks in filenames about a decade before Microsoft did.

The real problem is elsewhere: spaces in filenames wreak havoc to command line tokenization. Unix shells and tools have had the necessary quoting mechanisms to deal with that issue for ages --- the Microsoft shells had it added as a late afterthought, and it still shows.

The problems with blanks usually appear elsewhere. GUI applications that can't handle blanks in paths to external tools are just about the textbook example. So if there's a problem here, it's more likely in uVision than in Cygwin.

 RE: GNU support

"I think this issue could be discussed in Keil forum more comprehencive than in GNU forum because this issue is related to Keil's IDE configurations to use the GNU compiler."

There are two issues here:

(1). Configuring the GCC compiler;

(2). Applying those configurations via the Keil IDE (uVision).

Clearly, before you can think about (2), you have to thoroughly understand (1) - and this is where you need to go to a GCC forum!

Once you know what you're trying to achieve with the GCC compiler (independent of Keil), then (and only then), can you start thinking about how to implement that in uVision - and that's where you need this forum!

 RE: GNU support

I personally use CodeSourcery GNU toolchain
that is very well maintained. It uses no Gygwin
envronment taht is also a big advantage.
As I already mention, there are some problems with
integration into uVision.
Here you can find one of possible solutions:

http://www.keil.com/forum/docs/thread8537.asp

 Integration WinARM into Keil uVision

Dear Milos,

Thank you for your given link. I downloaded the glue tools and tried. Although I couldn't see the object files ( *.o ) as a compiler results for source files *.C ( C code ) and *.S ( assempler code, f.e. Startup.S ). I didn't see any errors or warnings ! As a result of build I saw two new files lcd_gnu.__i.gnu and startup._ia.gnu What the files these are? As these files had small sizes ( 129 bytes and 115 bytes ) I don't have any idea about these files.

Anyway here are the compilation results I have got:

Build target 'LPC2148'
compiling lcd_gnu.c...
assembling Startup.s...
linking...
"LCD_GNU.elf" - 0 Error(s), 0 Warning(s).

But..
While I tried to configure to create a hex file too, it gives the following messages:

Build target 'LPC2148'
compiling lcd_gnu.c...
assembling Startup.s...
linking...
creating hex file...
--- Error: failed to execute 'arm-glue-objcopy'
"LCD_GNU.elf" - 1 Error(s), 0 Warning(s).

Thanks.

 RE: Integration WinARM into Keil uVision

Arthur,

I have checked my version of "glue" package. It is newer than one downloaded from internet. Note that the package was written by my student and put on the web page by him.

Let me know your email address and I will send you the
latest package. This should solve your problem.

 RE: Integration WinARM into Keil uVision

Dear Milos,

Thank you for your reply.
Sorry for delaid response ( there are 3 hour time difference between Armenia and Central Europe ).
My email is:
Arthur.Khachatryan@epygiarm.am

P.S.
Anybody in forum can send me emails related to ARM processors (at this moment I am working on LPC2148).

Thanks.

 RE: Integration WinARM into Keil uVision

Anybody in forum can send me emails related to ARM processors (at this moment I am working on LPC2148).

There are more information available about ARM processors than your mailbox can handle. Most information is available on web sites and are better transmitted as links, so why a wild-card request for mail responses?

 RE: Optimisation

If you want really good results, you should move to the newest GNU releases.

E.g. this is also written on the page that I point you to:
>Code generation for Thumb mode has reportedly been >improved in GNU GCC 3.4.3...

Current version is arround 4.2. Not only compiler is improved but also libraries were optimized (and this can have a big influence to the generated code).

What is a problem is the setting of uVision environment for the newest GNU tools as you can see from many threads in the Keil forum. The settings is not as easy as for officialy supported GNU version downloaded form Keil webpages.

 RE: Optimisation

"officialy supported GNU version downloaded form Keil webpages."

I think you'll find that GCC is not actually supported by Keil at all - it's purely on a "as-is" basis.

As is generally the case with free software, of course!

 RE: Multiple Targets

Hmmm - don't know what happened there!

The post should've contained the following:

"I give two configurations for Keil IDE for the same project"

You use uVision's multiple Target facility to do this sort of thing.
See: http://www.keil.com/support/man/docs/uv3/uv3_ca_projtargfilegr.htm

 Configuring GCC via uVision

See: http://www.keil.com/support/man/docs/uv3/uv3_dg_armccp.htm

In particular, the last paragraph:

"Compiler Control String
Displays the current directives at the Compiler command line."

So you can see exactly what options the dialogue settings are passing to the Compiler!

And the penultimate paragraph:

"Misc Controls
Specify any compiler directive for which there is no individual dialog control."

So you can manually specify any settings that aren't directly supported via the dialogue.

Of course, as already noted, you need a thorough understanding of GCC and its available options to make use of these; for this, you need to study the GCC Documentation - and the best support for this is liable to be via the GCC forums...

 RE: Optimisation

Andy, you are definitely right.

Actually I wanted to say, that GNU version downloaded from Keil
webpage works correctly with uVision.
This is not the case with newer versions.

Sorry for confusing formulation.

 RE: Optimisation

"Remember: Cygnus is basically unix for windows - and unix doesn't support spaces in filenames"

Unix doesn't have any problems with spaces. It just has a different way of handling them than broken Windoze. If the path is encapsulated in quotes or the space is prefixed by a break character, they will be processed ok.

This requirement is needed to make sure that a path is always processed the same way, insted of the OS trying to auditected if the space is a separator or part of a name.

 RE: Unix doesn't have any problems with spaces

I stand corrected.

"If the path is encapsulated in quotes they will be processed ok."

That should also apply to the windoze command line.

However, in the past, uVision-2 had problems with correctly doing the encapsulation.

I don't know if those problems were ever fixed in uVision-2, nor if uVision-3 has inherited them - I just play it safe and never use spaces in path and/or filenames where the Keil tools are concerned.

Many other toolsets have similar problems (including those that use Cygwin) so my general principle is never use spaces in path and/or filenames.
At least that way you know that you're safe!

 Spaces in Folder Names

See this Microsoft article for how to change the 'My Documents' folder name - eg, to something without that stupid space:
http://support.microsoft.com/kb/310147/en-us

I have successfully done this on 2 systems now.

But is there a way to similarly rename 'Program Files'...?

See: http://www.8052.com/forum/read.phtml?id=138965

 RE: Spaces in Folder Names

Hmm. "auditected" must be the most interesting spelling error I have managed in a while. Sounds like it has something to do with audio...

I really can't see how I could have managed to convert "autodetected" to "auditected" :)

 RE: auditected

And I didn't even notice it!

Have you been borrowing Erik's kyeborad...?!

;-)

 RE: auditected

Yes, it is probably contagious :)

 RE: Spaces in Folder Names

A problem here is that some programs do follow the M$ guilelines how to access "My Documents" and some just hard-code "C:\My Documents\".

Since a Win system that has been up for a couple of years and having a lot of programs installed tends to be a bit fragile, it is extra hard to know if that fragility is caused by the system or by individual applications being buggy and making assumptions that they are not allowed to make.

 undefined reference to '_start', undefined reference to '_data'

Dear Andy,

Even i copied target.ld file into project root directory, i am having the same problem,

startup.o(.text+0xf0):/cygdrive/c/Keil/ARM/GNU/Examples/Blinky/Startup.s:167: undefined reference to '_data'

Please help me

Karuna

 RE: undefined reference to '_start', undefined reference to '_data'

"Even i copied target.ld file into project root directory"

It's nothing to do with file location - the message would say something about file location, or file not found, if that were the case.

As previously explained, it's telling you that you have referred to a symbol '_data' but haven't provided any definition for that symbol.

Where do you think that symbol should be defined?
Have you checked to see if it is defined?

 RE: undefined reference to '_start', undefined reference to '_data'

I would like to express my thanks to all members who has been taken a participation on discussing of this topic. Special thanks to Milos Drutarovsky. Thank you Milos very much for your help. I got the code compiled and linked. I got the hex file and have burned onto target's flash. Unfortunately I couldn’t get the code started on target. I don't know what the reason is?
Maybe it has been related to additional options setting for linker? The same project runs while it was compiled by Keil compiler. When I change set the uVision for using of GNU compiler, the code doesn't run on target (LPC2148).