WinAVR poll and feedback requested

Last post
74 posts / 0 new

Pages

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

Hi Again,

So...

Do you remember the post I did a while back that people thought was a bit odd? It had a poll in it that asked if I should do another release of WinAVR.

Well, here it is again. Should I do another release of WinAVR?

Also, I would like some feedback on the feasibility of continuing an all open-source, community directed and made toolchain for the AVR (and, sure let's throw in for the AVR32 too).

The problem is this: WinAVR is a lot to do. A lot of people make requests, but it takes time and effort to implement new features and fix bugs. And it seems that we're always short of volunteers to help.

Luckily, the toolchain is broken down into multiple self-contained projects, and one does not have to be an expert to help out. You could also learn some good skills along the way, and I'm willing to provide help for the skills needed.

Ideally, I would like to see WinAVR contain:

- A fully functioning, cross platform IDE. Programmers Notepad has been nice, but it didn't progress like I thought it would. There's an AVR Eclipse plug-in open source project on SourceForge. I would like to include that in WinAVR, and also see it continue to advance.

- We have talked about adding a "core library" (corelib) to avr-libc for a while. We started a mailing list for it a while back, but it hasn't gone far. This library would provide functionality for on-board peripherals across the whole AVR family. I would really like to see this progress, and I have code to contribute to this.

Maybe you have some other ideas?

Let me know.

Eric

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

When I work with Windows XP on a netbook, WinAVR is the ultimate choice. WinAVR is also good to upgrade the Arduino tool chain, since the original tool chain does not support modern AVRs.

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

uracolix wrote:
When I work with Windows XP on a netbook, WinAVR is the ultimate choice. WinAVR is also good to upgrade the Arduino tool chain, since the original tool chain does not support modern AVRs.

Would you be willing to help out when you can, Axel? Would you be willing to have me include your uracolix project in WinAVR?

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

> Would you be willing to have me include your uracolix project in WinAVR?

Do you think that makes sense? I.e., is there enough audience for it
shared with the (potential) WinAVR users?

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.

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

I voted yes but please don't go filling it with bloat as that's the fault of the "official" offering. In fact I'd vote STRONGLY for an AVR8 only one (like it used to be).

(I've lost count of the number of avr-gcc toolchains I now have on various disks - this morning I just deleted an old Arduino-nnnn and recovered another 160MB - it would benefit from being kept fairly small).

Actually, talking of Arduino, I'll bet they'd vote a HUGE "yes" as I'm pretty sure they just lift their toolchain from WinAVR and don't build it from scratch in a Win32 environment.

 

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

I have not voted yet.

I do not care about an IDE. The way I use WinAVR is that I install it, then zip the resulting directory, and then use that zip file to reinstall or install on other machines. I have seen a link to a portable WinAVR, but never cared to try it. If WinAVR lives, I would like to have an option to have a zip distribution in addition to the installer.

Do I want WinAVR to be continued? That depends on what will come with the official Atmel distribution. I definitely not going to be using the official IDE. But if I can install it once, then zip just the avr-gcc part (i.e., make my own portable avr-gcc zip distribution), then, I guess, I can live without WinAVR.

Eugene

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

Ok, to address the above issues, then how about this?:

Would you be ok with WinAVR and it contained some new libraries, the Eclipse plug-in, and both AVR and AVR32 toolchains, IF the installer allows you optional installation for these various components, and the installer is not overly big?

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

To date: 146 views, but only 8 votes! C'mon people! Vote!

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

I voted yes.

Frankly WinAVR is the single greatest contributing factor to my moving to AVRs.

Arduino certainly never would have happened without it and we have no way of knowing what new great things might be build on WinAVR based on the lessons learned with the Arduino.

Over the years I've tried to find time to participate but never felt competent enough. To help me learn the processes involved, I started a project: avrtoolbox that I intended to be an intermediate step to the corelib. I’ve written several Nuts&Volts articles on it and will be writing more over the next year. My plan is to generate a C library of Arduino-like functions and once they get wrung-out seeing if they would be appropriate to the corelib project. You can see what I'm organizing at: http://code.google.com/p/avrtoolbox/ .

I chose to do this outside corelib because I needed to learn some more recent project management tools like SVN and I didn't want to burden you guys with my ignorance.

I think the killer problem with getting corelib moving was that there seemed to be a desire to make libraries that could be run on any AVR by changing a #define and I don't see that as being possible, without a mind-numbing set of #ifdefs and a huge effort not only at writing the libraries but quality testing.

IIRC the corelib was going to start with an SPI library. To avoid the #ifdef clutter I wrote an SPI library for three specific AVRs ATmega169, 328 and 644 - then I assume that with those as an example anyone needing the library for another device could learn by example and modify the library as needed.

I have this library, demonstration hardware projects, and a couple of Nuts&Volts articles that I'd be happy to put up and let folks critique to see if this is a direction we want to take with corelib.

Smiley

PS may I suggest you add WinAVR to the title?

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

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

I was the first to vote whatever.
I voted whatever because no was not a choice.

Please put all available effort into
avr-gcc avr-libc avrdude and other such
truely open source tools.

Dont really see the point of a lot of very able
people working to make open source run on
commercial operating systems.
I think there are better things they could use
their abilities for.
Maybe someone will explain.

The only explaination I can think of for not
using a totally open source system is that
you work for a company with some kind of rough
tough boss who insists otherwise.

John

If all else fails, read the instructions.

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

Quote:

IF the installer allows you optional installation for these various components

Sounds like a good compromise.

But PLEASE don't let the download grow to 522MB ! ;-)

 

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

clawson wrote:
Quote:

IF the installer allows you optional installation for these various components

Sounds like a good compromise.

But PLEASE don't let the download grow to 522MB ! ;-)

The 20100110 release of WinAVR contained both the AVR and AVR32 toolchains and it was only 28M, and that is using LZMA compression. I don't see it growing even twice that size.

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

JohnWalton wrote:
I was the first to vote whatever.
I voted whatever because no was not a choice.

Please put all available effort into
avr-gcc avr-libc avrdude and other such
truely open source tools.

Dont really see the point of a lot of very able
people working to make open source run on
commercial operating systems.
I think there are better things they could use
their abilities for.

You have really good points, and I can respect your poll choice.

What you bring up is also one of the things that I hope I was referring to: it's a lot of work to make sure the underlying components, such as avr-libc, avrdude, avarice, etc., are keeping up to date. This is where it would be great to get a little more help.

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

smileymicros wrote:

Over the years I've tried to find time to participate but never felt competent enough. To help me learn the processes involved, I started a project: avrtoolbox that I intended to be an intermediate step to the corelib. I’ve written several Nuts&Volts articles on it and will be writing more over the next year. My plan is to generate a C library of Arduino-like functions and once they get wrung-out seeing if they would be appropriate to the corelib project. You can see what I'm organizing at: http://code.google.com/p/avrtoolbox/ .

I chose to do this outside corelib because I needed to learn some more recent project management tools like SVN and I didn't want to burden you guys with my ignorance.

Just my 2 cents, but it is NOT a burden! I would rather that we can join forces and work on projects together, than to have yet another AVR open source project. There is more power in working together than working separately.

If you want help in learning tools, just ask!

smileymicros wrote:

I think the killer problem with getting corelib moving was that there seemed to be a desire to make libraries that could be run on any AVR by changing a #define and I don't see that as being possible, without a mind-numbing set of #ifdefs and a huge effort not only at writing the libraries but quality testing.

I agree with you. I don't want a bunch of #ifdefs everywhere. It's difficult to maintain.

With that, I also don't like having to import source code into an application (like the definition I have seen of a 'software framework').

This is why libraries were invented. I would much rather see something like:
libcore_.a
And that library then contain everything for that particular device. Have all of those libraries in a single directory, where you can point the compiler to link the specified library. And we must have killer documentation to make sure that it is easy to use. Keep all conditional compilation to a bare minimum.

smileymicros wrote:

IIRC the corelib was going to start with an SPI library. To avoid the #ifdef clutter I wrote an SPI library for three specific AVRs ATmega169, 328 and 644 - then I assume that with those as an example anyone needing the library for another device could learn by example and modify the library as needed.

I have this library, demonstration hardware projects, and a couple of Nuts&Volts articles that I'd be happy to put up and let folks critique to see if this is a direction we want to take with corelib.

I have an SPI library for the ATmega640/1280/1281/2560/2561/128. I also have libraries for a SW (bit bang) SPI, ADC, and Ring Buffer (to be used in a future UART library), plus others in the wings.

smileymicros wrote:

PS may I suggest you add WinAVR to the title?

Done.

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

More than happy to help how ever possible.

Be forewarned - I have nearly zero skills with Linux though I can handle modest c tasks. My working platform is MacOS.I am trying to become more familiar with the underlying linux stuff, but it is a painfully slow process for me. I'm not even comfortable with "building" something, yet(!)

Jim Wagner

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

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

ka7ehk wrote:
More than happy to help how ever possible.

Be forewarned - I have nearly zero skills with Linux though I can handle modest c tasks. My working platform is MacOS.I am trying to become more familiar with the underlying linux stuff, but it is a painfully slow process for me. I'm not even comfortable with "building" something, yet(!)

We appreciate any and all help! Would you be willing to help review documentation? Perhaps even write a little of it? avr-libc can always use some help in this area?

Learning to use 'diff' (in order to create a patch) is also not too difficult. If you're willing to learn that, then you can help work on avr-libc on fixing bugs, and immediately adding a feature to help notify the user about deprecated items.

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

Documentation is something I would enjoy working on! Reviewing OR writing.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

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

EW wrote:
Just my 2 cents, but it is NOT a burden! I would rather that we can join forces and work on projects together, than to have yet another AVR open source project. There is more power in working together than working separately.
Just to make sure folks understand, the avrtoolbox project [http://code.google.com/p/avrtoolbox/] is not meant to be an alternative to the corelib, but a way for me to learn what I'm doing before submitting stuff to the corelib. It is also meant to be a repository for my Nuts&Volts stuff which is written for the 'baby talk for pothead' crowd and not the level of professionalism I see in the avrlibc/avrgcc mailing lists.

I have a lot more to say, but it would be a distraction here so I'm going to post to the corelib mailing list. I should have some stuff ready for discussion by Sunday.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

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

I voted yes...don't know why. :) I don't see me using AS5, at least the way it looks like it is going.

Maybe they are just teasing us.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

EW wrote:
This is where it would be great to get a little more help.
I don't understand your posts in the last months, Eric. I thought you were an Atmel employee. Isn't that the very place to ask for a little more help?

In the various AVRStudio related threads, we've seen responding half a dozen or more people who overtly act as Atmel employees supposedly working on various aspects of AS. And that must be only the tip of the iceberg. Yet except you, I've seen only one (1) whom I'd guess is payed by Atmel, to contribute to the stuff which really counts.

Does this relate somehow with the percentage of Atmel's developers who are proud to avoid the stuff with serial ports?

---

I voted Yes even if I agree with John and Cliff, because I believe that *some*thing is better than *no*thing.

Jan Waclawek

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

I voted yes because I now use it almost exclusively through the Arduino IDE/Environment.

Cheers

Alex Shepherd

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

EW wrote:
Hi Again,

Ideally, I would like to see WinAVR contain:

- A fully functioning, cross platform IDE. Programmers Notepad has been nice, but it didn't progress like I thought it would. There's an AVR Eclipse plug-in open source project on SourceForge. I would like to include that in WinAVR, and also see it continue to advance.

Eric

Eric, I voted yes (even though I've left windows behind for linux).
But you have lost/confused me with the statement above.

To date, I believe that "WinAVR" is a set of command line tools.
It has no GUI components. That part was done by studio.

So in my mind WinAVR is the portable component that should remain portable and non GUI and not provide anything but
a set of core functions/applications for building things like IDEs and GUIs on top of.

If properly maintained, it could be the same sources (at least for the compiler and binutils) that get built on all the platforms including the linux variants.

This should actually ease the support load as there would
be one set of command line tool sources.

A GUI package, whether it is Studio, or even the Arduino IDE
then picks up the WinAVR package and uses it for its base functionality.

My biggest concern is that if Atmel no longer supports a "WinAVR" type command line only package in preference of their GUI and IDE package, that over time there will slowly be
a drift away from commandline tools.

For example, consider if something like avrdude is abandoned and the functionality is built directly/natively inside a studio type GUI that only works on Windows.
So over time the non-windows operating systems begin to lose out on functionally because there is no longer a commandline equivalent.

=====
Now in terms of packages...
I think it would be nice to keep the separation of GUI
tools and command line tools.
(WinAVR vs Studio)

However, I think it would be useful to include the command line tools with the GUI tools the way the Arduino IDE does.
i.e. the Arduino IDE, essentially includes the full WinAVR
package and does not require the user to install them separately. It also bundles it under its own install
area, which ensures that the GUI and the commandline
tools are bound together and always remain in sync.

This also allows users to install multiple versions
of the tools and not have to worry about them stepping
on each other.

===

My big point is I would be saddened if Atmel decided
to move needed functionality into windows only GUI tools
rather than have Windows GUI tools that called command line tools that could also be portable across other operating systems.

--- bill

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

I would love to see a MAC OSX port of the tool chain.
Eclipse is available on OSX, it just needs AVR tool chain & plugins. :)

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

wek wrote:
I don't understand your posts in the last months, Eric. I thought you were an Atmel employee.

Yes, I am. It's difficult to explain as it's a complicated situation.

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

hnhoan wrote:
I would love to see a MAC OSX port of the tool chain.
Eclipse is available on OSX, it just needs AVR tool chain & plugins. :)

It also needs someone to do it, and maintain it. The history has been very spotty when it comes to people willing to step forward to help build and maintain on Mac OSX.

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

bperrybap wrote:

Eric, I voted yes (even though I've left windows behind for linux).
But you have lost/confused me with the statement above.

To date, I believe that "WinAVR" is a set of command line tools.
It has no GUI components. That part was done by studio.

That's not quite correct. Since the very beginning it has contained Programmers Notepad, which although first and foremost it being an editor, it does have a way to call command line tools. Granted it was never a full-fledged IDE, and debugging was problematic (to say the least). WinAVR also came with Insight, which is GDB with a GUI (via Tcl/Tk). Again, not used very frequently. So, no, WinAVR was never exclusively command line tools.

bperrybap wrote:

So in my mind WinAVR is the portable component that should remain portable and non GUI and not provide anything but
a set of core functions/applications for building things like IDEs and GUIs on top of.

Unfortunately, I would have to say that that is not quite right either. WinAVR has always been the AVR toolchain built for running on Windows. It is not portable in the sense that it can run on other platforms. Other people have always had to build the sources for other platforms, e.g. Joerg has built the AVR toolchain for FreeBSD.

bperrybap wrote:

If properly maintained, it could be the same sources (at least for the compiler and binutils) that get built on all the platforms including the linux variants.

And that is what has been done over the years. Joerg and I have always coordinated on package versions and patches that way the FreeBSD AVR toolchain and WinAVR would be identical as possible. Bingo, here, has tried to do the same in providing build scripts for Linux that would be compatible with FreeBSD and WinAVR.

bperrybap wrote:

This should actually ease the support load as there would
be one set of command line tool sources.

It helps the end-user, but it doesn't necessarily help with maintenance. It's amounts to some extra organization on the developers' part.

bperrybap wrote:

A GUI package, whether it is Studio, or even the Arduino IDE
then picks up the WinAVR package and uses it for its base functionality.

Well, there we're running into a problem. AS5, as you can see, is not using the WinAVR package. It has it's own toolchain package.

bperrybap wrote:

My biggest concern is that if Atmel no longer supports a "WinAVR" type command line only package in preference of their GUI and IDE package, that over time there will slowly be
a drift away from commandline tools.

Others have said that there will be a standalone toolchain installer package (outside of AS5).

bperrybap wrote:

For example, consider if something like avrdude is abandoned and the functionality is built directly/natively inside a studio type GUI that only works on Windows.

Something you have to understand: AVR Studio never abandoned avrdude because they never accepted it to begin with. AS4 has always had their own programming tool, which is proprietary (not open source). They have never used avrdude to begin with.

bperrybap wrote:

So over time the non-windows operating systems begin to lose out on functionally because there is no longer a commandline equivalent.

Yes, that is an issue.

bperrybap wrote:

Now in terms of packages...
I think it would be nice to keep the separation of GUI
tools and command line tools.
(WinAVR vs Studio)

False assumption. AS5 has both, but with their way of doing things. I'm considering that WinAVR should be revived, but stay with fully open source tools. Which means that it should have an IDE too, based on open source, and that is cross-platform, so that way those on Linux and Mac could benefit too.

bperrybap wrote:

However, I think it would be useful to include the command line tools with the GUI tools the way the Arduino IDE does.
i.e. the Arduino IDE, essentially includes the full WinAVR
package and does not require the user to install them separately. It also bundles it under its own install
area, which ensures that the GUI and the commandline
tools are bound together and always remain in sync.

This also allows users to install multiple versions
of the tools and not have to worry about them stepping
on each other.

I think we would agree on this. I'm all for making it easy on the user to install/uninstall, and for giving them choices, because not everyone works with these tools in the same way.

bperrybap wrote:

My big point is I would be saddened if Atmel decided
to move needed functionality into windows only GUI tools
rather than have Windows GUI tools that called command line tools that could also be portable across other operating systems.

Near as I can tell, I don't think that they're doing this with AS5.

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

I began working with AVR's on an early version of Studio 4 in ASM - then transferred to WinAVR and Studio + WinAVR. I have since ( for reasons of functional preference alone ) moved to exclusively Linux on my primary machine. Still, I believe that if WinAVR can continue to develop in a striped down, slim, form to allow for flexibility in IDE, or, indeed, no IDE, that it could continue to be highly beneficial to the AVR community.

What I would hope to see, however, is that development tools remain as unified ( in core functionality and, therefore code base ) as possible. It is a waste to have development efforts directed many different ways. As I see it, WinAVR should continue much as it has been: avr-gcc toolchain and related tools ( i.e. MFile and avrdude ), along with avr-libc and possibly corelibs. If, indeed, the debugging back end is going to be modular and multi-platform ( if not open ), it would make sense to include a GDB interface for that as well. With any luck, a majority of the bug fixes and feature requests will be applicable to other platforms, even if the binaries and packaging are not.

As for avr-libc and corelibs, I am willing ( perhaps even eager ) to help but I neither want to duplicate work when it comes to getting basic functionality running on my own ( different ) platform, nor spend time reinventing components that Atmel is already working on. I think that WinAVR more or less as it was combined with general library projects would meet these requirements; any IDE should, in my opinion, be something separate - there will be the official Studio version available for Windows after all.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

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

I vote a BIG YES,
The problem is that Atmel might put a little time in their toolchain for now. Then after a while that will stop and everybody is forced to commercial compilers. They will be come more expensive as there will be no freeware around as an alternative. For commercial use that probably is not a problem, but for the people that are having fun at home this will be a problem.

about plugins etc.... why are they not made as separate down loadable packages, like for instance firefox does. When you need an additional plug-in just download and install that package and you are ready to go.
Dont know how things are sorted with studio 4 and studio 5 integration though (I just install and run).

regards

1)Datasheet and application notes checked?
2)tutorial forum
3)Newbie start here

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

