[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: [avr-gcc-list] Re: crosstool-NG
Date: Fri, 04 Mar 2011 15:02:08 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8

On 04/03/2011 14:23, Gjermund Stensrud wrote:
Hi David

What you say sounds perfectly reasonable to me. We also use AVR
microcontrollers in a professional environment and have pretty much the
same setup as you describe where we try to use the newest IDE and have
several tool-chains installed that we switch between depending on
project. If we are to upgrade to AS5 it also needs to be able to work
with different tool-chains before we will consider to use it, and if it
can't work with WinAVR we will always need AS4 installed as well.
Switching between different tool-chains can be a little tricky in AS4,
the best would be if the IDE could provide a list of installed versions
and let you choose.

I have never liked AS as an editor or IDE, so I don't have that problem. I sometimes use it as a debugger or simulator, but the precise version doesn't matter then.

When it comes to Atmels website I also find it messy and inconvenient at
times. They really should have a log-in system where you register once
and only need to log in to download. I only bothered to fill in the form
once, since they put all the files in the same folder it is easy to
guess the path of the files. I think the old versions are still there
too, if you know the file name you can download them. Either way, since
the files are there it would be really nice if they kept a neat list of
previous versions to download. WinAVR does this nicely.

Agreed 100%.

Visual Studio is a very good editor, I like it and use it a lot on C#
based windows development. It is slow, heavy and have many unnecessary
CPU and memory eating background processes. But it's good and get's the
job done, with some patience. The really big downside is that it's built
on the .NET framework which runs very badly on other systems than
windows. And which will never be used in AVR development. So it's almost
like you buy a car just to use the ash-tray. Are there really no other
good editors Atmel can build on?

I have only a little experience with Visual Studio - for PC programming, I've been a Borland man since Turbo Pascal, and these days I use Python for the PC. My issue with VS is not so much whether it is good or bad, or too big and heavy (Eclipse is not exactly lightweight), but that it is different from what everyone else uses (almost all new IDEs are Eclipse), it is not cross-platform (no matter what the mono fans may claim), and like most MS software it can totally muck up your system.

It insists on a particular choice of OS and service pack (there is nothing in XP SP3 that could possibly be relevant to AVR Development - but MS likes to force everyone to have the latest service packs whether they want them or not). It then proceeds to claw its way into the rest of the system, installing its own version of dlls and other bits and pieces throughout the OS. I have seen too many problems with MS software messing up everything else to be happy installing it on my main machine. I'll run windows because it is convenient to do so - lots of the software I need is only available for windows. But I won't willingly install other MS software.

The only time I used Visual Studio was a version of Code Composer Studio from TI that was built on VS in the same way AS5 is. It ran okay, but it had screwed up a lot of my system. Amongst other symptoms, trying to run Task Manager would BSOD. I am okay with an application crashing or failing - but not with it destroying the rest of my computer. Of course, current versions of CCS are Eclipse-based.



- 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

        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

    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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]