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.
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.
"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/
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?"
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.
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...
I recommend to read the following link:
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.
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.
For GCC support, you'd probably be better going to a GCC forum