Why is Studio such a bloatfest? Firmware upgrade without it?

Go To Last Post
114 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anyone from Atmel read this forum? If so, I would like to know why Studio has become such an hilariously big program!

I don't use Studio (or indeed Windows) any more, but I need it to upgrade to the latest version of firmware for the MkII JTAG ICE. So, here I am downloading this stupidly large piece of bloatware, just to install a few k of firmware.

Is there any other way of installing firmware upgrades? It would be nice for those of us who don't use Studio. Can't be that difficult for you to knock up.

Also, Atmel software engineers: take a long hard look at yourselves and stop falling into this trap of writing big, slow, bloaty software. It's lazy and unnecessary!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AFAIK parts of Studio are now written with some .NET stuff and to ensure compatibility with all the .NET flavors out their Atmel simply bundled half of the .NET framework with Studio ...

You could try Atmel's Windows command line tools package (24 MB download). Maybe they bundled firmware update tools with it. I don't know, I never looked at that separate bundle.

Atmel not providing a means to update their firmware from anything else but Windows is a long-standing Atmel decision. They just don't want to. It would only take them to publish the update download protocol and to regularly publish new firmware files.

But no, why be nice to your customers? And Atmel, don't give me that "to avoid ripoffs". Anyone in China with half a brain, a disassembler and probably a logic analyzer can figure it out today.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It could be somewhat smaller if all the appendices were able to be separately downloadable and installable, like battery Studio, RF Studio, Qtouch Studio, which many peole would not use or even care about.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
It could be somewhat smaller if all the appendices were able to be separately downloadable and installable, like battery Studio, RF Studio, Qtouch Studio, which many people would not use or even care about.
What, you mean they should use the idea of ( :shock: gasp! ) plug-ins? You screaming revolutionary! :twisted:

If I understand the AVR-Studio architecture correctly, it already supports plug-ins. I just wish they didn't ship all of their plug-ins with it. Perhaps a "bare bones" install, eh?

But then I would prefer that they spend their time supporting some open-source IDE with plug-ins and leave the editor stuff to someone else. (Actually, IIRC they already leave the editor to someone else.) I've played with both Eclipse and Code::Blocks and was impressed with both of them. If I could get a reasonable source-level debugger in one of them, I would probably drop AVR-Studio. My compatriot-in-crime working on the Xmega code already uses his personal copy of a separate editor (CodeWright? Nah, one of the other ones). But he needs to use AVR Studio for the debugger (and yells like a mashed cat every time :evil:).

*sigh* I suppose if Atmel decided to support a third-party open-source IDE they would choose one that I didn't like. Oh well.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They already have Eclipse know-how in-house as the AVR32 Studio is based on that AFAIK, but don't anticipate a move over to that for AVR(8) Studio. Between the lines it has sounded like
- It will be too much of an investment
- They'd have to reveal eg the JTAG/debugWire protocols
- There has been resistance aired amongst the user community

I don't think Eclipse is perfect. Re this thread it also is bloated. Still, I'd love to have the opportunity to use
- third party plug-ins for source formatting etc
- third party plug-ins for version control systems (Subversion, Mercurial, Bazaar...)
- third party plug-ins for project control (ticket/issue/task tracking)
- third-party plug-ins for automated builds and tests
- third-party plug-ins for almost anything you want
Not to mention that you could write your own plug-ins, if you really was tempted..

And that would run on any platform that supports Java.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan wrote:
I don't think Eclipse is perfect. Re this thread it also is bloated.
*sigh* :roll: I believe that "bloat" is in the eye of the beholder. It basically means, "The size of the package is preventing me from what I want to do, therefore the package is bloated." There's also a basic assumption that "The folks who created the package are drooling imbeciles who should never be allowed near a keyboard, let alone close to the package I want to use." The accusers are rarely, in my experience, all that clever and could be painted by their own brush.

Wolfgang Amadeus Mozart was once told one of his operas had "too many notes", proof positive that idiots complained of "bloatware" even in the 18th century.

Johan wrote:
Still, I'd love to have the opportunity to use
- third party plug-ins for source formatting etc
- third party plug-ins for version control systems (Subversion, Mercurial, Bazaar...)
- third party plug-ins for project control (ticket/issue/task tracking)
- third-party plug-ins for automated builds and tests
- third-party plug-ins for almost anything you want
Not to mention that you could write your own plug-ins, if you really was tempted..

