Quantcast

Living With Atmel Studio 6.0

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Living With Atmel Studio 6.0

David Kelly
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.

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.

--
David Kelly N4HHE, [hidden email]
============================================================
Whom computers would destroy, they must first drive mad.




_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

David Brown-4
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).

mvh.,

David

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

Dave Harper
In reply to this post by David Kelly
On 8/9/2012 9:42 AM, David Kelly wrote:
> I think its time to start a new thread leveraged off another:
Good idea - the other thread was getting cluttered with posts that had
nothing to do with the original topic.
> Forget the editor, just get the debugger right.
I agree completely.

> 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.
I started out with the XMega128 about 10 years ago.  Studio and WinAVR
were the main tools.  I've always done source editing outside of any IDE
since I've used many different programming languages depending on what
I'm working on.  Things have evolved for me since I first started with
the AVR and the current project uses an AT91SAM7X512, three Mega164Ps
and 18 XMega32As.  A test environment that drives the project uses an
additional three Mega32U4s and an XMega64A3.  Talk about a mix of
development tools!  For the ARM it's Eclipse which I use for compiling
and debugging.  For the Mega164Ps and XMega32As I still use Studio 4.18
since that was what I started the project with.  The test environment
doesn't use Studio at all - I use WinAVR on the command line and debug
with a logic analyzer. When I started the project I switched to SVN and
used the plugin for Eclipse as the ARM was the first code developed.  
When I started the code for the Mega164P I switched to TortoiseSVN
across the project and that has worked out well - especially since all
edits are done outside the IDE. I tried AS5 when it first came out and
thought it was so slow it was unusable.  I have AS6 installed now, along
with a JTAGICE3 for programming and debug, and will likely use that on
any new projects.  It seems like throughout my career nothing has been
more dynamic than the tools I've used.  Virtually every time I start a
project the first thing that needs to be done is to re-evaluate the
current tools and put together a new set that will get the job done.

Dave

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

Erik Christiansen-2
In reply to this post by David Brown-4
On 09.08.12 17:22, David Brown wrote:
> 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").

Yup, have to agree. Managing teams up to 8, and sometimes several teams
on several projects, over several decades, I've never asked either
contractor or permanent employee which editor he used. I did run CVS
myself, so I knew what we had in the can, and auto-converted CRLF line
endings if there were guys editing on M$, to stop the diffs exploding
spuriously. Everyone was happy.

> >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.)

Having observed other projects repeatedly have trouble with M$-based
version control applications, I've only allowed versioning on unix.
Things have doubtless improved more recently.

> 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).

Yes, and the specifications, in plaintext preferably. I've rarely had
them remain static for the life of a project. That makes it easier to
prove "Specification Redefinition" as cause of a reported defect, for
use in the bug database, as it comes into use prior to alpha testing.

Erik

--
Oregano, n.:
        The ancient Italian art of pizza folding.


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

Weddington, Eric
In reply to this post by David Kelly

> -----Original Message-----
> From: avr-gcc-list-bounces+eric.weddington=[hidden email] [mailto:avr-
> gcc-list-bounces+eric.weddington=[hidden email]] On Behalf Of David
> Kelly
> Sent: Thursday, August 09, 2012 8:42 AM
> To: [hidden email]
> Subject: [avr-gcc-list] Living With Atmel Studio 6.0
>
>
> Being the AVR-gcc list the development environment isn't really on-topic but
> most seem to acquire avr-gcc bundled in Atmel Studio.
>

Agreed that it's *technically* not on-topic, but I think this topic is very valuable to discuss, so I will allow it to continue. (It helps that I'm a co-admin of this list. Joerg W. may beg to differ.)

Eric

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

Erik Christiansen-2
In reply to this post by Dave Harper
On 09.08.12 10:54, Dave Harper wrote:
> It seems like throughout my career nothing has been
> more dynamic than the tools I've used.  Virtually every time I start
> a project the first thing that needs to be done is to re-evaluate the
> current tools and put together a new set that will get the job done.

About a decade and a half ago, I escaped that struggle. I've lost count
of the number of projects that have since used only the gnu toolchain,
across M68K, PowerPC, V850, and, AVR, that I can still remember.

The first step was always to build the cross-target toolchain from
source, and salt the source away for the life of the project, together
with newlib, or whatever was replacing glibc on the embedded target.
(Usually the work of a few hours - less if no config tweaks had to be
figured out for the build.) Then the RTOS.

There's enough to tackle on a new project, without ditching hard-won
toolset expertise as well.

Erik

