Getting going again...

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

After a hiatus of a couple of years, I'm restarting my AVR 8-bit development environment from scratch... Previously I was using the winavr distribution...

I know that AS 6.1 (beta) is the latest and greatest, but what is the relationship between AS 6 and winavr/avr-libc?

What about all those nice macros & support routines in avr-libc? are they now integrated with AS? What's the state of play here?

Many thanks,

Nicko

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

Quote:

but what is the relationship between AS 6 and winavr?

WinAVR = 4.3.3
AS6.1B = 4.7.2

Just as with WinAVR where you could also use AS4 and the two together gave you an integrated development environment for avr-gcc, all that's happened in AS5/6 is that Atmel have incorporated a copy of avr-gcc (and avr32-gcc and arm-gcc) into the installation package so you don't need to go shopping for your WinAVR separately.

You've come back at just the right moment in fact as Atmel had a stumbling/fumbling start to all this and didn't seem to have much clue about how to build a copy of avr-gcc and set up an environment that people would want to use it in. But 6.1Beta finally represents something that is pretty good and now makes a nice alternative to AS4+WinAVR.

The one downside of the whole thing is that they seem to deliberately not want to play the GPL game properly and feed their changes (mainly new device support) back to the generic GCC project so that other users on Linux can benefit from their work. Instead they branched their own copy of avr-gcc and have worked on that in isolation and show no signs of helping the community. This is a true shame and goes against the spirit of GPL but I suppose if their Windows users are happy why should they care? They don't seem to mind the one-way-street policy in the other direction so they recently integrated patches from core 4.7 tree into the 4.6 that was previously shipped in AS5 and AS6.0 which means they have benefitted from work such as SprinterSB's excellent __flash work to replace PROGMEM/pgm_read*().

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

Quote:

The one downside of the whole thing is that they seem to deliberately not want to play the GPL game properly and feed their changes (mainly new device support) back to the generic GCC project so that other users on Linux can benefit from their work.

FWIW, the process of upstreaming the patches has started - not sure when they'll get into the toolchain's mainline versions though.
Meanwhile, I have been consciously working on and submitting patches on mainline/trunk. Having a local "branch" is actually painful that way, as I/we have to repeat the work on that branch, so we too are trying to get rid of that.

Regards

Senthil

 

blog | website

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

Thanks for the answers guys, but I still would like to know if my avr-libc stuff is likely to all be OK? What about all those macros & support routines?

Nicko

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

Quote:

Thanks for the answers guys, but I still would like to know if my avr-libc stuff is likely to all be OK? What about all those macros & support routines?


What makes you think there'll be an issue with that? True WinAVR uses AVR-LibC 1.6.7 and AS6 (6.1B) uses 1.8.0 so I suppose there might be slight differences/improvements but why do you think it will really be that much different?

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

clawson wrote:
What makes you think there'll be an issue with that? True WinAVR uses AVR-LibC 1.6.7 and AS6 (6.1B) uses 1.8.0 so I suppose there might be slight differences/improvements but why do you think it will really be that much different?

Paranoia :)

I'll have a look at the differences - that should be fine, then...

Nicko

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

Still using 6.0 as 6.1 beta has one annoying problem: If the chip has already been programmed, it will fail erasing the chip.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Quote:

If the chip has already been programmed, it will fail erasing the chip.

I don't find that using JTAG to program a mega32 on an STK500.

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

Using ISP and ISP Mk II, I get it on Tiny 10's and Tiny 45's and Tiny 2313's.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.