And that would run on any platform that supports Java.

And that's the beauty (and cost) of open-source, isn't it? It's a hearkening back to the "good old days" of computing when we all shared source and utilities. Of course, the "good old days" weren't all that good and open frameworks mean that things are just a little clumsier (but more orderly) for little applications.

Johan wrote:
Between the lines it has sounded like
- It will be too much of an investment
- They'd have to reveal eg the JTAG/debugWire protocols
- There has been resistance aired amongst the user community
I suspect that item 1 is the deal breaker. Item 2, well they had to expose the JTAG/DebugWire interface for the AVR32, didn't they? And for item 3, I haven't heard any vehement exceptions to Atmel supporting Eclipse. They would certainly get praise from me - one less "different" IDE to maintain is all the better for me.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Getting acceptance for Eclipse was probably more easy for the AVR32, than it would be for AVR(8) users. The AVR(32) can and do run Linux, and the people delving deep into that tend to be more open to open stuff, and more against things looking like they came from Redmond.

Also, Atmel could of-course distribute proprietary binary code to drive JTAG/debugWire on a Windows installation of Eclipse "with ADT" (AVR Development Toolkit). It would be harder both politically (for sure) and technically (I imagine) harder to do the same for GNU/Linux. Eg Debian (and [K]Ubuntu etc) users seem to prefer "sudo apt get ..." rather than downloading some binary that they are never sure will actually execute correctly on their specific system. And if I understand things correctly, Atmel would have to build binaries for many, many versions of GNU/Linux. Of course they could open up the JTAG/debugWire protocols, but using yesterdays weather as a prognosis tool that is not likely to happen. Oh well.. Rant over..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stu_san wrote:
*sigh* :roll: I believe that "bloat" is in the eye of the beholder.

Que? No it's not. The completely cross-platform IDE I use for AVRs is a fifth of the size of Studio, includes the C compiler and is more feature rich.

.NET is just for lazy programmers who don't care they're making bigger and bigger, slower and slower code because it makes turning things round faster.

Atmel refuse to release the protocol for the AVRs, which is completely nonsensical. Good job there are people clever enough to reverse engineer it and provide sensibly priced, stable, fast tools.

Sorry for the rant, but this whole subject really gets my goat! :p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The completely cross-platform IDE I use for AVRs is a fifth of the size of Studio,
And the link to it is???

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DiBosco wrote:
stu_san wrote:
*sigh* :roll: I believe that "bloat" is in the eye of the beholder.

Que? No it's not. The completely cross-platform IDE I use for AVRs is a fifth of the size of Studio, includes the C compiler and is more feature rich.

...


He was defending eclipse not studio.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DiBosco wrote:
.NET is just for lazy programmers who don't care they're making bigger and bigger, slower and slower code because it makes turning things round faster.
Lazy? Maybe they are actually wise folks who've heard of Moore's law and have left their 80's programming mindset back in the 20th century where it belongs.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
The completely cross-platform IDE I use for AVRs is a fifth of the size of Studio,
And the link to it is???

www.rowley.co.uk

It's not free or open source, but it's worth every penny IMHO.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thmjpr wrote:

He was defending eclipse not studio.

OK, sorry.

Eclipse is almost as bad though. At least it's cross platform.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
DiBosco wrote:
.NET is just for lazy programmers who don't care they're making bigger and bigger, slower and slower code because it makes turning things round faster.
Lazy? Maybe they are actually wise folks who've heard of Moore's law and have left their 80's programming mindset back in the 20th century where it belongs.

Smiley

I understand your point, but it's hardly a valid one when there are native cross-platform toolsets available that are not much more difficult to use and create much smaller, more nimble code.

Saying that compact, well thought out programming belongs in the '80s is utterly bizarre. There's nothing wise in turning out a program that runs slower on much more powerful hardware than it did several years ago on much less powerful hardware with little or no benefit in its functionality.

It's a good job there are still some programmers around who take care and pride in their craft.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmmm does this mean that if Rowley would use .NET they could sell their products at 10% of the price? :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is getting confusing. Are we talking about AVRStudio versus Rowley, or are we talking about the language they were written in, or are we talking about the code they generate for the AVR? Anyway...

