recent avr-libc activity

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

As a new avr-libc is going to be released soon, there is quite a lot of activity around there.

For those who are not subscribed yet to the avr-libc-dev mailing list, but are interested, it can be folowed through the archive.

JW

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

Can you explain what this is about?

I use avrlibc and frequently read the mailing list, but I've no idea what this poll is for.

Also, isn't WinAVR itself EOL? I thought that it was being integrated into the next AVRStudio version and there wouldn't be any more WinAVRs except maybe bug fixes?

Maybe you have a link to specific discussions on the mailing list that caused you to post this?

Smiley

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

The poll is just my curiosity and is just loosely related to the post. I wonder whether there are people willing to go for the bleeding-edge avr-libc before it appears as part of the package, beta-testing it, sort of.

The poll might've been perhaps better formulated in past tense (for which WinAVR would make sense). My English is poor as you can see, sorry. I assume those who went for the newest avr-libc in the past are likely do so in the future, too.

Jan

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

But what is the newest avrlibc? How does this differ in any way from the normal process of getting the latest version through the normal means? Do you have some information to indicate that this new avrlibc is going to be specially different? Will it be available in some different way. I just don't get what your are asking.

And what is this "recent avr-libc activity" that you are referring to? What have I missed?

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

smileymicros wrote:
But what is the newest avrlibc? How does this differ in any way from the normal process of getting the latest version through the normal means?

avr-libc is not bound strictly to WinAVR and changes occur asynchronously. Although apparently most of the issues happened a few days before a new WinAVR happened, there are exceptions.

Assuming that for most of the users "normal" means getting the newest avr-libc through a new WinAVR (or whatever it will be called in the future), the "not-normal" may be:

  • get the complete issue from http://mirror.lihnidos.org/GNU/s... (say those few days before it appears in a new WinAVR, if at all)
  • regularly synchronize the complete development sources from the source repository
  • get an isolated item from the repository as a reaction to a fix or change critical to one's application
  • some other way, unknown to me ;-)
Quote:
And what is this "recent avr-libc activity" that you are referring to?
While changes to avr-libc happen from time to time, around a planned issue date much more things happen - patches submitted in the meantime are accepted or rejected, issues are fixed and closed. These days, for example a couple of XMega issues, cli() and memory barrier issues, malloc()/free() patch were discussed, to name just a few.

JW

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

The Linux users of the build-script/.deb packages. Has been using avr-libc-1.6.8 for a while.

/Bingo

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