EW wrote:

Quote:
Would you be willing to help out when you can, Axel? Would you be willing to have me include your uracolix project in WinAVR?

Eric, of course, if I can do something, I will contribute.

The idea of selectable components I would prefer also rather then a single monolithic block that holds all and everything in a archive of size WXYZ MB.

If there is a directory structure where one can put arbitrary AVR libs, docs and tools this would be cool
(like site-packages in python).

Finally I would appreciate, if we could align the efforts with Bingos work, so that a cross plattform core toolchain can come up (same compiler, same avr-libc, same tools).

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

I don't think any particular IDE or editor should be *extensively* supported. There is maybe a dozen of programmer editors of which probably each can run an external batch and then process the result (to highlight errors etc.) And as programmers tend to be opiniated about editors (no wonder as that's arguably their most extensively used tool), chosing/preferring a particular one inevitably pisses off some of the community.

Some editors (I don't like the "IDE" moniker) provide interfaces to plug in debugging "frameworks", but that requires a lot of work to maintain, not to say that Atmel wants to keep these things private.

OTOH I believe that "integration" documentation (HOWTOs) and/or templates wherever available for these editors should be provided.

JW

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

I voted yes ...

But primarily to get Atmel to keep supporting avr-gcc (new patches).

I started out (as a newbie) with WinAVR , and PN was a nice addition. But mostly because the "make magic" was integrated in it.
If PN (the make integration) wasn't included i would have used Multi-Edit , witch i allready knew.
And actually liked better.

I have since then realized that i "only" need the commandline tools. And even now in C::B , i use "external makefile" and no "Clicky..Clicky" configuration.

I really hates it when i get a studio project wo. a makefile.
It should be "illegal" to distribute a project wo. a makefile. :-)