--
Duct tape is like the force.  It has a light side, and a dark side, and
it holds the universe together.
                                                         - Carl Zwanzig

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

Dave Harper
On 8/9/2012 11:46 AM, Erik Christiansen wrote:
> On 09.08.12 10:54, Dave Harper wrote:
>> It seems like throughout my career nothing has been
>> more dynamic than the tools I've used.  Virtually every time I start
>> a project the first thing that needs to be done is to re-evaluate the
>> current tools and put together a new set that will get the job done.
> About a decade and a half ago, I escaped that struggle. I've lost count
> of the number of projects that have since used only the gnu toolchain,
> across M68K, PowerPC, V850, and, AVR, that I can still remember.

Actually that's roughly the same time I switched to gnu as well.
Unfortunately, it doesn't do everything I need - my project has a
browser based user interface so that means JavaScript and the test
environment is largely programmed in Tcl.

Dave

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

David Kelly
In reply to this post by Erik Christiansen-2

On Aug 9, 2012, at 11:18 AM, Erik Christiansen wrote:

>> 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.)
>
> Having observed other projects repeatedly have trouble with M$-based
> version control applications, I've only allowed versioning on unix.
> Things have doubtless improved more recently.
I do host my SVN repository on MacOS X. I will not let other SVN executables directly manipulate my repository.

>> 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).
>
> Yes, and the specifications, in plaintext preferably. I've rarely had
> them remain static for the life of a project. That makes it easier to
> prove "Specification Redefinition" as cause of a reported defect, for
> use in the bug database, as it comes into use prior to alpha testing.
That is a bone I have to pick with IDE's. I want things written out nice and simple as with Makefiles, not buried under a GUI.

I have a Windows project which uses libtomcrypt. Got the lib compiled long time ago under VS2008 Express. Then built another project linking against it. This past week I needed to start another and spent nearly a solid day hunting down the buried small changes in each project's Properties before I finally had a new project that would build.  :-(

But also some here are mistaking the IDE with the text editor.

I am happy with the gnu toolchain, build with Makefile. Edit with something else. But the one big thing Atmel needs to get right is the debugger.

--
David Kelly N4HHE, [hidden email]
============================================================
Whom computers would destroy, they must first drive mad.




_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Living With Atmel Studio 6.0

David Brown-40
On 09/08/12 19:05, David Kelly wrote:

>
> On Aug 9, 2012, at 11:18 AM, Erik Christiansen wrote:
>
>>> 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.)
>>
>> Having observed other projects repeatedly have trouble with
>> M$-based version control applications, I've only allowed versioning
>> on unix. Things have doubtless improved more recently.

If the "M$-based version control" was Source Safe, then it is not
surprising that people had trouble with it.  After all, MS themselves
never used it, and they recommended users do a database rebuild at least
once a week to stop the inevitable database corruption from spreading!

>
> I do host my SVN repository on MacOS X. I will not let other SVN
> executables directly manipulate my repository.

One of the reasons we standardised on SVN for version control is that it
works well cross-platform.  We have people using it on Windows, Linux
and Macs (no BSD, AFAIK).  Of course, the server is Linux.

>
>>> 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).
>>
>> Yes, and the specifications, in plaintext preferably. I've rarely
>> had them remain static for the life of a project. That makes it
>> easier to prove "Specification Redefinition" as cause of a reported
>> defect, for use in the bug database, as it comes into use prior to
>> alpha testing.
>
> That is a bone I have to pick with IDE's. I want things written out
> nice and simple as with Makefiles, not buried under a GUI.
>

You can use external makefiles with most IDE's.  It certainly works fine
with Eclipse.

> I have a Windows project which uses libtomcrypt. Got the lib compiled
> long time ago under VS2008 Express. Then built another project
> linking against it. This past week I needed to start another and
> spent nearly a solid day hunting down the buried small changes in
> each project's Properties before I finally had a new project that
> would build.  :-(
>
> But also some here are mistaking the IDE with the text editor.
>
> I am happy with the gnu toolchain, build with Makefile. Edit with
> something else. But the one big thing Atmel needs to get right is the
> debugger.
>

Previously, I have used avr-gdb and avarice for debugging AVR's.  I
haven't done so for a while (I haven't done much AVR work in the past
few years, and the boards either haven't had JTAG, or I haven't needed
to use it), so I don't know the current state of these tools.  Some time
I must have a look at them again, and see if I can use Eclipse as a
front end for the debugger (although I quite like command-line gdb -
it's very fast and efficient to use).

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Loading...