WinAVR continuation

Go To Last Post
86 posts / 0 new

Pages

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

Eric!

Are there any news on this that you can reveal. Or (my fear...), is the resurrection of WinAVR ditched?

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

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

 

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

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

Must be that XMEGA syndrome... They said three months, but they meant a year and three months.

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

Who is "they".

I don't think Atmel is enthusiastic about a second tool chain, and Atmel won't put effort into WinAVR.

Atmel prefers to support it's "Atmel toolchain", they are too myopic to see that there migh be anything else besides their Studio moloch thing.

IMO they would be better off to sponsor a more light-weight and more general approach.

They could just as well supply their moloch bundled with a quality distribuítion like WinAVR was.

avrfreaks does not support Opera. Profile inactive.

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

While EW is an Atmel employee I was under the impression that he would do a new WinAVR on his free time, so Atmel would not put any time into this.

The more saddening hypothetical scenario would be that Atmel said to EW, "No dont do that - even if it is on your spare time". In that case I would suspect EW to just stay silent (but please understand that a silent EW not ncessarily implies that such words where spoken!)

My hope is of-course that EW stops by during this weekend saying "It'll happen, but it takes some more time" so just be patient.

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

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

 

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

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

fyi
GCC 4.7.0 Release Candidate available.
GCC 4.7 Changes, ... (Note the significant AVR changes; search for "AVR").

"Dare to be naïve." - Buckminster Fuller

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

I see that they announced official support for Xmega, and official support for named address spaces, both in the same release.

Based on my reading, I sincerely doubt that they support the Xmega's ability to use RAM above the 64kB boundary. That's fine, because I suspect it would be a relatively infrequently-used hardware feature.

However, I will be very curious to see if they took all necessary precautions to ensure that it is safe to use both Xmega (which actively makes use of RAMPZ for all "LD Z"-type instructions) and named address spaces (specifically, __flash1, __flash2, etc which modify RAMPZ) within the same project without one causing unintended corruption of the other.

Last Edited: Wed. Mar 7, 2012 - 01:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ask SprinterSB - he did it!

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

lfmorrison wrote:
I see that they announced official support for Xmega, and official support for named address spaces, both in the same release.
Support for the new features will take until 4.7.1 at least.
Quote:
Based on my reading, I sincerely doubt that they support the Xmega's ability to use RAM above the 64kB boundary.
Correct. The hardware + GCC compination is simply too weird to make that hippo dance.
Quote:
However, I will be very curious to see if they took all necessary precautions to ensure that it is safe
Yes: http://gcc.gnu.org/onlinedocs/gc...

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
The hardware + GCC compination is simply too weird to make that hippo dance.

Could not avoid the temptation. But at least I didn't photoshop Xmega on her belly.

Smiley

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

Cute :-)

You are the hippo whisperer?

Here is the original from Kenny Zadeck.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
lfmorrison wrote:
I see that they announced official support for Xmega, and official support for named address spaces, both in the same release.
Support for the new features will take until 4.7.1 at least.
Quote:
Based on my reading, I sincerely doubt that they support the Xmega's ability to use RAM above the 64kB boundary.
Correct. The hardware + GCC compination is simply too weird to make that hippo dance.
Quote:
However, I will be very curious to see if they took all necessary precautions to ensure that it is safe
Yes: http://gcc.gnu.org/onlinedocs/gc...

That is truly excellent news. Good work!

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

any news about the new compiler?

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

I cannot believe I'm going to say this but the avr-gcc 4.6.2 that is now supplied in AS6 doesn't seem too bad. If you don't want the AS6 "bloat" I believe you can download this as a separate "toolchain".

I wish someone would do a distribution with a 4.7.1 but I guess it might still be "work in progress"?

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

clawson wrote:
avr-gcc 4.6.2 that is now supplied in AS6
What does "avr-gcc -v" say?

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
What does "avr-gcc -v" say?
Quote:
gcc version 4.6.2 (AVR_8_bit_GNU_Toolchain_3.4.0_663)
Don

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

donblake wrote:
gcc version 4.6.2 (AVR_8_bit_GNU_Toolchain_3.4.0_663)

Isn't there a similar dowload for that release, just like that?
http://www.atmel.com/Images/avr-toolchain-installer-3.3.0.710-win32.win32.x86.exe

Or a link to the patch(es) against FSF 4.6.2?

avrfreaks does not support Opera. Profile inactive.

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

The standalone installer isn't published yet, but I've attached a zipped version of the "source" folder from the 3.4.0 release in the Studio 6 public build.

- Dean :twisted:

Attachment(s): 

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

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

There are several issues:

Build-ins for SEI, CLI, NOP, etc. are missing memory barriers. See FSF trunk for examples.

The fmul* insns have wrong constraints. Reloading is controlled by constraints, not by predicates. See FSF trunk.

Constraint "w" is mapped to an empty register class for some targets. This will shred the compiler if delay_cycles_2 is emit for such a target.

