Searching \ for '[EE] New AVR Studio 5' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=new+avr+studio
Search entire site for: 'New AVR Studio 5'.

Exact match. Not showing close matches.
PICList Thread
'[EE] New AVR Studio 5'
2011\03\03@031402 by Xiaofan Chen

face picon face
www.microcontroller.com/news/Atmel_AVR_Studio_5.asp

The feature looks quite good. Now it is using a unified IDE
for the AVR and AVR32. The current AVR32Studio
is using Eclipse based IDE and runs under
Linux/Windows.

"Features of the new Atmel AVR Studio 5 include:

   * Visual Studio Editor
   * Support for all Atmel tinyAVR, megaAVR, AVR, XMEGA, and
     AVR UC3 microcontrollers
   * C/C++ compiler
   * Assembler
   * Linker
   * Debugger & Simulator
   * Support for target board debugging via JTAG or PDI (Program
      Debug Interface)"

Their reason of not using Eclipse is quite interesting.

"All of Atmel's future development environments will be based upon
the AVR Studio IDE. Atmel will no longer support Eclipse-based IDEs
or editors. As Eclipse is more geared towards desktop PC software
development, Eclipse has not proven itself as efficient or effective as
a dedicated embedded development IDE such as AVR Studio."

The downside of using Visual Studio interface is the loss
of potential support for Mac OS X and Linux.

So Atmel is going a detour now. Microchip, on the other
hand, has the unified IDE for all PICs all along, but no
Linux support last time. Now Microchip is going to support
Linux and Mac OS X along with Windows with the new
Netbean based MPLAB IDE X.

Microchip is still doing quite well now. But Atmel is doing
much better than last time. So let's see if this move
will affect any thing or not.


-- Xiaofa

2011\03\03@043726 by Jesse Lackey

flavicon
face
I totally agree - Eclipse is a way overcomplicated frustrating beast for microcontroller development.  I use it with CodeSourcery for Stellaris ARM, and frankly I hate/fear it.  The code editor is great, stepping and looking at variables/memory etc. is smooth, but configuration hassles to get even simple projects running is daunting.  With MPLAB, I can get a new project for a PIC setup and starting-point code from an existing project running with the CCS C compiler in 1 minute.  This is simply impossible in Eclipse.  God help you if you have a wrong setting somewhere and you don't know why your debug session won't start or the compiler throws odd errors.

If you are developing 250K -> multi-million line systems with Subversion/CVS and multiple developers and targeting a half dozen platforms with 3 builds each, well, it is geared for that, absolutely. This is not the majority of microcontroller development that I do or am involved in, in any way.

I see this as the biggest impediment to widespread adoption of ARM+GCC for the less experienced pros/high-level hobbyist EEs.  I cannot recommend it to several high-level hobbyist friends who are reasonably comfortable with AVR+GCC.  I was originally very very enthused about it, saying this is the future etc. etc. and it is, but disappointingly this future does not include the more casual EE.

MPLAB and AVR studio will likely never be in the same league as the Eclipse code editor, and Microchip and Atmel will have to spend $100s of K a year on developer time on enhancing tools that Eclipse just has for the taking, but I think they are making the right choice.

I'm curious if other ARM vendors that use Eclipse have managed to simplify or streamline or bury the complexity somehow to make it more microcontroller developer friendly.

Anyway, my 2c.
J


Xiaofan Chen wrote:
>
> Their reason of not using Eclipse is quite interesting.
>
> "All of Atmel's future development environments will be based upon
> the AVR Studio IDE. Atmel will no longer support Eclipse-based IDEs
> or editors. As Eclipse is more geared towards desktop PC software
> development, Eclipse has not proven itself as efficient or effective as
> a dedicated embedded development IDE such as AVR Studio."

2011\03\03@064454 by Xiaofan Chen

face picon face
On Thu, Mar 3, 2011 at 5:38 PM, Jesse Lackey <spam_OUTjsl-mlTakeThisOuTspamcelestialaudio.com> wrote:
> MPLAB and AVR studio will likely never be in the same league as the
> Eclipse code editor, and Microchip and Atmel will have to spend $100s of
> K a year on developer time on enhancing tools that Eclipse just has for
> the taking, but I think they are making the right choice.

The problem is that apparently Microchip and Atmel no longer be
able to spend the time/money for their respective internal
developed IDE. So Microchip is switching to Netbean
(Linux, Mac OS X support along with Windows). Atmel is
switching to Visual Studio shell (Microsoft technology,
Windows only).

