ok to use -mmcu=attiny84 instead of 84a?

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

I'm trying to use fuse.h to define fuse settings in my elf files.
I noticed the fuse definitions for the 84a are not correct (and submitted avr-libc bug #42084).
The signature bytes are the same, and the datasheet doesn't seem to indicate any differences other than power consumption.
Am I missing something? If they are programmatically identical then I don't see the point of having different headers for the 84a.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

If the signature byte is the same, then Atmel is saying that there is no PROGRAMMING difference. There may be electrical differences such as output sink/source current, but not in the register and bit function.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Ralph,

Regarding code generation, GCC should produce the same binary for t84 and t84a

Study the contents of the header files very carefully before you use any .fuse "feature".

Some files have got complete rubbish in their .fuse descriptions. You stand a good risk of killing your AVR.

Even if or when Atmel correct the headers, there will be many punters throughout the world that are using the current distribution. So I would never publish source code with .fuse sections.

Since there are not very many AVR models, it surprises me that any typos get through the Atmel "quality control". Especially since these files are supposed to be machine generated from the master XML description.

The ATtiny84A seems an unusual choice of chip. It is not compatible with the STK500 or any third party dev board.

David.

p.s. I made a bug report about the .fuse section in tiny2313 several months ago. I never used a SED script to identify anomalies in all the other headers. It would help Atmel to rectify the bug(s).

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

david.prentice wrote:
Ralph,

Regarding code generation, GCC should produce the same binary for t84 and t84a


Yet the avr-gcc folks made a separate -mmcu option along with new headers (that are not quite the same as the t84 headers) for the 84a. If I were in control of avr-libc things would be a lot different...

Quote:

Some files have got complete rubbish in their .fuse descriptions.

Yes, I've noticed that now. I think I'll have to take another approach to the problem of managing fuse settings...

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Quote:

If I were in control of avr-libc things would be a lot different...

Which avr-libc - are you talking about the generic one on Savannah or Atmel's private branch of it that they use for the toolchains in AS6 (and the separate Atmel Toolchain for Windows and Atmel Toolchain for Linux)?

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

clawson wrote:
Quote:

If I were in control of avr-libc things would be a lot different...

Which avr-libc - are you talking about the generic one on Savannah or Atmel's private branch of it that they use for the toolchains in AS6 (and the separate Atmel Toolchain for Windows and Atmel Toolchain for Linux)?

I didn't know there was anything other than the gnu libc (hosted on Savannah).

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

david.prentice wrote:
You stand a good risk of killing your AVR.

Is that just a dramatic exaggeration, or is there really a set of fuse settings that can render an AVR unrecoverable, even through HVSP?

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Quote:

is there really a set of fuse settings that can render an AVR unrecoverable, even through HVSP?

1) I recall a discussion about fatal fuse combinations. Perhaps related to the "bad" combinations from Atmel that David mentioned? I don't remember the result--perhaps try to search out the thread?

2) IME/IMO HVxP just isn't worth setting up for. For us, almost all "real" work is surface-mount anyway. None of our AVR DIP apps are socketed.

2a) We've never killed an AVR with fuses. We've sent one to the hospital every few years with improper clock selection, but paramedic treatment with the paddles revived it. (In other words, clock injection into XTAL1)

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

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

ralphd wrote:
david.prentice wrote:
You stand a good risk of killing your AVR.

Is that just a dramatic exaggeration, or is there really a set of fuse settings that can render an AVR unrecoverable, even through HVSP?

Yes. Of course it is a dramatic exaggeration.
Mind you, I suspect that anyone caught by this would be upset.

Only the smaller Tinys use HVSP. The others use HVPP.
It is not too difficult to apply +12V to the reset pin on most circuit boards. You already have access to all the LVSP pins. It is HVPP which would be the serious problem. You need an awful lot of pins. What else is connected to those pins? Can you physically access them?

Regarding FUSE errors in header files.
I reported Bugzilla #3310 in 26 DEC 2013
This was a duplicate of #2396 reported 23 NOV 2012

Morten confirmed it was fixed 31 DEC 2013

