Best AVR development environment? (windows)

[8086]

As per title, would like your opinions on this.

I've not really worked with AVRs before (except using arduino bootloader) so anything goes.

[jmaja]

Depends on what you like. I like to work in unix like environment using shell. Thus I use cygwin with makefiles and Emacs. But I still use Atmel Studio for debugging and programmin (unless I use a bootloader + avrdude). You get the compiling tools when you install Atmel Studio. The path is quite well hidden, but you'll find it.

[dannyf]

Probably no consistent answer - as what's best is highly subjective.

IAR - high quality and feature rich compiler. Most reliable and supports the full range of chips. Utilitarian and consistent UI. Most expensive.
CB + gcc-avr - clean and fast interface. Large user base so good user support. Least expensive in $s, but lacks commercial support.
AVR/Atmel Studio: modern UI. Free. 6.0 is bloated so 5.x is the way to go in my view.
ICCAVR/CVAVR: somewhere between gcc-avr and IAR. Good wizard.

I personally use CB + Atmel's avr tool chain and found it to be well behaved. If I had to code a project for a living, I would go with IAR.

Other alternatives you may try include VS + VAX + gcc-avr. Or simply an editor + make + gcc-avr. SI, UE, PN+, or sublime text, etc. SI does a superb job in code analysis. sublime is superb visually. The later category also allows you to work on other chips, if you have the respective compilers. For people transitioning from cmd environment, they are particularly attractive.

[vvanders]

+1 on V6 Atmel Studio. I find VS with VAX combo to be one of my most productive development environments.

[Kremmen]

+1 (or is it +2 already?) for Atmel Studio.
Bloated? Who cares - gigabytes are cheap and the Studio works right out of the box. No f-ing recursive exercise to set up the environment to set up the environment to set up the development tools. Eclipse and the rest is OK if you are already familiar with that stuff, otherwise don't combine that exercise with this - you will only get frustrated. Some still favor command line tools. I don't understand why - the 60s are long gone - but then i don't really care either...

[Bored@Work]

+1 (or is it +2 already?) for Atmel Studio.
Bloated? Who cares - gigabytes are cheap and the Studio works right out of the box. No f-ing recursive exercise to set up the environment to set up the environment to set up the development tools. Eclipse and the rest is OK if you are already familiar with that stuff, otherwise don't combine that exercise with this - you will only get frustrated. Some still favor command line tools. I don't understand why - the 60s are long gone - but then i don't really care either...

Spoken like a true lone warrior hacking away in his closet all day.

In the corporate environment gigabytes, integration, manageability etc. still matter. Especially with an outsourced, standardized, secured, locked down, mostly centralized IT environment. Vendors better offer superior value when trying to force-feed their customers with such bloatware, which of course happens to not fit into the existing IT environment, doesn't interwork with existing, standardized tools, being it installation, but of course also in production, Can't be beaten into shape to be working within the framework of established processes, increases system management costs, requires an endless stream of manual workarounds, tears holes into the IT security, requires special drivers, etc.

There is only so much people in a corporate IT environment are willing to bear with.

AVR Studio 5 was what pushed us over the edge to finally drop Atmel AVRs. The MCUs are so-so. But then Atmel broke previous promises of a cross-platform environment, and instead delivered the broken, bloated, only adding negative value Studio 5 POS. And the only kind of support you got from Atmel for that POS was that we had to shut up, because that POS was supposed to be perfect.

Atmel Studio 6 just gained more bloat, still runs on the wrong operating system, is impossible to integrate with all that is right and holly for us and crashes a bit less often than Studio 5. Nothing in Studio 6 made us reconsider AVRs.

[firewalker]

Atmel Studio 6 just gained more bloat, still runs on the wrong operating system, is impossible to integrate with all that is right and holly for us and crashes a bit less often than Studio 5. Nothing in Studio 6 made us reconsider AVRs.

They should use Mono.

Have you tried MPLAB X? Is it ok? Last time I tried it o GNU/Linux it needed a specific JRE in order to run.

Alexander.

[dannyf]

A lesson to be learned from the divergence of opinions is that don't ask people for their judgment ("ABC is the best development environment") - what's best is highly subjective and a perfectly valid reason for me to like an environment may be a perfect reason for you to avoid it. Having just the "judgment" does not help you.

Instead, ask people the basis of their judgment ("ABC is the best development environment because X, Y, and Z"). You can then assess if those X, Y, and Z apply to you and if you should discount a like or dislike.

The issue with Internet is that a monkey with a keyboard can come cross as Shakespeare. The only way for you to tell that monkey with a keyboard is if you ask the next question(s).
 

[jmaja]

Some still favor command line tools. I don't understand why - the 60s are long gone

With command line in a good shell (not DOS nor cmd.exe!) you can just do many things so much easier and faster once you have learned them. The ones who have already learned them can't really understand why people want to use tools like Atmel Studio, Excel etc.

