Keil MDK unaffordable

The Keil MDK software development environment seems seems amazingly affordable. Maybe barely affordable ($2.5k) for a specific processor, for a one-year license, but this assumes you'll be willing to forgo supporting your project a short 12 months after you begin thinking about working on it, and buy the license. It appears to be 4 to $5k for a perpetual license, but this is only for a specific version of somebody's specific processor model -- cough up new massive bucks for any new versions. I'm not even sure $10k gets you properly into the game, there are so many subdivisions and variations, each separately and highly priced. Are we talking $30k or more? Am I somehow wrong about this?

--
 Thanks, 
    - Win
Reply to
Winfield Hill
Loading thread data ...

Welcome to life in the fast lane.

Reply to
krw

dable.

ect a

only

new

erly

tely

t this?

In a nutshell - yes, you're wrong. The perpetual pro version (all arm vari

t (say the cortex M family) then they have lower cost solutions. See

formatting link

only

new

Perhaps the new distribution model where you only download support files fo r the processors you are interested in is confusing you.

For anyone developing products for ARM I would highly recommend Keil. Supp ort, should you need it, is first class.

Reply to
sunaeco

Keil was always top dollar, even back in the 90's the C51 was $3k for a perpetual license.

Cheers

Reply to
Martin Riddle

There's a reason I use gcc. And support, once you get past the notion that you have to pay for it, is superlative.

--
Tim Wescott 
Control systems, embedded software and circuit design 
I'm looking for work!  See my website if you're interested 
http://www.wescottdesign.com
Reply to
Tim Wescott

It's not quite that bad. The first question is to determine how many processor FAMILIES you are likely interested in. E.g., if you're always playing with M devices, no need for support for A's.

If you're a big shop (and can have folks working on many different families at the same time), then you probably can afford to pay a bit more for the tools.

OTOH, a small operation will be busy with processor X for quite a while before having time to explore processor Y.

(a few kilobucks translates to very little billable time!)

Reply to
Don Y

I remember that name... And I've always wondered, is there a reason people use this stuff other than having been breastfed it during some embedded course at university?

is there?

Reply to
Johann Klammer

The middleware.

Reply to
sunaeco

How good the support for gcc is depends on three factors.

One is how good you are at asking for help sensibly. In the world of high-price commercial tools, there are people paid to listen to customers ask "support" questions like "how big is an integer?". If you are using free or low-price support services, you are expected to do more of the basic work yourself. So the free support services (mailing lists, etc.) are excellent - /if/ you know how to work with them. Also note that you have little control of the timing, and you may be asking for help from people in a very different timezone. But if you ask questions appropriately, you can often get help from the compiler developers themselves - that's something you almost never see with commercial toolchains.

If you are looking at commercial support, then the quality can vary tremendously. Some companies are mere resellers of gcc, and may not know much about the details. But some resellers make a point of thoroughly understanding the tools, precisely so that they can offer top-line support. And some companies, such as Code Sourcery and Red Hat, are heavily involved in the /development/ of gcc - you get support directly from the people who wrote the thing.

And of course, the support contracts and prices make a difference - you can pay more and get to talk to people on the phone, for example.