> I'm curious if other ARM vendors that use Eclipse have managed to
> simplify or streamline or bury the complexity somehow to make it more
> microcontroller developer friendly.
>

The NXP's low cost LPC Expresso (from Code Red) is based on
Eclipse. TI/Luminary Code Composer is based on Eclipse.

Code Sourcery's IDE is also based on Eclipse. So is Tasking's.

But take note IAR, Keil and Roley Associates are all not using
Eclipse. IAR and Keil are probably the two leading compiler
vendors for Arm based MCU (not MPU). Roley Associates'
IDE is based on QT for cross-platform support.


-- Xiaofa

2011\03\03@072821 by Chris McSweeny

picon face
On Thu, Mar 3, 2011 at 9:38 AM, Jesse Lackey <.....jsl-mlKILLspamspam@spam@celestialaudio.com> wrote:
> If you are developing ... with
> Subversion/CVS ...
> This is not the majority of microcontroller development that I do or am
> involved in, in any way.

So why don't you use any version control? I use Subversion for even my
hack projects.

Chri

2011\03\03@122439 by William \Chops\ Westfield

face picon face

On Mar 3, 2011, at 12:14 AM, Xiaofan Chen wrote:

> The downside of using Visual Studio interface is the loss
> of potential support for Mac OS X and Linux.

This is really sad.

Unless they know something about VS environment that we don't...

With Oracle acquiring Sun, the future of the Java vs C# debate is less  clear than I used to think it was...  :-(  VS/C# for Mac/Linux?

BillW

2011\03\03@124115 by Tamas Rudnai

face picon face
On Mac there is the ObjectiveC, no need C#. .NET is another thing but I
guess Mono project is just as good at some extent.

Other than that you can use BootCamp or VirtualBox or VmWare or other
virtualisation or dual boot solution to run Windows apps.

Tamas



On Thu, Mar 3, 2011 at 5:24 PM, William "Chops" Westfield <westfwspamKILLspammac.com>wrote:

{Quote hidden}

>

2011\03\03@135009 by Gerhard Fiedler

picon face
Chris McSweeny wrote:

> On Thu, Mar 3, 2011 at 9:38 AM, Jesse Lackey wrote:
>> If you are developing ... with Subversion/CVS ... This is not the
>> majority of microcontroller development that I do or am involved in,
>> in any way.
>
> So why don't you use any version control? I use Subversion for even
> my hack projects.
I think Jesse wasn't talking so much about version control than about
setup hassles. I'm not an Eclipse expert, but the support for large
projects is no good reason for complicated setup for simple projects.

I remember looking into Eclipse a few years back when looking for a
suitable replacement for the defunct CodeWright, but didn't find it
attractive -- for the same reasons Jesse mentioned. It just seemed to be
too much hassle to get something simple working, without a really
promising advantage waiting at the end to counterbalance the hassle.

FWIW, I do (and did back then) use version control, but this didn't make
Eclipse any more attractive :)

Gerhar

2011\03\03@143653 by Peter Loron

