MK <mk@nospam.co.uk> wrote:> We had seen the odd hard fault and today pinned it down - the UART > driver is GARBAGE ! It uses a circular buffer and will fall over (hard > fault the processor) every time an incoming message wraps round the end > of the buffer. We didn't see it at first because the device sending data > happens to use 8 byte packets but as soon as we started real testing for > exceptions the fault was obvious.Is the driver actually Keil's handiwork, or was it part of the chip vendor's support libraries? I haven't used MDK5, but in previous versions most of the bundled support software was simply the same libraries you could grab from the chip vendor's website (except slightly outdated). The quality of those libraries can be... /varying/. -a
Replace Keil/ARM tools
Started by ●May 14, 2014
Reply by ●May 15, 20142014-05-15
Reply by ●May 15, 20142014-05-15
On Thu, 15 May 2014 13:54:00 +0200, David Brown <david.brown@hesbynett.no> wrote:>On 15/05/14 09:24, boB wrote: >> On Wed, 14 May 2014 15:37:53 -0500, Tim Wescott >> <tim@seemywebsite.please> wrote: >> >>> On Wed, 14 May 2014 13:34:03 +0100, MK wrote: >>> >>>> For many years I've been using Keil/ARM's C compiler. Recently we >>>> started using the so called 'middleware' which was, to put it at its >>>> best, a rather mixed experience. >>>> >>>> They have just released (couple of months ago) version 5 of their tool >>>> set which includes a software component packaging system and the full >>>> ARM CMSIS API with drivers for many processors. >>>> >>>> The CMSIS API is rather limited but we gave it a good try and have >>>> developed a real system with it. >>>> >>>> We had seen the odd hard fault and today pinned it down - the UART >>>> driver is GARBAGE ! It uses a circular buffer and will fall over (hard >>>> fault the processor) every time an incoming message wraps round the end >>>> of the buffer. We didn't see it at first because the device sending data >>>> happens to use 8 byte packets but as soon as we started real testing for >>>> exceptions the fault was obvious. >>>> >>>> In this case we were able to extract the offending driver from the >>>> packaging system, work out what was wrong and fix it but our confidence >>>> level in code supplied by Keil/ARM is now zero. >>>> >>>> I'm kind of cross about this, since the price of this POS is about �7000 >>>> with annual maintenance at about �1400. >>>> >>>> I'm ready to dump it. >>>> >>>> So, I'm looking for suggestions - it would be nice if we could still >>>> have decent debugging using the ARM ETM (yes we have a ULink Pro >>>> (�825)). >>> >>> gnu/Eclipse/OpenOCD. >>> >>> Why pay someone else a big pile of money to screw it up when you're >>> perfectly capable of screwing it up for free? >>> >>> If you really feel like you need to shell out $$$ (or pounds sterling) >>> for the privilege of being ignored by a customer service department, then >>> go with CodeSourcery or one of the other gnu/gcc packagers out there. >> >> >> I've been using IAR EWARM for years now. I feel his pain about the >> ransom $ for support, etc. (or used to when we had issues) but it >> works pretty well usually. >> >> 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. boB> >> You know how important that usually is when you don't have a >> lot of flash and RAM to begin with. We tend to use these parts to the >> max. (NXP ARM and Cortex M0/M3 parts). We use Code Red on the M0 part >> for another prouct that doesn't use all of the peripherals. >> >> boB >> K7IQ >> >>
Reply by ●May 15, 20142014-05-15
On Thu, 15 May 2014 06:18:05 -0700, Dave Nadler wrote:> On Wednesday, May 14, 2014 4:37:53 PM UTC-4, Tim Wescott wrote: >> ...If you really feel like you need to shell out $$$ (or pounds >> sterling) >> for the privilege of being ignored by a customer service department, >> then go with CodeSourcery or one of the other gnu/gcc packagers out >> there. > > I had really excellent support from CodeSourcery. > They promptly fixed a bug I found and answered some difficult questions > regarding MIPS startup. > This was prior their acquisition by Mentor. > > As always your mileage may vary... > Best Regards, DaveI can see that I was hasty about condemning CodeSourcery. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●May 15, 20142014-05-15
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.
Reply by ●May 15, 20142014-05-15
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.
Reply by ●May 15, 20142014-05-15
On 15/05/14 20:59, Tim Wescott wrote:> On Thu, 15 May 2014 06:18:05 -0700, Dave Nadler wrote: > >> On Wednesday, May 14, 2014 4:37:53 PM UTC-4, Tim Wescott wrote: >>> ...If you really feel like you need to shell out $$$ (or pounds >>> sterling) >>> for the privilege of being ignored by a customer service department, >>> then go with CodeSourcery or one of the other gnu/gcc packagers out >>> there. >> >> I had really excellent support from CodeSourcery. >> They promptly fixed a bug I found and answered some difficult questions >> regarding MIPS startup. >> This was prior their acquisition by Mentor. >>I haven't had much contact with CodeSourcery since they were bought by Mentor, but it certainly seems successful enough. I heard only positive things about it - I think the CodeSourcery folks viewed it as letting them get on with the compiler development, and let the Mentor folks worry about sales, marketing, and where the next paycheck was coming from.>> As always your mileage may vary... >> Best Regards, Dave > > I can see that I was hasty about condemning CodeSourcery. >If you look on the gcc contributors list, mailing lists, maintainers, release managers, etc., you will see CodeSourcery email addresses everywhere. I have never noticed a Code Red or Rowley entry - though of course they could be posting under different names, and I certainly don't see /everything/. But CodeSourcery are in a different class from other gcc toolchain packagers - you might or might not like their packages and their prices, but you can be sure their technical folks know gcc better than almost anyone else around, and at least part of your money goes right back into gcc development.
Reply by ●May 15, 20142014-05-15
On 2014-05-14, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:> You cannot beat the price/preformance ratio of the GUN toolset,I've been using GCC for embedded ARM stuff for 15 years now. Never regretted it for a second.> often called by the C compiler as GCC. There are several ready- made > sets for different compilation host computers, e.g. Yagarto.Building it yourself from sources isn't really that hard either.> If you need an IDE, the same applies to Eclipse.I'm an emacs guy, but you can use whatever you like -- that's the nice thing about avoiding lock-in by a vendor.> It needs some work to set up, but there are good instructions in the > Net. > > For debugging, I'm using an USB-JTAG dongle and OpenOCD > with the GNU debugger, GDB.Yep. There are a variety of frontends for gdb: Eclipse, DDD, emacs, KDbg, and a handful of others whose names escape me. [Is the Tcl/Tk based one that used to be "included" with gdb sources still around?]. A few years ago I remember hearing a lot of good things about Rowly CrossWorks (gcc/binutils ARM toolchain with proprietary debugger and libraries). -- Grant
Reply by ●May 16, 20142014-05-16
On 16/05/14 02:17, Grant Edwards wrote:> On 2014-05-14, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote: > >> You cannot beat the price/preformance ratio of the GUN toolset, > > I've been using GCC for embedded ARM stuff for 15 years now. Never > regretted it for a second. > >> often called by the C compiler as GCC. There are several ready- made >> sets for different compilation host computers, e.g. Yagarto. > > Building it yourself from sources isn't really that hard either. > >> If you need an IDE, the same applies to Eclipse. > > I'm an emacs guy, but you can use whatever you like -- that's the nice > thing about avoiding lock-in by a vendor. > >> It needs some work to set up, but there are good instructions in the >> Net. >> >> For debugging, I'm using an USB-JTAG dongle and OpenOCD >> with the GNU debugger, GDB. > > Yep. There are a variety of frontends for gdb: Eclipse, DDD, emacs, > KDbg, and a handful of others whose names escape me. [Is the Tcl/Tk > based one that used to be "included" with gdb sources still around?].You mean "Insight"? I believe it is no longer included in modern gdb, and the last version of gdb with Insight does not work with the latest version of OpenOCD as it supports newer methods of talking to gdb. That's the disadvantage of having the gui tied into gdb itself. There are a number of other IDEs that support debugging via gdb, such as jedit and Code Blocks, as well as gvd (I used to like that one) which is part of GPS, the GNAT Programming System for those that like Ada on their ARMs.> > A few years ago I remember hearing a lot of good things about Rowly > CrossWorks (gcc/binutils ARM toolchain with proprietary debugger and > libraries). >
Reply by ●May 16, 20142014-05-16
On 15/05/2014 15:07, Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:> MK <mk@nospam.co.uk> wrote: >> We had seen the odd hard fault and today pinned it down - the UART >> driver is GARBAGE ! It uses a circular buffer and will fall over (hard >> fault the processor) every time an incoming message wraps round the end >> of the buffer. We didn't see it at first because the device sending data >> happens to use 8 byte packets but as soon as we started real testing for >> exceptions the fault was obvious. > > Is the driver actually Keil's handiwork, or was it part of the chip > vendor's support libraries? I haven't used MDK5, but in previous > versions most of the bundled support software was simply the same > libraries you could grab from the chip vendor's website (except slightly > outdated). The quality of those libraries can be... /varying/. > > -a >The driver file in question says: * Copyright (C) 2013 ARM Limited. All rights reserved. * * $Date: 12. September 2013 * $Revision: V1.01 * * Driver: Driver_UART1, Driver_UART2, Driver_UART3, * Driver_UART4, Driver_UART5, Driver_UART6 * Configured: via RTE_Device.h configuration file * Project: Middleware UART Driver for ST STM32F4xx at the top of the file so it can't be blamed on ST ! I was kind of hoping that some Keil/ARM bods might hang out here and raise their heads above the parapet. Thanks all for suggestions, but so far none that are free, open source and support the Cortex ETM. Rowley has got pricey ($1500 per seat, $300 for a Ulink like debug interface that you can get for $25 from Amazon) and CodeSourcery seems to be $1000 - $3000+ depending on edition. So if anyone has some ideas about the tracing I'd be really interested. Michael Kellett
Reply by ●May 16, 20142014-05-16
David Brown <david.brown@hesbynett.no> writes:> On 15/05/14 20:59, Tim Wescott wrote: >> On Thu, 15 May 2014 06:18:05 -0700, Dave Nadler wrote: >> >>> On Wednesday, May 14, 2014 4:37:53 PM UTC-4, Tim Wescott wrote: >>>> ...If you really feel like you need to shell out $$$ (or pounds >>>> sterling) >>>> for the privilege of being ignored by a customer service department, >>>> then go with CodeSourcery or one of the other gnu/gcc packagers out >>>> there. >>> >>> I had really excellent support from CodeSourcery. >>> They promptly fixed a bug I found and answered some difficult questions >>> regarding MIPS startup. >>> This was prior their acquisition by Mentor. >>> > > I haven't had much contact with CodeSourcery since they were bought by > Mentor, but it certainly seems successful enough. I heard only > positive things about it - I think the CodeSourcery folks viewed it as > letting them get on with the compiler development, and let the Mentor > folks worry about sales, marketing, and where the next paycheck was > coming from. > >>> As always your mileage may vary... >>> Best Regards, Dave >> >> I can see that I was hasty about condemning CodeSourcery. >> > > If you look on the gcc contributors list, mailing lists, maintainers, > release managers, etc., you will see CodeSourcery email addresses > everywhere. I have never noticed a Code Red or Rowley entry - though > of course they could be posting under different names, and I certainly > don't see /everything/. But CodeSourcery are in a different class > from other gcc toolchain packagers - you might or might not like their > packages and their prices, but you can be sure their technical folks > know gcc better than almost anyone else around, and at least part of > your money goes right back into gcc development.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. It is regularly updated, it seems to stay one version behind mainline gcc with a few bugfixes from themselves and backported from mainline. It comes with "newlib nano", an attempt to reduce the footprint of newlib with e.g. option for no-floating point printf. There are also some simple c++ and semihosting examples, which work out of the box. Two things I never got around to with my own builds of gcc, so interesting just for that. -- John Devereux