And sure enough, my current AS6.2B installation has the correction. In fact my is dated 18 FEB 2014. So I suspect the fix appeared in AS6.1 SP2.

David.

Edit. As usual, I typed my original assertion without checking my facts. i.e. looking up Bugzilla.
I still maintain that it would be unwise to publish code that might be used by punters with the earlier Toolchain.
What is your Bugzilla number for tiny84?

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

david.prentice wrote:

Only the smaller Tinys use HVSP. The others use HVPP.

I agree messing up the fuse bits on an AVR with no HVSP would be a real PITA.
david.prentice wrote:

What is your Bugzilla number for tiny84?

There's two: 42084 and 42085.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Much as we all like to be rude to Atmel, there is no way that they could have a #42084.

I can't find anything on the Atmel Bugzilla.
Perhaps you could just post both Bugzilla reports here.

David.

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

Quote:

Much as we all like to be rude to Atmel, there is no way that they could have a #42084.

Those are avrlibc bug numbers: http://savannah.nongnu.org/bugs/...

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

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

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

Yes, I have found the avrlibc bug numbers.

I suspect that you would be better off with putting them on the Atmel Bugzilla. After all, this sort of item is down to Atmel.

Of course, Atmel may choose to put it on avrlibc bugzilla themselves!

David.

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

But is the error in the core AVR-LibC or Atmel's private development branch? Assuming Atmel merge from the mainline (who knows?) it's surely better that something like this be fixed at the higher level?

Atmel did say they were working to merge their private work back into the mainline to ease their own maintenance - wonder where that effort is right now?

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

Surely the model-specific information comes from Atmel. So if there is a problem, it is up to Atmel.

In practice, it is more in Atmel's interest to fix model information than the 'avrlibc' community.

Atmel supply the XML files to generate the header files. So every Compiler vendor benefits.

Two years ago, there were appalling spelling errors in some Interrupt Vector names of some header files. These were fixed by Atmel as far as I know. Somehow, I trust that this was achieved more promptly than by the avrlibc.

Pure speculation by me!

David.

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

Quote:
Surely the model-specific information comes from Atmel.

Err no. There were ioxxxx.h files in AVR-LibC long before Atmel's involvement in the project. When I look at the open SVN for AVR-LibC I see iotn84.h and iotn84a.h files there. Someone put them there and it wasn't Atmel.

Now it's true that since Atmel have chosen to effectively take over WinAVR they have added a load of ioxxxx.h files to their "private" branch so if you compare an Atmel installation of AVR-LibC to a generic one you will find almost 100 device support headers that clearly "belong" to Atmel (one day they'll have the good grace to push this back to HEAD of AVR-LibC!). If those "private" files have errors then, yes, they should be reported in Atmel's private bugzilla. But if it's an inherited "public" file an error in it should be reported to the open AVR-LibC bugzilla.

Of course the question is "how do you know?". I guess all you can do is install both. Diff the trees and if a file is only in the Atmel version report it to them, otherwise report it to the open project. But there could be an issue there. Suppose the edit in the "open" file is actually a private edit by Atmel!

The sooner Atmel push back to HEAD and everyone can use the open bugzilla to report everything the better.

I imagine the open AVR-LibC volunteers probably get a bit passed off getting reports of Atmel errors they can do nothing about.

Anyway the tn84 files look like they are open ones (but check for local Atmel edits).

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

Quote:

Atmel did say they were working to merge their private work back into the mainline to ease their own maintenance - wonder where that effort is right now?

Work in progress, but no big differences anymore in the device headers. I and a couple of others internally have pushed a bit to get this upstreamed, and now at least one from our toolchain team has access to upstream. Last sum-up I did on the mailinglist was (as far as I remember) only 1 or 2 tinys that had major differences. Look on the mail list to see some of the status...

As for xml generation, the truth is a bit more grayscale unfortunately.
For xmega, uc3, sam and newer mega/tiny, we generate headers from our xml. This is currently not done for those headers that are defined in avr-libc, as the generated output is very different than the 'legacy' header files. Due to the gap, we have not migrated older avr8 devices over to our generators (note, older in this sense means all but a couple of new mega and tiny devices).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

