- Gjermund
On Fri, Mar 4, 2011 at 1:42 PM, David Brown <address@hidden
<mailto:address@hidden>> wrote:
On 04/03/2011 05:23, Weddington, Eric wrote:
Hi Stu,
Hope you're doing well. :-)
WinAVR is the Windows packaging of the AVR-GCC stuff, along with
the avr-libc library.
Along with some other stuff, too. ;-)
(In addition, WinAVR is about to be deprecated in favor of a
toolset integrated into AVR Studio. It is on it's last official
release, at least officially.)
Officially, it's up to me what to do with WinAVR. Admittedly there
hasn't been a lot of incentive what with AS5 coming out with a
toolchain.
However, based on some discussion on AVR Freaks, I'm reconsidering.
(This is going to sound like an "I want" rant - which I suppose it
is. Ultimately, these are things I want Atmel to stand behind -
paying people or sponsoring contributors as appropriate. I pay
Atmel for the chips we buy, and it's even possible that I will have
a chance to help with these ideas (I keep hoping to have spare time
one day), but I think it would have to be Atmel that forms the base
here.)
I am a professional developer, and my company uses AVR's in many of
our products. What I need is consistent toolchains - primarily the
compiler and library. The toolchain is part of each project I work
with - if I run a project with WinAVR-20080512, then that will
typically be the toolchain I use for that project for ever after.
You don't change toolchains in a project without very good reason
- it's too big a risk, and involves too much re-qualification and
extra testing.
So I have a range of WinAVR compilers on my machine - typically
about one or two releases a year. They are archived and backed up
just like my source code. The makefiles for my project each refer
explicitly to a given version of the toolchain.
If I need to work on the same projects on a different machine, I can
therefore easily install exactly the same toolchain there, and
continue as before.
It is vital that I can take an old project, re-compile it with the
same toolchain and the same options, and generate a bit-perfect copy
of the old binary target file.
As I say, WinAVR has made this easy for me on Windows. The AvrTools
release from Atmel's web site also works fine for this.
But I worry about the heavy integration in AS5. I fully understand
Atmel is trying to make a system that is easy to use - but it is
important to remember how professionals work, or at least how they
/should/ work. It is conceivable that I can install different
versions of AS5 in different directories as they come out, and
archive them just as I do with the WinAVR toolchains. But that is
getting very inefficient. It would be much better to always use the
latest IDE and debugger, while choosing the toolchain on a project
basis. This means, at the very least, that the toolchain should
remain separate from the IDE.
Another issue is cross-platform development. It is certainly
possible to build avr-gcc and avr-libc on Linux and other platforms
- lots of people do so. But for professional work, the toolchain
should be identical. Again, I should be able to compile the same
source code and get a bit-perfect target code binary on either
Windows or Linux (or other platforms) - only then is the toolchain
cross-platform. This /can/ be done at the moment, but it is not an
easy job to ensure that you have all the right patches and source
versions. The patch sets provided with WinAVR (and
AvrTools3.0.0.240) are an excellent starting point - but it could
easily be made very much smoother. All that is needed is a set of
three downloads for each release - a Windows binary package, a Linux
binary package, and a source tarball with the build scripts for
Linux, Windows mingw, and maybe other systems.
This is not actually anything new for Atmel - they have had
something like this for the AVR32 for years. But what is missing is
a consistency and simplicity, and transparency. There is a lot of
stuff available from Atmel - but most of it is hidden by somewhat
random placements. If you want to get the latest build of avr-gcc
for Windows, you get it by following links for the AVR32 - not
exactly intuitive. And if you want to get a specific older version,
such as AvrTools3.0.0.240 - tough luck, Atmel apparently doesn't see
the need for archives of older software. And of course when you have
found what you want, you have to "register" to get the download.
But it is not "registering" - it is a inconvenient, obtrusive and
repetitive file-in-the-form-and-we'll-email-you-a-link system.
avr-gcc and avr-libc is an incredible tool. It is a professional
quality development tool - but it is currently suffering from less
than professional distribution from Atmel. I don't believe it would
take a lot of effort or investment from Atmel's side - just an
understanding of what developers need. I even think much of it is
already in place, simply hidden away. But unless Atmel do something
here, we will end up with fragmentation. Professionals need to have
a source of "official" versions of the toolchain - ready built for
the platform of their choice - and they need that source to be
easily found from obvious places such as Atmel's website.
As an aside, why on earth did Atmel base AS5 on Visual Studio? The
world and its dog uses Eclipse, as does Atmel for their AVR32
Studio. As more people move towards Eclipse and cross-platform
development, Atmel has taken a giant leap backwards here. And it
turns out that I can't install it anyway - my main machine runs XP
service pack 2, and the AS5 installation insists on service pack 3.
I look forward to more WinAVR releases.