You should apply (fix PR51374)
http://gcc.gnu.org/viewcvs?view=...

Mayba also apply (fix PR51756)
http://gcc.gnu.org/viewcvs?view=...

If I see correctly, your tools still come with wrong multiply as explained in
http://gcc.gnu.org/bugzilla/show...

avrfreaks does not support Opera. Profile inactive.

Last Edited: Sat. May 26, 2012 - 11:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I wish someone would do a distribution with a 4.7.1 but I guess it might still be "work in progress"?
And I though you *are* brave, Cliff... :-)

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

SprinterSB wrote:
There are several issues:

Atmel, I still don't get why don't you hire Johann.

Tomorrow is Sunday, a free day for most of the guys with the cheque book, but the Monday after that is a business day.

JW

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

I'm not on the Atmel Toolchain development team, but I can get into contact with them. Johann, can you please email me a list of everything that needs to be fixed (dean_patrick.camera at atmel dot com) in the toolchain so I can send it along to them?

- Dean :twisted:

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

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

abcminiuser wrote:
Johann, can you please email me a list of everything that needs to be fixed in the toolchain
And what would be the reason to "fix" 4.6.x and not to move to 4.7.1?

Dean, have you tried Johann's build already?

Jan

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

Not yet - I've been trying to go for stability while developing some hairy code, and IIRC the new builds don't have full C3 XMEGA support.

- Dean :twisted:

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

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

wek wrote:
And what would be the reason to "fix" 4.6.x and not to move to 4.7.1?
The last version was 4.5. Thus, the next reasonable step is to move to 4.6.

4.7.1 isn't even officially released.

Moreover, Atmel will have to rewrite all of their GCC patches. I didn't spot a simgle patch that would merge without causing conflicts in every line or yield silly results if it happens not to raise conflicts.

There was too much noise in the sources as their old patches would be useful. Apart from serving as documentation what was added in 4.6, they are useless with 4.7.

wek wrote:
Atmel, I still don't get why don't you hire Johann.
Because I introduced way more bugs and way more severe bugs than mentioned in the small list above? :lol:

At the moment I'm fine to decide myself what to change in the compiler. And how many or how little time to spend on the compiler.

Hacking the compiler is fun. Bundling resources would reduce that fun. See my note on patches just above.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
wek wrote:
And what would be the reason to "fix" 4.6.x and not to move to 4.7.1?
The last version was 4.5. Thus, the next reasonable step is to move to 4.6.
This step has already happened. Dean is talking about *fixing* the 4.6-based AS6-"toolchain". I question the reason to do this in light of advances in your 4.7.1.

SprinterSB wrote:
4.7.1 isn't even officially released.
In the past, it took always several months between consecutive "toolchains". So I guess 4.7.1 will be released by the time a new "toolchain".

SprinterSB wrote:
Moreover, Atmel will have to rewrite all of their GCC patches. I didn't spot a single patch that would merge without causing conflicts in every line or yield silly results if it happens not to raise conflicts.

There was too much noise in the sources as their old patches would be useful. Apart from serving as documentation what was added in 4.6, they are useless with 4.7.

Okay, but what would be the reason to maintain (indefinitely) a fork? They would need to move on to 4.7 or newer, doing that work, sooner or later. So why not start now.

There is a big incentive in 4.7.1 - the native _flash (and related) support.

SprinterSB wrote:
wek wrote:
Atmel, I still don't get why don't you hire Johann.
Because I introduced way more bugs and way more severe bugs than mentioned in the small list above? :lol:
Even the fact that you *know* of your bugs means you have a huge knowledge.

SprinterSB wrote:
At the moment I'm fine to decide myself what to change in the compiler. And how many or how little time to spend on the compiler.

Hacking the compiler is fun. Bundling resources would reduce that fun. See my note on patches just above.

I understand all of this.

And I did not suggest the "toolchain" crew should now stop working, depending on you entirely for the new issue, nothing like that. I just say that this is an opportunity for them to grab on your particular expertize, and an opportunity for you to finally get your work to the intended audience.

The decision is upon both of you, of course. I just said what I thought might be beneficial for both Atmel and the community (which includes me - selfish, I know).

Jan

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

SprinterSB wrote:

Quote:
Hacking the compiler is fun. Bundling resources would reduce that fun.

Not here. I want compiled and downloaded code. Nothing else. Hacking gets in the way of this. Not good for most users!

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

actually, my code is no longer correctly working with the new compiler. Now I have to find out why, it compiles OK and works OK, until I use some functions in my code that used to work, and now they are no longer working.

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

ka7ehk wrote:
SprinterSB wrote:
Quote:
Hacking the compiler is fun. Bundling resources would reduce that fun.

Not here. I want compiled and downloaded code. Nothing else. Hacking gets in the way of this. Not good for most users!

Jim

Jim, I am afraid you misunderstood what was here meant by "hacking". Johann contributed an enormous work to the avr backend of gcc in the last months, adding several new features, and fixing or helping to fix quite a couple of bugs.

