WinAVR....

Last post
99 posts / 0 new

Pages

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

... 20100110 is now uploaded to SourceForge.

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

This is the final release of WinAVR :?: :shock:

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

..I'm sure not..there will be many more. :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

That's what the WinAVR user manual say's. :(

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

Quote:

That's what the WinAVR user manual say's. Sad

That's probably a typo, and was supposed to read "a final release" (as opposed to a Release Candidate build or Beta Release). Eric is being bankrolled by Atmel to keep producing WinAVR, and I doubt they'd kill off the project.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Not being ready to install right now, I'm being stumped trying to find the release notes without installing. I'm pretty sure I've done this before but can't recal now how. Anyone in the know?

"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]

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

Quote:
10.3 Future
For all intents and purposes, this is the last release of WinAVR. The underlying tools contained in the WinAVR distribution will, of course, continue to be developed. For future toolchain distributions for Windows and other other operating systems please refer to Atmel Corporation.

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

Aha! So it'll be incorporated into an official Atmel sanctioned package, rather than Atmel supporting Eric unofficially. Just so long as they don't include Eclipse, I'll be happy :).

Oooh, this release includes Splint!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

JohanEkdahl wrote:
Not being ready to install right now, I'm being stumped trying to find the release notes without installing. I'm pretty sure I've done this before but can't recal now how. Anyone in the know?

The download page normally has it. I see the release notes for previous versions but not this one.
I'am actually talking about the WinAVR manual though.

http://sourceforge.net/projects/winavr/files/

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

Quote:

Aha! So it'll be incorporated into an official Atmel sanctioned package

Signs of the next major release of AVR Studio, perhaps. :)

Quote:

Just so long as they don't include Eclipse, I'll be happy

I'm willing to concur, as long as they base the next AVR Studio on some other cross-platform IDE (with an open plugin interface/framework, and a similar number of plugins already available). :wink:

"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]

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

While I can see Atmel's argument that it confuses beginners who want to use (free) C that they have to go to two places to get the necessary bits I can't help wondering how happy Asm programmers or those that don't want to use GCC are going to be when the Studio download bloats from the already ridiculous 130MB to 160MB ! (DiBosco is going to be SO happy). Hopefully they'll offer two downloads - with and without C (it'd be good if we could ditch battery and radio studio too!)

 

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

If the new Studio is an entirely different architecture (that is, a customized version of Eclipse or something) I'd imagine that it would consist of a base install, plus a bunch of downloadable modules. That way Atmel could have seperate plugin downloads for Battery Studio, etc. and avoid the bloat.

Granted Atmel could do that NOW with AVRStudio 4, but not to worry.

Personally I like the "built specifically for AVRs" aspect of the current AVRStudio version, even if the editor sucks. I'd MUCH prefer they integrated a better editor module (such as SCITE, used in Programmer's Notepad) into a dedicated product, than made something like AVR32 Studio - which no mortal could possibly understand.

Eclipse in my opinion is a great example of jack of all trades (and then some), yet master of none. Too damn confusing and SLOW for my tastes.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:
Not being ready to install right now, I'm being stumped trying to find the release notes without installing. I'm pretty sure I've done this before but can't recal now how. Anyone in the know?
Open/extract the exe with 7Zip.

(avr32 stuff inside- intentional or unintentional?)

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

OK, I read that statement a little more carefully. Notice my emphasis

Quote:

For future toolchain distributions for Windows and other other operating systems

If the avr-gcc toolchain will be supplied directly from Atmel, and will be supplied for several different OS'es then this to me increases the probability that Atmel is indeed planning for a cross platform AVR Studio. If so IMO good news indeed!

"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]

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

Quote:

So it'll be incorporated into an official Atmel sanctioned package, rather than Atmel supporting Eric unofficially. Just so long as they don't include Eclipse, I'll be happy

But--but--but--I have been told several times here, including by the horse himself, that Atmel has NO compiler brand preferences. This was in discussions about certain "free" libraries only being provided for a couple of compiler brands. And early model samples (e.g., Xmega) seeming to be available only to a couple of compiler brands.