DiBosco wrote:
Saying that compact, well thought out programming belongs in the '80s is utterly bizarre. There's nothing wise in turning out a program that runs slower on much more powerful hardware than it did several years ago on much less powerful hardware with little or no benefit in its functionality.
Bizarre? I haven't found that my PC programs running under C#.NET runs slower and I find the benefit to be an amazing increase in productivity. And my PC programming goes back to the original IBM PC, and before that I even programmed with switches so I've some experience with 'compact' and even, believe it or not 'well thought out'. I can write a nice little GUI serial terminal program in minutes using C# .NET, hours using C++ with MFC, days with the original Windows API - what reason would I have for spending more time on the task than necessary?

DiBosco wrote:
It's a good job there are still some programmers around who take care and pride in their craft.
I'm not sure how valid a software engineering principle it is to insult people while asserting superiority with no proof.

And are you asserting that the $1500 Rowley compiler is going to give me something I don't already have? So what if it makes a little smaller and a little faster code than my FREE AVRStudio WinAVR AVRDude setup when I have yet to face either size or speed penalties? If I hit either, I'll drop in some tuned assembly code in the spots that I've profiled to prove the need.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use their ARM and MSP430 tools, they are excellent.

Apart from the superior compilers, you get the benefit of their IDE, which is the best I've ever used, with superb editing and debugging facilities - it's far better than AVR Studio. Other advantage are that you use the same IDE for ARM, AVR, MSP430 and MAXQ chips, and that it runs on MACos and Linux, as well as Windows. Support is very good, with queries answered within an hour or so, as a rule. Their debug hardware is very good, also.

Hobbyists can get a personal license for $150, which is very reasonable.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still waiting for a good reason to move from FREE tools that work just fine for me. What do I get by $150 tool for personal use or $1500 if I want to sell anything? And I don't use: 'ARM, MSP430 and MAXQ chips', and I don't run 'MACos and Linux' so what is the advantage?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said, a better compiler, better IDE and simulator and debugger, and excellent support. They compete with IAR, a far larger company. I've used IAR software and the Rowley tools are better and cheaper. I've used their software for years.

They even give it away to deserving causes. I'm working on a medical system with a university in France, and Rowley gave them a complimentary ARM license.

Why don't you try it for yourself, it's free for 30 days.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

better compiler

"better" than WHAT exactly? and "better" in what way?

