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.
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
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.
"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
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.
"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!
"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!
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
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.
"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.
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.
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!
See this Microsoft article for how to change the 'My Documents' folder name - eg, to something without that stupid space: support.microsoft.com/.../en-us
I have successfully done this on 2 systems now.
But is there a way to similarly rename 'Program Files'...?
See: www.8052.com/.../read.phtml
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" :)
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.