So my wote goes for gcc , libc , srectools , "the dude" & co.

And if people wants an ide let them download Studio or eclipse or C::B or .... whatever they like.

But if the commandline tools is maintained , the prereq. of all the ide's are in place.

Maybe even make Studio a 2 stage thing ...

1: Ide/Debugger/Programmer (with hooks for ...)
2: The AVR-Commandline tools

Then it would be easy to create & maintain "2" , for Win/Lin/OSX

/Bingo

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

EW wrote:
IF the installer allows you optional installation for these various components, and the installer is not overly big?
How about to release (in addition to installer) separate portable zip archive for advanced users with no extras at all? No IDE. No plugins. No msys utilities. No MFile. No avrdude etc. And no installer. Just avr-gcc, avr-binutils and avr-libc. I think it's simple enough to create such archive in build script.

I don't need (and don't want) installer to change my registry or environment variables. I don't need utilities because I have up-to-date mingw/msys. I don't need IDE because I use single Eclipse for AVR/ARM/MSP430/PC. I don't need plugins because I don't need it. I don't need MFile because I have universal makefile for all my projects (just copy to new project and change name of output file). I need just unzip archive into D:/programs/winavr/2011.... and add TOOLCHAIN = ${WINAVR}/2011.... to my makefile.

And as far as I know I'm not the only one who wants the same - no extras.

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

