WinAVR continuation

86 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I've decided.

I'm going to continue WinAVR.

I would like to come out with a release say in the next 3 months (or less, if I can swing it).

It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

Joerg has mentioned a new avrdude and avarice release as well, but realize that his time is spread thin across multiple projects.

We have to work out what version of avr-gcc to include and what kinds of patches it needs to contain. There's a number of bug fixes that need to be done.

I'm sure there will updates on other tools as well.

Bug reports, patches, and constructive feedback welcome. And help on any of the projects is always welcome too.

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

Hi EW,

Awesome news!! Thanks for your hard work!

Alan

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

Does this mean then that this will just work with Studio 4.xx?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

It works the other way around. The IDE has to be built such that it works with any installed toolchain. I'm not in control of the IDE portion.

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

If you need any help (with documentation, what ever), please shout, scream, or otherwise pull my chain. Not much experience, but It is something I ought to be able to help with.

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

Good news, Eric!

"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

Looking forward to it.

Jan

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

Great news. "Toolchain" was starting to look a lot like a half baked lame duck.

 

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

EW wrote:
I'm going to continue WinAVR.

Hi Eric, that's very good news! What base version?

Quote:
I would like to come out with a release say in the next 3 months (or less, if I can swing it).

Is there any effort on your side to fix the evil PR46779/45291/41894 issue? I did not yet backport and 4.7 changes.

Quote:
It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

What is the rationale behind poisoning the SIG_ semantic sugar?

That will render many applications to freak without any need, that just builds up barriers. There have been two nomanclatures in avr-libc:

Numenclatur of avr-libc with SIG_ prefix.

Names that occured in any target manual, suffixed _vect. If a vect is renamed in the handbook because of some update, new versions of avr-libc should NOT remove the old name but still support it. For example some handlers are named TIM0_* and others TIMER0_*.

If some name ever existed, it should persist to do so.

There are already enough barriers useres have to cope with, so I do not understand yet another, pure artificial barrier.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
EW wrote:
I'm going to continue WinAVR.

Hi Eric, that's very good news! What base version?

Good question. I don't have an immediate answer on that. This is one of the main things that we need to look into in order to do the release. I know that there are issues in GCC 4.5.x, 4.6.x, and trunk (future 4.7). We need to figure out which version and which set of patches to include. Very likely some bugs need to be fixed before a release.

SprinterSB wrote:

Quote:
I would like to come out with a release say in the next 3 months (or less, if I can swing it).

Is there any effort on your side to fix the evil PR46779/45291/41894 issue? I did not yet backport and 4.7 changes.

Certainly we need to go through the bug list and address issues like those. There has been work done recently by Georg-Johann Lay on various bug reports, which has been very much appreciated.

SprinterSB wrote:

Quote:
It will contain a new avr-libc release. This will tentatively be 1.8.0. Joerg and I are currently working on bug fixes and patches to avr-libc.

What is the rationale behind poisoning the SIG_ semantic sugar?

That will render many applications to freak without any need, that just builds up barriers.

Technically, the SIG_* names have been deprecated for years. The *_vect names have been preferred. We've been slowly moving to those names over time, mainly because they are compatible with IAR. If you have noticed, new device support does NOT contain the old SIG_* ISR naming.

What we have not had in avr-libc in the past, is an easy way to tell the user what is deprecated and what is not. With the upcoming 1.8.0, these old deprecated names are now "poisoned" so that if they are used in an application the compiler will generate an error. However, the good thing with our deprecation system is that any user can easily get to the deprecated names just by defining an identifier before including io.h and then all of the deprecations are immediately available without warnings or errors.

The point of deprecations is that they eventually will go away. We try to give ample warnings to the end user so they have time to change their applications to any new system. Please realize that we are actually very conscientious about keeping old names around for a long time. We are keenly aware about backwards compatibility. But in the end, those SIG_* names are outdated, and they are not used across all devices. The *_vect names are used across all devices.

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

EW wrote:
There has been work done recently by Georg-Johann Lay on various bug reports,
[whisper] SprinterSB IS Georg-Johann Lay ;-) [/whisper]

Stefan Ernst

Pages