Plea for AVRStudio for linux

Go To Last Post
28 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh mighty Atmel, hear my pleas...
Make a AVRStudio porting under linux...
I'm thinking about switching and this would be a advatage...

Thanks,

David

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

Suggest you search here for "wine". I'm pretty sure someone previously got Studio working under Wine in Linux.

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

> Suggest you search here for "wine". I'm pretty sure someone
> previously got Studio working under Wine in Linux.

But kinda terrible and complicated, and possibly even violating the
legal stuff.

I think it's really time for AVR Studio to become multi-platform. That
would not only include Linux, but also the apparently growing MacOS X
AVR users community.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

avrstudio works under the free version of vmware. I have used it with an stk500 and was able to read fuses okay so I cant imagine it having trouble with the rest of it.

I really am amazed how well vmware works. I have tested it further with my PCB CAD software and that works great. The 3d generation doesnt really work that well but this is due to now getting direct access to the video probably.

Anyway, vmware really is working very well.

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

> avrstudio works under the free version of vmware.

But that requires a full-blown Windows installation, including the
licensing fees for Microsoft. Also, it's limited to the few supported
Linux versions, and misses the point for a wider range of host systems
(free Linux versions which are not supported by vmware, other Unixes,
MacOS X).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

I totally agree that the best option is a platform independant version. But this would take time and the OP is talking about switching now.

As he is already running AVRStudio, he has a microsoft operating system already. So for him at least vmware might be a practical option to get going now and enjoy the benefits of Linux as well. Ubuntu definately runs it fine if that is a good distro to start off with.

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

PC users have another option. They can dual boot their computer with Windows and Linux. Just make at least one extra general purpose FAT32 disk partition that both operating systems can read/write to for shared data. I use FAT32 because I do not trust Linux to write to a windows NTFS partition, but I do use “read only” NTFS from Linux. This should also work for BSD. I know this does not address the desire for a platform independent version, its only offered as a work around for some users.

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

I second the wish that the AvrStudio should become native multiplatform software, it would simplify our OS choices.
However, as stated above, AvrStudio runs pretty well under wine on my slackware machine. The only prerequisite to work with AvrStudio on wine is to install IE (5 or 6) before (I don't know license problems for that). Thus an native DLL is installed (msxml3) and should be used when start Avrstudio under wine.
And one more thing: the JTAG ICE clone (RS232 version) works nice but I'm really curious about various USB tools (MK2, Avrdragon...).

Daniel

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

I can not see these days given the similarity of the Operating systems why any program has to be platform dependent.

Most modern code is built with some sort of C++ application builder. What does it matter how the skins are created be it X11, Quartz or DirectX. It seems that most of the display graphics are being handled by accelerator cards anyway.

There is no excuse for ATMEL NOT to make a *nix port of AvrStudio that supports a generic window manager like X11 and let the user choose what skins to use.

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

Well, the excuse for the current system that it has been inherently
bound to the MS platform initially by relying on MS proprietary
stuff (namely on MFC), so it will require a full rewrite into some
kind of modern GUI system. But then, it will probably also kill a
lot of MFC-related bugs in it. ;-)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

dl8dtl wrote:
Well, the excuse for the current system that it has been inherently
bound to the MS platform initially by relying on MS proprietary
stuff (namely on MFC), so it will require a full rewrite into some
kind of modern GUI system. But then, it will probably also kill a
lot of MFC-related bugs in it. ;-)

Well the windows APIs and the foundation classes are actually "borrowed." from apple development tools like macapp which dates from the late 1980s. This was a C++ fingerpainting system that was moderately successful.

With the replacement of the "resource fork" on the mac with nib files that can be fingerpainted, along with the introduction of "carbon events," There is really little to distinguish the difference; when programming in C++ these days.

Most of studio seems to be XML databases. Which seems to be what apple calls plists. The rest is just HID window handlers and state machines that change state based on OS events.

I have a project at hand which is a USB scanner. The code is written in MFC++. I opened this code with the latest Xcode tool from apple. The "test bench" application from National semi is almost identical to AVRstudio in that it displays register settings and results into generic windows. The database are *.ini files, but the effect is the same.

Originally this NS test bench code connected to a parallel version of the LM9830 scanner controller chip. National semi also makes USB versions of the LM983x family. I can take my old LM9830 parallel chip, throw an FTDI and an AVR in front and it now is USB.

To make the NS test bench MFC++ work all I need to do is create some window skins with the nib framework and change the MFC classes to call the almost identical carbon event classes both of what started life in the late 1980s as Mac app c++ classes.

National semi gave the LM983x MFC++ code to one of the sourceforge projects. This is code is now the root of almost all of the popular scanner support under Linux and the other *nixes.

A few years back Win98 and MFC did make sense as OS X was in transition. That there were some things that had to use Intel endians or the need for serial ports. I do not think that this is the now the case.

