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)). Michael Kellett
Replace Keil/ARM tools
Started by ●May 14, 2014
Reply by ●May 14, 20142014-05-14
On 14.5.14 15:34, 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)). > > Michael KellettYou cannot beat the price/preformance ratio of the GUN toolset, often calle by the C compiler as GCC. There are several ready- made sets for different compilation host computers, e.g. Yagarto. If you need an IDE, the same applies to Eclipse. 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. -- Tauno Voipio
Reply by ●May 14, 20142014-05-14
On Wed, 14 May 2014 17:33:25 +0300, Tauno Voipio wrote:> On 14.5.14 15:34, 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)). >> >> Michael Kellett > > > You cannot beat the price/preformance ratio of the GUN toolset, often > calle by the C compiler as GCC. There are several ready- made sets for > different compilation host computers, e.g. Yagarto. > > If you need an IDE, the same applies to Eclipse. 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.I second this. GNU/GCC, newlib, Eclipse and OpenOCD. They all play nicely together. There are volumes of information on the web about how to set this up. I started with Yagarto on Win XP. This was done because I had a dev board and LPCxpresso (code red). I then moved everything back to Linux with a built from source GCC tool set. In my option there is no reason to pay that kind of money for a tool set when you can spend maybe a day and get a free tool chain working. And you have complete control over the tool chain. -- Chisolm Republic of Texas
Reply by ●May 14, 20142014-05-14
On Wed, 14 May 2014 13:34:03 +0100, MK <mk@nospam.co.uk> wrote:>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)).I've been happy with Rowley's CrossWorks. It's gcc-based but with custom libraries. There's a 30-day trial license and excellent support from Paul and Jon and the team. They're located in Glust... Gloust... Gloster... (hell) somewhere over on your side of the pond.
Reply by ●May 14, 20142014-05-14
On Wed, 14 May 2014 17:33:25 +0300, Tauno Voipio wrote:> On 14.5.14 15:34, 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)). >> >> Michael Kellett > > > You cannot beat the price/preformance ratio of the GUN toolset, often > calle by the C compiler as GCC. There are several ready- made sets for > different compilation host computers, e.g. Yagarto. > > If you need an IDE, the same applies to Eclipse. 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.And when something breaks, you end up spending about as much time fixing it as you would yelling at one of those $3000/year "service contract" places to return your emails. Without, note, having to spend $3000/year for the privilege. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●May 14, 20142014-05-14
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. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
Reply by ●May 15, 20142014-05-15
On 14/05/14 22:37, Tim Wescott 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 agree with your principle here, though my experience with CodeSourcery is that you don't get ignored by a customer service department - you get answered by their technical guys, who are heavily involved in the real gcc development (CodeSourcery has always been a major part of gcc development - not just gcc repackagers). For many people, it can be easier to work with a pre-packaged gcc/eclipse system. Most of the Cortex manufacturers have a preferred tool (such as CodeSourcery, CodeRed, etc.), or make their own (such as Freescale CodeWarrior and now KDS), and most are cheap or free. Pre-packaged toolsets can make it easier to get started, and easier to get debugging to work, but can make it harder if you want to move to devices from a different manufacturer. But you have to have very good reasons these days before spending multiple K$ on toolchains from the "big" vendors, at least in the ARM world. When some of these (I mention no names) are known to have bigger support departments for handling licensing and dongle issues than for handling compiler questions, you have to wonder what you pay for. In a related issue, it seems that ARM is dropping their own proprietary compiler for future versions of their tools, and moving to llvm/clang (the other big open source compiler, and "competitor" to gcc). I don't know if they plan to fix their drivers or other code, and I doubt if they will reduce the price, but they expect to generate better code.
Reply by ●May 15, 20142014-05-15
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. 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 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.> 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 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, Dave