Bingo600 wrote:

Quote:

I really hates it when i get a studio project wo. a makefile.
It should be "illegal" to distribute a project wo. a makefile.

I agree, but the AVRStudio4 GCC Plugin honestly needs the support of command line arguments for the Makefile. Currently for multiconfiguration projects it is a nightmare to maintain one Makefile for each aps file. In the same category is the constraint that name of the target has to be the same as the basename of aps file.

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

EW wrote:

bperrybap wrote:

So over time the non-windows operating systems begin to lose out on functionally because there is no longer a commandline equivalent.

Yes, that is an issue.

bperrybap wrote:

Now in terms of packages...
I think it would be nice to keep the separation of GUI
tools and command line tools.
(WinAVR vs Studio)

False assumption. AS5 has both, but with their way of doing things. I'm considering that WinAVR should be revived, but stay with fully open source tools. Which means that it should have an IDE too, based on open source, and that is cross-platform, so that way those on Linux and Mac could benefit too.

Eric, I don't think this point should be understated.

I'm no doubt in the minority here, but we exclusively use Linux for all of our development simply because we find it to be a much better environment for us than windows.

There's no question that continued support and improvements to an open source WinAVR+tools will necessarily bring those improvements to Linux also.

The 8-bit AVR Linux community is hugely neglected by Atmel and can use all the support it can get, even if the method is by being dragged behind WinAVR. By not providing some common ground for users on different OS's, I think it will only serve to further fragment the developer communities.

