Keil uVision - so good but so expensive

[Howardlong]

I've been using uVision for the past three or four days on a small evaluation project using three different vendors' Cortex M4F boards, a Cypress FM4 board, a TI Launchpad and an STM Discovery board.

I wasn't looking forward to this, not least because the last time I used Keil was in 2005 on a Silabs 8051 project, and I remember gritting my teeth when handing over a substantial sum for the privilege then.

For this evaluation, I used the 32KB limited version, so it was free.

The whole experience has been unexpectedly good, so good in fact that I'm way ahead of where I thought I'd be. Typically when you start of on a new dev environment, you spend some time understanding its nuances, and most often you end up in a fight to get the hardware debugging to work reliably. This has not been the case with uVision, despite the three different dev boards, all using their own integrated debuggers. (Interestingly enough, I gave up trying to get TI's CCS to work). Each board I was up and running in between five and fifteen minutes.

Debugging and programming is really quick, with the exception being that single stepping didn't work on the STM32 board at first, although when I tried it again just now it works fine.

The automated pack loading feature is another area which other vendors should consider. In all three cases, the project files I had been provided with downloaded all the appropriate support libraries. The exception was the TI board, where an older TI Tivaware library wasn't available for download, not even from TI: they don't seem to provide Tivaware archives, an important ommition in my view for supporting and maintaining old projects, the semi-TI official excuse being that "not much has changed so it's low risk". I repointed the project to the newer Tivaware I already had installed and the project I had worked right away. Interestingly, I gave up trying to get the project to work on CCS. I've not really got along with CCS for some time, the way library and directory structures are defined is complex and takes a while to understand, especially if you want to do things properly.

The debugging aspect alone shows why Java is a bad choice for cross platform IDEs, both Eclipse and Netbeans are evidence of this, it's slow, breaks a lot, and often takes some time to get working.

So why won't I be using Keil going forward? One word, price. It's at least ten times what I'd be willing to pay, and it's on an annual semi-subscription.

[nctnico]

Better avoid doing on-target debugging. It is a slow and cumbersome process even with the most expensive debugger.
Some Eclipse versions need setting the right skin for the OS to improve the performance so that could be the slowness you have experienced.

[marcopolo]

Maybe could you try CrossWorks?

https://www.rowley.co.uk/arm/index.htm

Personal Non-Commercial License USD 150.00
Commercial License USD 1500.00

[voltsandjolts]

Keil is essentially free (256Kbyte limit IIRC) for STM Cortex M0 parts, which suits me perfectly.

http://www2.keil.com/stmicroelectronics-stm32/mdk

[Howardlong]

Better avoid doing on-target debugging. It is a slow and cumbersome process even with the most expensive debugger. .

Why on earth should you avoid on-target debugging?

It’s provided for a reason. I’m not sure what you mean by “slow and cumbersome” when compared to other options, surely that depends on the what you’re trying to achieve. There are many strings to your bow when debugging, I use the most appropriate at the time, which is often using the on-target debugging features. Adding GPIO twiddles, high speed serial, printfs or other real time telemetry, for example, have their own pitfalls as well. Please understand that I was brought up on this stuff in the 70s when on-target debugging was either non-existent or prohibitively expensive, so I’m well aware of, and still use, very many other techniques.

My complaint is that on-target debugging can be done slickly and well, as I found in uVision, and has been the case in the past before vendors jumped on the Eclipse and Netbeans bandwagon for IDEs.

The problem for these Java based IDEs is that to talk to the debuggers they have to use an inefficient interface to make multiple function calls with significant amounts of data. In the case of JNI that has to be marshalled between native and managed code, and that’s where the sluggishness comes. Now given enough direction and need, these could I am sure be far quicker, but you have to battle with the JNI, and frankly these days not many front end developers give much care to performance.

[Howardlong]

Keil is essentially free (256Kbyte limit IIRC) for STM Cortex M0 parts, which suits me perfectly.

http://www2.keil.com/stmicroelectronics-stm32/mdk

Sadly that’s not my use case.

[nctnico]

Better avoid doing on-target debugging. It is a slow and cumbersome process even with the most expensive debugger. .

Why on earth should you avoid on-target debugging?

Because you can't really debug realtime processes without interfering too much and algorithms are easier and better to unit test on a PC. What is left is the occasional access violation.

The problem for these Java based IDEs is that to talk to the debuggers they have to use an inefficient interface to make multiple function calls with significant amounts of data. In the case of JNI that has to be marshalled between native and managed code, and that’s where the sluggishness comes. Now given enough direction and need, these could I am sure be far quicker, but you have to battle with the JNI, and frankly these days not many front end developers give much care to performance.

The problem is more likely to be delays & overhead in the JTAG interface layer. Debugging code running on a PC using Eclipse to debug works just fine.

[Howardlong]

Better avoid doing on-target debugging. It is a slow and cumbersome process even with the most expensive debugger. .

Why on earth should you avoid on-target debugging?

Because you can't really debug realtime processes without interfering too much and algorithms are easier and better to unit test on a PC. What is left is the occasional access violation.

Like I said, you use the best tool for the job. In many cases, you do not care about real time behaviour. Yes, when debugging real time situations, you would tend to rely on telemetry, but not all the time. You use what’s appropriate. I wouldn't stick in a load of telemetry to check a peripherals’ registers have been set up correctly, I set a breakpoint and check the values. Sometimes even in real time a hardware debugger is a better option, for example you might want to see if a function is ever called. Stick a breakpoint at the function. No need for a recompile and reprogram cycle.

A blanket prescription not to use on on-target debugging capabilities might work for you, but I think you are not benefitting your own productivity by completely dismissing it. I realise we all have our own workflows, and you’re welcome to yours, but I find that completely dismissing it is a bit strange.

The problem for these Java based IDEs is that to talk to the debuggers they have to use an inefficient interface to make multiple function calls with significant amounts of data. In the case of JNI that has to be marshalled between native and managed code, and that’s where the sluggishness comes. Now given enough direction and need, these could I am sure be far quicker, but you have to battle with the JNI, and frankly these days not many front end developers give much care to performance.

The problem is more likely to be delays & overhead in the JTAG interface layer. Debugging code running on a PC using Eclipse to debug works just fine.

I don’t agree. Like I said, again, the same debugging hardware performs well on non-Java platforms. I’d imagine the Eclipse devs spent some time optimising it considering native debugging is by far the most common use case.

[NorthGuy]

@Howardlong: Howard, you have just spent too much time in company of MPLAB X, and accepted all to bloat and slowness, so that Keil now looks super fast to you. Remember MPLAB 8? It used to debug much faster and better. It wasn't in 70-es, it was 5 years ago.

@nctnico: I think real-time debugger may be quite beneficial. I prefer using hardware over simulators or test benches. Most of the time I run things without a debugger, but if you want to stop the process at a given point, inspect the variables, perhaps take few single steps, the real-time debugger is quite beneficial. It only takes less than a minute to setup and can save you lots of time. Even if your algorithms are verified and tested elsewhere, there still may be problems unique to real-world runs.

[nctnico]

@nctnico: I think real-time debugger may be quite beneficial. I prefer using hardware over simulators or test benches. Most of the time I run things without a debugger, but if you want to stop the process at a given point, inspect the variables, perhaps take few single steps, the real-time debugger is quite beneficial. It only takes less than a minute to setup and can save you lots of time. Even if your algorithms are verified and tested elsewhere, there still may be problems unique to real-world runs.

My experience is that hardware debuggers are a royal PITA to setup and very prone to failing. I've stopped using them because they took me more time to setup & babysit than to do actual work. Printf works much easier for me. And there is also costs versus benefit. My firmware always has a cli over the serial port which can do diagnostics and testing.

[andyturk]

My experience is that hardware debuggers are a royal PITA to setup and very prone to failing. I've stopped using them because they took me more time to setup & babysit than to do actual work.

Really? Which ones were you using?

[nctnico]

My experience is that hardware debuggers are a royal PITA to setup and very prone to failing. I've stopped using them because they took me more time to setup & babysit than to do actual work.

Really? Which ones were you using?

That has been a long time ago. I recall the Blackfin environment and that wasn't stable at all. Most recently I've used a dongle for some Freescale 8 bit MCU but that was just as flaky and wouldn't work from a virtual machine after changing to a new PC.

[andyturk]

My experience is that hardware debuggers are a royal PITA to setup and very prone to failing. I've stopped using them because they took me more time to setup & babysit than to do actual work.

Really? Which ones were you using?

That has been a long time ago. I recall the Blackfin environment and that wasn't stable at all. Most recently I've used a dongle for some Freescale 8 bit MCU but that was just as flaky and wouldn't work from a virtual machine after changing to a new PC.

Ah. Sometimes I forget about life outside the ARM Cortex ecosystem.

[Bassman59]

My experience is that hardware debuggers are a royal PITA to setup and very prone to failing. I've stopped using them because they took me more time to setup & babysit than to do actual work.

Really? Which ones were you using?

Yeah, seriously! The built-in debugger for SiLabs parts (both 8051 and ARM) is dead simple to set up and use. The GNU Eclipse ARM Plug-in thing with a Segger J-Link on Atmel ARMs is similarly easy to use.

The last hardware debugger I used that was a "royal PITA to set up" was the Nohau 8051 emulator with the bond-out pod that always died when you needed it the most.

[ehughes]

Ozone + JLink is the *best* for on chip debugging.      Light years beyond printf.     You can monitor variables/registers in real-time with a breakpoint or printf.   It is the closest thing you can get to seeing what is happening in real time on the target without having to add any extra code to profile what is going in.

I am working on an OFDM application on an M7 and ozone has been very useful for monitoring DMA, computations, etc without having to insert (slow) code such as printf to instrument the process.     The SWD transactions steal a few bus cycles but it is the best you will get when you want to see what is really going on.

[mikerj]

My experience is that hardware debuggers are a royal PITA to setup and very prone to failing. I've stopped using them because they took me more time to setup & babysit than to do actual work.

Really? Which ones were you using?

That has been a long time ago. I recall the Blackfin environment and that wasn't stable at all. Most recently I've used a dongle for some Freescale 8 bit MCU but that was just as flaky and wouldn't work from a virtual machine after changing to a new PC.

IME debugging with Keil is a breeze.  Once you have a debugger correctly physically connected, it just works and works very well.

[Howardlong]

@Howardlong: Howard, you have just spent too much time in company of MPLAB X, and accepted all to bloat and slowness, so that Keil now looks super fast to you. Remember MPLAB 8? It used to debug much faster and better. It wasn't in 70-es, it was 5 years ago.

Indeed, I agree, MPLAB 8 is significantly quicker than MPLAB X. MPLAB X has become a little more bearable as host hardware has improved, but it’s still painful: it’s slow and flaky. I rejected MPLAB X almost universally for some time until I had no choice due to part support.

I also have a fair bit of experience with LPCxpresso and CCS, both Eclipse based. CCS used to be its own IDE, and was reasonably snappy and reliable. I’ve found LPCxpresso and Eclipse based CCS to be less than reliable with hardware debuggers, often frustratingly so.

Come to think of it, a brief couple of experiences with Atmel Studio 7 (Visual Studio based) haven’t been bad, except for the minefield of trying to figure out which debugger supports which devices.

[jnz]

I've been using Keil for years and it's never what I would have described as "so good!". Some of the features are great, and work really well. Occasionally there are debugging or building issues that make you want to pull your hair out.

Keil's big selling point of it's pack manager - is not great. The RTE (run time enviroment pack selector) uses often old packs, the mfg will put out version 2.1 and Keil has v2.02 still because no one went back to update it yet. Nordic for one example decided to drop Keil's pack system altogether so those are years out of date. Without the pack system you have to know exactly where your includes and references are (GASP!!) which is really what you should be doing anyhow. I may drop Keil because all of my projects now are "manually" built and I think I could get as good debugging in other systems.

Originally purchased Keil for the Middleware suite. Dumped that after 1 year. RTX is alright, but has no support compared to FreeRTOS. etc etc

If I had to pay for the IDE myself... I'd be using Crossworks, or Segger Embedded Studio, or whatever Atollic became for STM32 parts. Basically it's that, some licenses are free if you use x or y chip. Rowley was great for a universal as much as I used it. Keil has the free M0+ license and under 32kb for every ARM part. IDK, I guess I've been using Keil long enough to not be in love with it, but I do get work done.

[hans]

Better avoid doing on-target debugging. It is a slow and cumbersome process even with the most expensive debugger. .

Why on earth should you avoid on-target debugging?

Because you can't really debug realtime processes without interfering too much and algorithms are easier and better to unit test on a PC. What is left is the occasional access violation.

Like I said, you use the best tool for the job. In many cases, you do not care about real time behaviour. Yes, when debugging real time situations, you would tend to rely on telemetry, but not all the time. You use what’s appropriate. I wouldn't stick in a load of telemetry to check a peripherals’ registers have been set up correctly, I set a breakpoint and check the values. Sometimes even in real time a hardware debugger is a better option, for example you might want to see if a function is ever called. Stick a breakpoint at the function. No need for a recompile and reprogram cycle.

A blanket prescription not to use on on-target debugging capabilities might work for you, but I think you are not benefitting your own productivity by completely dismissing it. I realise we all have our own workflows, and you’re welcome to yours, but I find that completely dismissing it is a bit strange.

The problem for these Java based IDEs is that to talk to the debuggers they have to use an inefficient interface to make multiple function calls with significant amounts of data. In the case of JNI that has to be marshalled between native and managed code, and that’s where the sluggishness comes. Now given enough direction and need, these could I am sure be far quicker, but you have to battle with the JNI, and frankly these days not many front end developers give much care to performance.

The problem is more likely to be delays & overhead in the JTAG interface layer. Debugging code running on a PC using Eclipse to debug works just fine.

I don’t agree. Like I said, again, the same debugging hardware performs well on non-Java platforms. I’d imagine the Eclipse devs spent some time optimising it considering native debugging is by far the most common use case.

I more or less agree with nctnico. I usually verify functional behaviour of programs using PC tools like unit tests, and do my debugging there.

If you design your software in a decent way with proper IPC, then you can pretty much be guaranteed that PC and embedded will be functionally deterministic and identical. The 3 things preventing your application from "working" is:

- Wrong assumption how your software should work.
- Bug in BSP.
- Temporal constraints not met (real-time and/or performance wishes).

Of course an embedded debugger is an useful tool to have such that you can halt programs, set breakpoints and probe around. But it's absolutely horror when you're debugging any device that is either real-time or has modern connection interfaces with time-outs on them, like USB, ethernet and/or some CAN protocols. It depends what you're making - but we cannot dismiss that the typical embedded application is by definition rather constrained by it's environment (i.e. real time), so that can make debugging at a high functional level completely redundant. At this point tracing can't be beat, and most uCs have fast enough serial ports to support it.

So basically for me I only use debuggers for troubleshooting BSP problems. Software state can be traced. Temporal constraints can be measured with a LA or oscilloscope.


Nonetheless to the point; the debugging I've done on ARM with GDB and OpenOCD has been pretty stable. An advantage of GDB is that you can use it in any tool you would like. I've used it in Qt Creator, now using CLion, but various Eclipse builds also exist and I think there was also a plug-in for VisualStudio (VisualGDB?) that supported this.

Basically, I wouldn't want to marry myself again to 1 specific IDE and toolchain again. Although, if your employer says you have to use a particular tool, then it is possible to work around/with it.

[Kjelt]

Standard functions can indeed IME best be debugged on a pc with unit tests.

On non embedded systems with big infrastructure logging, printf etc are well suited for error tracing.

On small or constrained embedded systems printf can be an outcome though it can also affect the real time behaviour or not be processed properly so you can have issues esp towards a slow peripheral as serial port.
Having the possibility to set a life breakpoint and at that moment freeze everything and inspect the registers, variable values etc etc or even logical breakpoints that trigger as a certain logical condition arises can be extremely valuable.

So IMO there is no best way to debug but is it a choice or combination of choices that should be choosen wisely, having the luxury of choosing any of the above debug options is in that sense "the best".

[Howardlong]

FWIW, I totally agree with debugging your algorithms on a PC first. In all my mixed signal stuff, which is most of what I do, I use a common code base, and tweak as appropriate and necessary for the target environment, but the source is the same.

This is limited however. If you are debugging a peripheral driver, there is usually no exact equivalent on the PC. Occasionally simulators have simulated peripherals but unless I’m desperate I’d far rather debug on the metal, what few peripheral simulations there are are rarely reasonable reproductions of the real thing. The same applies to complex timing interactions. Rather than adding tons and tons of telemetry, you can often avoid that with a hardware debugger.

For high speed stuff, for telemetry I frequently set up a high speed low footprint unbuffered SPI and/or UART streams (10Mbps and above, and often more than one) with carefully crafted binary packets and monitor and/or trigger on the scope. Add to the mix a few GPIOs to let you know where you are. Printf is useless for high speed real time bulk data unless you buffer it, which introduces even more code overhead for your telemetry.

You can also use telemetry and hardware debuggers together, collecting data in a memory buffer and then breakpointing with your debugger to catch the aberration. You can examine the buffer data structures right there in the debugger, no need for a ton of printfs.

So as we all know, debugging is frequently an iterative process. I personally find the build step gets in the way of my workflow, so if I try to achieve what I need without necessarily having to add more telemetry and therefore require a rebuild.

There is always the Heisenberg Uncertainty Principle as applied to debugging, in that you also tend to want to touch as little as possible. We’ve all seen something work fine in debug but not in production. Adding telemetry often leaves a much bigger uncertainty footprint than a hardware debugger would do, but it does depend on the case.

I use all these methods, and choose the most appropriate tool for the job at hand. It’s horses for courses.

[Sal Ammoniac]

I don’t agree. Like I said, again, the same debugging hardware performs well on non-Java platforms. I’d imagine the Eclipse devs spent some time optimising it considering native debugging is by far the most common use case.

The problem with Eclipse isn't the underlying architecture, it's all the plug-ins and add-ons that most vendors can't seem to resist adding to their IDE implementations. I always start with the bare bones Eclipse, add CDT and the JTAG support, and that's it--none of that other crap that slows everything down.

[mikerj]

FWIW, I totally agree with debugging your algorithms on a PC first. In all my mixed signal stuff, which is most of what I do, I use a common code base, and tweak as appropriate and necessary for the target environment, but the source is the same.

This is limited however. If you are debugging a peripheral driver, there is usually no exact equivalent on the PC.

Exactly this. Developing/debugging algorithms on a PC is a good and obvious step, but it's most always tracking down problems with peripherals that gets my debugger out of it's cupboard.

[EEVblog]

So why won't I be using Keil going forward? One word, price. It's at least ten times what I'd be willing to pay, and it's on an annual semi-subscription.

Welcome to the world of professional tools at professional prices. Clearly not priced for individuals.
BTW, how much?

[Howardlong]

So why won't I be using Keil going forward? One word, price. It's at least ten times what I'd be willing to pay, and it's on an annual semi-subscription.

Welcome to the world of professional tools at professional prices. Clearly not priced for individuals.
BTW, how much?

Three editions, Essential, Plus and Professional:

Essential - Cortex-M
Plus - adds R4, SecurCore, ARM7, ARM9, IPv4 & USB device libraries
Professional - adds IPv6 & USB Host libraries

Node locked pricing Essential/Plus/Professional
Perpetual: $3840/$6600/$9500
One year: $1535/$2640/$3800

Floating licence options add another ~20% or so.

I'm not that bothered about ARM7/ARM9/R4/SecurCore, but I would want the IPv4, IPv6 and both USB stacks.

To put it into perspective, the Professional annual sub of $3800 is more than all my other annual software expenditure. That's assuming I could swallow the limitations of a one year licence. Great for fly by night start ups, crap for those of us who are around for longer than the life of a mayfly.

[Kjelt]

Do you use it for commercial applications, eg earn money with it?
If not, you should contact them stating this and asking for a pc locked perpetual version or something similar.
If you are really interested that might give very high discounts, a friend of mine got 40-50% on a IAR license under these conditions and without any support etc. etc.
In my case I would find a 50% discount still too expensive for hobby use.

[Howardlong]

Commercial, which is precisely why I’ve avoided it for so long, knowing how much it cost all those years ago.

I realise there’s a school of thought that says it’s a false economy to resist. I am just looking at it in terms of what it would offer me long term, and the cost of that, compared to other options. I have the same battle of thoughts over Matlab pricing too. Neither offer me particularly good value for money considering how often I would be using them.

[Kjelt]

Then actually you should earn the investment back in the price of your product or service.
Raise the price of your product or your hourly wage such that in 2 years the software is paid back.
I know that is probably also not an option, but it is how it should be done 

[Howardlong]

Then actually you should earn the investment back in the price of your product or service.
Raise the price of your product or your hourly wage such that in 2 years the software is paid back.
I know that is probably also not an option, but it is how it should be done 

I am torn, but I’m also tight! It’s the first time I’ve used it in about thirteen years. I don’t want to be tied to an expensive platform if I need to do a small bug fix or feature change in three or four years time. Fundsmentally, I still just don’t see it as value for money compared to the alternatives that I battle with.

My OP was as much about how crap vendor produced IDEs are in comparison as it was the sticker shock. The $10k could be spent on far more interesting things, like a bit of TE with knobs and buttons and flashing lights on it!

[nctnico]

I don’t want to be tied to an expensive platform if I need to do a small bug fix or feature change in three or four years time.

That is what puts me off about software with a subscription model. If I buy software it must available to me forever.

BTW there are other IDEs besides Eclipse which may offer better performance.

[Kjelt]

They do offer a perpetual license if you had read the post on the end of the previous page, which has to be saluted since most companies no longer do this.

[Howardlong]

They do offer a perpetual license if you had read the post on the end of the previous page, which has to be saluted since most companies no longer do this.

Indeed, although it’s perpetual only in so much as you get one year of updates and support. Beyond that, you’ll have to keep and maintain a working system, or hope that their licensing server doesn’t disappear if you need to install elsewhere. “Perpetual” isn’t necessarily quite what it suggests.

[Kjelt]

Ok yes I remember, in my previous company we had three versions of the Keil compiler and IDE so we could compile for old products and did not want to spent a lot of time fixing changed things like optimization settings or worst case the entire projectsettings, for each version you had to request a different license key.
So you probably get a key without expiration date but only for that computer. Updates and so are less of a concern unless there is a big bug in the version.

With IAR you can still get a dongle AFAIK, so you can use it on more than one computer but ofcourse not at the same time.
I still would like more software companies to do this but since dongles or the software that uses them were often hacked in the past the software companies got more and more restrictive and the good users/clients are screwed by that.

[Sal Ammoniac]

I am torn, but I’m also tight! It’s the first time I’ve used it in about thirteen years. I don’t want to be tied to an expensive platform if I need to do a small bug fix or feature change in three or four years time. Fundsmentally, I still just don’t see it as value for money compared to the alternatives that I battle with.

Have you ever tried Rowley CrossWorks? Several others have mentioned it on this thread, but you don't seem to have responded. It's only $1500 for a commercial license, so it's more palatable than Keil, plus it's from a UK company.

[Howardlong]

I am torn, but I’m also tight! It’s the first time I’ve used it in about thirteen years. I don’t want to be tied to an expensive platform if I need to do a small bug fix or feature change in three or four years time. Fundsmentally, I still just don’t see it as value for money compared to the alternatives that I battle with.

Have you ever tried Rowley CrossWorks? Several others have mentioned it on this thread, but you don't seem to have responded. It's only $1500 for a commercial license, so it's more palatable than Keil, plus it's from a UK company.

The reason I mentioned Keil uVision was that I happened to need to use it for one evaluation project where I was comparing a selection of Cortex M4F devices in the same market segment, and there happened to be a common set of examples for Keil available for the three dev boards to get me started. Like I say, I wasn’t looking forward to it, but I was very pleasantly surprised. Normally I expect such evaluations to take some time as it seems to be such a terribly difficult thing to provide tooling backwards compatibilty these days. As I mentioned earlier, TI gets a thumbs down for not having archived versions of Tivaware available. If the get-starting examples I’d had were for Rowley CrossWorks, I’d have used that. But you’re right, the pricing is far more palatable.

[Sal Ammoniac]

Do you use it for commercial applications, eg earn money with it?

Professional tools do indeed cost money, but it's generally a small expense in the overall budget. Around here the burdened cost of an embedded engineer is around $300,000 a year. A $5000 Keil license is only 1.6% of this, so in the overall scheme of things, the cost of Keil licenses is insignificant.

[Kjelt]

Around here the burdened cost of an embedded engineer is around $300,000 a year.

I am doing something wrong..... can I work from home? 

[NorthGuy]

Around here the burdened cost of an embedded engineer is around $300,000 a year.

I am doing something wrong..... can I work from home? 

Me too 

[Bassman59]

Around here the burdened cost of an embedded engineer is around $300,000 a year.

I am doing something wrong..... can I work from home? 

He's including the salary (which may be 1/3 of that), and all of the overhead, which includes not only employer-paid taxes, health insurance and retirement benefits, but also things people rarely think about. There's the cost of the space in the building where the engineer works, which includes heating and A/C, water, sewer, electricity, and so forth. Don't forget IT-related stuff -- computer workstation, networking infrastructure, servers, Internet access, phone system, etc.

[Kjelt]

Yes I know those calculations, and they fail miserably because they don't save $300k$ when they fire an engineer.
Actually even when they have no-one on the payroll except the janitor, the janitor costs $40000000 a year 
These are the calculations managers use to fire people while the net effect is 1/3 of the figures.

[NorthGuy]

He's including the salary (which may be 1/3 of that), and all of the overhead, which includes not only employer-paid taxes, health insurance and retirement benefits, but also things people rarely think about. There's the cost of the space in the building where the engineer works, which includes heating and A/C, water, sewer, electricity, and so forth. Don't forget IT-related stuff -- computer workstation, networking infrastructure, servers, Internet access, phone system, etc.

When you contract someone (as opposed to employing), it is up to the contractor to cover most (if not all) of these expenses.

[Bassman59]

He's including the salary (which may be 1/3 of that), and all of the overhead, which includes not only employer-paid taxes, health insurance and retirement benefits, but also things people rarely think about. There's the cost of the space in the building where the engineer works, which includes heating and A/C, water, sewer, electricity, and so forth. Don't forget IT-related stuff -- computer workstation, networking infrastructure, servers, Internet access, phone system, etc.

When you contract someone (as opposed to employing), it is up to the contractor to cover most (if not all) of these expenses.

Right, but Sal was most likely referring to direct employees when he used the term "burdened cost."

[ali_asadzadeh]

Torrents

[nctnico]

Torrents

Those are great for getting a version without the licensing crap but you still should pay.

[Kjelt]

Lots of those versions are drenched in malware, after a few weeks you can still pay but then to some bunch of hackers to unlock your entire PC.
It is just sad that there are almost no free non-commercial versions for hobbieists. Commercial companies should just pay up or switch to something else.

[krish2487]

Not to mention it is the wrong attitude for software.

Quote from: ali_asadzadeh on Today at 05:08:57 pm

Torrents

Sure you can get them, but you didn't pay for it..

Would you steal a drill or a hand tools from Walmart or similar because you need the tools to work on a project?? Or would you rather pay for a tool that fits within your budget, does the job you need it to?

So are softwares. they are tools to help a professional do his job.


Malware or not, it is the attitude thats fundamentally wrong.

[julianhigginson]

I am torn, but I’m also tight! It’s the first time I’ve used it in about thirteen years. I don’t want to be tied to an expensive platform if I need to do a small bug fix or feature change in three or four years time. Fundsmentally, I still just don’t see it as value for money compared to the alternatives that I battle with.

hopefully you will do plenty of other development in the same tool, during the years between finishing a project and then opening it up again for a feature update!

Assuming it works for all the platforms you are going to be using - you could have a single professional tool that handles all the dev you need, and you are familiar and quick with it because you just know it!

My OP was as much about how crap vendor produced IDEs are in comparison as it was the sticker shock. The $10k could be spent on far more interesting things, like a bit of TE with knobs and buttons and flashing lights on it!

Yes, it definitely could, but if you count how much it might cost in time to use cheaper options, learning whatever the free option is for every different thing you try to work on, maybe you could get more work done with this tool and then use money earned from that to buy more fun tools, too?

[benst]

+1 for Rowley CrossWorks. Been using it for 10 or 15 years now. Jtag debugging works well and fast. Great support too. Runs on Win/Linux/Mac.

They have a free evaluation version.

Ben