The way I see it is that modern programmers are just not taught to think abstractly anymore.

-julie

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

> The way I see it is that modern programmers are just
> not taught to think abstractly anymore.

Full agreement on that. However, to have a look over your horizon, I guess you
need the experience there's more out there in the world than your own yard.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

I am going out on a limb here and taking an unpopular position: Do not create an AVR Studio for Linux.

It is easy for a bunch of people who have never seen the source code to make grand, sweeping statements about how easy it would be to port it to Linux, but reality will intrude and problems will occur throughout the development and support cycles. I've been a professional software/firmware developer since 1980 and I have *NEVER* seen a major software project ported to a new OS without the task becoming an order of magnitude harder and more time consuming than was originally predicted.

Atmel would need experienced developers who are comfortable working with both Windows and Linux. They would need technical writers to create documentation on the installation and configuration of the tool under various flavors of Linux and differing windows managers. Time would be spent tracking down why feature X has problems under Linux and not under Windows. And that's just scratching the surface.

Basically, it would dilute the effort, delay the addition of new features, and result in a slower response to bug reports. And for what? So that a tiny fraction (less than 10%) of the AVR Studio users could avoid buying a Windows license and/or use their favorite OS? Sorry, but I don't find that to be compelling. AVR Studio is a complete Integrated Development Environment (IDE) and I don't see how putting out a Linux version would result in its users being significantly more productive. You click on an icon and it runs, so how does Linux improve on that?

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

To fmaxwell;

I like your rebuttal argument about sweeping statements. It is almost persuasive. I must respectfully disagree with their application to the subject at hand.

I have been programming since 1977. Yes 30 years this spring. For first 20 years of that I was associated with Apple. So I have an interest, almost of a religious nature for not wanting to use windows.

I have seen this attitude often. It is a popular excuse by clueless managers who underestimate the time to market. It is much the reason that for the last 30 years I have had to find a new job every 18 months. This is why the industry likes young programmers. Use them and throw them away.

I and others, who have been around and programmed if not millions of lines of code at least hundreds of thousands of lines. Would not be making this plea if we had not thought about it. I actually built a version of X11 APIs to run under OS8! It is on my website still to this day.

At the moment I am porting that National Semi code for scanners over to handle my AVR front end to their chip and run the code from OS X. So I am not speculating or making sweeping statements here.

The concern is not so much clicking on the program and it runs. It is more of clicking on the program and it does not run. To wake up one morning and be told. "Sorry, unless you pay your extortion and protection fees you have to leave the playground." That is what scares me the most.

I am also making the argument that given the age and stability of C++ and the application building (Fingerpainting) programs that allow anyone who can type and click a mouse to modify someone else's work. That there is no longer an excuse to tie code like AVRStudio to a specific hardware platform.

-julie

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

Besides, I have yet to see a single large project that wouldn't benefit
from a full rewrite. ;-) For sure, it might not be quite stable in
version 1.0, but the users will miss many of the old bugs afterwards...

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

I should resist, but I can't. If all large projects benefit from a rewrite and you do rewrite a large project, you still end up with a large project which therefore must also benefit from a rewrite itself. It all seems kind of infinitely recursive :).

Seriously, a rewrite sounds like a hard sell for a free IDE. Especially since the software is already keeping up with new products and maintenance. Personally I also would love to see a platform independent solution, but I do not see any path that leads there yet.

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

> If all large projects benefit from a rewrite and you do rewrite a
> large project, you still end up with a large project which therefore
> must also benefit from a rewrite itself.

That's a wrong conclusion -- unless you are Microsoft, and start the
rewrite with a new set of people, as you've already scared the
previous team away. If the same people are rewriting it, they
certainly have learned their lesson during the maintenance period of
the first attempt. Usually, the more maintenance you are doing, the
more you recognize what should have been done in a completely
different way straight from the beginning.

I disagree that good multiplatform software requires developers who've
got equally good skills in all platforms. As long as the platform
abstraction is already provided by some kind of toolkit and the
developers got some form of self-discipline to modularize their code,
a multiplatform project can be run with something like an 80:20 or
even 90:10 ratio on the developer's side (but of course, it won't
really work with a 100:0 one :). If you don't believe it, take a look
at AVRDUDE. It is multiplatform (Unix, Win32, MacOS X), and while it
arguably required a bit more feedback from the MacOS X users to get it
run smoothly there, it is run on the developer's side with something
like a 98:2:0 ratio between these OSes. (Each OS is further divided,
so Unix = [Linux, FreeBSD, Solaris], and Win32 = [MinGW, Cygwin].)

Of course, what it really takes is some goodwill by the developers to
really support that effort. Otherwise, AVRDUDE were still a
FreeBSD-only tool that it used to start out as several years ago.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Hey, whatever happened to that platform independent runtime system everyone was talking about during the 90's? It was supposed to let application developers (like the AVR Studio team) write an app safe in the knowledge that it could then run on any operating system or platform that implemented the run-time engine. Now if I could just remember what it was called....