So, I voted yes.

-mark

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

mlitwack wrote:
EW wrote:

bperrybap wrote:

So over time the non-windows operating systems begin to lose out on functionally because there is no longer a commandline equivalent.

Yes, that is an issue.

bperrybap wrote:

Now in terms of packages...
I think it would be nice to keep the separation of GUI
tools and command line tools.
(WinAVR vs Studio)

False assumption. AS5 has both, but with their way of doing things. I'm considering that WinAVR should be revived, but stay with fully open source tools. Which means that it should have an IDE too, based on open source, and that is cross-platform, so that way those on Linux and Mac could benefit too.

Eric, I don't think this point should be understated.

I'm no doubt in the minority here, but we exclusively use Linux for all of our development simply because we find it to be a much better environment for us than windows.

There's no question that continued support and improvements to an open source WinAVR+tools will necessarily bring those improvements to Linux also.

The 8-bit AVR Linux community is hugely neglected by Atmel and can use all the support it can get, even if the method is by being dragged behind WinAVR. By not providing some common ground for users on different OS's, I think it will only serve to further fragment the developer communities.

So, I voted yes.

-mark

Thanks, Mark. Ever since the inception of WinAVR, I've always had some core principles that I've stuck by over the years, which I think time has proven out. One of the reasons why I wanted to build WinAVR is to show to users in the Windows world the power of open source software, which I hope would lead them to consider using other open source software, including Linux, FreeBSD, etc.