david.prentice wrote:
Yes, I have found the avrlibc bug numbers.

I suspect that you would be better off with putting them on the Atmel Bugzilla. After all, this sort of item is down to Atmel.

Of course, Atmel may choose to put it on avrlibc bugzilla themselves!

David.


I submitted bug #41519: wrong SPM_PAGESIZE definition in iotn[48]8.h on Feb 9th, and it is now showing as fixed.
We'll see if the fuse definitions gets fixed as quicly...

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

clawson wrote:
[
Of course the question is "how do you know?". I guess all you can do is install both.

I just use the official avr-gcc (not WinAVR), so it's simple for me.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

meolsen wrote:
Quote:

Atmel did say they were working to merge their private work back into the mainline to ease their own maintenance - wonder where that effort is right now?

Work in progress, but no big differences anymore in the device headers. I and a couple of others internally have pushed a bit to get this upstreamed, and now at least one from our toolchain team has access to upstream.

That's great news. Thanks for the transparency.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

meolsen wrote:
As for xml generation, the truth is a bit more grayscale unfortunately.
For xmega, uc3, sam and newer mega/tiny, we generate headers from our xml. This is currently not done for those headers that are defined in avr-libc, as the generated output is very different than the 'legacy' header files. Due to the gap, we have not migrated older avr8 devices over to our generators (note, older in this sense means all but a couple of new mega and tiny devices).

I agree that 'legacy' header files might require a bit of work. Let's face it, most of a ioxxxx.h refers to SFR_NAMEs and BIT_NAMEs. Surely you could machine-generate most of this, with a DEPRECATED or LEGACY conditional to support obsolete names.

This would require a few Beta-testers but in the long run would keep everyone happy.

Any twin-track system of reporting is prone to confusion. I must admit that my view is "Atmel has more to lose if errors are not swiftly corrected".

David.

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

Quote:

I just use the official avr-gcc

What is "the official" avr-gcc in this context?
The tip of the gcc and avrlibc repositories?
Or the lastest toolchain from Atmel?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

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

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

Quote:

That's great news. Thanks for the transparency.

New dawn :P Well, no Rome in a day, but better than a year a ago.

Quote:

Any twin-track system of reporting is prone to confusion. I must admit that my view is "Atmel has more to lose if errors are not swiftly corrected".

Yes (to both)

Quote:

I agree that 'legacy' header files might require a bit of work. Let's face it, most of a ioxxxx.h refers to SFR_NAMEs and BIT_NAMEs. Surely you could machine-generate most of this, with a DEPRECATED or LEGACY conditional to support obsolete names.

There have been some droddling w.r.t to this. However there are many more pressing issues before I see much happening here. The biggest issue with moving from legacy to generated is that the xml base I have could have been better (I have the third incarnation of the description format, and I guess things have only moved between them in the past). ALso the AVR base has its interesting quirks.

Maintaining a splitted xml and header system is quite painful, so it seems that this is starting to reach the agenda.

For some slightly interesting movement, there is also the Embecosm GitHub which are working on improving parts of the ecosystem.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

JohanEkdahl wrote:
Quote:

I just use the official avr-gcc

What is "the official" avr-gcc in this context?
The tip of the gcc and avrlibc repositories?
Or the lastest toolchain from Atmel?

I consider builds from the gnu sources to be official.
I never even knew Atmel provided avr-gcc builds (outside of WinAVR) until you mentioned it. Looking at their web site, it looks like they're still on 4.3.x. On Windows I use

avr-gcc.exe (GCC) 4.8.0 20130306

On Linux I use 4.8.1 (because I couldn't find a 4.8.1 minGW build and was too lazy to build it myself).

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Quote:
it looks like they're still on 4.3.x.
You mean 3.4.x? That's the Atmel toolchain version. The latest is 3.4.3 and is based on gcc 4.8.1.
$ avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
==========================================================================
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even on Linux the current "best" distribution is "Atmel's Toolchain for Linux". As I said it currently supports almost 100 more "new" AVR than the "official" source.

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

Quote:

I never even knew Atmel provided avr-gcc builds (outside of WinAVR)

Sidenote: WinAVR was not an Atmel initiative.

It is true though, that the initiator of WinAVR Eric Weddington, went on and got hired by Atmel. At one point he asked if there was any interest in a new WinAVR to update the 2010 one. Then this went all quiet, and it is not hard form a conspiracy theory about what happened. Eric has now left Atmel. He has a high level of integrity if you ask me, so we will never know what actually went down. But an excellent initiative died, and now Atmel relies on the open source compiler AVR-GCC, but does not (yet) push their patches upstream.

Since, by definition, Atmel will be the first to know about new AVR devices, avr-gcc is essentially hijacked by Atmel until they start pushing in a timely fashion. I have for a long time found it "troubling" that they have not prioritized this.

Nothing of this is in any way a jump on the Atmel folks that frequent these fora. Somewhere in the Atmel hierarchy are persons with power over budgets but lacking an understanding of what the community has done for them. Or they have realized that, but are cynical enough to essentially just go: "Thank You! Suckers...".

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

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

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

snigelen wrote:
Quote:
it looks like they're still on 4.3.x.
You mean 3.4.x? That's the Atmel toolchain version. The latest is 3.4.3 and is based on gcc 4.8.1.
$ avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
==========================================================================


That's rather confusing. I would have expected them to use the same version numbers.
Thanks for pointing it out though.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

clawson wrote:
Even on Linux the current "best" distribution is "Atmel's Toolchain for Linux". As I said it currently supports almost 100 more "new" AVR than the "official" source.

Until I saw Morten's post I didn't know that Atmel's version was based on the latest avr-gcc version plus updated headers.
Seems to be the tail wagging the dog, but as Morten indicated they're working on changing that.

I am surprised it's not more well known.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

JohanEkdahl wrote:
Eric has now left Atmel. He has a high level of integrity if you ask me, so we will never know what actually went down.

Perhaps we have different definitions of integrity. Openness and honesty are how I'd define it.
Now if you happen to know he agreed to an NDA, then honesty would dictate that he stick to his agreement and not disclose anything.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Any good dictionary should have a definition (well, definitions) of "integrity". I see "honesty" being in several dictionaries, but fail to finsd "openness".

I used it in the meaning "of high moral standard".

I would think that most hiring contracts included a NDA section? (I know or sure that I, as a contractor, get to sign them for more or less every assignment.)

Another angle on the matter is that if it became known on the workforce marketplace that you leak what went down at a former employer you might be less attractive as a hire. So unless you feel you have a moral whitsle to blow, you just don't talk about what went down when you where employed by X.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

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

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

Quote:

I am surprised it's not more well known.

Do we measure "well known" by whether you've heard of it or not? :-)

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

clawson wrote:
Quote:

I am surprised it's not more well known.

Do we measure "well known" by whether you've heard of it or not? :-)

Alright, then more spoken of?
I've read dozens of posts about AVR development, and the Atmel toolchain is rarely mentioned.
Here's some numbers from google that would indicate it's not a misperception:
atmel toolchain: 155K
avr-gcc: 735K
avr stdio: 3M
arduino ide: 2.7M

Searching for "AVR compiler" in google doesn't show the atmel toolchain on the first page. IAR, AVR Studio, avr-gcc are all in the first page results.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

JohanEkdahl wrote:
Any good dictionary should have a definition (well, definitions) of "integrity". I see "honesty" being in several dictionaries, but fail to finsd "openness".

I used it in the meaning "of high moral standard".

I think you're somewhat conflating morals with social norms. Most NT's don't pay much attention to the difference, but as an Aspie I notice it a lot.

An example would be when a neighbor bragged about cheating on his wife while on business trips. Not being constrained by social rules or concerned over his likely displeasure, I did the moral thing and told his wife.

Qui tacet consentire videtur.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Did you get a smack in the mouth?

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

david.prentice wrote:
Did you get a smack in the mouth?

No, he convinced the local police to charge me with criminal harassment of him and his wife. It took a year to go to trial, and when it was finally over I was aqcuitted. The wife told the police that she feared for her safety, but when questioned at trial it was clear she only feared embarrassment.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Quote:

Here's some numbers from google that would indicate it's not a misperception:

Did you limit that search to the last 2 years say (about the period over which Atmel's toolchain has become the defacto standard). Obviously there's going to be 10+ years during which WinAVR (et al) were the dominant avr-gcc toolchain. But Atmel have taken over recently with "recently" being the operative word. 2 years ago I was still using 4.3.3 in WinAVR as it was the "best" distribution out there - but times change. As bingo's sticky at the top of this forum will tel lyou I also used to host the "best" Linux distribution at www.wrightflyer.co.uk/avr-gcc/ - these days my page has a last line that basically says "forget all this - just get Atmel".

EDIT: thinks I must update my own page - Atmel offer 4.8.1 not 4.6.2 now.

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

clawson wrote:
these days my page has a last line that basically says "forget all this - just get Atmel".

I just checked it out, and it's not really public in the way the gnu avr-gcc release is. It seems you have to register with Atmel, and must be employed (company is a mandatory field).

That's probably why it never came up when I was searching for avr-gcc builds. It seems rather stupid to put the work into an improved version of avr-gcc/avr-libc and hide it behind a closed site.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

ralphd wrote:

I just checked it out, and it's not really public in the way the gnu avr-gcc release is. It seems you have to register with Atmel, and must be employed (company is a mandatory field).

That's probably why it never came up when I was searching for avr-gcc builds. It seems rather stupid to put the work into an improved version of avr-gcc/avr-libc and hide it behind a closed site.

Methinks that if this doesn't violate the letter of the GPL, it violates the principle of free software.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

ralphd wrote:
ralphd wrote:

I just checked it out, and it's not really public in the way the gnu avr-gcc release is. It seems you have to register with Atmel, and must be employed (company is a mandatory field).

That's probably why it never came up when I was searching for avr-gcc builds. It seems rather stupid to put the work into an improved version of avr-gcc/avr-libc and hide it behind a closed site.

Methinks that if this doesn't violate the letter of the GPL, it violates the principle of free software.

I found the source and build instructions, so it looks like they are GPL compliant.
http://distribute.atmel.no/tools...

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Quote:

I just checked it out, and it's not really public in the way the gnu avr-gcc release is. It seems you have to register with Atmel, and must be employed (company is a mandatory field).

Ever heard of "lying" ;-)

I used to just lie and use a@b.com as an email etc. when doing the Atmel registration thing. These days I just signed up for "myAtmel" the once (you don't have to be employed - everything I do with AVR these days is just a hobby). Now when I visit atmel.com I just log into myAtmel then all the downloads (studio, toolchain, whatever) come without any further registration required.

If you have Windows you are missing out greatly by not having AS6 (also requires registration). It had a shaky start but is really good these days.

Quote:

It seems rather stupid to put the work into an improved version of avr-gcc/avr-libc and hide it behind a closed site.

Yeah but Atmel are not philanthropists. They answer to no one but their shareholders for whom they try to maximize profit. They do that by selling silicon and they are more likely to be able to do that to you once they have your email address and know who to target the "newsletter" (aka spam) to. Personally I don't mind Atmel spam. It's about something I'm interested in and unlike so many other companies they don't over do it. in fact they could email more often about more stuff and I'd be interested. I guess this is the price you pay to employ their engineers in Norway and India who do the work on their avr-gcc variant.

As I say it is simply "better" than others because it has the widest range of supported devices. Of course., if you stick to old faithfuls like mega16 and mega168's (I do) then I guess you don't need support for XmegaE5's or whatever Atmel's latest work has targetted.

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

clawson wrote:
Quote:

I just checked it out, and it's not really public in the way the gnu avr-gcc release is. It seems you have to register with Atmel, and must be employed (company is a mandatory field).

Ever heard of "lying" ;-)

Yeah, but it's something you NT folks seem to be much more comfortable with than those of us on the spectrum...

I have no special talents.  I am only passionately curious. - Albert Einstein

 

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

Ralph, stop waving the aspy card - it gets tiring after a while. You've lied many times, it that you probably don't realise it or you actually believe your own BS.