So, going forward if you want to use cool AVR stuff--touch, integrated RF, network RF, USB, motor control--you had better be prepared to start building your drivers totally from scratch, or to get into line and don't waver from the sanctioned compiler brands. Gee, at that point (if compiler brand needs to be changed) why keep the focus on the Atmel/AVR model selection? Let's look at the other brands...

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

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

Sorry about not having any release notes for this version yet. SourceForge changed their system yet again, and how they do their uploads. At the moment I can't seem to figure out how to upload notes without it being some separate file.

The Release Notes for the WinAVR releases are really just the beginning section of the WinAVR User Manual. For 20100110 the release notes are:

Here's a sample of what's new:
==============================

- AVR32 GNU toolchain

- Splint 3.1.2
Splint is a tool for statically checking C programs for security
vulnerabilities and programming mistakes. Splint does many of the
traditional lint checks. More powerful checks are made possible by
additional information given in source code annotations.

- New Device Support

- Component Version Upgrades

============================================================

Points go to atomicdog who spotted that bit of news in the WinAVR User Manual. I'm surprised that someone actually reads it.

I cannot, of course, corroborate any other rumours or speculation as to what this all means.

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

EW wrote:
I cannot, of course, corroborate any other rumours or speculation as to what this all means.
However, if you could, perhaps via private means, you might just get some really good beta testers for free.

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:
EW wrote:
I cannot, of course, corroborate any other rumours or speculation as to what this all means.
However, if you could, perhaps via private means, you might just get some really good beta testers for free.

Unfortunately, I couldn't, even in private.

I can neither confirm, nor deny,.....

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

Since this contains the AVR32 toolchain, can I go ahead and uninstall my separately installed Atmel AVR32 toolchain package? Which one is more up to date?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

So far, I was under the impression that the WinAVR project is open source...

JW

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

Quote:

So far, I was under the impression that the WinAVR project is open source...

Interesting point, sort of. All parts that go into WinAVR is OS AFAIK. But who has control of the name "WinAVR"?

Quote:

I can neither confirm, nor deny,.....

Ooooooooohhh! The tension, the tension...

"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]

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

abcminiuser wrote:
Since this contains the AVR32 toolchain, can I go ahead and uninstall my separately installed Atmel AVR32 toolchain package? Which one is more up to date?

- Dean :twisted:

Um, I wouldn't do that quite yet. The one in WinAVR probably won't work very well with AVR32 Studio. I'm not sure if AVR32 Studio would recognize WinAVR-based toolchains or not, but I seriously doubt it. The latest AVR32 GNU Toolchain release (from Atmel) and the one in WinAVR are very probably the same versions IIRC. I've worked on both.

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

JohanEkdahl wrote:
Quote:

So far, I was under the impression that the WinAVR project is open source...

Interesting point, sort of. All parts that go into WinAVR is OS AFAIK.

That is absolutely 100% correct. All of the underlying components within WinAVR are open source, and come from other projects that are hosted in other locations. And as I mentioned, those projects will continued to be developed.

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

JohanEkdahl wrote:
Quote:

So far, I was under the impression that the WinAVR project is open source...

Interesting point, sort of. All parts that go into WinAVR is OS AFAIK.

No, I am talking about WinAVR as such. The winavr.sf.net project page says, "Licence: OSI approved Open Source". I never investigated further i.e. whether the actual build can be indeed reconstructed from the sf hosted cvs/svn tree: a project hosted on sf sounded to me always as an assurance of this fact.

Is this not the case? Am I too naive?

JW

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

> No, I am talking about WinAVR as such.

There's not much of it about it. Just have a look at what lives there.
Usually, Eric uploads the patches into the CVS there (but only after a release
has been done, i.e. they weren't really continually maintained within that
CVS). As most of the tools being patched are under GPL, these patches will
have to be provided in source code form anyway even in future, one way or
the other (e.g., they could also be provided on some atmel.com website).

Then, there's a version of my Mfile in CVS, but I failed to maintain it really
that much.