[Kremmen]

Regarding questions of opinion and shooting from the hip, i recommend Nobel prizewinner Daniel Kahneman's book "Thinking, Fast and Slow". Once you understand the concept of System 1 and System 2, then responses like Bored@work's become rather easier to understand.

B@w, you are wrong on all counts by the way.

[dannyf]

-recommend Nobel prizewinner Daniel Kahneman's book "Thinking, Fast and Slow". -

you don't need to think fast and slow. Instead, you just need to think, period.

it does not take a brilliant mind to understand that not everyone thinks and works the same way.

all it takes is a half-functioning brain to recognize that what works for me may not work for you, vice versa.

unfortunately that kind of common sense is beyond the comprehension of too many people.

[G0HZU]

I haven't done much with AVRs recently but I always wrote stuff for them in assembler. So my response may not be useful...

I started off with a third party command line system and a homemade programmer which produced a combination I quite liked because it was quick.

When I started writing more complex code eg for 3D lookup tables with full interpolation and stuff like CRC routines I went across to Atmel Studio 4 and found it to be quite powerful for debugging. I also used IDA Pro to disassemble my own code if I hit a particularly strange problem.

Most of the stuff I wrote was to do with engine/motor control using various lookup tables. eg 16x8  tables with full interpolation. I also used to use AVRs as a piggy interface to hack into other systems.

I found the above setup to be very useful for coding in assembler and I don't think it held me back in any way. If I was writing very simple stuff in assembler I would always use the command line interface rather than Atmel Studio because it was far quicker.
I also made my own encrypted bootloader and associated loader GUI to allow really rapid code changes via USB/Serial.

Note that some of the Atmel AVR 'Mega' datasheets are (were?) very lazy because the assembly code snippets were often generic and were pasted into datasheets where they didn't actually apply to the device in the datasheet. So they are of limited use! But there's a lazy disclaimer about this in the datasheet somewhere. I guess this is less relevant if you program in a higher language.

[Bored@Work]

They should use Mono.

There is actually a rumor around that Atmel is indeed trying to get the shit running on Linux using Mono. We laughed very hard when we heard this.

B@w, you are wrong on all counts by the way.

I don't care about your opinion. We have objective reasons.

It takes our competitor roughly four weeks to push out a new firmware release. They claim it is three weeks, but our observation tells us it is typically four weeks, sometimes six weeks.

The time is measured from end of coding, e.g. after a bug was found and fixed, until the firmware reaches the customer. It including tests, signing off the release by higher ups, etc.

Compare that with us. It takes us two hours - yes, two hours - to push out a new release. Version controlled, traceable changes, build, automatically regression tested, packaged, manually signed off by someone higher up with the right to sign it off, made available.

That is a competitive advantage we are not willing to give up or compromise, just because an arrogant MCU manufacturer thinks they know what their customers need, provides no support but a rubbish tool, and ignores any feedback. If a tool does not fit in our environment, if it can't be properly integrated, if the bloatware just makes trouble, or if it crashes, we don't care what some Nobel price winner says.

[firewalker]

There is actually a rumor around that Atmel is indeed trying to get the shit running on Linux using Mono. We laughed very hard when we heard this.

 

It would be easier to start from scratch using ones and zeros.

Alexander.

[Rigby]

It takes our competitor roughly four weeks to push out a new firmware release. They claim it is three weeks, but our observation tells us it is typically four weeks, sometimes six weeks.

Compare that with us. It takes us two hours - yes, two hours - to push out a new release. Version controlled, traceable changes, build, automatically regression tested, packaged, manually signed off by someone higher up with the right to sign it off, made available.

Who is "our competitor" and who is "us"?

[dannyf]

"our competitor": that neighborhood weirdo living across the street.
"us": those who pretend to live a life of others.

[vvanders]

Some still favor command line tools. I don't understand why - the 60s are long gone

With command line in a good shell (not DOS nor cmd.exe!) you can just do many things so much easier and faster once you have learned them. The ones who have already learned them can't really understand why people want to use tools like Atmel Studio, Excel etc.

It's not as well advertised as it should be but VS has a pretty solid command window that has short text based aliases for everything you can do from the menus. "of <file>" has autocomplete and I guarantee that I can move around a project much faster than someone on the command line because it has enough context to provide what I'm looking for.

Much like VI each tool has an investment required to get the most out of it and certain things will work better in situations over others.

[hans]

PowerShell in VS is a lot better than normal CMD window. At least it has piping.

Mono is absolutely useless on Linux. Or be very regretful about the choice of C# to develop an application that should run over multiple platforms, instead of C++/Qt or Java. I think it's really a big miss for Atmel.

