Replace Keil/ARM tools

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 ready to dump it.

So, I'm looking for suggestions - it would be nice if we could still

Michael Kellett

Reply to
MK
Loading thread data ...

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.

--

Tauno Voipio
Reply to
Tauno Voipio

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 to
Joe Chisolm

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 to
Rich Webb

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 
 Click to see the full signature
Reply to
Tim Wescott

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 
 Click to see the full signature
Reply to
Tim Wescott

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 to
David Brown

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 to
boB

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.

Reply to
David Brown

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

Reply to
Dave Nadler

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

Reply to
Anders.Montonen

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

Reply to
boB

I can see that I was hasty about condemning CodeSourcery.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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 to
Arlet Ottens

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 to
David Brown

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.

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 to
David Brown

I've been using GCC for embedded ARM stuff for 15 years now. Never regretted it for a second.

Building it yourself from sources isn't really that hard either.

I'm an emacs guy, but you can use whatever you like -- that's the nice thing about avoiding lock-in by a vendor.

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 to
Grant Edwards

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.

Reply to
David Brown

The driver file * 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 to
MK

There is also the ARM gcc distribution from ARM themselves:

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
Reply to
John Devereux

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.