.... ah yes, that was it, Java. ;-)

Cliff
(who always thought Java was a bit of a joke that was just designed to sap the ever increasing computing power of our computers - until he started to use ProjectX for video processing which proves how good it can actually be)

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

Atmel is currently developing an IDE in java for the AVR32 micros, as can be seen on various press releases.
Now, we all might ask ourselves why Atmel didn't go for AVRStudio4 support on these babes... ;)

-Ole

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

Just to add here... the Wine-Avrstudio "compatibility" is broken after the 4.13 release :( . Now we have several new native DLLs requested (MFC80 related).
Too bad...
Daniel

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

While I agree about having an ideal of cross-platform tools, unfortunately the reality of economics sets in. The economics say that 95+% of all AVR users use the Windows platform. Even if one is generous about the number of users on other platforms, it would still something like 85+% users are on Windows.

Now, I prefer to find a win-win situation. There is a solution that fits the ideal of cross-platform support, while simultaneously solving other current problems with the tool, *and* has a certain amount of economic incentive.

Like all engineering though, there are tradeoffs. The major one is *time*. It will take some time to put together a new solution and have it work reliably. The other is that it may introduce regressions, but I would hope that that would not be the case, at least for major regressions. It may be larger to download. And it may have more dependencies.

But I strongly believe that there is a way to achieve all of this. Everyone just has to be patient. :)

Eric

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

clawson wrote:

Now if I could just remember what it was called....

.... ah yes, that was it, Java. ;-)

And I dare say that Java has become a VERY viable platform to build cross platform applications that run reliably across multiple OS's with literally no change required. Where I work, we have built an entire architecture for global network managment on the Java platform. All of the Tier1 GUIs, Tier2 Servers and DB servers, and Tier3 NMS systems are written in Java and are performing incredibly well. The same classes that we compile for Sparc platforms work equally well on a XP Workstation or an HPUX server. In fact, we have completely dumped legacy C++ applications in favor of Java, due mostly to these same portability and maintainability issues.

It really is too bad that AVR Studio is not written in Java- that would make all the difference in the world. It would be easier to maintain (IMHO), easier to adopt as a development platform by a larger potential audience, and would certainly break the current shackles with MS.

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

dl8dtl wrote:
That's a wrong conclusion -- unless you are Microsoft, ....
Actually it was an attempt at humor and intended to be a funny conclusion :lol:.

Your point about Microsoft didn't take my friends experience into account. He was up there on a contract project in the 90s and he found complete computer science ignorance about any technology/technique that Microsoft had not already implemented prevailed. The attitude was like they didn't even need to know about it unless it was already included in that MS bottle they were weaned on. They appear to enjoy their self imposed ignorance, although it does help explain some of their limitations that even rewriting projects will not cure.

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

> The economics say that 95+% of all AVR users use the Windows platform.

OTOH, there have already been a number of people who said one of the
few remaining reasons for still using Windows is the existance of AVR
Studio. So I guess, this 95+ is simply a slowly decreasing number,
and it would probably be more rapidly decreasing with a cross-platform
GUI. (You know me, Eric, I wouldn't use it anyway but rather improve
GDB, but I know there are many people outside who will use it then
[and please don't exclude the MacOS X users]). I guess that trend
would become even stronger now with Windows Vista... Why should you
waste computing power in looking at your graphics output 30 times a
second when you don't ever play a movie on that computer anyway?

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Future buyers of Vista could maybe benefit from information given in the link below, if money, reliability and computing resources are of interest:

http://www.cs.auckland.ac.nz/~pg...

Erik

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

dl8dtl wrote:
> The economics say that 95+% of all AVR users use the Windows platform.

OTOH, there have already been a number of people who said one of the
few remaining reasons for still using Windows is the existance of AVR
Studio. So I guess, this 95+ is simply a slowly decreasing number,
and it would probably be more rapidly decreasing with a cross-platform
GUI. (You know me, Eric, I wouldn't use it anyway but rather improve
GDB, but I know there are many people outside who will use it then
[and please don't exclude the MacOS X users]). I guess that trend
would become even stronger now with Windows Vista... Why should you
waste computing power in looking at your graphics output 30 times a
second when you don't ever play a movie on that computer anyway?

Really I do agree with you. I always prefer to try and find a win-win situation.

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

Just wondering: If the chinese (just one of the users of AVRs)are supposed to get their own avrfreaks forum, shouldn't by that logic linux users get their own AVRStudio?

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

daqq wrote:
Just wondering: If the chinese (just one of the users of AVRs)are supposed to get their own avrfreaks forum, shouldn't by that logic linux users get their own AVRStudio?

When Linux users start buying AVRs in the same quantities as the Chinese then I'd guess that will happen!