I've always wanted to enable the user to use the tools however they wanted, whether they are inexperienced new users, or expert users using the tools in strange ways. It is always better to provide options, make it easy to use as possible in whatever way possible, and get out of the way. I'm not into dictating a particular solution to anyone, because I never wanted to be dictated to when I use these tools. Remember, I started off as an embedded software engineer, sitting in the same seat as you, doing the same kinds of things. I've used AVRs (and other microprocessors) and developed firmware for them on real products.

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

EW wrote:

Thanks, Mark. Ever since the inception of WinAVR, I've always had some core principles that I've stuck by over the years, which I think time has proven out. One of the reasons why I wanted to build WinAVR is to show to users in the Windows world the power of open source software, which I hope would lead them to consider using other open source software, including Linux, FreeBSD, etc.

I've always wanted to enable the user to use the tools however they wanted, whether they are inexperienced new users, or expert users using the tools in strange ways. It is always better to provide options, make it easy to use as possible in whatever way possible, and get out of the way. I'm not into dictating a particular solution to anyone, because I never wanted to be dictated to when I use these tools. Remember, I started off as an embedded software engineer, sitting in the same seat as you, doing the same kinds of things. I've used AVRs (and other microprocessors) and developed firmware for them on real products.

Eric,
Based on this and the comments you made to me, perhaps
you could lean on Atmel to abandon the use of any proprietary source code in their core toolset.
That way people that don't necessarily want to use the same
tools in the same way or environment can have the freedom to go in and modify them for their particular environment
or even fix low priority bugs.