I think Bingo hit the nail on the head. Windows users really have no alternative but to use the latest WinAVR version as it comes nicely packaged and they have no possibility of building the libraries (as they don't have the MinGw/Msys setup that Eric uses).

In Linux it's (fairly) easy for any user to cross compile the latest AVR-LibC as Linux is the natural build environment for GCC code.

So Linux users are either as up to date as

(a) their distro repository (if timid) or
(b) Bingo's latest build at www.wrightflyer.co.uk/avr-gcc/ (if a normal user) or
(c) Bingo's latest script (if bold) or
(d) the latest GIT/SVN/whatever-it-is pull from the AVR-LibC source repository an "home build" (if a complete bit junkie)

Maybe the poll should simply have been

do you use:
+ Windows
+ Linux

Last Edited: Wed. Jun 9, 2010 - 10:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well if you have a linux machine ....

https://www.avrfreaks.net/index.p...

/Bingo

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

clawson wrote:
I think Bingo hit the nail on the head. Windows users really have no alternative but to use the latest WinAVR version as it comes nicely packaged and they have no possibility of building the libraries (as they don't have the MinGw/Msys setup that Eric uses).

For those who need an isolated piece of libc which fix a problem (e.g. EEPROM on XMegas), it might be quite easy to use the relevant files as a "normal" source; this still provides valuable testing feedback for the avr-libc developers/maintainers.

There are also "standalone" binaries of avr-libc available here, although they appear to be slightly off sync... :-?

clawson wrote:
In Linux it's (fairly) easy for any user to cross compile the latest AVR-LibC as Linux is the natural build environment for GCC code.

So Linux users are either as up to date as

(a) their distro repository (if timid) or
(b) Bingo's latest build at www.wrightflyer.co.uk/avr-gcc/ (if a normal user) or
(c) Bingo's latest script (if bold) or
(d) the latest GIT/SVN/whatever-it-is pull from the AVR-LibC source repository an "home build" (if a complete bit junkie)


I don't know how far (c) is off "standard", but it appears that only (d) would constitue a "yes" in the poll.

JW

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

But taking your EEPROM example. The latest incarnation of eeprom.h (at least the one in the latest WinAVR ;-)) is no longer a standalone set of inline Asm macros but simply a call interface to routines in library .a/.o files. If I build:

#include  
#include 

int main(void) __attribute__((OS_main));
int main(void) {
	eeprom_write_byte((void *)3, 0x5A);
	while(1);
}

what I see in the .map file is:

 .text.avr-libc
                0x0000007a       0x1a c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5\libc.a(eewr_byte_atmega16.o)
                0x0000007c                __eewr_r18_m16
                0x0000007a                __eewr_byte_m16

So if I was a naive user who simply cherry picked a new eeprom.h from the latest AVR-LibC I'd be totally stuffed as I would not have copies of .../avr5/libc.a containing eewr_byte_atmega16.o

You have to take a whole AVR-LibC for it to be coherent and that includes a built set of .a/.o files (which a Windows user relies on Eric/Atmel for)

PS I built that same code for X128A1 and it says:

 .text.avr-libc
                0x00000242       0x46 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avrxmega7\libc.a(eewr_byte_atxmega128a1.o)
                0x00000242                __eewr_byte_x128a1
                0x00000244                __eewr_r18_x128a1

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

clawson wrote:
So if I was a naive user who simply cherry picked a new eeprom.h from the latest AVR-LibC I'd be totally stuffed as I would not have copies of .../avr5/libc.a containing eewr_byte_atmega16.o

Well, you have to be less naive user who won't believe everything is in the headers ;-)

I'd say it's often quite easy to follow what has changed and pick all needed files and adopt them for a non-library use; the eeprom example was maybe the worst possible example from the recent changes (okay I know it was I who brought it up).

Or, you can read the poll also as "Are you brave enough to go for the newest stuff on your own?"

JW

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

Quote:

I'd say it's often quite easy to follow what has changed and pick all needed files and adopt them for a non-library use; the eeprom example was maybe the worst possible example from the recent changes (okay I know it was I who brought it up).

Yes but how does a non-power-user know whether a particular kind of support is just .h based or a combination or .h and binary?

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

clawson wrote:
Quote:

I'd say it's often quite easy to follow what has changed and pick all needed files and adopt them for a non-library use; the eeprom example was maybe the worst possible example from the recent changes (okay I know it was I who brought it up).

Yes but how does a non-power-user know whether a particular kind of support is just .h based or a combination or .h and binary?
It's the same question as "How does a user know if he has THE power?"

Look, Cliff, I am not encouraging users to do that. I was asking a question, and Joe asked me to clarify the "criteria". If the Moderator Cliff thinks so, he might as well remove the poll (MereUser Jan simply cannot do that).

JW

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

Oh no, personally I'm quite interested in the poll but I fear it really is just a Windows vs Linux user poll (interesting enough in itself). I'm principally (for AVR use - because of Studio) a Windows user so I voted the Windows way.

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

reading through the post.

I and I think alot of people indeed are waiting for a next WinAVR release to be available and then install that. I run on windows.
Slowly I'm getting grip on C programming and for now ( and probably a long time in the future I hope) not to spend to much time on updating loose files and potentially killing parts that I do not yet understand and then keep me bussy while I could be doing more interesting stuff like getting my code to work.

regards

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

> There are also "standalone" binaries of avr-libc
> available here, although they appear to be slightly off sync...

I got the impression nobody uses these, so I didn't put much energy
into updating them with each new release lately. It's not too much
work doing this, so if people are interested in getting this
service continued, just drop me a note. (I'm building these on my
personal FreeBSD machine, but the libraries itself are supposed to be
completely independent of the build system so they should work as
a drop-in replacement on top of *any* older avr-libc. It's just there
is no fancy installer that keeps track of what it is about to install,
and about preserving older files for backing it out again.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:

but the libraries itself are supposed to be
completely independent of the build system

Don't make the mistake Eric did in WinAVR and forget to "avr-strip -g" the files then ;-) (or maybe they aren't built with -g in the first place?)

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

dl8dtl wrote:
> There are also "standalone" binaries of avr-libc
> available here, although they appear to be slightly off sync...

I got the impression nobody uses these,

I believe so; I've just listed the options.

JW

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

> Don't make the mistake Eric did in WinAVR and forget to "avr-strip -g" the files then

No worries: I've got a script, and it's even in SVN. Of course, it contains:

# Remove all debugging symbols so debuggers don't get confused about
# the different location of source files.
find . -name '*.[ao]' | xargs avr-strip -g

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

You guys crack me up with all the speculation that's going on here.

For the last several years, there has always been a sudden surge of work on avr-libc before an avr-libc release. There has always been (or at least almost always been) a new avr-libc release before a toolchain distribution release (such as WinAVR), AND the new avr-libc release has always been included in the toolchain distribution release. This is nothing new, or nothing very secret. I have always released WinAVR, on Windows obviously, and Joerg has always released the toolchain on FreeBSD. A long while ago we had another colleague (Ted Roth) who would also release it on Linux. Ted Roth has not been around for 6 years or so. Bingo has filled in the role on the Linux host by providing a build script and keeping it up to date, using the latest patches.

So in reality, if one is using the latest toolchain release (e.g. WinAVR), then they are using the latest avr-libc release as well. So the poll is really rather moot.

And, yes, there will be a replacement for WinAVR.

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

avr-libc version 1.7.0 is out now for almost two weeks, with no WinAVR equivalent so far.

This is the situation I talked about when trying to justify the poll.

JW

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

Jan,

You obviously missed the point made in the release notes of WinAVR20100110? He said that it would be the last ever release of WinAVR. There never will be another WinAVR so what is currently happening with AVR-LibC is irrelevant.

Those of us who like playing guessing games and who've also being reading about AVR Studio 5 believe this is because Atmel will make a release of an Eclipse based IDE with avr-gcc and avr32-gcc with whatever flavour of AVR-LibC is current at that time in the future (which, knowing Atmel could be 1 week, 1 month, 1 year, 1 decade, 1 century, or 1 millenium from now). This will be called "Studio 5" and will cover AVR(8) and AVR32. So that's where the "next" version of AVR-LibC is likely to appear but as for when - how long is a piece of string?

(OTOH it could be that AVR-LibC has stepped from 1.6.x to 1.7.x for the very reason that something is close to release?)

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

clawson wrote:
You obviously missed the point made in the release notes of WinAVR20100110? He said that it would be the last ever release of WinAVR.

This is why I used the wording "WinAVR equivalent" above.

I still naively hope Atmel won't force me (and others) to download and install gigabytes of thin s**t just to get the newest binaries of the compiler and suite (read this as a desperate appeal to those who might read this and be competent to decide it).

clawson wrote:
There never will be another WinAVR so what is currently happening with AVR-LibC is irrelevant.

Joerg was overtly pushed by EW to make this release (I am lazy to look up the exact forum posts), apparently in expectation to wrap it up into the next whatever-is-it-called.

Whatever - we are in the situation where the newest official avr-libc is ahead of what can be downloaded as a package with the compiler. I wonder how many brave man and woman out there are willing to go through the pains of testing it (the whole or as snippets - there is no binary release unfortunately) before the whole package happens.

JW

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

You want to get yourself a Linux machine! ;-)