However, most of what's "inside WinAVR" is the answer to the question: "How to
build all this under a Win32 environment?", and that's basically been Eric's
job for years, where he's been paid by Atmel in recent years to do that job
(so him doing so wasn't any kind of "unofficial Atmel support" anymore then).
*This* answer, however, has never been "open source".

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

dl8dtl wrote:
However, most of what's "inside WinAVR" is the answer to the question: "How to
build all this under a Win32 environment?", [...]
*This* answer, however, has never been "open source".

Well, then that should maybe have been made clear on the SourceForge page.

I am no OS purist, just like to have things labeled clearly as they are.

JW

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

But well, this is very frequently not part of a project. For example, I tried
building the gpib-tcl project under Unix a couple of days ago, and had a hard
time figuring out how the heck the authors did build their (binary) Linux version.
There's a Makefile in the tree, but it didn't really work, and the source code in SVN
used things like "DllExport"... Apparently, the main developer mostly develops under Win32
(various Win32 project files are around in SVN), yet somehow, he must have managed to get a
Linux build.

The "opensource" label is no real guarantee that you'll get detailed build
instructions for everything. Depending on how the person developing the software
organized his job, he might simply have the instructions to build it just in his
head, no script, no Makefile, nothing else. However, the *source code* itself
is available, and that's basically all what "opensource" is promising you.

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

dl8dtl wrote:

However, most of what's "inside WinAVR" is the answer to the question: "How to
build all this under a Win32 environment?", and that's basically been Eric's
job for years, where he's been paid by Atmel in recent years to do that job
(so him doing so wasn't any kind of "unofficial Atmel support" anymore then).
*This* answer, however, has never been "open source".

This also shows that not everyone is observant. I provided these instructions quite awhile ago, to very little fanfare.

Look in the avr-libc user manual. There is a section called "Building and Installing the GNU Tool Chain":
http://www.nongnu.org/avr-libc/user-manual/install_tools.html

I guess people just don't bother scrolling down far enough. :wink:

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

If one looks closely at the WinAVR project, there are only 2 minor things that have never been "open sourced" in its existence:
- Build scripts
- The installer

The "core contents" of the build scripts were documented in the AVR-LibC User Manual; in other words the configuration switches and make targets used to build the projects. Admittedly the documentation might be a bit stale at the moment, but it will essentially allow a person to build the various projects. Certainly the information is easy enough to figure out for those 'skilled in the art'.

The script to build the installer was never open sourced. However, the WinAVR User Manual always documented the layout of the installation directory structure, and it described the registry keys that were used. So technically one could recreate an installer, using any installer system (designed for Windows, because of the registry).

One should not go off and try to continue the WinAVR project. It still exists under SourceForge. I did say that for future toolchain distributions for Windows, please refer to Atmel. I very seriously doubt that anyone is going to be left "high and dry".

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

Though others have survived it,
typing make as root makes me nervous.
To avoid it, I:

$ su
# mkdir /usr/local/avr
# chown myself:humans /usr/local/avr
# exit
$ ...
$ make install
$ su
# chown --recursive root:root /usr/local/avr
# exit

Is it racist to discriminate against someone who changes species?

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

Well, at least the GPL 2 and 3 both require to provide all the source necessary to build the software, including build scripts.

From GPL v3:

Quote:
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

A good bunch of GPL violations in the embedded work are indeed done by not providing the necessary tools/scripts to get some software build, and even worse, not providing tools to install the software.

Stealing Proteus doesn't make you an engineer.

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

The one "danger" I see with WinAVR dying, and Atmel instead taking the development and building of the tool chain indoors is that this will be anti-productive re the community contributing stuff. I'm not ssufficiently versed in the licenece-lingo to understand what has to be revealed, but Atmel might develop stuff that is not revealed. Assuming that someone "in the community" contributes something and Atmel does not incorporate it in it's build, then the simple, deadly users are forced to choose between a build from Atmel lacking the cumminity-contributed stufff, or the community build lacking the Atmel stuff.

Totally made up scenario, but to try to illustrate what I am thinking: The Atmel-built avr-gcc package comes for several platforms. Atmel has also managed to develop a cross-platform AVR Studio 5. Studio5 has certain demandws on the avr-gcc toolchain however. In paarticular this holds for debugging capabilities, where Atmel wants to keep secret how eg debugWire works. In orderr to keep this secret the avr-gcc tool chain from Atmel is at least partly closed even though many of the components are open.

Out there in the community the AVRfreaks user "geckosenator" add a few bells and whitstles to his fixed point patches. They are now very much desired by a substantial part of the user community. Atmel, decides they will not incorporate this (eg there is a catch with the license, or they just feel they can not "vouch for the quality", or...).

An ordinary user now seems to have three or more alternatives:
- Use the Atmel tool chain as is, so that he can use his AVR Dragon to debug with debugWire.
- Use the community built tool chain so that he can prosper form the fixed point work of geckosenator.
- Use the Atmel tool chain but try to patch it with the fixed point stuff. Makes demands on abilities and knowledge that far from all users posess. Is required for each new release from Atmel.

Am I just seeing ghosts here? Is this scenario possible at all?

"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]

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

Atmel can keep extensions inhouse as long as they don't distribute them, but the moment they distribute GPL software (and GCC, the core of WinAvr is GPL software) they better have a good look at all the terms of the GPL.

Stealing Proteus doesn't make you an engineer.

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

Why does everyone see this as a threat? The sources of all the main toolchain elements are in the public domain. All Eric's sterling work has done is made it easier for Windows users by building a set of binaries for them. Before he went to work for Atmel he was just "one of us" and any one of us could have (eventually!) done the same thing. A bit like the way Bingo600 is helping to put together a composite package for Linux. If people don't like the fact that Eric is now doing the work targetted for Atmel (they do now pay his mortgage after all!) then why not just do the same yourself? He's even documented the basis of the process for you - what more do you want? Jam on it? Perhaps it's just easier to beat on about the erosion of civil liberties and how corporate America is taking over the world?

For me, assuming Atmel don't hit real financial problems, the occicialisation/legitimalisation of GCC (perhaps even over above their previous IAR focus) is a positive thing, not a negative.

Are folks worried that in a years time Atmel are going to start charging a hundred bucks for Studio+GCC or something?

 

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

Quote:

Are folks worried that in a years time Atmel are going to start charging a hundred bucks for Studio+GCC or something?

Nope; I'm worried that more and more of the "good stuff" from Atmel will now be only available with carefully-selected toolchains, as I mentioned above. All the new "good stuff" is that way.

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

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

Quote:

Nope; I'm worried that more and more of the "good stuff" from Atmel will now be only available with carefully-selected toolchains, as I mentioned above. All the new "good stuff" is that way.

Lee,

Up to this point exactly how much "good stuff" that Atmel made available was directed towards CodeVision (for example)?

So what's changed? (possibly less focus on the IAR that virtually no one can afford to use?)

Cliff

 

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

None. The "good stuff" was released as libraries-only for a narrow subset of compiler brands. It must be my imagination, though, as I have been told in no uncertain terms that Atmel has no compiler-brand preferential treatment.

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

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

I'm not sure I see what the fuss is about. What is wrong with deciding that a tool is mature and locking it down as a final version? It seems to me that WinAVR has admirably done what it set out to do so why not lock it down and move on? Does WinAVR really need anything more than it already has? Eric stated that they'd still fix bugs.

Just as a related aside, the Arduino folks are locking Arduino down with version Uno Punto Zero (1.0) and plan on doing new stuff. I see no problem with that either since it is a mature tool and has filled it's intended purpose.

However, on the Internet no good deed goes unpunished so I'm sure Eric will catch Hell for all the great things he's done for the community. And as WinAVR is released as a final mature tool, we'll see many bizarre conspiracy theories.

Eric's work is the single most significant reason that I moved to the AVR in the first place and I can't possibly thank him enough.

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

The fuss is that you play drama queen about a harmless exchange of opinions and speculations.

Stealing Proteus doesn't make you an engineer.

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

smileymicros wrote:
Eric's work is the single most significant reason that I moved to the AVR in the first place and I can't possibly thank him enough.

Smiley


I second that !

Now, as I understand Atmel will no longer fund Eric to update WINAVR with newer devices, newer gcc versions etc. Atmel will come out with a gcc based plugin for the new generation of AVR studio (Studio 5). So for now I'll just wait an see what shape the new beast takes on.

Markus

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

sadly to say that 20100110 final build took away USB support.

C:\Documents and Settings\supercoolman>avrdude -c usbasp -p m88
avrdude: error: no usb support. please compile again with libusb installed.

C:\Documents and Settings\supercoolman>avrdude -?
Usage: avrdude [options]
Options:
  -p                 Required. Specify AVR device.
  -b               Override RS-232 baud rate.
  -B               Specify JTAG/STK500v2 bit clock period (us).
  -C            Specify location of configuration file.
  -c             Specify programmer type.
  -D                         Disable auto erase for flash memory
  -i                  ISP Clock Delay [in microseconds]
  -P                   Specify connection port.
  -F                         Override invalid signature check.
  -e                         Perform a chip erase.
  -O                         Perform RC oscillator calibration (see AVR053).
  -U :r|w|v:[:format]
                             Memory operation specification.
                             Multiple -U options are allowed, each request
                             is performed in the order specified.
  -n                         Do not write anything to the device.
  -V                         Do not verify.
  -u                         Disable safemode, default when running from a script.
  -s                         Silent safemode operation, will not ask you if
                             fuses should be changed back.
  -t                         Enter terminal mode.
  -E [,] List programmer exit specifications.
  -x         Pass  to programmer.
  -y                         Count # erase cycles in EEPROM.
  -Y                 Initialize erase cycle # in EEPROM.
  -v                         Verbose output. -v -v for more.
  -q                         Quell progress output. -q -q for less.
  -?                         Display this usage.

avrdude version 5.8cvs, URL: 

C:\Documents and Settings\supercoolman>

[/code]

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

clawson wrote:
All Eric's sterling work has done is made it easier for Windows users by building a set of binaries for them.

And, based on that this collection has been located on SF, known for support of OS, and from the licence stated on the WinAVR SF page, I (falsely) inferred that THIS work is OS-ed, too. I have seen no indication ever to assume otherwise. I must have looked at the wrong places.

Now, things have been made as clear as I like it: "WinAVR is a collection of OS tools, built in a non-open way".

Whatever the ramifications are - I didn't want to discuss that.

Cliff wrote:
For me, assuming Atmel don't hit real financial problems[...]
And if they do, it then won't matter anymore whether there is an opensource tool for nonexistent AVRs, would it? ;-)

JW

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

wek wrote:

> "WinAVR is a collection of OS tools, built in a non-open way".

Not even that, as Eric demonstrated. It's just "a collection of tools, *installed*
in a non-open way".

supercoolman wrote:

> sadly to say that 20100110 final build took away USB support.

That looks like a serious bug to me. So, maybe 20100110 probably isn't going
to be all that "final"? ;-)

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

dl8dtl wrote:
wek wrote:

> "WinAVR is a collection of OS tools, built in a non-open way".

Not even that, as Eric demonstrated. It's just "a collection of tools, *installed*
in a non-open way".


I meant, the collection is built non-OS way, not the individual tools.

Maybe, better, "A non-OS collection of pre-built OS-tools, in the form of a Win installer"?

JW

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

I guess it doesn't matter so much bit I just installed this last WinAVR on Vista and the install program stalls part way through with "Could not find symbol: DllRegisterServer". After a long pause it moved on anyway but I'm guessing that a DLL that was supposed to be registered hasn't been.

BTW the addition of Splint is a nice touch - does this mean the AVR-LibC headers have been made (sp)lintable?

 

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

ArnoldB wrote:

A good bunch of GPL violations in the embedded work are indeed done by not providing the necessary tools/scripts to get some software build, and even worse, not providing tools to install the software.

GPL violations of what? Binutils and GCC are GPL. All patches that I use in building those tools are included in the download. The main source is also available at those project's web sites. I can also provided them to you if you so desire. The instructions to build these tools are also available to you. You have everything you need to build them yourself. The GPL does not mean that you get binaries handed to you on a silver platter.

The WinAVR package itself is a suite of other tools. Nowhere in the license does it say that the installer is licensed to you. And the build scripts to build all the other packages contain nothing that cannot already be found elsewhere on the internet.

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

JohanEkdahl wrote:
The one "danger" I see with WinAVR dying, and Atmel instead taking the development and building of the tool chain indoors is that this will be anti-productive re the community contributing stuff. I'm not ssufficiently versed in the licenece-lingo to understand what has to be revealed, but Atmel might develop stuff that is not revealed. Assuming that someone "in the community" contributes something and Atmel does not incorporate it in it's build, then the simple, deadly users are forced to choose between a build from Atmel lacking the cumminity-contributed stufff, or the community build lacking the Atmel stuff.

Totally made up scenario, but to try to illustrate what I am thinking: The Atmel-built avr-gcc package comes for several platforms. Atmel has also managed to develop a cross-platform AVR Studio 5. Studio5 has certain demandws on the avr-gcc toolchain however. In paarticular this holds for debugging capabilities, where Atmel wants to keep secret how eg debugWire works. In orderr to keep this secret the avr-gcc tool chain from Atmel is at least partly closed even though many of the components are open.

Out there in the community the AVRfreaks user "geckosenator" add a few bells and whitstles to his fixed point patches. They are now very much desired by a substantial part of the user community. Atmel, decides they will not incorporate this (eg there is a catch with the license, or they just feel they can not "vouch for the quality", or...).

An ordinary user now seems to have three or more alternatives:
- Use the Atmel tool chain as is, so that he can use his AVR Dragon to debug with debugWire.
- Use the community built tool chain so that he can prosper form the fixed point work of geckosenator.
- Use the Atmel tool chain but try to patch it with the fixed point stuff. Makes demands on abilities and knowledge that far from all users posess. Is required for each new release from Atmel.

Am I just seeing ghosts here? Is this scenario possible at all?

My honest opinion is that you're seeing ghosts. Regarding the patches from 'geckosenator' (which are the fixed point patches): IIRC (and please correct me if I'm wrong), they are for 4.4.x which I haven't released yet in WinAVR. I'm sure that Atmel finds them desirable too and would include them in some toolchain distribution that includes AVR GCC 4.4.x. The other issue is that 'geckosenator' needs to make sure that he has an FSF copyright assignment in place, because these patches eventually needs to get upstream. AFAIK, he has not pursued this as diligently as needed. Because no one, including Atmel, wants to keep patching versions ad infinitum. All patches eventually needs to move upstream for better maintenance.

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