(my understanding is that the Rowley tool chain is based in GNU/GCC - is that the case?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It produces faster or more compact code, the usual criteria for comparing compilers.

The Rowley ARM compiler is gcc, with their own libraries. The other compilers were written from scratch. They could have written their own ARM compiler, they have said, but the gcc ARM compiler was already pretty good, so there wasn't much point.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

better compiler

"better" than WHAT exactly? and "better" in what way?

(my understanding is that the Rowley tool chain is based in GNU/GCC - is that the case?)

The ARM one is, the others are all their own compilers.

Edit, sorry Leon, didn't see your reply.

Last Edited: Sat. Dec 19, 2009 - 06:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
I'm still waiting for a good reason to move from FREE tools that work just fine for me. What do I get by $150 tool for personal use or $1500 if I want to sell anything? And I don't use: 'ARM, MSP430 and MAXQ chips', and I don't run 'MACos and Linux' so what is the advantage?

Smiley

From my perspective I get tools that run on a much better operating system than Windows and I don't have to buy Apple's hilariously expensive vainware (and equally as locked down OS as Microsoft's).

Plus, I get faster, more responsive tools than were I running Studio and cheaper, better supported tools than were I running IAR. The latter is what you'd get on running Windows.

If you're happy to put up with Studio, that's totally cool and I wouldn't dream of trying to force anyone to use something else. What I cannot and will not accept is that Studio has not become a much slower, bloatier tool than it used to be. I have run it since the late 90s up until last year on and off and I've seen it with my own eyes.

Last Edited: Sat. Dec 19, 2009 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
This is getting confusing. Are we talking about AVRStudio versus Rowley, or are we talking about the language they were written in, or are we talking about the code they generate for the AVR? Anyway...

Yes, sorry, we've gone off at a tangent here. :)

smileymicros wrote:
Bizarre? I haven't found that my PC programs running under C#.NET runs slower and I find the benefit to be an amazing increase in productivity.

Sure, an increase in productivity for the programmer maybe, but for the poor sap who's trying to use the end app, it's a nightmare. You haven't found your C# .NET programs running slower than ones you wrote on which other toolkit? And how big and complex are these programs?

I've used apps like TI's Code Composer and Nikon's NX2, a simple little Bluetooth app from ConnectBlue all of which are .NET based and they're terrible. Huge, huge installs and so desperately slow.

The same argument is going on in the Linux world with Mono which is the equivalent of .NET. I just completely gave up on all Mono based programs as they're such resource hogs.

smileymicros wrote:
And my PC programming goes back to the original IBM PC, and before that I even programmed with switches so I've some experience with 'compact' and even, believe it or not 'well thought out'. I can write a nice little GUI serial terminal program in minutes using C# .NET, hours using C++ with MFC, days with the original Windows API - what reason would I have for spending more time on the task than necessary?

Because there are other IDEs out there for writing GUIs that enable you to knock up programs that are quicker and smaller, but still quick to put together? I can knock out a C++ terminal program in minutes using the Qt toolkit I use.

smileymicros wrote:

I'm not sure how valid a software engineering principle it is to insult people while asserting superiority with no proof.

The proof is there for my eyes to see, .NET based programs are big and slow. A virtual machine is inevitably slower than native code, it's the nature of the beat just like with Java apps. You seemed to be asserting than anything other than .NET belongs in the last century which is insulting to other people's programming style and patently not correct.

Not everyone can afford to keep buying new hardware to keep up with Microsoft's latest attempt to kill off the rest of the competition. :p

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that Rowley uses Qt, BTW.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The definitely do, Leon. They set up a nightly build which then produces programs for all three platforms that only needs minimal differences between each version. The Qt toolkit is really nice and Nokia's new qt-creator is a cracking IDE.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One advantage of paying $1500 for the Rowley software I forgot to mention is that the superior debugging facilities will mean that applications can be developed much quicker than with AVR Studio. The time saved will pay for the tools in a few days.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
One advantage of paying $1500 for the Rowley software I forgot to mention is that the superior debugging facilities will mean that applications can be developed much quicker than with AVR Studio. The time saved will pay for the tools in a few days.

Yes, I remember being amazed at things like being able to click on a breakpoint while the program was running. To be fair, they may have implemented that in Studio now.

I love the HUD style windows for things like traces and watches in v2.0, you can spread that and the code windows across two monitors or lock them all into one window. Is very nice. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DiBosco wrote:
The proof is there for my eyes to see, .NET based programs are big and slow. A virtual machine is inevitably slower than native code, it's the nature of the beat just like with Java apps. You seemed to be asserting than anything other than .NET belongs in the last century which is insulting to other people's programming style and patently not correct.
Last point first - by defending myself and those who chose to use modern tools - I'm insulting others? You say we are lazy and lack pride in our work, but by countering your slam, I'm insulting someone?

But the main point still stands. You are asserting without proof that .NET or Java apps are big and slow - yet designing code for the current generation of systems has been the driving force for the evolution of the software industry since day one. More memory and faster CPUs lead to larger code that, yes, runs slower on antique devices, but does just fine on most peoples PCs. Are you suggesting that we should still be building code for the 386 or maybe that is too advanced and we should be making sure everything is up to snuff for a 286 with 64k RAM a 51/2 inch floppy and a 5 Mbyte hard drive?

And of course there are really bad programs written in .NET and Java, there were really bad programs written in assembly for the original IBM BIOS, saying that one thing has problems doesn't prove that the other thing has no problems (IIRC there is a Latin term for that kind of argument dating from Aristole's book on rhetoric).

Okay, so you start a thread complaining about code bloat in a program that by your own original statement you can't use anyway since it doesn't run on your chosen system. One just has to wonder why a Linux user is complaining about a program written for Windows. So I have to ask, other than educating us benighted folks who like Atmel's tools, what is your real goal with this thread?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An altruistic endeavor to save AVR users time and money?

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I can knock out a C++ terminal program

Oh dear, oh dear!!! This is too good to be true!...

You've missed a lot of proof presented here on AVRfreaks over the last couple of years, This is how it is: C++ creates bloated and slow programs too!

[OK, I made myself promises both to stay out of that argument unless something really bad showed up, and away from this thread, but that one just made it soooo unresistable]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
Last point first - by defending myself and those who chose to use modern tools - I'm insulting others? You say we are lazy and lack pride in our work, but by countering your slam, I'm insulting someone?

Er, yes! You started being insulting by saying your way was the only right way and other methods belonged in the last century! I was just hitting back.

smileymicros wrote:
But the main point still stands. You are asserting without proof that .NET or Java apps are big and slow

Er, no. All .NET programs I have run have been hideously slow and bloaty. There's the evidence. It's quite simple. Show me a small, nay, medium sized, nimble .NET program beyond anything simple and I'll accept your point.

Why is it that .NET programmers cannot get their heads round the simple fact that the very nature of the whole environment means it will be be bigger and slower? How can a virtual machine not be slower than native code?

Why is it that lots of examples of huge program written using the .NET platform are thrown at .NET programmers and they just say, ah it's because it's badly written? Why is it that people cannot see that just because something is put together quickly, does not make it best for the end user?

smileymicros wrote:
- yet designing code for the current generation of systems has been the driving force for the evolution of the software industry since day one. More memory and faster CPUs lead to larger code that, yes, runs slower on antique devices, but does just fine on most peoples PCs.

That doesn't make it right, and I'm sorry, but I have seen it with my own eyes that older, but far from ancient, hardware can make some software fly and other crawl. I have an HP6000 P4 1.6GHz laptop that flies running the latest Mandriva release that simply crawled with XP and .NET apps and wouldn't even run Vista.

smileymicros wrote:
Are you suggesting that we should still be building code for the 386 or maybe that is too advanced and we should be making sure everything is up to snuff for a 286 with 64k RAM a 51/2 inch floppy and a 5 Mbyte hard drive?

Nice argument. roll:

smileymicros wrote:
And of course there are really bad programs written in .NET and Java, there were really bad programs written in assembly for the original IBM BIOS, saying that one thing has problems doesn't prove that the other thing has no problems (IIRC there is a Latin term for that kind of argument dating from Aristole's book on rhetoric).

