IAR has a good product that stands on its own merits. In my experience, if developers are comfortable with GCC then they are going to use GCC no matter what; if they're not, then the fastest and cheapest way to tool up for the AVR will be to write a check to IAR. I don't see any meaningful competition between the two of them.
But AVRStudio is the software development hub for you flagship uC product. If you can really only manage to prioritize *one thing* at a time with this program, then you really ARE crazy.. You'd be better GPL'ing it and publishing the source. Then the AVR/GNU crowd would quit whining, Atmel would get a broader base of support, and IAR's position would really remain intact.
As I said there is a *big* list of things to do, I send in new things every week, and I do not belive that protection of IAR matters here. Some things gets done, and somethings get on the backburner.
High priority items for AVR studio is AFAI think bug fixes,improving trace support code coverage, performance analysis, support of new parts and the new debugwire emulators. I do not really know for sure the list, but the guys certainly have plenty to do. There are not tons of people
A nice thing which I really would appreciate, is a way to save the fuse settings in the ISP popup window. Everyone thinks this is a good idea, but has never gotten through the eye of the needle. I'd rather have than the ELF/DWARF, but then I have both the gcc and the IAR compiler.
Pls Dont forget to read the last row in this email...
--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.
That may sound naive, but a compiler never ever should generate bad code ! If so it is or certain modes of it's usage are useless. Or is there a warning like: -O3 might generate bad code !
(BTW: It's a problem I've seen with many compilers, I guess that's what they call agressive optimization, but in fact it make the tools useless.)
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !
From what I've seen, every last one of them is capable of generating bad code. That's why you see complex pieces of code -- like OS's and middleware -- specifying the compiler and version you must use.
Corrections: The GUI based debugger, Insight, has been around for quite some time, on various platforms and for various targets. It is only in the most recent release of WinAVR that it has been built for the Windows platform. And also, Insight, is nothing but a GUI wrapper around GDB. The JTAG ICE support comes from the AVaRICE project which is the glue between the JTAG ICE and GDB.
I would not necessarily say that any of the developers are "sidestepping" AVR Studio. AVR Studio is currently the best free AVR simulator. There is also the SimulAVR project (which connects with GDB) but it is not as advanced as AVR Studio, yet. The main issue with AVR Studio is that it only accepts 3 file types:
Nordic Object: Atmel's proprietary format for their assembler.
UBROF: IAR's proprietary format.
COFF: For everybody else.
GCC natively produces the ELF format, which is none of the above. The ELF format also has a related debugging format, called DWARF (Search on Google for more info). In order for users of the GCC compiler to use AVR Studio for simulation, the file format has to be converted. One of the main AVR open source developers has recently wrote a ELF to COFF converter, however it is in Beta. Still, it is known that AVR Studio has some special features that is uses with IAR's UBROF format and not other formats. It is also known that the COFF format is old, and not widely used as much any more because other formats are better. It is also known that the COFF format does not support C++ very well.
Plus AVR Studio can only run on Windows.
So, with all this, it is not so much that the open source AVR people are abandoning AVR Studio, as so much as finding the right tool for the job. There is the open source debugger, GDB, which has been around for a long time and is used for many targets, including embedded targets. GDB has an AVR port. However, you have to use some "helper programs" for the AVR:
AVaRICE: For using a JTAG ICE.
SimulAVR: For simulation.
AVaRICE is very usable and I've heard good reports. SimulAVR can be used but it is not nearly as good as AVR Studio, yet. But all of these tools are cross-platform and can be run on Windows, Linux, FreeBSD, and there have been report of them being built on Mac OSX and Solaris.
Considering that the Open Source AVR toolset is run by volunteers, it's just a matter of time, energy and finding or writing the tools to do the job.
Indeed. Even if it is not "totally" the case, it certainly gives the impression.
This is one reason why it's so bad, because of how old it is!
Then, if COFF is *so* good, then why does AVR Studio also support UBROF which is proprietary to IAR? Why has GCC been dropping COFF support in favour of ELF/DWARF for years?
I beg to differ.
An obvious example of closing the doors, was that AVR Studio 3 had a very simple way to call 3rd party compiler, just with writing a command-line to call. Now, AVR Studio 4 doesn't have ANY support for calling 3rd party compilers. There has been reports that it will have it, in the future, but you'll have to write a DLL (plug-in) to have it call 3rd party compilers. Why does one need a stupid DLL to call a command-line? And that feature is supposed to be out "any day".....
In the age of the Internet, location doesn't matter. I've worked with many Open Source AVR developers to improve the toolset and these other developers are in:
Washington (State), US
Colorado, US
Pennsylvania, US
North Carolina, US
Germany
Poland
Russia
Denmark
Australia
New Zealand
Canada
England and many others. Only one have I met in person, and I only know what 2 of these people even look like.
Eric
------- My views are not that of my employer. Duh!
Indeed, let's look at this from Atmel's perspective:
1) Atmel makes money by selling chips.
2) Good tools sell chips.
3) Because of 2, Atmel worked with IAR to develop good tools.
4) Because of 3, the tools best support IAR.
5) Because of 3, Atmel does not want to make IAR unhappy.
6) Avr-gcc is also a good tool, and competes with IAR.
7) Because of 6, making AVR Studio play nicer with gcc could make IAR unhappy.
8) Because of 2, Atmel wants better support for gcc.
9) Atmel doesn't pay the people working on SimulAVR, Insight, or GDB.
10) Despite 9, these tools are (so far) always getting better.
Atmel's options are:
A) Add ELF/DWARF support to AVR Studio. B) Do not add such support.
Option A costs money and opportunity. It also risks displeasing IAR.
Option B costs nothing. It only risks displeasing the gcc community, whose likely reaction will be to improve its own tools in order to dump Atmel's. They (probably) aren't going to react by dumping the chips themselves, especially after having put so much time and effort into supporting them. Since Atmel makes its money from chips and not (free, as in beer) tools, this is no skin off Atmel's nose. In fact, better gcc tools may actually help Atmel sell more chips.
Disclaimer: this is all speculation. But I think it makes sense. I'm not claiming there's any conspiracy against gcc or even collusion between Atmel and IAR (beyond the obvious fact that they are friendly toward one another). It's just reasonable (and even logical) behavior.
The best way to handle this, is to document a standard method for mapping this option-Fuse info into the .HEX file.
That way, it is not single-point SW constrained, and all device programmer pathways can access the info. It also allows source-code generate/conditional compile control of option fuses, and puts all the info into a single file, for best version control. Hex file formats also allow comments, which can further clarify/document this.
I am not claiming that COFF is the best possible object file format. I dont argue against the fact that adding ELF/DWARF would improve AVR Studio. I am arguing that AVR Studio is a toolset which can be used by other compiler manufacturers to generate good code, but with less excellent debugging info. It is a proprietary architecture that supports the IAR well, and others less well at this stage but has the potential to support others well in a much better way that what was possible with AVR Studio 3.
I am arguing against the idea that the lack of ELF/DWARF is because Atmel wants to protect IAR: There are simply too many things indicating this is not the case. Atmel has spent time on bug fixing AVR Studio to make gcc for AVR run better. I have personally been involved in trying to find problems with AVR Studio when running with other toolsets, and have seen them beeing fixed.
command-line to call.
compilers.
I do not see that this favours IAR; since there is no DLL to call IARs C compiler either. The way I work, the Compiler runs in its own window, I recompile, and then AVR Studio detects that the object file is changed and loads the new object file. This should work with any compiler toolchain. Removing the simple command line call, does not change the fact that the architecture of AVR Studio was designed to allow third party plugins.
I have lots of opinions that differ from that of my employer. I think that the AVR Assembler should be open source, because this is really a place where improvement is needed. The fact that I think this, does not make it an Atmel opinion.
If I provide you with info, then this is based on what I know, and what I believe is not a company secret. It is not an official Atmel statement and might be untrue, simply because I do not have all the info or the info I have is obsolete. For all I know, Atmel could be working on an ELF/DWARF parser without telling me. Since I prefer not to hide the fact that I am an Atmel employee, I think it is advisable to remind people that if they want an official Atmel opinion on a subject, then they need to get it elsewhere.
--
Best Regards,
Ulf Samuelsson ulf@a-t-m-e-l.com
This is a personal view which may or may not be shared by my Employer Atmel
Nordic AB
But only by extending the COFF format, not with migrating to a better format. AVR Studio 4 requires the "AVR Extended COFF" format which barely improves things over AVR Studio 3's "AVR COFF" format.
Which is true; I have seen that too. However, the community is waiting for a next release of AVR Studio 4 that includes some of these fixes.
Point.
However, AVR Studio can detect that the object file has been changed
*without* requiring an architecture change that means to call a compiler you have to use a binary plugin. The "plugin" versus "command-line call" architecture debate does not affect the ability to detect object file change, but it does affect the ease of use in setting up 3rd party compilers.
Sure, and I respect that. I think everybody in the whole comp tree does! :)
What I don't understand, is why have an "Atmel assembler" to begin with? When there is the free software from the GNU project: binutils, to provide assembler, linker, librarian and other utilities, GCC for the compiler, GDB for the debugger, etc.
Actually, they are! There has been a post on the avr-gcc-list mailing list of someone from Atmel requesting DWARF samples, and he said he's working on an ELF/DWARF parser.
IMO, users are interested in *any* comments from Atmel. For a long time Atmel has been seen as non-communicative. So even unofficial, personal opinions from someone on the inside are very welcome. :)
Sheesh. You guys gave all these serious academic answers. I thought a stable compiler would have a a half-life decay time of five years or more..... And no one mentioned Imagecraft, which has a global optimizer/code compressor in its compiler, and brags abvout being ansi c. There is a compiler survey on avrfreaks that shows compiler use by percent... iar, gcc and icc are the main
3, icc is 3rd with 11% last time I looked, but it wins in price and ability to talk to the developer on email.....
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.