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

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.

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.

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.

"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!

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 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.

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?

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

Apparently not!

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.

"... 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...?

"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?"