I've never liked AVR Studio 5 or 6 though. AS5 tried to ruin my Visual Studio C# installation by overriding some settings which meant I couldn't start solutions from explorer (it started in AS5 and said "nope can't do C#, bye now"), some keyboard shortcuts were reset (also in combination with ReSharper) and panes were moved (not a real big deal).

Therefore, the last time I programmed an AVR (which was a tiny ATTINY btw, so not a "big" project) I installed AVR Studio 4 and used AVR-GCC from Arduino libraries. Not a big PITA to setup at all, and it seems to work OK & run smoothly.

I run MPLAB X on Linux and Windows, and it works out of the box. No extra JRE required. In contrast, XILINX ISE 14.7 was a much bigger pain to even start on Linux.

[fake-name]

I don't care about your opinion. We have objective reasons.

It takes our competitor roughly four weeks to push out a new firmware release. They claim it is three weeks, but our observation tells us it is typically four weeks, sometimes six weeks.

The time is measured from end of coding, e.g. after a bug was found and fixed, until the firmware reaches the customer. It including tests, signing off the release by higher ups, etc.

Compare that with us. It takes us two hours - yes, two hours - to push out a new release. Version controlled, traceable changes, build, automatically regression tested, packaged, manually signed off by someone higher up with the right to sign it off, made available.

That is a competitive advantage we are not willing to give up or compromise, just because an arrogant MCU manufacturer thinks they know what their customers need, provides no support but a rubbish tool, and ignores any feedback. If a tool does not fit in our environment, if it can't be properly integrated, if the bloatware just makes trouble, or if it crashes, we don't care what some Nobel price winner says.

You do realize that this has absolutely NOTHING to do with whether they use AS6 or not, right?

Are you seriously blaming their release times on the IDE? Shit, I could write a toolchain that emulated a freaking mouse and did automated builds using AS6/VS, and still get it done in less then 4 weeks including writing the tools to do all the automation, and there wouldn't even be a reason to do so since AS6 includes a full version of make anyways, as well as most of the GNU utilities compiled for windows anyways.

Your "competitor" having shit release times tells you about their internal political issues, and nothing else.

[Kremmen]

They should use Mono.

There is actually a rumor around that Atmel is indeed trying to get the shit running on Linux using Mono. We laughed very hard when we heard this.

B@w, you are wrong on all counts by the way.

I don't care about your opinion. We have objective reasons.

It takes our competitor roughly four weeks to push out a new firmware release. They claim it is three weeks, but our observation tells us it is typically four weeks, sometimes six weeks.

The time is measured from end of coding, e.g. after a bug was found and fixed, until the firmware reaches the customer. It including tests, signing off the release by higher ups, etc.

Compare that with us. It takes us two hours - yes, two hours - to push out a new release. Version controlled, traceable changes, build, automatically regression tested, packaged, manually signed off by someone higher up with the right to sign it off, made available.

That is a competitive advantage we are not willing to give up or compromise, just because an arrogant MCU manufacturer thinks they know what their customers need, provides no support but a rubbish tool, and ignores any feedback. If a tool does not fit in our environment, if it can't be properly integrated, if the bloatware just makes trouble, or if it crashes, we don't care what some Nobel price winner says.

I would rather say the opposite: your reasons appear very much subjective. Also, your overly polemic way to express your opinions makes it difficultand ultimately fruitless to comment in detail so i won't bother.
Just let me say this much: AS6 supports SVN integration using the AnkhSVN plugin and from there it is a short step to continuous integration using say Jenkins (or MS Team Foundation Suite if that floats your boat) and then we are not really any more talking about AS6 being somehow different or limited. So i say you are not really making a point. It is obvious issues you mention have very little to do with the tools in use and very much with the processes used - or lack of them. Conversely your advantage is not based in avoiding AS6.

Kahneman is silent on the issue of software tools. On the other hand he has a lot to say about human behavior and the reasons and mechanisms explaining same. You and many others in this forum and elsewhere prove his points.

[senso]

If AS6 is THAT bad, you can use the Arduino IDE

[zapta]

If AS6 is THAT bad, you can use the Arduino IDE

That's exactly what I am doing and it works well for me.

[dannyf]

If AS6 is THAT bad, you can use the Arduino IDE

Anything would be a big winner against Arduino,

There is a CB-based Arduino environment. I rarely use arduino ide to program my arduino boards: CB + gcc-avr does the job just fine.

[Rigby]

What the heck is CB and why can't you just spell it out so that we know what it is?

"I know of this magical tool that is perfect for what you're describing but I'm going to obfuscate the name so you never find it.  here's a clue: f(x) = 2x-1."

edit: are you talking about this? http://arduinodev.com/codeblocks/

[jancumps]

...Seriously, if you are relying on automated regression testing I wouldn't touch your products with a barge pole...

In this case or in general?
Regression testing is repetitive by implication. So why not trust an automated and maintained regression test suite?