For my own use, support is only one of the reasons I usually use gcc. (My experience of support for some commercial toolchains has been less than wonderful.) The user-friendly licence of gcc means that I can have lots of copies of it, run it on different machines, and archive old versions - this can be a real pain with tools that are tied to particular machines. And of course, the quality of gcc is excellent - it generates better code, and has fewer issues, than other tools I have used. (I haven't tried Keil for the ARM, but Keil for the 8051 has a number of weird and painful bugs and basic incompatibilities with C.)

Reply to
David Brown

--
 Thanks, 
    - Win
Reply to
Winfield Hill

I think that if I created a sock-puppet and asked "How big is an integer" on comp.arch.embedded I'd get several good answers.

They'd be buried in lots of general snarkiness, but I'd still get some good answers.

I think if you pinned me to the wall and asked me why I use gcc I'd answer mostly the same as you, with the additional advantage that when a customer wants a build environment for the code I'm developing for them (surprisingly few do), there's no stupid commercial barriers to overcome.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com
Reply to
Tim Wescott

In my case, so I and the client can continue to support the product/device long after the vendor has gone out of business, license expired, etc. I've known folks who went looking for extra copies of (> $10K) licenses "down the road" and were met with "we no longer offer them; you'll have to buy a license for our NEW product (and muck with it for some indetereminate amount of time before you can make it work with your legacy application)".

And, I don't have to wait for to fix a particular problem I'm experiencing in the toolchain. Nor do I have to embrace ALL of the "fixes" they've decided to apply! (and have a bigger problem revalidating the product/tools, etc.)

Reply to
Don Y

FWIW, I saw AVR Studio at my college. Which uses GCC.

There was another dev kit that used a moderately expensive IDE, but it was only used for one DSP class (think it was a TI DSP, forget which one) so it's forgettable.

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
Website: http://seventransistorlabs.com
Reply to
Tim Williams

The GNU toolset is good, and there are versions for pretty many processors. I have used it at least for Intel 386+ (PC's), PPC, AVR, MC68k (several versions), and a multitude of ARMs.

If you like to have an IDE, GCC works happily with Eclipse CDT.

All toolsets have a need to climb the learning steps, but after that, the GNU tools are OK.

--

-TV
Reply to
Tauno Voipio

Keil offers lots of drop-in stacks and libraries. You'd have to use one seat a lot to justify the per annum cost.

--
Les Cargill
Reply to
Les Cargill

Absolutely - but that is because comp.arch.embedded is a general discussion group for all things embedded. You would also get several good answers in comp.lang.c, before it wandered into discussions about whether the standards would be better if integers were more tightly defined, and other ramblings.

But if you asked it on the gcc help list, which is the prime support method for gcc, you would (rightly) be told that the list is for help with gcc, not basic C questions. (You would probably also be given a good answer too - but not in the depth you'd get in a more appropriate forum.)

On the other hand, if you have taken out a second mortgage and bought a compiler from GHS, Keil, CodeSourcery, etc., you could contact their technical support and expect a good answer to such questions.

As an example, a /long/ time ago my company were local resellers of an EDA package - and that meant we handled technical support. We had one customer who needed help with /everything/. As in "I've put the disk in the computer. Now what do I do?" or "How do I make an icon on the desktop to start the program?". To make everything even worse, this character did not have a phone in his office. He would leave the office, and go to the pay phone across the street (it was a /long/ time ago!), in order to call me for help. He did not like taking notes - either about what he saw on the computer, or about what I said on the phone. But he had paid a lot of money for the software, and we had to do our best to help him.

Yes, it is often the inconvenience and bureaucracy involved in commercially licensed software that is the problem, rather than the cost. Some commercially licensed software go out of their way to make it as convenient as possible for the customer and user, with flexible arrangements and fast help when there is a problem. Others seem to want to make it as difficult as possible. I had one customer who bought a very expensive commercial toolchain (because the vendor told them that their existing copy, acquired when their company bought an overseas rival, was not licensed for use in the new country). After the package arrived in the post, it was over two weeks before they had managed to sort out the problems with dongles and licenses and actually start to /use/ the software. It was another couple of weeks before they had sorted out some weird incompatibilities between the new version and the old version that they were not allowed to use. And from inside information, I believe the vendor has twice as many staff dedicated to helping out licensing and dongle problems as they have for helping customers with technical issues in the toolchain.

But that is a worst-case example - as I say, /some/ vendors get it right.

Reply to
David Brown

One should be able to sue such companies, on the grounds that 1. they aren't delivering their claimed product, and 2. are causing direct losses to the company.

Weeks lost is easily in the $10k range, worth talking to legal about!

I don't suppose such has been tried, or that any license agreement would permit such a thing...

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
Website: http://seventransistorlabs.com
Reply to
Tim Williams

Have you read the fine print?

Reply to
krw

In a few cases, yes - but only a few. Vendors vary about how much fine print they have, and how much they actually care about it themselves. Often, if a vendor refers to the fine print, they have lost that customer - so they usually only do it when they know that customer is lost anyway, and they are limiting damages.

Reply to
David Brown

A vendor won't refer to the fine print. That's your job. Their liability limit will be in there (maybe the cost of the software - maybe).

Reply to
krw

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.