flavicon
face
On 03/03/2011 09:24 AM, William "Chops" Westfield wrote:
> On Mar 3, 2011, at 12:14 AM, Xiaofan Chen wrote:
>
>> The downside of using Visual Studio interface is the loss
>> of potential support for Mac OS X and Linux.
> This is really sad.
>
> Unless they know something about VS environment that we don't...
>
> With Oracle acquiring Sun, the future of the Java vs C# debate is less
> clear than I used to think it was...  :-(  VS/C# for Mac/Linux?
>
> BillW
If you need to work in C# on non-Windows platforms, then I suggest looking into the Mono stuff. The Monodevelop IDE isn't as nice as Visual Studio, but it's pretty good.

-Pet

2011\03\03@163812 by Jesse Lackey

flavicon
face
One word... lazyness.  Actually lack of time coupled with lazyness to set it up and learn how to use it.  Really need such, and back in the days of working with 10 developers making 1million line windows apps in the 90s it was clearly an absolute requirement.

But this year, gonna get it going.
J


Chris McSweeny wrote:
> On Thu, Mar 3, 2011 at 9:38 AM, Jesse Lackey<.....jsl-mlKILLspamspam.....celestialaudio.com>  wrote:
>> If you are developing ... with
>> Subversion/CVS ...
>> This is not the majority of microcontroller development that I do or am
>> involved in, in any way.
>
> So why don't you use any version control? I use Subversion for even my
> hack projects.
>
> Chri

2011\03\03@170341 by Charles Craft

picon face
On 3/3/2011 4:38 PM, Jesse Lackey wrote:
> One word... lazyness.  Actually lack of time coupled with lazyness to
> set it up and learn how to use it.  Really need such, and back in the
> days of working with 10 developers making 1million line windows apps in
> the 90s it was clearly an absolute requirement.
>
> But this year, gonna get it going.
Need to add a [tm]  or (tm)  here.
{Quote hidden}

>>

2011\03\03@172358 by N. T.

picon face
Jesse Lackey wrote:
> One word... lazyness.  Actually lack of time coupled with lazyness to
> set it up and learn how to use it.  Really need such, and back in the
> days of working with 10 developers making 1million line windows apps in
> the 90s it was clearly an absolute requirement.
>
> But this year, gonna get it going.
> J

That can be the reason.

2011\03\03@173244 by Jesse Lackey

flavicon
face
Ha, indeed.  But really, this time I mean it! (tm)

Glad my source control comment regarding Eclipse has spawned a good thread on the subject.  The more real-world opinions, the better.  When I get to it (TM), making a smart choice from the start is really desired.

Cheers and thanks everyone
J


Charles Craft wrote:
> On 3/3/2011 4:38 PM, Jesse Lackey wrote:
>> One word... lazyness.  Actually lack of time coupled with lazyness to
>> set it up and learn how to use it.  Really need such, and back in the
>> days of working with 10 developers making 1million line windows apps in
>> the 90s it was clearly an absolute requirement.
>>
>> But this year, gonna get it going.
> Need to add a [tm]  or (tm)  here.
>>

2011\03\04@001300 by William \Chops\ Westfield

face picon face

> [revision control]
>> Actually lack of time coupled with lazyness to
>> set it up and learn how to use it.

RCS is pretty easy to set up and probably sufficient for personal use,  or small companies.
(up to the size where more than one person is working on a project  involving the same piece of source at the same time; ie "conflict and  merge free" source control.)

Some of these modern systems (git, svn, mercurial) may have important  features for web-based collaboration and large, distributed,  development teams, but the startup effort seems to be considerable (do  I really need a web server?)

I'm not terribly happy about having to use so many different tools  just to look at open source source, either.  Sigh.

I've now used rcs, cvs, clearcase, acme (which might be entirely  internal), svn, git, and mercurial.  rcs is the only one I really feel  like I understood to any degree; for the rest I just follow  instructions...

BillW

2011\03\04@004949 by Xiaofan Chen

face picon face
On Fri, Mar 4, 2011 at 1:12 PM, William "Chops" Westfield
<westfwspamspam_OUTmac.com> wrote:

> I'm not terribly happy about having to use so many different tools
> just to look at open source source, either.  Sigh.

Under Linux (and maybe Mac), it is not that difficult. If you
just need to look at the source (like me), then it is not that
bad either.

> I've now used rcs, cvs, clearcase, acme (which might be entirely
> internal), svn, git, and mercurial.  rcs is the only one I really feel
> like I understood to any degree; for the rest I just follow
> instructions...
>

The common open source tools (cvs, svn, git) are pretty easy to
set up under Cygwin (for Windows). There are native
Windows port as well but I always feel that the Cygwin port
is easier to use and less problematic. For example, Cygwin
git seems to be more stable than MSysGit/TortoiseGit.

On the other hand, since I do not really doing any real
software development, I only use them to check out
source codes (and occasionally generate a simple
patch), so I only need to know a few commands.


-- Xiaofan

2011\03\04@011135 by William \Chops\ Westfield

face picon face

On Mar 3, 2011, at 9:49 PM, Xiaofan Chen wrote:

>>
>> I'm not terribly happy about having to use so many different tools
>> just to look at open source source, either.  Sigh.
>
> Under Linux (and maybe Mac), it is not that difficult. If you
> just need to look at the source (like me), then it is not that
> bad either.

No, it's not that difficult.  It's just messy.  Mercurial seems to  require a different version of python than is otherwise present on my  Mac, for example.  And then when you're looking at the source code you  have in some directory to see what you've changed, it can take me a  couple of tries to remember which VCS is being used there.  And some  of them seem to have been dissatisfied with standard english words  like "update" and you have to refer to the man pages or something to  remember that you should use "pull" or some other weird verb.  So...  messy and annoying.

BillW

2011\03\04@013234 by Joe Koberg