I don't know if you follow Johann's work here, but if you do, you know that he already provided several "issues" of a complete, usable avr-gcc/avr-libc packages, have a look here (you can try out the latest and greatest; discussed here).

As they were intended to provide a quick way for users to test the new features, they did not contain stuff like documentation and bundled utilities; so they can't be seen as WinAVR replacements. However, they are complete enough to provide unpack-and-compile for us, the mere users.

I believe that is enough proof of Johann's qualification to *contribute* to building of a user-grade package.

JW

Last Edited: Mon. May 28, 2012 - 07:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

metal wrote:
actually, my code is no longer correctly working with the new compiler. Now I have to find out why, it compiles OK and works OK, until I use some functions in my code that used to work, and now they are no longer working.
Please post a minimal but complete compilable example, with the description of what is the expected behaviour and how does the result fall short of it; together with the version/source of compiler you are using and the complete command-line used to compile.

JW

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

Quote:

Jim, I am afraid you misunderstood what was here meant by "hacking". Johann contributed [...]

Great post, Jan!

But you are aware that Jim is a Mac user, right?

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

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

 

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

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

JohanEkdahl wrote:
But you are aware that Jim is a Mac user, right?
Uhmmmm... No.

Jan

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

Quote:

Jim, I am afraid you misunderstood what was here meant by "hacking". Johann contributed an enormous work to the avr backend of gcc in the last months, adding several new features, and fixing or helping to fix quite a couple of bugs.

Indeed - If there was one person I could e-hug on here, it would be him for his great work. I did try the posted packages and they appeared to work as advertised in my very limited tests, but I switched to the latest AVR Toolchain instead for stability reasons (to ensure I was debugging my own code, not the compiler!).

Quote:

This step has already happened. Dean is talking about *fixing* the 4.6-based AS6-"toolchain". I question the reason to do this in light of advances in your 4.7.1.

Upgrading patches between compilers is a big thing, and not something done in a slow weekend. Port work from one AVR-GCC version to the next started months before 4.7.1 was even started, and as SprinterSB says it's not actually released yet. You would be asking Atmel to port to an incomplete, moving target compiler over a stable version.

- Dean :twisted:

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

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

wek wrote:
what would be the reason to maintain (indefinitely) a fork? They [Atmel] would need to move on to 4.7 or newer, doing that work, sooner or later. So why not start now.
If I understand right, that's not a decision of the tools folk. It's legal stuff, advocates fineprints an the like that's required when contributing to GCC. Anyone correct me if I am wrong here.

Moreover, in a private sandbox, you can do any change at any time and release anything at any time. No reviews, no GCC development stages, no release cycles, no coding rules, no ChangeLogs, no other kinds of "annoyances".

But I think in the long run it would be much less work to contribute early. Adding xmega dedives for example is trivial now after xmega support is there. Adding the missing devices would be a one-liner for each device...

Contributing this to GCC/Binutils and get rid of that pile of patches would reduce costs and increase consistency. It shows that Atmel's tools folk did not yet find out how to "hacking the company", as Meissner puts it :twisted:

wek wrote:
I just say that this is an opportunity for [...] you to finally get your work to the intended audience.
My intended "audience" is GCC. It will reach the biggest audience if avr-gcc users. Users have th freedom the chose what tools they want to use.

abcminiuser wrote:
Upgrading patches between compilers is a big thing, and not something done in a slow weekend.
If GCC supports the architecture, adding a device to GCC is a one-liner. Ar least 26 patches (not counting ATtiny patches) of the 45 GCC patches in 3.4.0 are of that kind.

A reasonable strategy would be to add support to 4.8 and then backport to 4.7. At the moment, 4.8. and 4.7 have not yet diverged too far, and these simple patches will fit both versions. If it's ok for the AVR maintainers, the support could even be added to official 4.7. It's not GCC's policy to add such extension in stage 3; but these changes are trivial enough and dont's affect other devices if they come with a typo, for example.

abcminiuser wrote:
You would be asking Atmel to port to an incomplete, moving target compiler over a stable version.
Getting as much as possible changes in the official release is very reasonable, no matter if Atmel will ship 4.6 or not. Except you want to keep that ever increasing tower of patches until end of time...

To help maintenance, it's preferred to get rid of patches as soon as possible, and not stick to them as long as possible. That is only my own, private opinion, of course.

avrfreaks does not support Opera. Profile inactive.

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

metal wrote:
actually, my code is no longer correctly working with the new compiler. Now I have to find out why, it compiles OK and works OK, until I use some functions in my code that used to work, and now they are no longer working.
Would you open a new thread and outline the problem?

avrfreaks does not support Opera. Profile inactive.

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

I've created internal issue AVRTC-539 for your posted bugs Johann - thanks! I'll keep you updated when the AVR Toolchain team take a look at it.

- Dean :twisted:

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

Pages