Hi ,
I am a relatively new in embedded systems and have so far only used ARM realview tool chian , tool chains for TI DSPs and GNU tool chain. But I have not encountered many problems with either yet ( most probably due to lack of experience :-( ) . Can any one tell me thier better or sweet experiences using GNU toolchain for embedded software development?
Thanks
Rate
In article , ratemonotonic writes
It depends.
On your target. What you are making. What if any standards you have to work to. What if any product liability there is.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Anything that comes with : a) Hardware support after sale. b) Active mailing list. d) Good documentation. e) Tools that can be replaced with similar tools is a BIG advantage. f) Finally, I'd prefer tool chain that comes with less patches;) from kernel to libraries.
ali
I've been using nothing but Gnu tools for embedded work for 10 years (ARM, H8, MSP430, NIOS2). Couldn't be happier with them.
--
Grant Edwards grante Yow! Let's send the
at Russians defective
visi.com lifestyle accessories!
in your experience is GNU tools easyly replaceble by other commercial tool ?
If you design your code with this in mind in the first place, then - yes. The FreeRTOS.org code compiles with GCC, Keil/Keil, IAR, Keil/RVDS, Rowley (GCC with different project management and IDE), Raisonance (GCC with different project management and IDE).
-- Regards, Richard. + http://www.FreeRTOS.org A free real time kernel for 8, 16 and 32bit systems. + http://www.SafeRTOS.com An IEC 61508 compliant real time kernel for safety related systems.
..... not to mention all the non-ARM compilers.
-- Regards, Richard. + http://www.FreeRTOS.org A free real time kernel for 8, 16 and 32bit systems. + http://www.SafeRTOS.com An IEC 61508 compliant real time kernel for safety related systems.
Yep. Me too. The only exceptions are when clients use micros that aren't supported by GCC.
-- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
I've been lucky. :)
I came pretty close to chosing a Mitsubishi M16C part a few years ago (for which you couldn't even find commercial tools hosted on Linux), but the Hitachi H8/300 solution turned out to be a little cheaper (and has a much nicer memory model).
--
Grant Edwards grante Yow! Now I'm concentrating
at on a specific tank battle
visi.com toward the end of World
War II!
Some previous comments on this:
this:
Thanks a lot ! reading the comments and the links I have a lot more confidence in using GNU tools. FreeRTOS is a great site !
Well! it depends, if you stick to genuine GNU thing then chances are vital to get replacement of required tools. But if someone want you to buy proprietary software with GNU suit then its different story;)
ali
In theory you can fix that.
Maybe even in practice if you can find a supported one that is not too distant architecturally.
I "could", but I *do* have a life (family, etc ;-) I figure that if the device mfg want their micro to thrive, or the community thinks it should, then it will happen.
Although it's been done with some "interesting" architectures, GCC may not be easily portable to some micro-controller architectures. It is
*basically* targeted at higher end 32-bit stuff, though there are many exceptions. It also likes single address space RISC like architectures, better than others.At 50 years of age, I've learned that I really don't have time to do *everything* myself ;-)
-- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
... snip ...
You're quick. It took me longer. :-)
--
cbfalconer at maineline dot net
It seems to port well to CPUs with 16-bit address spaces like the 6812 and the MSP430. It helps that those CPUs handle
16-bit quantities well. If you look at the code gcc generates for something like the AVR, it's a bit more painful.It deals pretty well with CISC architectures like the IA32,
68K, VAX, etc. In fact I think most of the earlier ports were for CISC machines. The RISC ports were more recent.
Sad but true.
--
Grant Edwards grante Yow! Didn't I buy a 1951
at Packard from you last March
visi.com in Cairo?
Damn! I have just four days to learn *something*.
Peter
One of the key points is that the gcc model works well when you have lots of similar registers. It's not the RISC style cpu that is the particular requirement, but multiple symmetric registers a characteristic commonly associated with RISC. For example, the 68k is a CISC architecture, but it has many RISCy features, such as multiple registers.
And the i386 target is an exceptional case for gcc - it is not a natural fit for gcc's models, but generates good code as a result of a huge effort in optimising the compiler for the i386.
David , Could you expand on 'similar registers' I dont understand. Rate
On the 68k, for example, there are eight data registers D0 .. D7, all of which can be used in exactly the same way at any time. Similarly, address registers A0 .. A6 are identical. ABI and compiler conventions use specific registers for specific purposes, but this is not enforced by the cpu, and the compiler has a free choice. Compare this to a true CISC processor like the i386, whose data registers A, B, C and D have different purposes and different instructions.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.