I say this because your comments of Atmel never buying into Avrdude and then implementing their own proprietary programming tool inside a windows only GUI scares the crap out of me.

My personal belief is that the success of the AVR is directly related to Atmel using open source tools.
Once you start to venture down a closed path, it becomes a very slippery slope to start expanding its use, even if it is un-intentional.
i.e. at some point it can be difficult to distinguish the
open source from the closed source and so it all starts to become closed source.

The open source nature of the AVR tools including tools like avrdude is what enabled the Arduino project.

So again my biggest concern is that Atmel starts to move
more and more needed functionality into windows only programs and even more scary is that those programs are closed source.

To me a good way to ensure that other environments or projects like Arduino can continue to exist and new ones created, is to maintain a core set of open source commandline tools which includes a tool to update firmware inside the AVR. (whether it is actually avrdude or not does not matter)
That way the core tools are easily ported to alternate environments and those so motivated can produce alternate
user interfaces on top of it just like the Arduino guys
did with their IDE.

The key is carefully/clearly define what the core set of tools is.

--- bill

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

I voted "Yes" to continue WinAVR.

Many or most AVR developers use WinAVR or other leightweight (with respect to AS5) distributions of avr-tools.

I do not see a reason to couple avr-tools and AVR Studio. Independant releases will make it easier to update one or the other. WinAVR could be released in a mor timely manner, i.e. closer to current avr-tools development.

From the avr-gcc perspective, a leighweight distribution of avr-tools will help to make the release/feedback/bugfix cycle narrower because WinAVR will not have to wait for very big things like AS5.

Johann

avrfreaks does not support Opera. Profile inactive.

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

Quote:

because WinAVR will not have to wait for very big things like AS5.

Though in the past I think there was some co-ordination with AS4 wasn't there? So that as the compiler and avr-libc added support for new devices the GCC plugin in Studio was updated to offer them on the menu. (or vice versa)

 

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

Quote:

They will be come more expensive as there will be no freeware around as an alternative.

This isn't the place or platform for Compiler Wars. But please give some basis for that statement.

If you claim that, would the converse be true--that with the introduction of AVR support with gcc, commercial compilers became less expensive? Or is this only a one-way street?

You can put lipstick on a pig, but it is still a pig.

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

Nobody voted "No"? I am a devil's advocate then.
Well, I must admit I am a hobbyst with ancient tools (JTAG Mk1) and for quite a long time I wasn't able to use new devices. I also do not plan to upgrade. AS4+avr-gcc does all the job in my case and the next step is ARM. New WinAVR with IDE ans support of new devices/new libraries would not be very useful in my case (perhaps I should consider "whatever").
You guys did a great job porting WinAVR but I believe the time came when one has to stop and this is a good moment. I think Atmel's release of AS5, proprietary strategy and ubiquitous ARMs make AVRs less and less popular among hobbysts. If I really miss using some modern AVR in the future, then AS8 will do.

No RSTDISBL, no fun!

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

theusch wrote:
Quote:

They will be come more expensive as there will be no freeware around as an alternative.

This isn't the place or platform for Compiler Wars. But please give some basis for that statement.