flavicon
face
On 2011-03-03 23:12, William "Chops" Westfield wrote:
> Some of these modern systems (git, svn, mercurial) may have important
> features for web-based collaboration and large, distributed,
> development teams, but the startup effort seems to be considerable (do
> I really need a web server?)

I have found the distributed versioning systems actually make fewer assumptions about the infrastructure. Git and mercurial are explicitly de-centralized, with no need for a server of any kind.  Everyone has one or more repositories (being simply a directory in some project root folder), and you commit, push, and pull changes between them at will.  That's all there is.  There is no checkout/checkin, server/client, etc...  The collaboration website just happens to be a repository that lots of people push their changes to.  And to me (for git at least) it's both completely clear and completely magic how every node in the revision tree is identified by a UID.... It's globally unique!  That makes so many things easier and eliminates the need for central naming and coordination points.

> I'm not terribly happy about having to use so many different tools
> just to look at open source source, either.  Sigh.
I agree with you a bit here.

> I've now used rcs, cvs, clearcase, acme (which might be entirely
> internal), svn, git, and mercurial.  rcs is the only one I really feel
> like I understood to any degree; for the rest I just follow
> instructions...
>
Check out http://hginit.com/ for a good Mercurial primer.  It helped me rethink and understand what was going on after having come from RCS/CVS/SVN.  After that I felt more ready for Git .


Joe Koberg

2011\03\04@013512 by Xiaofan Chen

face picon face
On Fri, Mar 4, 2011 at 2:11 PM, William "Chops" Westfield
<@spam@westfwKILLspamspammac.com> wrote:
> On Mar 3, 2011, at 9:49 PM, Xiaofan Chen wrote:
>>> I'm not terribly happy about having to use so many different tools
>>> just to look at open source source, either.  Sigh.
>>
>> Under Linux (and maybe Mac), it is not that difficult. If you
>> just need to look at the source (like me), then it is not that
>> bad either.
>
> No, it's not that difficult.  It's just messy.  Mercurial seems to
> require a different version of python than is otherwise present on my
> Mac, for example.  And then when you're looking at the source code you
> have in some directory to see what you've changed, it can take me a
> couple of tries to remember which VCS is being used there.  And some
> of them seem to have been dissatisfied with standard english words
> like "update" and you have to refer to the man pages or something to
> remember that you should use "pull" or some other weird verb.  So...
> messy and annoying.

Same here. What I do is that I create one-line or two-line shell scripts
so that I do not need to remember them.

-- Xiaofan

2011\03\04@014042 by Xiaofan Chen

face picon face
On Fri, Mar 4, 2011 at 1:24 AM, William "Chops" Westfield
<KILLspamwestfwKILLspamspammac.com> wrote:
>
> On Mar 3, 2011, at 12:14 AM, Xiaofan Chen wrote:
>
>> The downside of using Visual Studio interface is the loss
>> of potential support for Mac OS X and Linux.
>
> This is really sad.
>
> Unless they know something about VS environment that we don't...

VS Environment is not bad even though I do not really use
them much (mostly I use MinGW/MSys and a text editor under
Windows for the simple programs I work with).

> With Oracle acquiring Sun, the future of the Java vs C# debate is less
> clear than I used to think it was...  :-(  VS/C# for Mac/Linux?
>

Mono is not bad actually. Of course I do not do much programming
and my experiences are limited to libusbdotnet. MonoDevelop
(Linux) and ShardDevelop (Windows) can be used for libusbdotnet
in stead of Visual Studio. libusbdotnet works under Mac OS X
as well but I do not have a Mac.
http://sourceforge.net/projects/libusbdotnet/

-- Xiaofan

2011\03\04@100523 by Gerhard Fiedler

picon face
Xiaofan Chen wrote:

> VS Environment is not bad even though I do not really use them much
> (mostly I use MinGW/MSys and a text editor under Windows for the
> simple programs I work with).

There are a few things not to like about it (e.g. restricted to
Windows), but the debugger is the best (free) debugger I've used -- at
least for C/C++/C#.

Gerhar

2011\03\04@102157 by Joe Koberg

flavicon
face
On 2011-03-04 00:35, Xiaofan Chen wrote:
> Same here. What I do is that I create one-line or two-line shell scripts
> so that I do not need to remember them.
>
>

Git will also let you put command aliases in the ~/.gitconfig file using a section such as:

   [alias]
      st=  status
      di=  diff
      co=  checkout
      ci=  commit
      br=  branch
      sta=  stash



So you can use your favorite/well known command names such as "co" for "checkout" or "ci" for "commit"

Joe

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...