[avr-gcc-list] Re: crosstool-NG

[David Brown]

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.