On Fri, 16 May 2014 21:10:07 +0100, Mike Perkins wrote: << snip >>> OpenOCD (though reverted back to 0.6.0 due to > bugs) I feel I have a pleasant and effective IDE.<< snip more >> What bugs? Have you tried 0.8.0 yet? Do you like it? (I'm using 0.7.0, and it's working well for me). -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Replace Keil/ARM tools
Started by ●May 14, 2014
Reply by ●May 16, 20142014-05-16
Reply by ●May 16, 20142014-05-16
On 16/05/2014 21:30, Tim Wescott wrote:> On Fri, 16 May 2014 21:10:07 +0100, Mike Perkins wrote: > > << snip >> > >> OpenOCD (though reverted back to 0.6.0 due to >> bugs) I feel I have a pleasant and effective IDE. > > << snip more >> > > What bugs? Have you tried 0.8.0 yet? Do you like it? > > (I'm using 0.7.0, and it's working well for me).I'm currently playing with USB / ULPI / FPGA at the moment. I haven't had a chance to look at 0.8.0. Is it very different? Just that to the uninitiated, OpenOCD is either something that does work, or just doesn't; without any explanation why!! I can't recall precisely the problems with 0.7.0 but loading and reset gave unpredictable results. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
Reply by ●May 16, 20142014-05-16
On Fri, 16 May 2014 22:19:21 +0100, Mike Perkins wrote:> On 16/05/2014 21:30, Tim Wescott wrote: >> On Fri, 16 May 2014 21:10:07 +0100, Mike Perkins wrote: >> >> << snip >> >> >>> OpenOCD (though reverted back to 0.6.0 due to bugs) I feel I have a >>> pleasant and effective IDE. >> >> << snip more >> >> >> What bugs? Have you tried 0.8.0 yet? Do you like it? >> >> (I'm using 0.7.0, and it's working well for me). > > I'm currently playing with USB / ULPI / FPGA at the moment. I haven't > had a chance to look at 0.8.0. Is it very different? Just that to the > uninitiated, OpenOCD is either something that does work, or just > doesn't; without any explanation why!! > > I can't recall precisely the problems with 0.7.0 but loading and reset > gave unpredictable results.I haven't used 0.8.0 yet. I have it on a machine, but haven't used it. I can't even remember what the changes were -- I was just curious if your problems continued on 0.8.0. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●May 17, 20142014-05-17
John Devereux <john@devereux.me.uk> wrote:> There is also the ARM gcc distribution from ARM themselves: > > <https://launchpad.net/gcc-arm-embedded> > <https://launchpadlibrarian.net/170926122/readme.txt> > > I have been using this successfully for a year or so (unsupported, only > support is by forum AFAICT). Last time I looked it came with more > libraries than the free versions of codesourcery, e.g. hard floating > point for CM4.The slightly weird thing about that is that IIRC ARM contracted CodeSourcery to provide a free toolchain, but in order to not upset other compiler vendors, it could not include hardfp support.> It comes with "newlib nano", an attempt to reduce the footprint of > newlib with e.g. option for no-floating point printf.ARM engineers have been feeding some of the optimizations back into Newlib. Newlib has I think always had integer-only versions of the formatted input and output functions (iprintf and friends), but they still have a pretty large footprint. -a
Reply by ●May 17, 20142014-05-17
On Thu, 15 May 2014 23:49:50 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 15/05/14 21:02, Arlet Ottens wrote: >> On 05/15/2014 08:05 PM, boB wrote: >> >>>>> But doesn't IAR and Keil have 15 to 20% better code compiling >>>>> efficiency for size and speed over GCC ? That is what I have heard >>>>> anyway. >>>> >>>> Who told you that? IAR or Keil? Both are well known for using >>>> out-of-date versions of gcc and carefully picked samples to "prove" how >>>> much better they are than gcc. They are wary about using the same >>>> tricks against each others (or alternatives such as GHS), because they >>>> will get sued - but condemning gcc is fair game in the eyes of their >>>> marketing folk. No one independent can give any sort of objective >>>> comparisons, because the licensing for IAR, Keil (and most other >>>> commercial compilers for most targets) forbids it - and if anyone with >>>> any influence tried it, they would be sued. >>>> >>>> In reality, it is not unlikely that you will get 15-20% smaller and/or >>>> faster code with IAR or Keil than gcc for /some/ code samples - and gcc >>>> will be smaller and/or faster for others. The variation can be >>>> significant, and it can depend on small details in the code, and details >>>> in the code generation options. But there is certainly no general rule >>>> that these compilers have better code generation than gcc. If you need >>>> to know real numbers, you have no choice but to try it out yourself on >>>> your own code. >>> >>> >>> Interesting info, thanks. >>> I don't think that 15 to 20% was from either of those companies but >>> was from a couple of people on the Yahoo LPC2000 tech list. >>> >>> I sure wish I could test the theory easily. I suppose I could strip >>> the code way down to try part of it though. I may have to sometime. >>> >>> I hate having to pay ransom and especially when a hard drive fails and >>> a software key goes kaput and IAR only replaces it once before they >>> want the many years of back-ransom $$. >>> >>> I would think though that some third party or someone would have done >>> what I would like to do and really compare 2 or 3 or those with a >>> semi-large project. I forsee a lot of time and effort to do that even >>> with C being a portable source format. >>> >>> I may try stripping a lot of code out and see if I can get my stuff to >>> compile with GCC. >>> >> >> Keep in mind that compiler efficiency is not the only thing. There can >> also be quite a bit of performance difference in the compiler libraries. > >And of course there are lots of other reasons to pick different >compilers - different library features, different debuggers, different >RTOS support, different profiling tools, different test quality >certifications, etc. > >You can't get third-party comparisons that can give more than a rough >idea - they cannot (normally) legally publish benchmarks from the big >commercial compilers, and they cannot test with /your/ code. The best >that can be done is a comparison with gcc, llvm, and "commercial >compiler 1", "commercial compiler 2", etc.That's OK. Since there are only 2 commercial compilers for ARM that I know of, and they are both pretty good AFAIK that title should work well for that. So, from what I am hearing, nobody has done a comparison of a large-ish project that we can hear about here. boB
Reply by ●May 18, 20142014-05-18
Anders.Montonen@kapsi.spam.stop.fi.invalid writes:> John Devereux <john@devereux.me.uk> wrote: >> There is also the ARM gcc distribution from ARM themselves: >> >> <https://launchpad.net/gcc-arm-embedded> >> <https://launchpadlibrarian.net/170926122/readme.txt> >> >> I have been using this successfully for a year or so (unsupported, only >> support is by forum AFAICT).Looking back at the above, "unsupported" is wrong; forum support can be adequate especially when the authors participate as in this case. And it is gcc; the answer to any question I have had is a google search away in any case.>> Last time I looked it came with more >> libraries than the free versions of codesourcery, e.g. hard floating >> point for CM4. > > The slightly weird thing about that is that IIRC ARM contracted > CodeSourcery to provide a free toolchain, but in order to not upset > other compiler vendors, it could not include hardfp support.Oh really? I did not know that. It is just an edit to a config file anyway, when building from source ("multilibs"). This sort of nonsense is annoying. I expect it is the reason the ST gcc code examples only build with someones proprietary packaging of gcc. Instead of a Makefile, say.>> It comes with "newlib nano", an attempt to reduce the footprint of >> newlib with e.g. option for no-floating point printf. > > ARM engineers have been feeding some of the optimizations back into > Newlib. Newlib has I think always had integer-only versions of the > formatted input and output functions (iprintf and friends), but they > still have a pretty large footprint.I think you use linker flags to choose a cut-down printf. Not sure of the details, I use my own "formatted output" functions myself.> > -a-- John Devereux
Reply by ●May 18, 20142014-05-18
On 18/05/14 00:20, boB wrote:> On Thu, 15 May 2014 23:49:50 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 15/05/14 21:02, Arlet Ottens wrote: >>> On 05/15/2014 08:05 PM, boB wrote: >>> >>>>>> But doesn't IAR and Keil have 15 to 20% better code compiling >>>>>> efficiency for size and speed over GCC ? That is what I have heard >>>>>> anyway. >>>>> >>>>> Who told you that? IAR or Keil? Both are well known for using >>>>> out-of-date versions of gcc and carefully picked samples to "prove" how >>>>> much better they are than gcc. They are wary about using the same >>>>> tricks against each others (or alternatives such as GHS), because they >>>>> will get sued - but condemning gcc is fair game in the eyes of their >>>>> marketing folk. No one independent can give any sort of objective >>>>> comparisons, because the licensing for IAR, Keil (and most other >>>>> commercial compilers for most targets) forbids it - and if anyone with >>>>> any influence tried it, they would be sued. >>>>> >>>>> In reality, it is not unlikely that you will get 15-20% smaller and/or >>>>> faster code with IAR or Keil than gcc for /some/ code samples - and gcc >>>>> will be smaller and/or faster for others. The variation can be >>>>> significant, and it can depend on small details in the code, and details >>>>> in the code generation options. But there is certainly no general rule >>>>> that these compilers have better code generation than gcc. If you need >>>>> to know real numbers, you have no choice but to try it out yourself on >>>>> your own code. >>>> >>>> >>>> Interesting info, thanks. >>>> I don't think that 15 to 20% was from either of those companies but >>>> was from a couple of people on the Yahoo LPC2000 tech list. >>>> >>>> I sure wish I could test the theory easily. I suppose I could strip >>>> the code way down to try part of it though. I may have to sometime. >>>> >>>> I hate having to pay ransom and especially when a hard drive fails and >>>> a software key goes kaput and IAR only replaces it once before they >>>> want the many years of back-ransom $$. >>>> >>>> I would think though that some third party or someone would have done >>>> what I would like to do and really compare 2 or 3 or those with a >>>> semi-large project. I forsee a lot of time and effort to do that even >>>> with C being a portable source format. >>>> >>>> I may try stripping a lot of code out and see if I can get my stuff to >>>> compile with GCC. >>>> >>> >>> Keep in mind that compiler efficiency is not the only thing. There can >>> also be quite a bit of performance difference in the compiler libraries. >> >> And of course there are lots of other reasons to pick different >> compilers - different library features, different debuggers, different >> RTOS support, different profiling tools, different test quality >> certifications, etc. >> >> You can't get third-party comparisons that can give more than a rough >> idea - they cannot (normally) legally publish benchmarks from the big >> commercial compilers, and they cannot test with /your/ code. The best >> that can be done is a comparison with gcc, llvm, and "commercial >> compiler 1", "commercial compiler 2", etc. > > > That's OK. Since there are only 2 commercial compilers for ARM that I > know of, and they are both pretty good AFAIK that title should work > well for that.For "big name" commercial ARM compilers, there is ARM/Keil (though it will be replaced by llvm), IAR, Green Hills, CodeWarrior (though gcc is the default now). There are also "small" commercial compilers such as ImageCraft. I don't have a complete list, but that's 5 independent commercial compilers for ARM that I know of. I can't give any indication of their quality for code generation or as tools in general (even if it was allowed by their licenses!) - I simply haven't used them.> > So, from what I am hearing, nobody has done a comparison of a > large-ish project that we can hear about here.Correct. If you are planning a big project for which these tools are a possible choice, it should not be hard to get evaluation versions - but expect to spend quite a bit of your time if you want to get a fair test.> > boB > >
Reply by ●May 19, 20142014-05-19
Mike Perkins <spam@spam.com> writes:> [...] > Coupled with Eclipse, OpenOCD (though reverted back to 0.6.0 due to > bugs) I feel I have a pleasant and effective IDE.I get very confused on which JTAGs/debugger interfaces OpenOCD will work with. E.g., how about the following (some of my immediate work and/or possibilities): 1. TI Tiva tm4c1294ncpdt 2. Freescale Coldfire MCF52235 3. Freescale Ketis K6x 4. TI Sitara AM335x ??? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●May 19, 20142014-05-19
Randy Yates <yates@digitalsignallabs.com> writes:> 3. Freescale Ketis K6xKinetis -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●May 19, 20142014-05-19
Actually, let me ask a very naive question: Can one even use a debugger with a largish process/OS like the AM335x/linux? I mean, what happens if you break in some time-critical portion of the linux kernel? --RY Randy Yates <yates@digitalsignallabs.com> writes:> Mike Perkins <spam@spam.com> writes: >> [...] >> Coupled with Eclipse, OpenOCD (though reverted back to 0.6.0 due to >> bugs) I feel I have a pleasant and effective IDE. > > I get very confused on which JTAGs/debugger interfaces OpenOCD will work > with. E.g., how about the following (some of my immediate work and/or > possibilities): > > 1. TI Tiva tm4c1294ncpdt > > 2. Freescale Coldfire MCF52235 > > 3. Freescale Ketis K6x > > 4. TI Sitara AM335x > > ???-- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