Correct, you can get poor programs in any language, but I again state that you cannot get nimble, small programs of any complexity with .NET.

smileymicros wrote:
Okay, so you start a thread complaining about code bloat in a program that by your own original statement you can't use anyway since it doesn't run on your chosen system. One just has to wonder why a Linux user is complaining about a program written for Windows. So I have to ask, other than educating us benighted folks who like Atmel's tools, what is your real goal with this thread?

Smiley

It's quite simple - as I explained at the start of the thread - I had no choice but to download a massive, slow program just to update the firmware on my JTAG MkIIs and had to use my emergency laptop for the rare occasion when I have to go back to the world of Windows. Everything else that's gone on has been in reply to other people's points.

Even if there had been a little program in Windows to do it, I'd have been happy(er).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

I can knock out a C++ terminal program

Oh dear, oh dear!!! This is too good to be true!...

You've missed a lot of proof presented here on AVRfreaks over the last couple of years, This is how it is: C++ creates bloated and slow programs too!

[OK, I made myself promises both to stay out of that argument unless something really bad showed up, and away from this thread, but that one just made it soooo unresistable]

Much as I am not that keen on C++, I have seen many examples of C++ program written on ARM7s. I would agree, it's not anything like as fast or small as C.

Genuine question: what would you recommend for writing object orientated PC programs that's less bloaty than C++ but still powerful? (I'm not being sarcastic, I would happily try and learn something else.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
An altruistic endeavor to save AVR users time and money?
I fully understand that your efforts on behalf of Microchip are altruistic and that your goal is to save AVR users time and money. Your honest sincerity is so persuasive that I think that it will only take a few more of your generous and unbiased posts to convince the folks at Atmel to finally sell assets to Microchip, shutter their doors, quit trying to pollute the world with AVRs when PICs are so much better, and finally unplug AVRFreaks so that those of us wasting time here can start getting real truth on the Microchip forum.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
leon_heller wrote:
An altruistic endeavor to save AVR users time and money?
I fully understand that your efforts on behalf of Microchip are altruistic and that your goal is to save AVR users time and money. Your honest sincerity is so persuasive that I think that it will only take a few more of your generous and unbiased posts to convince the folks at Atmel to finally sell assets to Microchip, shutter their doors, quit trying to pollute the world with AVRs when PICs are so much better, and finally unplug AVRFreaks so that those of us wasting time here can start getting real truth on the Microchip forum.

