[Top][All Lists]

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

Re: [avr-gcc-list] Living With Atmel Studio 6.0

From: David Brown
Subject: Re: [avr-gcc-list] Living With Atmel Studio 6.0
Date: Thu, 09 Aug 2012 17:22:31 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 09/08/2012 16:42, David Kelly wrote:
I think its time to start a new thread leveraged off another:

On Aug 9, 2012, at 9:05 AM, David Brown wrote:

For what it's worth, I too dislike the newer AVR Studio - partly
because I do most of my development work with Linux, and partly
because even on Windows it is a bloated mess.  I can't figure out
why they decided to use MS VS as a base - the industry has
practically standardised on Eclipse, and the single biggest request
from users for AVR Studio 5 was that it be cross-platform.  But I
guess Atmel had their reasons, and they are certainly good at
making the compiler toolchain easily available from Linux, so I
don't want to complain /too/ much.

Being the AVR-gcc list the development environment isn't really
on-topic but most seem to acquire avr-gcc bundled in Atmel Studio.

When I started on AVR an editor was bundled in WinAVR that I came to
like. AVR Studio was only launched to debug. CVS was used, and also
served as an rsync between my preferred editing machine (oddly that
was nvi on FreeBSD via PuTTY, but also often BBEdit on Mac) and my
debugging machine (XP). That is a mode I could happily return to. And
might again. And a means for Atmel to meet their cross-platform
goals. Forget the editor, just get the debugger right.

But sometimes the right professional thing to do is not customize our
development environments so much that another could not reasonably
replicate and continue our work. That currently binds me to Atmel
Studio 6.

I see that point - but I think a replicateable build system trumps a common IDE. And Atmel's idea of bundling everything with an enormous IDE, and having new installations overwrite and update existing ones, makes that nearly impossible (in particular, the installer gives you no choice about your installation path, and messes up your PATH without asking you).

You simply cannot do professional development work that way - it is a fundamental requirement that you keep the tools stable for a project. This means that if a project is developed using the avr toolchain 3.2.0, you continue using it even if you also have 3.4.0 installed on the machine. And an archive of toolchain 3.2.0 needs to be kept accessible, so that at any time you can replicate the build environment used for the project. Of course, you may migrate an existing 3.2.0 project over to 3.4.0 - but you must consider it a major change, and expect extra testing and checking, because things change between toolchain versions.

This means that whatever editor you use, you need to do your builds using specific toolchains - not the IDE's default toolchain.

Similarly, you need to have compile-time options and flags tied explicitly to the project - you can't rely on default flags from any particular version of the IDE. So that means external makefiles.

And once you've got external makefiles, externally managed source files, and externally managed toolchains, then it's pretty easy to use whatever editor you want. You can then do a "build" at any time, without having to involve the editor. As a bonus, your builds will usually be much faster than via the IDE (especially if you use "make -j").

So asking of others suffering with AS6, what SVN client do you use?
Am thinking I should advance from TortoiseSVN running outside of the
dreaded VS10 shell to something integrated. Perhaps something that
knows more about what needs to be saved and what doesn't. Something
that knows the files are in a savable state so I don't have to exit
AS6 to make sure everything is properly flushed to disk.

You should be highly sceptical about using integrated SVN clients in other programs. It is important that you don't mix major version numbers of the svn clients on a machine - you'll end up corrupting your local svn metadata, or at least getting error messages about version compatibility. So install TortoiseSVN gui client /and/ command line tools, and stick to integrated svn clients that work using external command-line tools. (This is for brain-dead windows, of course - on Linux or BSD you install the subversion client libraries once, and all programs use that automatically.)

You should not have to exit AS6 to make it save files (or else it is worse than I thought). As to which files to store in the svn repository, that is up to you. I store the source files (obviously), Makefiles, and often the final .hex file (since it makes it convenient for testing or programming from different machines).



reply via email to

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