ArnoldB wrote:
Atmel can keep extensions inhouse as long as they don't distribute them, but the moment they distribute GPL software (and GCC, the core of WinAvr is GPL software) they better have a good look at all the terms of the GPL.

Atmel is very well aware of all legal implications. And probably a lot more aware of more subtleties than you have mentioned.

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

ArnoldB wrote:
The fuss is that you play drama queen about a harmless exchange of opinions and speculations.

[MODERATOR]
Please refrain from ad hominem attacks. They will not be tolerated on this Forum.
[/MODERATOR]

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

clawson wrote:

BTW the addition of Splint is a nice touch - does this mean the AVR-LibC headers have been made (sp)lintable?

No.

An open source lint has been on my "want" list for a while. I just added the tool, without doing anything else. Honestly I'm not sure how well it will work.

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

Quote:

Honestly I'm not sure how well it will work.

Better discussed in the other thread I started specifically about Splint but the AVR-LibC headers don't do too bad so far. Other places I've tried to use (sp)lint with existing headers it's generally been a case of being impossible to make them lintable (too much work if nothing else) and directives are added to simply say "don't lint these #includes". In the headers so far it's just "/*@" (used by Doxygen) that causes problems as this is the same "escape sequence" that splint uses to introduce its own directives.

Cliff

 

Pages