Smiley

What on earth has the above got to do with this topic? It seems completely off-topic to me, and an unwarranted hijacking of this interesting thread.

I use both PICs and AVRs, and several other MCUs. Like most sensible designers I choose the most appropriate chip for the job in hand; it might be an AVR, it might be a PIC, or something completely different like an XMOS chip. I choose whatever gets the job done as cheaply and efficiently as possible. Your "one size fits all" policy is inappropriate for successful embedded systems design.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have seen many examples of C++ program written on ARM7s. I would agree, it's not anything like as fast or small as C.
[...]
Genuine question: what would you recommend for writing object orientated PC programs that's less bloaty than C++ but still powerful?

I've made my opinions on this matter clear several times here on 'freaks. I'll summarise very shortly, and you seek out those threads, OK?
- C++ has some costs for specific constructs, compared with C.
- OO C++ as such bears no substantial additional costs as compared with C in most cases.
- Classes as such bears no aditional costs.
- Static member functions bear no additional costs.
- Non-virtual member functions bear no aditional costs.
- Virtual fuctions bear the aditional costs of one extra indirection at call.
- For avr-gcc there is a cost in that the vtable is allocated in RAM, and many AVRs are RAM challenged. If OTOH the vtable would be in flash ROM then the extra indirection at call would add a comparatively costly indirection.
- As I recall (I might be remembering badly though) the word is still out re the cost of template programming on AVRs.
- A feature in C++ that you decide to not use will not cost anything (this was an explicit design goal for the language).

The apps you claim to be bloated are likely so because of large and slow support libraries.

As for AVR Studio it does not consume much of my PCs memory, nor much of its hard-drive space , nor its CPU time, IMO. I'd gladly take a Studio double the size on disk if it would have the enhanced features and functionality that has been discussed here.

As far as I know, AVR Studio is written in C++ (and I suspect that it is largely MFC based).

I've programmed in many different languages, from assembler to C, to C++, to the higher languages of the eightites and nineties. Right now I make a living as a .NET programmer. I've never been as productive as now, despite my brain being a lot slower nowadays (my brain suffers from the inverted Moores Law :wink: ).

Oh well, not so short ater all.

Oh, the recommendation? Any language that you feel comfortable with. If you like Java, fine. If you fell like C#, cool. C++? By all means. Use the one that saves the most time. Salary-wise one to five hours of saved time will get you that larger hard-disk and change for a Jolt.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't really understand your point, Johan. I would never think of using C++ on an eight bit micro and Java and C# are much slower than a native C++ for GUIs. Sorry, maybe I'm missing your point.

Your experience of Studio's speed is very different to mine and to my mind it's irrelevant that we have big disk drives. It's not a claim that it's bloated, it's a cold fact. Compared to other some other IDEs it's big and slow. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Slow might be a problem, though I have not perceived it as such. I think the functional deficiencies and bugs are a more pressing issue, and feel like Atmel should work on these rather than speed issues any time they have to choose. Point me to a specific manouvre in Studio that is slow, and I might change my opinion. Slightly.

Quote:
It's not a claim that it's bloated, it's a cold fact.

AVR Studio consumes the enormous amount of about 120 MB on my hard disk AFAICT. 1/1000 of a "smallish standard size" hard disk. Are you arguing that regardless of what technology we posess we should, as a principle, press for smallest programs possible regardless of other factors involved? 116 MB is a wee in the Mississippi as far as I am concerned.

Quote:

Sorry, maybe I'm missing your point.