If you claim that, would the converse be true--that with the introduction of AVR support with gcc, commercial compilers became less expensive? Or is this only a one-way street?

Is there any way to take this tangent to a new thread? Thanks.

[cliff: if anyone's interested I can split this into a new thread - just PM to say "yes" and where you want the new thread and what it should be called]

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

I voted Yes.
I like WinAVR. I'm still using the 20100110 release and AS4. It's simple and straight forward. I could use a different version if I had problems with one. The only time I use the toolchain is with the Tiny10. And that is by way of extracting the right folder to a separate folder and using it like a WinAVR release.
I'm really hesitant to go with Atmel's massive toolchain, forget about AS5 until SP1 or SP2.

Jim M., Rank amateur AVR guy.

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

kiwi64ajs wrote:
I voted yes because I now use it almost exclusively through the Arduino IDE/Environment.

I'm in that line too.

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

I'd be happy for you to include MHVLib, which is essentially a C++ implementation of your proposed corelib.

I'm also happy for your to lift code from it for corelib, as long as attribution is given (as per the BSD license).

http://www.makehackvoid.com/mhvlib

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

Oh yeah, my vote is yes, on the proviso that full build scripts are released.

Ony of the driving factors for me releasing MHV AVR Tools (http://www.makehackvoid.com/group-projects/mhvavrtools) is that the community is highly dependant on you to make a release, and cannot effectivly submit patches back as only a subset of what is required to build WinAVR is provided.

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

evildeece wrote:
Oh yeah, my vote is yes, on the proviso that full build scripts are released.

Ony of the driving factors for me releasing MHV AVR Tools (http://www.makehackvoid.com/group-projects/mhvavrtools) is that the community is highly dependant on you to make a release, and cannot effectivly submit patches back as only a subset of what is required to build WinAVR is provided.

?
Can you elaborate?

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

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

smileymicros wrote:
?
Can you elaborate?

Smiley

Sure: Only the patches use against the component products are released. The build environment, build scripts, installer, etc were never made available, so rebuilding components is difficult.

I ended up addressing this by creating everything (at least, the bits that I considered important), including the development environment, from scratch, and publishing the lot for others to hack on.

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

I've been giving that some thought too, before you brought it up. And I can say that I'm very seriously considering doing just that. And I also appreciate the offer of including your code in the package too. That would certainly give it a jump start. Give me another day or so to cogitate on this..........

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

Ok, let me just express my thought process here, and see what you think. First, I have absolutely no problem with releasing the build scripts, because nothing in there is secret, by any stretch of the imagination. All of the information in the build scripts has been listed in various documentation (mostly avr-libc user manual) for years. Others, such as bingo (Carsten), Omar Choudry, have their own build scripts, which I'm sure are substantially similar.

This just leaves the installer. I have always written in the WinAVR user manual exactly what the installer does, the directory tree, all of the keys that are created in the Windows Registry, and exactly how the PATH is changed. So, technically, anyone could reproduce exactly what the installer does.

My only concern, and perhaps it doesn't need to be a concern anymore, is that if the installer script is public, that someone could go take that, roll a package of their own, and call it "WinAVR", when it is not an official release. I want to make sure that the official package has been vetted, in some ways, before it is released.

Like I said, perhaps I don't really need to be concerned about it, and I'm just being overly paranoid. SourceForge has the listing of all WinAVR packages; if it's not there, it's not official.

So, the more I think about it, the more I think that everything will be open, build scripts and installer. Which, if that's the case, and someone wants to help out on the installer, then start learning NSIS:
http://sourceforge.net/projects/nsis/

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

EW wrote:
My only concern, and perhaps it doesn't need to be a concern anymore, is that if the installer script is public, that someone could go take that, roll a package of their own, and call it "WinAVR", when it is not an official release. I want to make sure that the official package has been vetted, in some ways, before it is released.

Like I said, perhaps I don't really need to be concerned about it, and I'm just being overly paranoid. SourceForge has the listing of all WinAVR packages; if it's not there, it's not official.

I don't think you need to worry about this. I think discussions on AVRFreaks would quickly identify anyone attempting to spoof WinAVR. I think anyone who might use WinAVR is already aware of the kinds of crap that goes on in the Internet and would be cautious.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

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

I'd always be a bit suspicious of something called WinAVR if it wasn't hosted on Sourceforge anyway.

 

Pages