My point was that C++ as such does not necessarily produce bloat or sluggishness, neither on desktop PCs nor on AVRs.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did Rowley do a Motorola IDE/compiler at one stage? (don't see Mot/Freescale mentioned there)

I'm trying to find the old install cd but could have been something else.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt it. Paul Curtis who founded the company has always had a soft spot for the MSP430, and deals mainly with it. I'm quite sure that the MSP430 compiler was their first product. I think it's still their biggest market.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are correct (for once :lol: ) it was Codewarrior I was thinking of.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried Codewarrior once, on a Freescale DSP kit. I didn't think much of it.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Did Rowley do a Motorola IDE/compiler at one stage? (don't see Mot/Freescale mentioned there)

I'm trying to find the old install cd but could have been something else.

No, I did try to persuade Paul to do an HCS08 IDE, but he wasn't interested. IIRC, he said there just wasn't a market for it.

AFAIK, the ARM IDE is their biggest seller. That would, I think, make sense as it's an all pervading set of cores these days!

Last Edited: Sat. Dec 19, 2009 - 10:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
I tried Codewarrior once, on a Freescale DSP kit. I didn't think much of it.

Oh, I used Codewarrior for the 56800 DSP family and it was the single most terrible piece of software I've used! We ended up ditching it and using TI's Code Composer which is also awful, but at least usable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Slow might be a problem, though I have not perceived it as such. I think the functional deficiencies and bugs are a more pressing issue, and feel like Atmel should work on these rather than speed issues any time they have to choose. Point me to a specific manouvre in Studio that is slow, and I might change my opinion. Slightly.

I suppose all I could do is say have a go with Crossworks and just see what you think about its speed and features.

Quote:

AVR Studio consumes the enormous amount of about 120 MB on my hard disk AFAICT. 1/1000 of a "smallish standard size" hard disk. Are you arguing that regardless of what technology we posess we should, as a principle, press for smallest programs possible regardless of other factors involved? 116 MB is a wee in the Mississippi as far as I am concerned.

lol

No, I think your point is fair that there has to be a compromise between size and ease of development, especially when it comes to GUIs, especially when hard drives are so big. Where I will disagree is just saying, ah **** it, it doesn't matter that ours is way bigger than what other people are managing. You surely have to look at what engineering feats others are pulling off and try and improve?

Quote:
My point was that C++ as such does not necessarily produce bloat or sluggishness, neither on desktop PCs nor on AVRs.

Right, whereas .NET does, as does Java. To go back to the Eclipse point someone made. Horrible, horrible big slow environment that is way over the top for little AVR projects.

I dunno, maybe I have it wrong and it doesn't really matter that there are perceptible and sometimes long delays in things when running software packages. Take Eclipse as an example, when you're switching perspectives and compare that with (sorry to use the example again) Crossworks where switching between debug and code screens is instantaneous, even on my old HP6000. All I can say is it bugs the **** out of me and I know others who feel the same way. So let's have the choice.

I am very impressed with Google's Chrome at the moment. Boots up really fast, as opposed to Firefox which has become very slow to boot and runs script heavy pages faster than FF. To my mind, that's the kind of thing people should be striving for, not just saying size doesn't matter! :P

And this brings me back to a previous point; it's all fine if some people are happy with Studio and don't want to use something better, faster and leaner but, man, release protocols so that there is choice for other people. Take a leaf out of ARM's book and make these things easier for people to do. Atmel should be concentrating on making their (really excellent) microcontrollers and leave the tools to third parties and open source communities. So should all hardware manufacturers come to that.

You could have a wee Python, or Perl or Tcl or some other script to to do that firmware upgrade that would be tiny and the open source community would gobble it up if Atmel let them. Hell, it would reduce the burden of the people in Trondheim who have to keep this software up to date!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You surely have to look at what engineering feats others are pulling off and try and improve?

Absolutely not if it is "Look how clever we are - we can do something that is just 1/2000 of a hard disk compared to AVR Studio that is 1/1000 of a hard disk!" Comes embarrasingly close to comparing d*ck sizes if you ask me. What's the productive point?

Quote:
To go back to the Eclipse point someone made. Horrible, horrible big slow environment that is way over the top for little AVR projects.

Well, I for one have argued that there are productive advantages with choosing Eclipse. I'd love to capitalize on all those plugins. I'd love to have fewer IDEs to keep in my stupid little head. (The four or five I'm more or less forced to keep active at the moment is more than enough.) I'd love to have the fredom to choose to do AVR development on any common platform (not being forced to use Windows if I'd like to take advantage of eg ICE). A switch of perspective takes one or a few seconds on my machine - again my brain is slower than that.

As long as Moores law more or less works like it has, then the "bloat" you dislike will continue. When Moores law stops working, and I saw someone deem it to be dysfunctional within a few years due to reaching technology limits, then the "bloat" trend will eventually be broken.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do see your point about comparing **** sizes (nice way of putting it!) and to an extent I will agree with your point, but I do think that a bigger app will probably be slower. I only have a 20 gig hard drive on my excellent laptop for example and a nob-off great program like Studio takes a lot more than 1/1000 of the HDD (especially when you take the space the OS takes up into consideration). I don't really want to splash out for a new lappy just yet, thanks!

On the point of cross platform IDEs, I could not agree more, I just don't think a Java based solution like Eclipse is the way to go. There are other ways of doing cross platform IDEs and they already exist. In fact, you can already do AVR, MSP430, ARM and Dallas development on Linux, OS X and Windows with an identical IDE. ;)

I'm not sure what you mean when you say "(not being forced to use Windows if I'd like to take advantage of eg ICE" btw.

Sorry, I'm going to make a third point. The whole Moores law/software bloat thing has already started to change, it's just that it's not in the Windows world. In the Linux world there is a huge choice of lightweight desktops and applications. Not all apps, I grant you, Open Office is huge, but then you have lots of choices of smaller apps like koffice, Abi word etc. It's one of the many things that attracts me to Linux. (Sorry, way off topic now!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DiBosco wrote:
It's not a claim that it's bloated, it's a cold fact.
'Bloated' by definition means 'Much bigger than desired'. It has no formal engineering meaning but is merely an opinion. Those of us with computers made in this century might not consider AVRStudio 'bloated' Johan doesn't, I don't, it is OPINION not 'a cold fact' like you are asserting.

leon_heller wrote:
I use both PICs and AVRs, and several other MCUs. Like most sensible designers I choose the most appropriate chip for the job in hand; it might be an AVR, it might be a PIC, or something completely different like an XMOS chip. I choose whatever gets the job done as cheaply and efficiently as possible. Your "one size fits all" policy is inappropriate for successful embedded systems design.
And yet we keep asking you for links to PIC or XMOS or any other chip specific forum like AVRFreaks to show your honest benevolence and lack of bias by recommending AVRs on those forums. But we don't see that do we? All we see is you here trying to sell folks on competing products for reasons you claim are altruistic yet so many of us question. At least you are consistent and your motives have been long clear.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have yet to see an application on those forums that can be done better or cheaper by an AVR!

Microchip makes such a vast range range of devices that it is very easy to find a chip with exactly the right performance, peripherals and price for a particular job. That is why they are number one in 8-bit MCUS and Atmel is fifth. Their MAPS utility does the selection in a few seconds:

http://www.microchip.com/maps/microcontroller.aspx

You can even download it and run it on your own PC. I often wonder why Atmel doesn't provide anything like it.

The 32-bit XMOS four-core chips deliver 1600 MIPS, I don't think that anyone on their forum would be impressed by a mere 20 or 32 MIPS! One XMOS application actually used a small AVR, as an ADC connected to the XMOS chip via a (very slow) XLInk implemented in software on the AVR. XLInks can run at 200 Mbit/s. A single-core XMOS chip delivers 400 MIPS and has up to eight 100/50 MIPS hardware threads (like having eight processors) for $7.50. I don't see Atmel competing with that for a very long time.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am in complete agreement with you about choosing the best controller for the job.

Quote:
I have yet to see an application on those forums that can be done better or cheaper by an AVR!

I find this very strange. I would presume that there is a wide range of applications discussed.

IMHO it is equally 'troll' to religiously promote AVR or PIC to the exclusion of anything else. However since this is an AVR forum, it is quite natural for people to investigate an AVR's suitability.

Regarding the original subject: I find it irritating that you have to download a massive Studio package just to fix a small efficient command line utility.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at the forums for yourself and see if you can find an application that might be better served by an AVR:

http://www.microchip.com/forums/Default.aspx?

http://www.xmoslinkers.org/

http://www.xcore.com/

Smiley (he sounds more like Grumpy) seems to have a hobbyist's mentality. His advocacy of an AVR in every application when there might be a better option isn't the approach favoured in industry.

I've even used a PIC master and several slave AVRs on the same PCB before now, using each device's strengths for that particular application. It was very cost-effective compared to my colleague's suggestions, and management loved the idea.

Leon Heller G1HSM

Last Edited: Sun. Dec 20, 2009 - 12:18 PM

Pages