RE: [avr-libc-dev] PROGMEM section variables throw away by--gc-sections?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dean
> Sent: Tuesday, November 13, 2007 5:59 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] PROGMEM section variables throw away 
> by--gc-sections?
> 
> Hi guys,
> 
> I've been noticing some strange behaviour with my makefile arguments.
> 
> Firstly, LD.exe crashes when I use -mshort-calls with the 
> --relax linker option, but *only* if I *don't* use 
> -ffunction-sections and --gc-sections. With the latter two 
> options enabled both -mshort-calls and --relax work just fine.

IIRC, this was discussed somewhat on Freaks, although you seem to have
found a new twist on the matter. ;-) Can you open up a binutils bug
report? Let me know what the bug number is.

 
> Secondly, -ffunction-sections and --gc-sections seems to 
> throw away some of my PROGMEM variables. I rely on a few 
> PROGMEM variables being embedded into the binary so I can 
> later distinguish which version it was compiled from, similar to:
> 
> char PROGMEM buildtime[] = __TIME__;
> 
> --gc-sections seems to remove this, although I thought it was 
> only designed to remove unused functions and not PROGMEM 
> data. Is there a workaround to this?
> 

Can you post a minimal test case? What versions of the tools are you
using?

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] PROGMEM section variables throw away by--gc-sections?

[Weddington, Eric]

 

> -Original Message-
> From: Dean [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, November 13, 2007 7:39 PM
> To: Weddington, Eric
> Subject: Re: [avr-libc-dev] PROGMEM section variables throw 
> away by--gc-sections?
> 
> Eric,
> 
> Additional - the linker crashes if --relax and -mshort-calls 
> is enabled, but 
> not --gc-sections. The -ffunction-sections doesn't have any 
> effect. Where 
> should I submit the bug? Is there a GCC-binutils specific 
> tracker somewhere?

Remember, GCC and GNU Binutils are separate projects. They have
different websites and bug trackers. Put "GNU Binutils" in Google and
hit the Lucky button. Find the link to the bug database. 

 
> As for the minimal test case, I'll have to work on it. It 
> only happens with 
> some of my projects, which all have -ffunction-sections, 
> --gc-sections 
> and --relax enabled. They were all rather complex, so I'll 
> see if I can get 
> it to happen with a smaller project.
> 

You'll need minimal test cases for entering bug reports.

Eric Weddington

PS: Try not to top-post, and don't forget to send your post the mailing
list too, not just to me. Thanks. :-)


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] PROGMEM section variables throw awayby --gc-sections?

[Weddington, Eric]

-Original Message-
From: [EMAIL PROTECTED] on behalf of Dean
Sent: Wed 2007-11-14 3:59 AM
To: Rolf Ebert
Cc: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] PROGMEM section variables throw awayby  
--gc-sections?
 
> --gc_sections removes all sections, that the linker thinks are unused. Did 
> you compile also with the -fdata-sections compiler switch?
>
> The assembler symbol of buildtime is not modified by -ffunction-sections, 
> only by -fdata-sections.
>
> I can also imagine a missing KEEP instruction in the linker script
>
> Rolf
>

Tested with -ffunction-sections and -fdata-sections, neither make any 
difference. Funny thing is, not all my PROGMEM data is being thrown away, 
only two unreferenced ones. I suppose the linker's technically justified in 
removing them, but is there a way to indicate that I want *all* PROGMEM 
variables preserved, no matter what? 

Come on, the linker is doing what you tell it to do. It's not psychic! Either 
don't use the -gc-sections switch, or use a custom linker script that uses the 
KEEP directive on the section. (See the ld manual for more information about 
this.)
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] New release?

[Weddington, Eric]

Hi All,

I'm interested in having a new release of avr-libc, sometime early next
week. I would be very interested in releasing 1.6.0.

Joerg, have you heard of any issues with the 1.5.1.20071029 release?

Dmitry, are you confident enough in your new math library work to
release it to the world? I know that you have done a lot of work on a
test suite.

I still have some changes to go into avr-libc that I will be working on
this week.

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, November 27, 2007 1:17 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] New release?
> 
> As Weddington, Eric wrote:
> 
> > I'm interested in having a new release of avr-libc, sometime early
> > next week. I would be very interested in releasing 1.6.0.
> 
> I'd like to have a look into the bugs and patches before.  Hopefully,
> will find some time by the weekend.

Sounds good. I'll be traveling all weekend until Sunday night.
 
Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 

> -Original Message-
> From: Anatoly Sokolov [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 28, 2007 9:16 AM
> To: Weddington, Eric; avr-libc-dev@nongnu.org
> Cc: Joerg Wunsch
> Subject: Re: [avr-libc-dev] New release?
> 
> Hi.
> 
> As Weddington, Eric wrote:
> > I'm interested in having a new release of avr-libc, 
> sometime early next
> > week. I would be very interested in releasing 1.6.0.
> 
> > I still have some changes to go into avr-libc that I will 
> be working on
> > this week.
> 
> I suggest to set up the minimal required version of GCC as 4.2.
> It will allow:
> A
> 1. To remove check of new devices which are already supported 
> in the GCC 4.2 
> from 'configure.ac' file.

Though leaving those checks in there does not do any harm.
 
> 2. To remove avr25 divices from 'AVR12_DEV_INFO' in 
> 'gen-avr-lib-tree.sh' 
> file, and do not build 'crt*' files for this devices twice.

That would be nice.

> 3. Do not define '__AVR_HAVE_MOVW__', '__AVR_HAVE_LPMX__' and 
> '__AVR_HAVE_MUL__' macros in avr-libc.

Are these macros used anywhere in avr-libc?

I saw that you updated the task about adding in an avr35 architecture.
FYI, I have patches that add another architecture. I do not want to
clash later when trying to commit those patches.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 


> > Simultaneously quality of a code concedes not only to
> > branches 3.3 and 3.4, but even concedes to a branch 4.1.
> > For example, Avr-libc's sscanf("1.2345","%e",&x) takes
> > 3886 bytes of flash and 140 bytes of stack with 4.2.2.
> > Above branch (4.1.2) uses only 3802 bytes of flash and
> > 128 bytes of stack.
> > 
> 
> This is a much more important issue.  I haven't tested 4.2 
> for the avr, 
> or done serious comparisons with older versions.  Is there anything 
> specific behind this problem?
> 

It's a bit late to be discussing these issues, or reworded: I wish that
discussions like this were done a lot earlier.

I'm planning on release WinAVR with GCC 4.2.2. The most major issue that
I see right now is GCC bug #29524

I would like to see a patch for this (even if it is not perfect but
works) sometime next week.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Thursday, November 29, 2007 8:24 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] New release?
> 
> Weddington, Eric wrote:
> 
> > I'm planning on release WinAVR with GCC 4.2.2. The most 
> major issue that
> > I see right now is GCC bug #29524
> > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524>
> > I would like to see a patch for this (even if it is not perfect but
> > works) sometime next week.
> > 
> 
> If that's the only sort of code quality issue remaining for 4.2, then 
> the picture is not nearly as bleak as Dmitry's post suggested.
> 

I can't say if that is the *only* issue. The bug list is here:
<http://www.nongnu.org/avr-libc/bugs.html>
But it is a major regression compared to 4.1.x.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 

> -Original Message-
> From: Wouter van Gulik [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 29, 2007 8:09 AM
> To: Weddington, Eric
> Cc: David Brown; avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] New release?
> 
> > It's a bit late to be discussing these issues, or reworded: 
> I wish that
> > discussions like this were done a lot earlier.
> > 
> > I'm planning on release WinAVR with GCC 4.2.2. The most 
> major issue that
> > I see right now is GCC bug #29524
> > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524>
> > I would like to see a patch for this (even if it is not perfect but
> > works) sometime next week.
> > 
> 
> I tried the code example in the bug report using -lm against 
> 4.2.2 and 
> it then is around 600 bytes
> Are you aware of this?

Meaning what?

I know that I tested the test case and confirmed that it adds 256 bytes
to RAM.
 
> I tried fixing this by implementing the __clzm in the 
> libgcc.s But I did 
> not succeed, because gcc would still use his own. This is probably 
> because i missed some config somewhere. But I could not find 
> documentation on using the library. Any pointers are well 
> come. I might 
> give it another try this weekend.

At this point, I would accept a patch that reverts the change back to
the 4.1.x code, while we wait to figure out the best solution that has a
reasonable chance to make it into the repository. I would then just
include that patch in the WinAVR release.

Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 

> -Original Message-
> From: Wouter van Gulik [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 29, 2007 8:25 AM
> To: Weddington, Eric
> Cc: David Brown; avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] New release?
> 
> > 
> > Meaning what?
> > 
> 
> Whoops. Let me be more clear on this. When compiling without 
> -lm you get 
> 3k+ bytes of program and 256+ bytes of ram used.
> 
> IIRC switching on -lm you get 600 bytes of flash and 0 bytes 
> of ram used...
> 
> > I know that I tested the test case and confirmed that it 
> adds 256 bytes
> > to RAM.
> >  
> 
> Yes nog using -lm indeed adds the 256 bytes

Oh, how interesting! So there may be a workaround? :-)

Can you add that bit of information to the bug report?
 
We usually tell users that if they are working with any floating point
then they should always use -lm, otherwise all bets are off.

Also, is there any way that you can confirm that this also works with
the CVS version of avr-libc? Or the 1.5.x version of avr-libc? Both
contain the new FP library.

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] RE: [avrdude-dev] avrdude GUI with Fuse Calculator

[Weddington, Eric]

 

> -Original Message-
> From: Shaun Jackman [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 29, 2007 1:06 PM
> To: Weddington, Eric
> Cc: [EMAIL PROTECTED]; avr-libc-dev@nongnu.org
> Subject: Re: [avrdude-dev] avrdude GUI with Fuse Calculator
> 
> On Nov 29, 2007 12:48 PM, Weddington, Eric 
> <[EMAIL PROTECTED]> wrote:
> ...
> > Note that a new API has been added to avr-libc that allows 
> the user to
> > set the fuses within an application, and these values will go into a
> > separate section within the resulting ELF file. To do this, 
> fuse data is
> > being added to each IO header file in avr-libc.
> 
> Each fuse bit is currently defined as an inverted mask. For example:
> #define BOOTRST ~_BV(0)  /* Select Reset Vector */
> I would prefer the flags be defined uninverted.
> EFUSE = ~(BOOTRST | BOOTSZ0 | BOOTSZ1);
> looks better to me than
> EFUSE = BOORST & BOOTSZ0 & BOOTSZ1;
> 
> This is a matter of preference though. I don't mean to start a
> painting-the-bikeshed argument. I just thought I'd take a quick poll.

Grrr. :-(
The API is already implemented and I'm trying to finish it up for the
next release of avr-libc/WinAVR/AVR Studio. We already had this
discussion.

Part of the reason that they are inverted is because the fuse itself is
inverted: logic 1 is unprogrammed, logic 0 is programmed.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] New release?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Thursday, November 29, 2007 11:52 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] New release?
> 
> On Friday 30 November 2007 01:30, Weddington, Eric wrote:
> [...]
> > > Yes nog using -lm indeed adds the 256 bytes
> >
> > Oh, how interesting! So there may be a workaround? :-)
> >
> > Can you add that bit of information to the bug report?
> >
> > We usually tell users that if they are working with any 
> floating point
> > then they should always use -lm, otherwise all bets are off.
> >
> > Also, is there any way that you can confirm that this also 
> works with
> > the CVS version of avr-libc? Or the 1.5.x version of avr-libc? Both
> > contain the new FP library.
> 
> Hi.
> 
> Has checked up with version 4.2.2. Addition of the '-lm'
> option reduces the size up to 770 bytes and eliminates an
> array in the RAM.  It is right: Avr-libc's conversion
> functions are used, not from libgcc. It is no matter, CVS
> or 1.4 branch.

This is great! :-)

It certainly reduces the importance of this bug. Also less to do for a
release.

Thank you for doing this Dmitry!

Eric Weddington
 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Problems with char */arrays

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Taj Morton
> Sent: Monday, December 10, 2007 3:08 PM
> To: Joerg Wunsch; avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Problems with char */arrays
> 
> On Dec 10, 2007 8:08 AM, Joerg Wunsch <[EMAIL PROTECTED]> wrote:
> > Hard to say without seeing all the commands you invoked.  My first
> > guess would be that you forgot to copy over the contents of 
> .data into
> > the ROM, e.g. you used an avr-objcopy command with -j .text 
> but forgot
> > to also include -j .data.  That way, the initializer data for
> > initialized variables will be missing, and all your initialized
> > variables will show up with 0xff in them (as that's the 
> pattern of the
> > uninitialized ROM).
> Compilation looks like this:
> avr-gcc -O -D__AVR_ATmega128__ -c gyro.c
> gcc -o gyro.elf gyro.o

Use "avr-gcc" to link, not "gcc".

As Rick Altherr said, use the -mmcu= switch on *both* your
compile command line and your linker command line.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] Fuse and Lockbit data and upcoming release

[Weddington, Eric]

Hi All,

Fuse and Lockbit data in various IO header files has now been committed,
to 1.4 branch and to HEAD. This was the last bit of stuff that I wanted
to get in before a release.

Dmitry, do you still have stuff you want to commit?

Joerg, are you comfortable with doing a 1.6.0 release?

Any other pressing issues?

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Fuse and Lockbit data and upcoming release

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Wednesday, December 12, 2007 12:15 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Fuse and Lockbit data and upcoming release
> 
> On Wednesday 12 December 2007 14:39, Weddington, Eric wrote:
> [...]
> > Dmitry, do you still have stuff you want to commit?
> 
> Yes, I have made all commits which wished to make
> before the stable release.
> 

Thanks!

I've now also fixed a few header bugs. AFAIK, I'm now done with all the
bugs I'm going to fix for this release.

Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Sunday, December 16, 2007 4:09 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> Hi.
> 
> Now in case of unforeseen interrupt the program is
> jumped to zero address. As a rule, such behaviour
> is bad, as it leads to restart program without
> restarting a MCU's hardware.
> 
> What about to perform 'reti' in case if the user
> does not define own __vector_default ?

That seems like a safe alternative. This has my vote.

Eric 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make abort() a normal function?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Sunday, December 16, 2007 3:58 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] What about to make abort() a normal function?
> 
> Hi.
> 
> Now the abort() is declared as inline function (which
> makes infinite loop). Such declaration does not give
> a possibility to the user to link the program with the
> own version of abort() function.
> 
> What about to declare the abort() as a normal extern
> function?  The library realization will as: load 1 to
> r24:r25 and jmp to exit().
> 

Sounds reasonable to me.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

 

> -Original Message-
> From: Marek Michalkiewicz [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, December 16, 2007 4:45 PM
> To: Weddington, Eric
> Cc: Dmitry K.; avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> 
> Not always safe - if interrupt is level triggered, and remains
> active, the main program will be interrupted again and again...
> This will make the main program run much slower (interrupt and
> "reti" after every instruction), but work fine otherwise - so
> it may be difficult to notice the bug (no handler defined for an
> enabled interrupt).  

Hi Marek!

Good points!

> An infinite loop might be even better than
> either "reti" or jump to zero (WDT will then do a proper reset).

Ok, that makes sense. It should make it easy to spot for the end-user.

Eric



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What (Binary) Tags?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, December 18, 2007 2:13 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What (Binary) Tags?
> 
> As Dean wrote:
> 
> > I propose a new macro, either:
> > 
> > =
> > #define PROGMEM_TAG PROGMEM __attribute__((used, 
> externally_visible))
> > =
> 
> > Or the what-tag standardised version:
> > 
> > =
> > #define BINARY_TAG(id, data) ...
> 
> Nice idea!  There are two (minor) things I don't like.  First,
> `binary' sounds misleading to me, as the contents actually are strings
> rather than binary data.  I'd probably call it ID_TAG instead.
> 
> The second thing, @(#) and "what" are remnants of an old and now
> completely obsolete revision control system named SCCS (source code
> control system).  I've got Linux systems that don't have a what(1)
> command at all.  These days, these lines would typically look like
> $Id$ instead (corresponding to the ident(1) command).  For that
> reason, I wouldn't want to hard-code the @(#) magic string but leave
> the setup of the string entirely to the user.
> 
> Once an agreement has been reached in the discussion, please file that
> as a patch tracker item so it won't get lost.  Please add a bit of
> doxygen blurb.  Even if you can't test it, it helps speeding up the
> patch integration later on (which I'm typically doing during release
> preparations).

I agree with Joerg on his comments.

One minor admin thing:
I would prefer that this go in 1.6.1, not in the release that we're
trying to get out now. I would rather that HEAD be frozen except for bug
fixes until 1.6.0 is released.

Thanks,
Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Monday, December 17, 2007 3:57 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> > > Not always safe - if interrupt is level triggered, and remains
> > > active, the main program will be interrupted again and again...
> > > This will make the main program run much slower (interrupt and
> > > "reti" after every instruction), but work fine otherwise - so
> > > it may be difficult to notice the bug (no handler defined for an
> > > enabled interrupt).
> 
> Marek, thanks for the weighty remark.
> 
> Nevertheless, I tend to a variant with returning. Why?
> In practice more often the mistake happens such: "no handler
> defined for an enabled interrupt". The situation when the user
> initiated interruptions which actually it in any way did not
> plan to use is improbable. (At least, by the moment of end
> of the project). Really, it can not notice delay of the
> program, but hardly incomplete functionality of system will be
> covered from its look. On the other hand, in this case the user
> can localize at once malfunction (a debugging output, LED...).
> While in a variant with cycling the user can say only:
> "My controller has died."

Before we go too much further in this discussion, I would like to
propose that this feature not be included in 1.6.0 as it is about to be
released. I would prefer that if anything comes from this, that it goes
in 1.6.1.

Regarding the discussion: First, is it an error to not have a handler
for an enabled interrupt? I would think yes.
Is there anyway for a tool to detect (via static analysis) that a
handler does not exist for an enabled interrupt? It would not be
impossible, but extremely difficult to do.
So, what can avr-libc provide, as a default, that would let the user
know at run-time that a handler does not exist for an enabled interrupt?
If the default is just to return, then I would agree that that does not
really let the user know of the error. It can get too easily lost. The
symptoms would just be reduced performance.
The current default, jump to zero, seems inadequate because of known
issues with doing this.
Marek's idea of going to an infinite loop seems reasonable because it
would be easily detectable by the user in almost any embedded system.
Would it be better to have the default call exit(1)? Does the default
implementation of exit go into an infinite loop?

Thanks,
Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, December 18, 2007 8:19 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> As Weddington, Eric wrote:
> 
> > Would it be better to have the default call exit(1)? Does 
> the default
> > implementation of exit go into an infinite loop?
> 
> It does, but I'd prefer calling (or jumping to) abort() instead.  It's
> also an infinite loop by default but it's the intended fault exit
> point.
> 
> I think both, exit() and abort() should disable interrupts before
> running into the loop.  Opinions on that?  If we agree, it would be a
> feature that either has to go into 1.6.0 still, or it will be delayed
> until 1.8.x because it's a non backwards-compatible change.

Agreed on all. Default handler jumps to abort, abort (and exit) disables
interrupts.
I'm ok with it going into 1.6.0, as long as it doesn't materially delay
the release.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, December 18, 2007 3:35 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> As Weddington, Eric wrote:
> 
> > Agreed on all. Default handler jumps to abort, abort (and exit)
> > disables interrupts.  I'm ok with it going into 1.6.0, as long as it
> > doesn't materially delay the release.
> 
> I won't touch the default handler right now.

Why not?
 
> abort() calls exit() now, so no change was needed.
> I added the CLI to exit(), and documented this as an incompatibility.

Thanks!

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [bug #1929] -Inf not detected

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Tuesday, December 18, 2007 3:43 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [bug #1929] -Inf not detected
> 
> On Wednesday 19 December 2007 07:38, Joerg Wunsch wrote:
> > Update of bug #1929 (project avr-libc):
> >
> >   Status:None => Fixed
> >  Assigned to:None => dmix
> >  Open/Closed:Open => Closed
> 
> Thanks.
> 
> In the summer of this year I have added the comment
> on correction, but have not dared to declare this bug
> closed as there was no realise with new fplib.
> 
> And a general question: what is the best method to
> do in this case: a bug is fixed only in CVS and there
> is no realise?  If a bug is declared as fixed it is
> removed from a view.

One suggestion:
Set Status to Fixed. Set Percent Complete to 100%. Leave Open/Closed as
Open. Add a Comment to say where the bug is fixed (e.g. CVS HEAD, future
version x.y).

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: [avr-libc-commit] avr-libc ChangeLoginclude/stdlib.h libc/stdlib...

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, December 19, 2007 6:17 AM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] Re: [avr-libc-commit] avr-libc 
> ChangeLoginclude/stdlib.h libc/stdlib...
> 
> As Dmitry Xmelkov wrote:
> 
> > Log message:
> > Add CLI to abort() and exit() functions, since GCC's 
> _exit() does not
> > disable interrupts today.
> 
> Umm, no, please don't.  If it's _exit()'s respsonsibility to do so,
> then let's leave it to libgcc.a instead.  That's why I completely
> backed out my nonsensical attempt from yesterday, and instead
> re-opened the bug.  There's no point in trying to plug libgcc's faults
> and omissions inside avr-libc.

Why not? We already do many workaround in avr-libc because of issues
with dealing with GCC, such as the long release cycles. If we get this
fix into AVR GCC, it might be available in 4.3.0, which could still be
2-3 months out. If we miss the window, it will have to be in 4.4, which
is certainly a lot longer.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: [avr-libc-commit] avr-libcChangeLoginclude/stdlib.h libc/stdlib...

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, December 19, 2007 7:19 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Re: [avr-libc-commit] 
> avr-libcChangeLoginclude/stdlib.h libc/stdlib...
> 
> As Weddington, Eric wrote:
> 
> > > ...  There's no point in trying to plug libgcc's faults
> > > and omissions inside avr-libc.
> 
> > Why not?
> 
> Because that bug is completely unimportant and purely cosmetical.
> Real embedded applications don't exit() anyway.  Mind you, we (at
> least you and me) have been shipping compiler/library combinations
> where returning from main() didn't jump to or call exit() at all, and
> people barely noticed it.
> 
> If you're really eager to fix it in the next WinAVR release, you could
> always pick up the libgcc.S patch from the bug tracker, and apply it
> to the compiler.
> 
> Also, there's no strong relationship between the compiler and library
> versions, so when is the correct time to remove the hack from libc
> again?  Once the major distributions picked up the libgcc patch?  Once
> a full release of GCC with the patch has been released?  But then,
> what about people still using older versions?
> 

Good points all. Ok. :-)

Eric 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Shaun Jackman
> Sent: Wednesday, December 19, 2007 12:00 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] Wishlist: place static bool in GPIO registers
> 
> The General Purpose I/O Registers (GPIOR0 through GIPOR3) are directly
> bit-accessible. It would be a very handy feature to be able to place a
> static bool (or any variable, I suppose) in the GPIO registers.
> 

Hi Shaun,

Could you be more specific? Anyone can use bitwise operators now to
achieve this. Do you have something different in mind?

Eric 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Stu Bell
> Sent: Wednesday, December 19, 2007 12:21 PM
> To: Shaun Jackman; avr-libc-dev@nongnu.org
> Subject: RE: [avr-libc-dev] Wishlist: place static bool in 
> GPIO registers
> 
> This was posted by Cliff Lawson on AVRFreaks.  I've modified it for
> GPIOR0.
> 
> 
> typedef struct
> {
>   unsigned char bit0:1;
>   unsigned char bit1:1;
>   unsigned char bit2:1;
>   unsigned char bit3:1;
>   unsigned char bit4:1;
>   unsigned char bit5:1;
>   unsigned char bit6:1;
>   unsigned char bit7:1;
> } BitRegisterType;
> 
> #ifndef true
> #define true 1
> #endif
> 
> #ifndef false
> #define false 0
> #
> 
> #define BIT_buffer_status((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit0
> #define BIT_recv_error   ((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit1
> #define BIT_active   ((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit2
> #define BIT_use_sample1  ((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit3
> 
> #define BIT_byte_count   ((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit4
> #define BIT_receive_132  ((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit5
> #define BIT_wait_uart_low((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit6
> #define BIT_RS232_calibrated ((volatile
> BitRegisterType*)_SFR_MEM_ADDR(GPIOR0))->bit7
> 
> 
> 
> 
> BIT_receive_132 = 1;
> BIT_recv_error = 0;
> if (BIT_buffer_status == 1) {}
> 

Thanks!

Note that "true" and "false" are already defined in  and any
implementation should use those definitions.

It would be great if someone could volunteer to help work up a full
implementation... ;-)

I know that nothing will be done with this until 1.6.0 is out and also
after the holidays.

Eric
 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, December 19, 2007 2:52 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] What about to make 'reti' as a 
> default behaviour?
> 
> As Weddington, Eric wrote:
> 
> > > I won't touch the default handler right now.
> > 
> > Why not?
> 
> After some thorough thinking about it, I decided to leave it alone
> right now.  After all, there has to be a reason to eventually roll a
> 1.8 release some day. ;-)
> 
> Random thoughts:
> 
> . Peter Danneggers suggestion to call (rather than jump to) the
>   default handler, and then pop the topmost two (or three for avr6)
>   bytes off the stack has some merit.  

I'm sorry, I must have missed this. Why does this have merit?


> Alas, *only* the default
>   handler can be called, all explicitly specified handlers (aka. ISRs)
>   still have to be jumped to.  Offhand, I don't have a real idea how
>   to accomplish this. 

Umm, yeah. It might get complicated quickly...


> There's a vague idea that it could perhaps be
>   had by using one weak entry point per vector, where the default
>   implementation can place a call into yet the _VECTOR() macro would
>   somehow replace that by a jump.  This, in turn, probably requires a
>   separate linker section for each vector. 

Ugh.



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Wednesday, December 19, 2007 6:38 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Re: 
> [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...
> 
> On Thursday 20 December 2007 00:53, Weddington, Eric wrote:
> > > Because that bug is completely unimportant and purely cosmetical.
> > > Real embedded applications don't exit() anyway.  Mind you, we (at
> > > least you and me) have been shipping compiler/library combinations
> > > where returning from main() didn't jump to or call exit() 
> at all, and
> > > people barely noticed it.
> [...]
> 
> I agree that bug is unimportant and cosmetical. For me it
> is no significance is CLI in abort/exit Avr-libc's functions,
> or is not.
> 
> But I have a few rationales against to keep GCC busy with CLI:
> 

I believe that there is enough rationale that it is worth doing the
change. In discussion with other colleagues, having a default interrupt
handler go to abort, and eventually an infinite loop with interrupts
disabled is a worthwhile method for detecting this application bug.

I think the question is now *where* to do the fix (avr-libc, gcc, which
function), and *when* to do the fix (now, or later [gcc 4.3.0, avr-libc
1.8.0]). Considering that I'm in desparate need to get a WinAVR release
out now, I would rather put this off to later.

But I definitely don't want to forget about this issue. I think that
this is an important enough change. Dmitry, would you be willing to add
a Task to the Task Tracker on avr-libc for this?

Thanks,
Eric



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re:[avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Wednesday, December 19, 2007 11:15 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] 
> Re:[avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...
> 
> On Thursday 20 December 2007 11:53, Weddington, Eric wrote:
> [...]
> > But I definitely don't want to forget about this issue. I think that
> > this is an important enough change. Dmitry, would you be 
> willing to add
> > a Task to the Task Tracker on avr-libc for this?
> 
> This bug (#21841) is open at present moment.
> Why is needed any task?
> 

The bug just describes adding cli to abort/exit. It doesn't talk about
changing the default interrupt handler, which is another important piece
to this topic. 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [bug #21862] File 'bench-libm.dox' does not exist indistribution

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry Xmelkov
> Sent: Thursday, December 20, 2007 9:43 PM
> To: Dmitry Xmelkov; avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] [bug #21862] File 'bench-libm.dox' 
> does not exist indistribution
> 
> 
> URL:
>   
> 
>  Summary: File 'bench-libm.dox' does not exist in
> distribution
>  Project: AVR C Runtime Library
> Submitted by: dmix
> Submitted on: Пятница 21.12.2007 at 04:42
> Category: Documentation
> Severity: 3 - Normal
> Priority: 5 - Normal
>   Item Group: Build system
>   Status: None
> Percent Complete: 0%
>  Assigned to: dmix
> Originator Email: 
>  Open/Closed: Open
>  Discussion Lock: Any
> 
> ___
> 
> Details:
> 
> Reason: 'bench-libm.dox' is not present in 'doc/api/Makefile.am'.

Hi Dmitry,

I found this issue too, when trying to build 1.6.0. I also notified Joerg of 
this. I'm sure it'll get fixed tomorrow.

Thanks,
Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [bug #21862] File 'bench-libm.dox' does not existindistribution

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Friday, December 21, 2007 3:29 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [bug #21862] File 
> 'bench-libm.dox' does not existindistribution
> 
> As Weddington, Eric wrote:
> 
> > I found this issue too, when trying to build 1.6.0. I also notified
> > Joerg of this. I'm sure it'll get fixed tomorrow.
> 
> I'll re-roll it as 1.6.1 then, and never announce 1.6.0.  Now that the
> 1.6.0 label is already in the bug report, it makes no sense to try
> sliding the tags.
> 

Hmm. I just released WinAVR with 1.6.0. I just included the missing
file. 

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] SPMEN, SELFPRGEN: name clash

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ivan Shmakov
> Sent: Saturday, December 29, 2007 11:43 AM
> To: avr-libc-dev@nongnu.org
> Cc: Ivan Shmakov
> Subject: [avr-libc-dev] SPMEN, SELFPRGEN: name clash
> 
> 
>   There's apparently a name clash between the SPMEN / SELFPRGEN
>   fuse bit and the eponymous bit of the SPMCSR register.
>   Consider, e. g.:
> 
> $ nl -ba include/avr/iotn13.h 
> ...
> 33/* avr/iotn13.h - definitions for ATtiny13 */

This is already recorded as bug #21869:


I'll be going through the IO headers to make sure other duplicates are
fixed before the next avr-libc release and before the next WinAVR
release in February.

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dean
> Sent: Sunday, December 30, 2007 5:24 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] avr-lib-c-extentions library
> 
> Joerg,
> 
> As requested, I'm following up your post on AVRFreaks 
> (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtop
> ic&p=392935#392935) about a possible companion library to 
> avr-lib-c, containing useful but out of scope for avr-lib-c functions.
> 
> What sort of contributions did you have in mind? Would the 
> "util" library code be moved over to the new library? How 
> would you imagine it structured?
> 
> I don't mind heading such a project, as I don't think it 
> would be too much trouble. I've got until the end of Feb 
> before Uni starts again, to get it all organised and moving.
> 

The link above to the AVR Freaks post does not work for me. Could you
double-check and repost?

I might have a thing or two to say about such a library...

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: SPMEN, SELFPRGEN: name clash

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ivan Shmakov
> Sent: Sunday, December 30, 2007 9:45 PM
> To: avr-libc-dev@nongnu.org
> Cc: Ivan Shmakov
> Subject: [avr-libc-dev] Re: SPMEN, SELFPRGEN: name clash
> 
> >>>>> "WE" == Weddington, Eric <[EMAIL PROTECTED]> writes:
> 
>  >> There's apparently a name clash between the SPMEN / SELFPRGEN fuse
>  >> bit and the eponymous bit of the SPMCSR register.  
> Consider, e. g.:
> 
>  >> $ nl -ba include/avr/iotn13.h 
>  >> ...
>  >> 33/* avr/iotn13.h - definitions for ATtiny13 */
> 
>  > This is already recorded as bug #21869:
>  > <https://savannah.nongnu.org/bugs/?21869>
> 
>   Thanks for the pointer.  (I haven't yet familiarized myself with
>   the bug tracker.)
> 
>  > I'll be going through the IO headers to make sure other duplicates
>  > are fixed before the next avr-libc release and before the 
> next WinAVR
>  > release in February.
> 
>   I'm primarily interested in what will be the solution to the
>   problem?  Would one of these be renamed, and which one, or both?
>   Once it will be decided, an appropriate patch will be a matter
>   of fifteen minutes.

The bit names for the registers have been around a long time. Those
would NOT be renamed. The fuse feature is new, so any renaming would be
done one those names.

For example, I would propose renaming the SELFPRGEN fuse definition to
SELFPRGEN_FUSE. And other duplicates renamed in a similar manner: add
the _FUSE suffix.

 
>   As to searching for duplicates, the following script seems to
>   find them (all?):
> 
> include $ (for f in avr/io?*.h ; do \
>cpp -I. -D__ASSEMBLER__ \
><(echo "#define _AVR_IO_H_" ; \
>  echo "#include \"${f}\"") > /dev/null ; \
>done) 2>&1
> In file included from /dev/fd/63:2:
> ./avr/io90pwm316.h:912:1: warning: "PSYNC1" redefined
> ./avr/io90pwm316.h:911:1: warning: this is the location of 
> the previous definition
> In file included from /dev/fd/63:2:
> ./avr/io90pwm3b.h:982:1: warning: "PSYNC1" redefined
> ./avr/io90pwm3b.h:981:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom1284p.h:950:1: warning: "UBRR0" redefined
> ./avr/iom1284p.h:947:1: warning: this is the location of the 
> previous definition
> ./avr/iom1284p.h:1005:1: warning: "UBRR1" redefined
> ./avr/iom1284p.h:951:1: warning: this is the location of the 
> previous definition
> ./avr/iom1284p.h:1009:1: warning: "UBRR1" redefined
> ./avr/iom1284p.h:1005:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom168.h:72:1: warning: "SELFPRGEN" redefined
> In file included from ./avr/iom168.h:36,
>  from /dev/fd/63:2:
> ./avr/iomx8.h:315:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom168p.h:746:1: warning: "UBRR0" redefined
> ./avr/iom168p.h:743:1: warning: this is the location of the 
> previous definition
> ./avr/iom168p.h:840:1: warning: "SELFPRGEN" redefined
> ./avr/iom168p.h:333:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom328p.h:747:1: warning: "UBRR0" redefined
> ./avr/iom328p.h:744:1: warning: this is the location of the 
> previous definition
> ./avr/iom328p.h:841:1: warning: "SELFPRGEN" redefined
> ./avr/iom328p.h:334:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom48p.h:744:1: warning: "UBRR0" redefined
> ./avr/iom48p.h:741:1: warning: this is the location of the 
> previous definition
> ./avr/iom48p.h:838:1: warning: "SELFPRGEN" redefined
> ./avr/iom48p.h:331:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom88.h:72:1: warning: "SELFPRGEN" redefined
> In file included from ./avr/iom88.h:36,
>  from /dev/fd/63:2:
> ./avr/iomx8.h:315:1: warning: this is the location of the 
> previous definition
> In file included from /dev/fd/63:2:
> ./avr/iom88p.h:746:1: warning: "UBRR0" redefined
> ./avr/iom88p.h:743:1: warning: this is the location of the 
> previous definition
> ./avr/iom88p.h:840:1: warning: "SELFPRGEN" redefined
> ./avr/iom88p.h:333:1: warni

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> > Joerg,
> > 
> > As requested, I'm following up your post on AVRFreaks 
> > (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtop
> > ic&p=392935#392935) about a possible companion library to 
> > avr-lib-c, containing useful but out of scope for avr-lib-c 
> functions.
> > 
> > What sort of contributions did you have in mind? Would the 
> > "util" library code be moved over to the new library? How 
> > would you imagine it structured?
> > 
> > I don't mind heading such a project, as I don't think it 
> > would be too much trouble. I've got until the end of Feb 
> > before Uni starts again, to get it all organised and moving.
> > 
> 
> The link above to the AVR Freaks post does not work for me. Could you
> double-check and repost?
> 

Ok, I think I found the Freaks thread. Is it this thread about malloc?:

(Down towards the bottom.)

Anyway,

There are plans to put together such a library, starting in 2008. Not so
much like Procyon AVRLib, but a library that contains drivers for AVR
on-board peripherals. I would suggest avoiding this area so you don't
conflict.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, January 02, 2008 2:13 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> As Weddington, Eric wrote:
> 
> > > Dean Camera wrote:
> 
> > > What sort of contributions did you have in mind? Would the
> > > "util" library code be moved over to the new library? How
> > > would you imagine it structured?
> 
> I really thought of things that are currently available in libraries
> like Procyon AVRlib.  Stuff from myself I'd consider candidate for
> inclusion in such a library contains:
> 
> . The LCD code from the stdiodemo example.  It's been living in my
>   private tree for a couple of years, and when I published it as part
>   of stdiodemo, I cleaned it up a good bit, and generalized it through
>   macros so it ought to be fairly easy adaptable for other hardware as
>   it is now.  It has been subsequently improved based on user
>   feedback.
> 
> . The one-shot timer code from:
> 
>   http://www.sax.de/~joerg/avr-timer/
> 

This is definitely good stuff to have in such a library. And it doesn't
conflict with future internal projects that I'll be doing.


> . same license as avr-libc to improve re-usability in closed source
>   projects (that's the major distinction from Procyon AVRlib)

I'm open to having the LGPL license on such a library project.
(Definitely not the GPL, though.) I can be persuaded to either the BSD
or LGPL license.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, January 02, 2008 3:00 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> As Rich Teer wrote:
> 
> > There's another (I'd argue, better) alternative: the CDDL.
> > Certianly worth evaluating...
> 
> Can you elaborate on "better"?

> . much more license text to worry about than the relatively simple
>   BSD license

This one bothers me the most. From a first glance, the CDDL contains a
lot of legalese. Almost need a lawyer to interpret. Constrast that with
the BSD license which is simpler and more straightforward for
non-lawyers to understand.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] SPMEN vs SELFPRGEN

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ivan Shmakov
> Sent: Thursday, January 03, 2008 9:36 AM
> To: avr-libc-dev@nongnu.org
> Cc: Ivan Shmakov
> Subject: [avr-libc-dev] SPMEN vs SELFPRGEN
> 
> > Ivan Shmakov <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
>  > BTW, since SPMEN seems to be frequent alias to SELFPRGEN, 
> why not to
>  > define one of them in a common file (`io.h'?) instead of defining
>  > both in each of the part-specific headers (where 
> applicable)?  E. g.:

In the future, the IO header files will be generated from the XML part
files from Atmel, requiring a 1-to-1 relationship of XML->IO header
file. It would be difficult to do this if common definitions are put in
separate files.
 

>   Since `SPMEN' seems to be used more widely in the AVR Libc
>   includes as the name for the bit, I suggest replacing
>   `SELFPRGEN' with `SPMEN' in the macro definitions in the
>   individual io*.h files, like the following.  (Though it could
>   easily done the other way around.)
> 

Our policy is to provide definitions that are found in the XML part
description files provided by Atmel.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Thursday, January 03, 2008 1:30 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> Weddington, Eric wrote:
> 
> >> . same license as avr-libc to improve re-usability in closed source
> >>   projects (that's the major distinction from Procyon AVRlib)
> > 
> > I'm open to having the LGPL license on such a library project.
> > (Definitely not the GPL, though.) I can be persuaded to 
> either the BSD
> > or LGPL license.
> > 
> > Eric
> > 
> 
> I'm not a lawyer, but I have seen a couple of open source embedded 
> projects get themselves into trouble by misunderstanding 
> licenses (the 
> LGPL in particular).
> 
> The LGPL is no good for embedded development - it only really differs 
> from the GPL in that you can dynamically link to a LGPL'ed library 
> without any restrictions on the license for the rest of your 
> code.  If 
> you are linking statically, you must GPL (or LGPL) all your code.

You're going to have to back up your claims on this one. I have never
seen, nor heard of such a limitation.

FYI, the libgcc library that ships with GCC, and many times gets linked
into your AVR application, is licensed as LGPL.
 
Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: SPMEN vs SELFPRGEN

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ivan Shmakov
> Sent: Thursday, January 03, 2008 11:00 AM
> To: avr-libc-dev@nongnu.org
> Cc: Ivan Shmakov
> Subject: [avr-libc-dev] Re: SPMEN vs SELFPRGEN
> 
>   BTW, is there any way to get these XML files (other than
>   downloading AVR Studio)?

For most people, unfortunately, no. AVR Studio is the way to get them.

I, and Joerg Wunsch, will have early access to the XML files for new
devices.
 
>   Does the name vary in the part description files themselves?

Unfortunately, it does.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Thursday, January 03, 2008 12:12 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> > FYI, the libgcc library that ships with GCC, and many times gets
> > linked into your AVR application, is licensed as LGPL.
> 
> No, it's plain GPL but since somehow they noticed that the full
> emforcement of the GPL rules for a library like that one would drive
> many people away from using GCC, they added a special clause that
> waives the requirement of giving away your own source code for just
> linking against it.  The GPL requirements only apply if you modify the
> libgcc code itself.  So in essence, it's probably largely the same as
> with the CDDL.

Thanks for the reminder; you're right it's GPL+exception. Then I would
be OK with a library having such a license.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Thursday, January 03, 2008 12:42 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> As Weddington, Eric wrote:
> 
> > Thanks for the reminder; you're right it's GPL+exception. Then I
> > would be OK with a library having such a license.
> 
> I find it quite complicated, compared to the plain old BSD-style
> license we've been using for avr-libc for years now.  Is there any
> specific reason you want it, are you unhappy that anyone could get
> along with changing it but not feeding back his changes?
> 

No, as I mentioned before, I'm ok with either BSD or GPL+exception.
Personally I have no preference between the two. I just want to make
sure that:
1. the license is easy to understand (or the ramifications are easy to
understand)
2. the code can be used in a commercial device without having to divulge
the proprietary parts.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: SPMEN vs SELFPRGEN

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Thursday, January 03, 2008 2:03 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Re: SPMEN vs SELFPRGEN
> 
> As Weddington, Eric wrote:
> 
> > >   BTW, is there any way to get these XML files (other than
> > >   downloading AVR Studio)?
> 
> > For most people, unfortunately, no. AVR Studio is the way to get
> > them.
> 
> Minor correction: I think they are also part of the "AVR command-line
> tools" which are distributed (IIRC from the Norwegian beta site)
> separately.  

Sure. That's a relatively new package.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [RFC] Fixing fuse definitions

[Weddington, Eric]

Hi All,

Problem: It seems that some of the new fuse definitions in various IO
header files conflicts with some bit definitions in the same file. This
is for avr-libc 1.6.x. There are 2 bug reports about this, and also
special thanks to Ivan Shmakov for finding out the rest of the name
conflicts in the IO header files.

Potential Solution: After talking to Joerg about this, we're proposing
to change *all* of the fuse definitions in *all* of the IO header files
(where fuse definitions exist, which is most of them) to add a prefix of
FUSE_ to the names. Obviously, this breaks any backwards compatibility.
However, this is for a feature that only *just* released, so it's not
like there is widespread use of this feature. We feel that adding this
prefix will group the fuse definitions better, making it easier to spot
in application code, and also give it's own namespace, so to speak,
which would remove any potential conflict with bit names. No bit names
will be changed, as they have been around a long time.

For users of WinAVR, I have been planning on doing another release in
February (early to mid) anyway, and these new changes would definitely
be incorporated in a new avr-libc release by then and included in that
WinAVR release.

Are there any overwhelming objections? If not, I will be working on
fixing this and committing this soon.

Sorry for any inconvenience.

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] Fixing fuse definitions

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Weddington, Eric
> Sent: Thursday, January 03, 2008 6:52 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] [RFC] Fixing fuse definitions
> 
> Hi All,
> 
> Problem: It seems that some of the new fuse definitions in various IO
> header files conflicts with some bit definitions in the same 
> file. This
> is for avr-libc 1.6.x. There are 2 bug reports about this, and also
> special thanks to Ivan Shmakov for finding out the rest of the name
> conflicts in the IO header files.
> 
> Potential Solution: After talking to Joerg about this, we're proposing
> to change *all* of the fuse definitions in *all* of the IO 
> header files
> (where fuse definitions exist, which is most of them) to add 
> a prefix of
> FUSE_ to the names. Obviously, this breaks any backwards 
> compatibility.
> However, this is for a feature that only *just* released, so it's not
> like there is widespread use of this feature. We feel that adding this
> prefix will group the fuse definitions better, making it 
> easier to spot
> in application code, and also give it's own namespace, so to speak,
> which would remove any potential conflict with bit names. No bit names
> will be changed, as they have been around a long time.
> 
> For users of WinAVR, I have been planning on doing another release in
> February (early to mid) anyway, and these new changes would definitely
> be incorporated in a new avr-libc release by then and included in that
> WinAVR release.
> 
> Are there any overwhelming objections? If not, I will be working on
> fixing this and committing this soon.

Now committed.

Eric Weddington 
 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-lib-c-extentions library

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Bourgeois
> Sent: Monday, January 07, 2008 9:33 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-lib-c-extentions library
> 
> Hi folks,
> 
> On Wed, 02 Jan 2008 22:12:37 +0100, Joerg Wunsch <[EMAIL PROTECTED]>
> wrote:
> 
> > My major criteria for inclusion would be:
> >
> > . general usability (i.e. covers at least a good number of 
> AVRs if not
> >   all of them)
> >
> > . same license as avr-libc to improve re-usability in closed source
> >   projects (that's the major distinction from Procyon AVRlib)
> >
> > . only include contributions where it is ensured that we (i.e. the
> >   current or perhaps future avr-libc developers) are really able to
> >   actively maintain it with the same dedication as avr-libc is being
> >   maintained
> >
> 
> I also thought about such a library some time ago and I'm 
> very happy such
> a project will get started. I may also consider a couple 
> stuff I'd be glad
> to share:
> 
> - a circular buffer (I spent quite some time on this one to 
> get it clean
> and optimized.)

I also have a ring buffer implementation that's been tested.
 
> - an I2C library (I made one inspired from Procyon AVRlib but want to
> rebuild a new one based on this:
> http://www.embedded.com/columns/technicalinsights/186500781?_r
> equestid=455589
> )

I would be interested in an I2C/TWI library.
 
> - maybe a MCP2515 driver.
> 
> A couple of questions/thoughts are emerging:
> 
> - What quality level should we achieve in order for you to consider
> inclusion?

Here are some random thoughts:
- Code tested on real hardware.
- Unit tests for any API.
- Clear documentation (as you mentioned below, I lean towards doxygen)
including any/all limitations with the library.
- For any on-board peripheral driver, it should be designed with
thoughts of having it work across most/all AVR devices (where the
peripheral exists). I'm certainly ok if it's not yet tested/ported to
all AVR devices, but it should be flexible enough to do this sometime in
the future.
- Code examples

All of the above, I would think, should be pretty obvious.
 
> - Shouldn't you have, like for linux distributions, 
> maintainers for each
> package. This way there's at least one person to look at the 
> bug reports
> and apply patches.

I would certainly hope for that, but if we're basing this library on
volunteers, then we're dependent on volunteers to do the continual
maintenance. I can guarantee that I am interested in heading up and some
maintenance of such a project because of my capacity as a Product
Manager in the AVR Tools Group of Atmel. I will also be looking into
additional resources in the near future.
 
> - There should be some code guidelines in order to have consistency
> throughout the library. Avr-libc is usually a good source of 
> inspiration
> for me. 

Then let it be the same style guidelines as avr-libc.

> Beside style guidelines, some pointers to what you 
> consider good
> practice would maybe be interesting (modular programming, use 
> of const,
> static, extern, what should be in the interface). 

If the project is a library, then take a look at the avr-libc user
manaual on how to build a library:

It talks a little about how to organize one.

> - There should be some documentation with the modules. I hope Doxygen
> would behave better with such a library than it does with avr-libc,
> otherwise is there any better alternative?

I don't know of a better alternative. I would prefer the "devil we
know", and stick with doxygen.
 
> - I think it would also be important to have an example of 
> how to use the
> library. 

Agreed. It's essential.

> I still didn't look at it but can't we reuse the 
> test framework
> already in avr-libc? Regression tests usually serve as good 
> examples of
> how to use the code, and of course check for regressions. But 
> I still have
> no idea how to do such tests with modules that depend on hardware.

Pick a standard (hardware) platform that the tests should run on. I
would lean towards using the new STK600 platform (it should be able to
handle newer devices). Specify in the test documentation any special
wiring needed to run certain tests. The more automated the better. 
 
> - Shouldn't there be an official library which is considered 
> stable and
> meet the requirements, and a kind of playground section or playground
> library where more people could contribute. When a module is 
> considered
> good, it can be moved to the official library. It's always 
> better if the
> community has a way to easily bring small contributions. 

Good idea. Yes, something like that should be incorporated.

> - On the other
> hand, there's already AVRFreaks.

Projects have a tendence to get a little lost. They're working on
overhauling their projects system.
 
> - I guess there will be a new ML for that.

Ev

[avr-libc-dev] Committed: Add missing EEAR word registers.

[Weddington, Eric]

Hi All,

In working on a new eeprom implementation, I found a couple of bugs. I
just committed a fix to the io90pwm2b.h and io90pwm3b.h IO header files
that adds a missing EEAR word-size register.

Thanks,
Eric Weddington



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

Hi All,

Because of an avr-libc bug (#21410), a GCC bug (#31644), and IIRC, the
fact that the EEPROM API does not work on at least 2 AVR devices, I have
taken a stab at rewriting the EEPROM API. The interface has been kept
the same, but instead of library functions, it has been rewritten as
macros generating inlined assembly.

Yes, there is the potential that the macro version could take up more
code space with more calls to the macro. However, it is imperative that
this API work on *all* AVRs (that have EEPROM) and to have it work on
future AVR devices as well. I would rather have it work correctly first,
optimize later. Since we do not have a true multi-lib environment (per
device), implementing it as macros is the only way we have right now to
handle differences with multiple devices.

I have done compile tests, however, I have not tried this out on actual
hardware yet. I thought I would get this out to everyone a bit early for
feedback. Over the next day or two, I will be testing this on some real
hardware (probably an ATmega128).

Thanks,
Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Wednesday, January 16, 2008 3:57 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> In general, I agree with you - static inline functions are often 
> preferable to macros, and are underused by many people.  They 
> are type 
> safe, can easily have local variables and multiple statements without 
> horrible "do {} while (0);" constructs, don't need line continuation 
> characters, and so on.  However, there are other things you 
> can do with 
> macros, that can't be done with inline functions.  I don't 
> know what the 
> new API will look like, but there might be something like this:

It's not a new API, per se, in that the interface remains the same. It's
just a new implementation to fix bugs and problems with the current
implementation.
 
> 
> Anyway, judging from the predominance of static inline 
> functions (often 
> with the ((always_inline)) attribute), I reckon that Eric will use 
> static inlines where possible!

- The way they are written now, the do{...}while(0) construct is not
needed and not used.
- The way they are written now, they have local (to a block level)
variables.
- Who cares if it has line continuation characters or not? The user
won't seem them.
- Yes, they are type safe. But the macros ensure that parameters are
typecast to the types needed.
- These types of inline assembly macros are used elsewhere in avr-libc,
notably , , and IIRC . Do you
propose to change all of this? Do you propose to do the work required?

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Wednesday, January 16, 2008 10:01 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Weddington, Eric wrote:
> >  
> > 
> No, no - I think you misunderstood my post.  I was responding 
> to Anton's 
> suggestion of using more static inline functions instead of macros by 
> saying that while static inlines have a lot of benefits, sometimes 
> macros are the right choice - and that avrlibc already uses static 
> inlines where it makes sense.
> 

I was giving this some further thought, and static inline functions
wouldn't work for avr-libc. Avr-libc is a library of object modules.
Having static inline functions requires a compilation step. Two things:

- The inline portion wouldn't work because we now have object code, and
the linking stage (AFAIK) doesn't do inlining.
- One big reason to move away from compiling code to macros, is that we
do *not* have a true multi-lib (per device) environment with avr-libc.
We need to be able to have different variants of code for different
devices (not just per architecture). Right now, the only way for us to
do this *is* with macros in a header file.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Michael Hennebry [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 16, 2008 10:24 AM
> To: Weddington, Eric
> Cc: David Brown; avr-libc-dev@nongnu.org
> Subject: RE: [avr-libc-dev] [RFC] New eeprom.h
> 
> On Wed, 16 Jan 2008, Weddington, Eric wrote:
> 
> > - One big reason to move away from compiling code to 
> macros, is that we
> > do *not* have a true multi-lib (per device) environment 
> with avr-libc.
> > We need to be able to have different variants of code for different
> > devices (not just per architecture). Right now, the only 
> way for us to
> > do this *is* with macros in a header file.
> 
> Additionally, someone who does want a function can write one 
> rather easily.

Very true. :-) 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] -mint8 compatible task

[Weddington, Eric]

Hi All,

We've had a task in the list to make avr-libc -mint8 compatible:


Is this still desired?

For my part, I would rather kill this task, and spend time on making GCC
optimal for the AVR target, even if it takes more time in the long run.

Thoughts?

Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Wednesday, January 16, 2008 12:34 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Weddington, Eric wrote:
> >  
> > 
> >> -Original Message-
> >> From: 
> >> [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED]
> >> org] On Behalf Of David Brown
> >> Sent: Wednesday, January 16, 2008 10:01 AM
> >> To: avr-libc-dev@nongnu.org
> >> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> >>
> >> Weddington, Eric wrote:
> >>>  
> >>>

> The current eeprom.h file from the latest winavr package uses static 
> inline functions in exactly this way, unless I'm really 
> getting things 
> mixed up.

Point.

Personally, I've just never been fond of the idea of putting function
definitions in header files.

 
> > - The inline portion wouldn't work because we now have 
> object code, and
> > the linking stage (AFAIK) doesn't do inlining.
> 
> It does not *yet* do inlining in this way.

But I have to deal with today, not the future.


> Is a multi-lib avrlibc something that is being considered?  I can see 
> that there would be definite advantages, but I can also see 
> it being a 
> lot more work.

We have a task in the project Task List for it, but as you said, it's a
lot more work and no one has had the time or inclination to tackle it.

Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Rick Altherr [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 16, 2008 2:41 PM
> To: Weddington, Eric
> Cc: David Brown; 
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Or inline functions defined in a header file.
> 

Sheesh. You guys are making comments about *how* I implemented the
functionality, not if it *actually works*.

Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Rick Altherr [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 16, 2008 3:49 PM
> To: Weddington, Eric
> Cc: David Brown; 
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> I'd test it, but my ski vacation didn't include an electronics test  
> bench.  :-)
> 

LOL!

Where are you skiing? Anywhere near Colorado? ;-)

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: C++ Interrupts

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ron Kreymborg
> Sent: Sunday, January 20, 2008 4:26 AM
> To: 'Dean Camera'; avr-libc-dev@nongnu.org
> Subject: RE: [avr-libc-dev] Re: C++ Interrupts
> 
> > which was another line of thought for me. My solution:
> > 
> >  #define CLASS_ISR(vector, ...) { vector(); } ISR(vector, 
> __VA_ARGS__)
> > 
> > That can be applied to any member function in the C file, 
> of any name.
> 
> Thanks Dean. This looks like it solves all my problems. In 
> fact it can be
> even more concise:
> 
> #define CLASS_ISR(vector, ...) {} ISR(vector)
> 

If this solution works for you, it would be nice if one of you could
write up something for the avr-libc user manual to let other people know
how to do this.

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Re: C++ Interrupts

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Sunday, January 20, 2008 12:29 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Re: C++ Interrupts
> 
> As Dean Camera wrote:
> 
> > My solution:
> > 
> > #define CLASS_ISR(vector, ...) { vector(); } 
> ISR(vector, __VA_ARGS__)
> 
> Thanks!
> 
> > Which means you can name the function anything, and it should be
> > accessible as a normal function, but also link in as an ISR. As I
> > can't seem to get the intermixed assembly listing, I can't see how
> > effective it is, but it should allow you to call the ISR by the
> > member function name you give it, with either no penalty at all (if
> > the optimizer inlines it) or a small penalty of a JUMP instruction.
> 
> Btw., I remember that Marek once mentioned an idea how the entire
> interrupt vector setup could be changed so arbitrarily named interrupt
> vectors are possible.  However, I cannot find his idea at a quick
> glance in my archive of avr-libc-dev, so I guess it has been discussed
> in avr-gcc-list by its time (which I do not archive personally).  I
> just remembered that idea when Ron asked that question in
> avrfreaks.net because I think it will also provide a solution.
> 

Perhaps Marek could comment?

Eric W.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] A possible workaround to bug #21872

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Tuesday, January 22, 2008 4:03 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] A possible workaround to bug #21872
> 
> Hi.
> 
> Avr-libc bug #21872: __floatunsisf/undisf incorrectly named
> 
> This bug is fixed at the end of 2007 in HEAD and 1.6
> branches.
> 
> (Remember: It enlarges the program size approx. by 1kB. The
> reason is incorrect name of function unsigned_long_to_float
> conversion. So the libgcc's variant is used: large if flash
> and RAM.  This bug is actual with new compiler - 4.2 - for
> all Avr-libc branches, including 1.4, 1.2 and so on.)
> 
> This is actually to users who are not happy to load
> a corrected CVS Avr-libc version.
> 
> The possible workaround is to add the needed function
> manualy like:
> 
>extern float __floatunssisf (unsigned long u);
>float __floatunsisf (unsigned long u)
>{
>  return __floatunssisf (u);
>}
> 
> This is not the best method. This is the simplest
> to understand.

I would also like to do a new release of WinAVR in late February (next
month). At that time, I hope that we can release avr-libc 1.6.2, and
hopefully correct any issues like this.

Eric W. 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Wouter van Gulik [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, January 27, 2008 2:00 PM
> To: Weddington, Eric; 'Rick Altherr'
> Cc: avr-libc-dev@nongnu.org
> Subject: RE: [avr-libc-dev] [RFC] New eeprom.h
> 
> 
> > > Or inline functions defined in a header file.
> > >
> > 
> > Sheesh. You guys are making comments about *how* I implemented the
> > functionality, not if it *actually works*.
> > 
> 
> Well I would, if I knew where to get the sources... There not 
> on the list,
> not in the avr-libc bug report. So where can I find them?
> 

They were in my original email to the list.

Since then, I have started testing on real hardward. The read/write byte
macros seem to work find. I've found, and fixed, a bug with the
read/write word macros. There are problems with the read/write block
macros that I haven't chased down yet.

Attached is my latest source.

Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Preston Wilson [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, January 27, 2008 7:58 PM
> To: Weddington, Eric
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> > Attached is my latest source.
> 
> I did not receive any attached source in any of the email in 
> this thread
> including this last email from you. 

Thanks for letting me know.

Trying again. Let me know if it's not attached this time.

Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Preston Wilson
> Sent: Monday, January 28, 2008 6:24 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h

> That is the problem. I received the attachment this time (I 
> was directly
> addressed), and eeprom.h is attached with type 
> "application/octet-stream".
> 

Bah! Trying again.

Thanks for everyone's patience.

Eric Weddington


begin 666 eeprom.h
[EMAIL PROTECTED]>7)I9VAT("AC*2 R,# W($%T;65L($-O7)I9VAT"B @(" @;F]T:6-E+"!T:&ES(&QI$9&*0H*(" @("-U;F1E9B!%
M1412"B @(" C9&5F:6YE($5%1%(@7U-&4E])[EMAIL PROTECTED](#X^([EMAIL PROTECTED]("8@
M,'A&1B I"@H@(" @(W5N9&5F($5%05(*(" @("-D969I;[EMAIL PROTECTED]
M7TE/."A(15A.4B F(#!X1D8I"@H@(" @(W5N9&5F($5%05)("@H@(" @(W5N
M9&5F($5%05),"B @(" C9&5F:6YE($5%05),($5%05(*"B-E;[EMAIL PROTECTED]"B\J
M*B!<9&5F(&5E<')O;5]I0H@(" @7&EN9W)O=7 @879R7V5E<')O
M;0H@(" @7')E='5R;G,@,2!I9B!%15!23TT@:7,@71E7V%D9')E71E*2!<"B @(" I.R!<"B @("!?7W)E<[EMAIL PROTECTED] I]*2D*"@HC
M:[EMAIL PROTECTED])%3D0@/B P>$9&"@HC9&5F:6YE(%]?965P'1E;G-I;VY?7RA[(%P*(" @(&1O
M>WUW:&[EMAIL PROTECTED]71E7V%D9')E
M'1E;G-I;VY?7RA[(%P*(" @
M(&1O>WUW:&[EMAIL PROTECTED]71E([EMAIL PROTECTED]'5I;G0X7W0I*&%D9'(I.R!<"B @("!?7V%S
M;5]?(%]?=F]L871I;&5?7R!<"B @(" H(%P*(" @(" @(" B;W5T("4P+" E
M-EQN7'0B(%P*(" @(" @(" B;W5T("4Q+" E-UQN7'0B(%P*(" @(" @(" B
M:[EMAIL PROTECTED];7!?'1E;G-I;VY?7RA[(%P*(" @
M(&1O>WUW:&[EMAIL PROTECTED]71E([EMAIL PROTECTED]'5I;G0X7W0I*&%D9'(I.R!<"B @("!?7V%S
M;5]?(%]?=F]L871I;&5?7R!<"B @(" H(%P*(" @(" @(" B;W5T("4P+" E
M-EQN7'0B(%P*(" @(" @(" B;W5T("4Q+" E03=<;EQT(B!<"B @(" @(" @
M(FEN(%]?=&UP7W)E9U]?+" E,UQN7'0B(%P*(" @(" @(" B8VQI7&Y<="(@
M7 H@(" @(" @(")S8FD@)3(L("4T7&Y<="(@7 H@(" @(" @(")S8FD@)3(L
M("4U7&Y<="(@7 H@(" @(" @(")O=70@)3,L(%]?=&UP7W)E9U]?7&Y<="(@
M7 H@(" @(" @([EMAIL PROTECTED] H@(" @(" @([EMAIL PROTECTED] H@(" @(" @(" 
@(FDB("A?4T92
M7TE/7T%$1%([EMAIL PROTECTED] H@(" @(" @(" @(FDB("A?4T927TE/7T%$
M1%(H145$4BDI+"!<"B @(" @(" @(" B:2(@*%]31E)?24]?041$4BA%14-2
M*2DL(%P*(" @(" @(" @(")I(B H7U-&4E])3U]!1$12*%-214<[EMAIL PROTECTED] H@
M(" @(" @(" @(FDB("A%14U712DL(%P*(" @(" @(" @(")I(B H145712DL
M(%P*(" @(" @(" @(")R(B H7U]A9&1R97-S7V)Y=&4I+"!<"B @(" @(" @
M(" B[EMAIL PROTECTED]@7 H@(" @7U]A[EMAIL PROTECTED] H@(" @(" @(" @(G(B("@H=6EN=#$V
M7W0I=F%L=64I(%P*(" @(" @(" Z(")R,"(@7 H@(" @[EMAIL PROTECTED] I]*2D*"@HC
M:[EMAIL PROTECTED])%3D0@/B P>$9&"@HC9&5F:6YE(%]?965P[EMAIL PROTECTED]@7 H@(" @7U]A$9&"B-D969I;[EMAIL PROTECTED]71E*&%D9'(I
M"B-D969I;[EMAIL PROTECTED]71E7V%D9')E71E*&%D9'(L('9A;'5E*0HC96QS90HC
M9&5F:6YE(&5E<')O;5]R96%D7V)Y=&4H861D71E7V%D9')E71E*&%D9'(L('9A;'5E*2 @7U]E97!R;VU?=W)I=&5?8GET
M95]A9&1R97-S7W=OR!<"B @("!U
M;FEO;B!<"B @("![(%P*(" @(" @("!U:6YT,39?="!W;W)D.R!<"B @(" @
M(" @71E
M.R!<"B @("!](%]?71E*%]?965P
MR!<"B @("!U:6YT,39?="!?7V-O=6YT
M([EMAIL PROTECTED]&XI.R!<"B @("!U:6YT,39?="!?7V4@/2 H=6EN=#$V7W0I*'!O:6YT
M97)?965P<[EMAIL PROTECTED] H@(" @=6EN=#A?=" J7U]R([EMAIL PROTECTED]'5I;[EMAIL 
PROTECTED]
M<&]I;G1E'1E;G-I;VY?
M7RA[(%P*(" @('5I;G0Q-E]T(%]?8V]U;G0@/2 H;BD[(%P*(" @('5I;G0Q
M-E]T(%]?92 ]("AU:6YT,39?="DH<&]I;G1ER!<"B @(" @(" @965Phttp://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Wouter van Gulik [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 29, 2008 12:23 PM
> To: Weddington, Eric
> Cc: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> So I got the header and my first consideration in is the copyright... 
> All previous contributers are now gone? I hope this is WorkInProgress.

Mainly because this is a total rewrite of the implementation. The API
(interface) stays the same. I'm certainly fine with putting the old
copyrights back on.


> Second why all these hideous define with there nasty \ ?

Because these are multi-line macros. The whole point of the
reimplementation of the EEPROM API is to get rid of the compiled code
(per architecture) and implement it in a way that is only in the header
file which can be targeted per device. Macros are just one way to do it.
Someone suggested implementing it as inlined C functions in the header
file. I chose the macros method of implementing as we have done that in
other headers.

 
> For eeprom read an inline function I came up with this (for 
> E2ND> 0xFF)
> 
> //static inline uint8_t __eeprom_read_byte_address_word(uint8_t*) 
> __attribute__((always_inline));
> static inline uint8_t __eeprom_read_byte_address_word(uint8_t* eeptr)
> {
>  uint16_t __address_word = (uint16_t)(eeptr);
>  uint8_t __result;
>  do{}while(!eeprom_is_ready());
>  EEARL = __address_word & 0xFF;
>  EEARH = __address_word >> 8;
>  EECR |= 1<  __result = EEDR;
>  return __result;
> }
> 
> This is plain C, but it's forced to be in this specific 
> order, since all 
> (!) access is to volatile memory. There is no timing constraint on 
> instruction sequence so there is no problem.
>
> For -O0 it generates large but valid code.
> For -O[123] it gives all the same small code
> For -Os it might give a function call, so I added the always_inline 
> constraint. Then it gives the same results, however it's 
> arguable to leave
> the inlining to gcc, since it might be smaller (in case of 
> several calls) 
> 
> My C function gives much, much smaller code. GCC gets its 
> hands tide up
> because of the assembler, it forgets it can recycle registers etc...
> 
> So I would recommend this C function approach for all read routines.
> Of course read word could be made more sophisticated using 
> gcc ability to
> check on constants (__builtin_constant_p), so you could then 
> check for page
> crossing and write the high address only once.

This sounds promising. Do you care to modify the header?

 
> The write sequence is best to be in asm since it needs a 
> special timing and
> interrupt clearing.
>  
> One last thing, why is there a loop before every function? In 
> the old code
> there is no loop (although the documentation state there is!?!).

There is a loop, or should be. The loop is checking the EEWE flag (or
equivalent) to make sure that a read or write is possible.

> 
> And the old code is not disabling interrupts during eeprom 
> write... which is
> no good! Maybe this was the problem of the report for the tiny13?

No, the old code is disabling the interrupts for the write routines. You
have to look in the libc/misc/eeprom.S file in the avr-libc source.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, January 29, 2008 2:17 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> As Weddington, Eric wrote:
> 
> > > And the old code is not disabling interrupts during eeprom
> > > write... which is no good! Maybe this was the problem of the
> > > report for the tiny13?
> 
> > No, the old code is disabling the interrupts for the write
> > routines. You have to look in the libc/misc/eeprom.S file in the
> > avr-libc source.
> 
> Sure, I'm now almost convinced that we have to move to a per-device
> library model some day.  This will really become a major step though
> (affecting the entire toolchain, binutils, compiler, and library), but
> will resolve many of these things:
> 
 

> I don't see much point in picking only one of these, and trying to
> craft a reimplementation for it (just because it /could/ be resolved
> by entirely reimplementing it within a header file) when all these
> things eventually have to be resolved anyway.

Joerg, we've gone over this before.

- Yes, we need to move per-device libs *someday*.
- This requires a lot of time and work.
- I need to fix a GCC bug, support *all* AVR device variants with the
EEPROM API, *and support future AVR devices that will be coming out
within a month*.
- No one has yet to volunteer to change all of avr-libc to per-device
libs
- You are working on avr-libc on a volunteer basis; I doubt you have the
time to work on per-device libs and get them working within 2 weeks.
- Therefore, I've chosen the path of least resistance and I'm modifying

- We have precedence in having inline macros that are tailored per
device: pgmspace.h, sleep.h, wdt.h. This just adds another one.

I know that the changes causes the code size to increase. The code *has
to work correctly* before there can be any focus on optimization. At
this point, the EEPROM API implementation causes a GCC bug (internal
compiler error) and IIRC doesn't even work for 2 AVR devices. This is
bad. To add to this, I need the EEPROM API to work for these future
devices that are coming out in a month. You have the datasheets to these
devices, which includes how the EEPROM operates in those devices.

This is the whole reasoning for this change. Since I don't expect anyone
else to volunteer to help, I took it upon myself to make the necessary
changes. Those changes have some problems. I submitted those changes for
feedback from the list.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Wouter van Gulik [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 30, 2008 3:55 AM
> To: Weddington, Eric
> Cc: Joerg Wunsch; avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Weddington, Eric schreef:
> 
> > - I need to fix a GCC bug, support *all* AVR device 
> variants with the
> > EEPROM API, *and support future AVR devices that will be coming out
> > within a month*.
> 
> If the gcc bug fix is the main reason,

No, the GCC bug fix is just one reason. Another reason is that the
EEPROM API doesn't work on 2 devices (IIRC). Another reason, is that the
EEPROM implementation needs to be flexible for new devices that are
coming out. All of these reasons have equal value. It just so happens
that we can address all three reasons just by reimplementing the header.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] AT90USB82 arch 'avr35' to gcc but 'avr5' to avr-libc

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Tod E. Kurt
> Sent: Thursday, February 07, 2008 3:45 AM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] AT90USB82 arch 'avr35' to gcc but 
> 'avr5' to avr-libc
> 
> Hi,
> 
> I may have found a problem with how avr-libc treats the AT90USB82  
> chips, but I'd like some other eyes in case I'm doing something  
> wrong.  I'm just starting to play around with the AT90USB82 and  
> rebuilt my avr-gcc toolchain to incorporate the latest patches for  
> the latest devices.
> 
> In patching gcc (or really, seeing what updates gcc-4.2.3 had), the  
> arch for AT90USB82 is listed as "ARCH_AVR35", but when configuring  
> avr-libc, I see the following scroll by:
>config.status: creating avr/lib/avr5/at90usb82/Makefile
> 

What version of avr-libc are you using? Is it the latest (1.6.1)? 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] AT90USB82 arch 'avr35' to gcc but 'avr5' to avr-libc

[Weddington, Eric]

 

> -Original Message-
> From: Tod E. Kurt [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, February 07, 2008 11:02 AM
> To: Weddington, Eric
> Cc: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] AT90USB82 arch 'avr35' to gcc but 
> 'avr5' to avr-libc
> 
> 
> Everything's brand new, fresh off the internet, compiled from source  
> tarballs:
> 
> - binutils-2.18 with 'newdevices-1.13' and 'newsections-1.1' patches
> - gcc-4.2.3
> - avr-libc-1.6.1
> 

Did you use the patches from the WinAVR project on SourceForge?


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] RE: required patches for avr-gcc 4.3.0

[Weddington, Eric]

 

> -Original Message-
> From: Rolf Ebert [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 11, 2008 3:13 PM
> To: Weddington, Eric; avr-libc-dev@nongnu.org
> Subject: required patches for avr-gcc 4.3.0
> 
 
>  From the list of patches in winavr/patches/gcc/4.2.2/* the following 
> patches

Thanks for the analysis and providing this list!
 
> - need porting to 4.3
> 11-gcc-4.2.2-exec-prefix.patch (not sure, it seems a 
> different solution 
> is already applied)

IIRC, that is correct.

> 21-gcc-4.2.2-disable-libssp.patch

I just submitted this patch to gcc bug #25035 and reopened the bug
report.

> 23-gcc-4.2.2-ada-Makefile.patch
> 43-gcc-4.2.2-bug-11259-v2.patch
> 50-gcc-4.2.2-mega256-v3.patch
> 61-gcc-4.2.2-ada-freestanding.patch
> 62-gcc-4.2.2-ada-mlib.patch
> 63-gcc-4.2.2-ada-timebase.patch
> 64-gcc-4.2.2-ada-gnat1_print_path.patch
> 

Rolf, will you and Bernd handle doing the ada patches above? Will any of
the above patches be eventually submitted (and committed) upstream?

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] Question on IO header policy

[Weddington, Eric]

Hi All,

The avr-libc project has had a policy where all register names and bit
names in a device IO header file are derived directly from the Atmel
device datasheet. We then updated that policy to state that those names
are derived directly from the Atmel device XML files that are shipped
with AVR Studio.

There is a WinAVR bug, #1883630, where a user is requesting the addition
of some *alias* bit names to the IO header file(s) for the
ATmega164P-324P-644P devices.


In doing a search of the latest datasheet for those devices, the
requested names (UCPHA0 and UCPHA1) are *not* found on the datasheet. In
doing a search of the relevant XML files for those devices I find that
those names exist, but with an ALIAS tag, for example:
UCPHA0
Where this alias is after the true listed bit name.

This is the first time that I have run across this ALIAS tag in the XML
devices files.

The question is, should avr-libc provide these alias names? Or should
avr-libc only strictly provide the real bit names, that are also found
in the datasheets?

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Question on IO header policy

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Wednesday, February 13, 2008 5:09 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Question on IO header policy
> 
> I haven't looked at the xml files to see these aliases, but one use I 
> can think of for aliases is compatibility between AVRs.  For 
> example, an 
> AVR with one uart would have a status register called UCSRA, 
> while its 
> big brother with two uarts would call the same register UCSR0A.  This 
> sort of thing can be an unnecessary pain when converting code 
> from one 
> AVR to another.

It's a good use. While I have some influence in what might go into these
XML files, doing what you suggest would be retroactively adding this
information; not impossible, but this would take some considerable time.
I'm more interested in what to do *now* with this bug report.

> Other than that, I think most people only ever read the 
> datasheets, not 
> the xml files - names that only appear in the xml files are therefore 
> probably of little use.
> 

Except that in the future, we will be automatically converting the XML
file to an IO header file for avr-libc. This makes the XML file just as
important.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Question on IO header policy

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Joerg Wunsch
> Sent: Wednesday, February 13, 2008 12:39 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Question on IO header policy
> 
>
> I just downloaded the latest datasheet, and still, both bit names
> *are* present there.

> So bottom line, yes, we should have both definitions.

Sounds good.

Thanks!

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Plans to update scanf().

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Saturday, February 16, 2008 11:41 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] Plans to update scanf().
> 
> Hi.
> 
> In the near future I am going to update vfscanf() function
> - a core of all scanf family (first only the HEAD branch).
> 

Hi Dmitry,

Can you make sure the avr-libc bug #19079 gets fixed?:
https://savannah.nongnu.org/bugs/?19079 

Frederic Nadeau was supposed to commit his patch, but hasn't done so yet.

Thanks,
Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] What about to update vfscanf() in 1_6 branch?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Thursday, February 21, 2008 3:13 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] What about to update vfscanf() in 1_6 branch?
> 
> Hi.
> 
> After testing with all GCC versions (3.3.6 - 4.3.X)
> I intend to update vfscanf() in 1_6 branch (from HEAD).
> 
> Any objections?
> 

None from me. :-)

Thanks again for taking care of this.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

Hi Wouter and All,

I took your rewrite and had to fix a few things. I also added new 32-bit
integer read/write routines per Shaun's feature request (tracker on
avr-libc). Everything finally tested correctly.

I can finally say this now: Besides all of the other reasons I mentioned
for changing the EEPROM routines, one of the other reasons to change
these routines is becase of the new XMEGA chips that have been
announced. Because avr-libc does not yet have a design of library per
architecture, changing the EEPROM API implementation to be restricted to
just a header file (no compiled code in a library) allows us to modify
the implementation per device. This is necessary to fix the
implementation for a couple of other AVR devices (where they are
currently broken) and also to implement some of the new ways to access
the EEPROM in the ATxmega128A1 and ATxmega64A1.

The attached eeprom.h file is the first step in this.

Joerg, what is your opinion about adding this to the 1.6 branch? Or
would you rather it be restricted to HEAD? If it is restricted to HEAD,
then I lean towards cutting a 1.8.0 release sooner rather than later.

Any other thoughts? I would like to get this committed sometime soon.

Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

Attachment problems. Trying again... 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Weddington, Eric
> Sent: Wednesday, February 27, 2008 6:55 PM
> To: Wouter van Gulik
> Cc: avr-libc-dev@nongnu.org; Joerg Wunsch; Shaun Jackman
> Subject: RE: [avr-libc-dev] [RFC] New eeprom.h
> 
> Hi Wouter and All,
> 
> I took your rewrite and had to fix a few things. I also added 
> new 32-bit
> integer read/write routines per Shaun's feature request (tracker on
> avr-libc). Everything finally tested correctly.
> 
> I can finally say this now: Besides all of the other reasons 
> I mentioned
> for changing the EEPROM routines, one of the other reasons to change
> these routines is becase of the new XMEGA chips that have been
> announced. Because avr-libc does not yet have a design of library per
> architecture, changing the EEPROM API implementation to be 
> restricted to
> just a header file (no compiled code in a library) allows us to modify
> the implementation per device. This is necessary to fix the
> implementation for a couple of other AVR devices (where they are
> currently broken) and also to implement some of the new ways to access
> the EEPROM in the ATxmega128A1 and ATxmega64A1.
> 
> The attached eeprom.h file is the first step in this.
> 
> Joerg, what is your opinion about adding this to the 1.6 branch? Or
> would you rather it be restricted to HEAD? If it is 
> restricted to HEAD,
> then I lean towards cutting a 1.8.0 release sooner rather than later.
> 
> Any other thoughts? I would like to get this committed sometime soon.
> 
> Eric Weddington
> 


begin 666 eeprom.h
[EMAIL PROTECTED]>7)I9VAT("AC*2 R,# R+" R,# S+" R,# T+" R,# W($UA7)I9VAT("AC*2 R,# X(%=O=71E<[EMAIL PROTECTED]
M:6L-"B @($%L;"!R:6=H=',@7)I9VAT#0H@(" 
@(&YO=&EC
[EMAIL PROTECTED]&AI71E('-T2!S<&%C92X-"B @(" @(" @061R97-S97,@9&5N;W1E9"!I;B!H97@@
M"[EMAIL PROTECTED]
M3TU?4D5'7TQ/0T%424].4U]?*0T*#0H@(" @(W5N9&5F($5%0U(-"B @(" C
M9&5F:6YE($5%0U(@7U-&4E])[EMAIL PROTECTED](#X^(#$V*2 F(#!X1D8I#0H-
M"B @(" [EMAIL PROTECTED]@T*(" @("-D969I;[EMAIL PROTECTED]/."@H
M2$583E(@/[EMAIL PROTECTED]"D@)B P>$9&("D-"@T*(" @("-U;F1E9B!%14%2#0H@(" @
M(V1E9FEN92!%14%2(%]31E)?24\X*$A%6$Y2("8@,'A&1BD-"@T*(" @("-U
M;F1E9B!%14%22 T*#0H@(" @(W5N9&5F($5%05),#0H@(" @(V1E9FEN92!%
M14%23"!%14%2#0H-"B-E;[EMAIL PROTECTED]"B\J*B!<9&5F(&5E<')O;5]I0T*(" @(%QI;F=R;W5P(&%V2!F;W(@82!N97<@[EMAIL PROTECTED];F5D
M*$1%14-2*0T*(R!D969I;[EMAIL PROTECTED]71E7V%D9')E
M71E+FAI.PT*(" @($5%
M0U(@[EMAIL PROTECTED]@/[EMAIL PROTECTED]@(" @71E*'5I;[EMAIL PROTECTED]<[EMAIL PROTECTED]"!V86QU
M92D-"GL-"B @("!D;WM]=VAI;&4H(65E<')O;5]I[EMAIL PROTECTED]"@T*
M(" @($5%05),([EMAIL PROTECTED]PT*(" @('5N:6]N#0H@(" @>PT*
M(" @(" @("!U:6YT,39?="!W;W)D.PT*(" @(" @("!S=')U8W0-"B @(" @
M(" @>PT*(" @(" @(" @(" @=6EN=#A?="!L;SL-"B @(" @(" @(" @('5I
M;G0X7W0@:&D[#0H@(" @(" @('[EMAIL PROTECTED]"B @("!](%]?=CL-"@T*(" @
M(%]?=BYW;W)D([EMAIL PROTECTED]@(" @7U]E97!R;VU?=W)I=&5?8GET95]A
M9&1R97-S7V)Y=&4H861D<[EMAIL PROTECTED])Y=&4N;&\I.PT*(" @(%]?965P71E*&%D9'(@*R Q+"!?7W8N8GET92YH
M:2D[#0I]#0H-"@T*#0II;FQI;F4@71E*'5I;[EMAIL PROTECTED]<[EMAIL PROTECTED],R7W0@
M=F%L=64I#0I[#0H@(" @=6YI;VX-"B @("![#0H@(" @(" @('5I;G0S,E]T
M(&1W;W)D.PT*(" @(" @("!S=')U8W0-"B @(" @(" @>PT*(" @(" @(" @
M(" @=6EN=#A?="!B>71E,#L-"B @(" @(" @(" @('5I;[EMAIL PROTECTED]
M#0H@(" @(" @(" @("!U:6YT.%]T(&)Y=&4R.PT*(" @(" @(" @(" @=6EN
M=#A?="!B>71E,SL-"B @(" @(" @?2!B>71E.PT*(" @('[EMAIL PROTECTED]@
M(" @7U]V+F1W;W)D([EMAIL PROTECTED]@(" @7U]E97!R;VU?=W)I=&5?8GET
M95]A9&1R97-S7V)Y=&4H861D<[EMAIL PROTECTED])Y=&4N8GET93 I.PT*(" @(%]?
M965P71E*&%D9'(@*R Q+"!?7W8N
M8GET92YB>71E,2D[#0H@(" @7U]E97!R;VU?=W)I=&5?8GET95]A9&1R97-S
M7V)Y=&4H861D71E+F)Y=&4R*3L-"B @("!?7V5E<')O
M;5]W71E7V%D9')ER -"B @(" @(" @[EMAIL PROTECTED]"B @(" @(" @71E
M+FAI.PT*(" @($5%05),([EMAIL PROTECTED])Y=&4N;&\[#0H@(" @145$4B @/2!V
M86QU93L-"@T*(" @([EMAIL PROTECTED];VQA=&EL

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: Shaun Jackman [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, February 28, 2008 7:45 AM
> To: Weddington, Eric
> Cc: Wouter van Gulik; avr-libc-dev@nongnu.org; Joerg Wunsch
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Hi all,
> 
> I like the rewrite. It looks good. My only concern is possibly code
> size. I haven't tested it, but it looks as though
> __eeprom_write_byte_address_word should generate about 10
> instructions, which means __eeprom_write_dword_address_word will
> generate 40 instructions, or 80 bytes. It seems to me that an 80 byte
> function should not be inlined. I have been following the history of
> this issue, and I know the reason these functions are inlined.
> However, I'm not sure that the end result, namely an 80 byte inline
> function, is valid.
> 
> It is possible for the application to provide it's own not 
> inlined copy:
> void eeprom_write_dword_not_inlined(uint16_t addr, uint32_t value)
> {
>   eeprom_write_dword(addr, value);
> }
> which is a reasonably straight forward workaround. It just seems a bit
> clunky. Since I don't have any solutions or suggestions, I'm
> definitely not objecting to the rewrite being checked in. The rewrite
> fixes otherwise unresolvable issues.
> 

Hi Shaun,

Thanks for your response!

Your last sentence is really the crux of the matter. If regular
functions are provided then we're back to where we started and it
doesn't resolve the avr-libc bugs (non-working routines on certain
devices). If the functions are provided in the header file, and they are
non-inline, then there is a strong potential for duplicate function
names at the link stage. Without going to "lib-per-device" design, the
only solution available has to be in a header file, whether inline
assembly, or inline C functions.

The AVR is not terribly efficient at moving around 32-bit integers, or
greater, so I would expect that a read/write dword would be large to a
certain degree.

Again, it comes down to having correct code first, and then optimized
code (for size) later.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Thursday, February 28, 2008 10:23 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Hi all.
> 
> I like the rewrite. It looks good. My only concern is not
> only code size. There is a second question: this functions
> are not a normal C functions.  That is:
> 
> . No argument type control at compile time. For expamle,
> the expressions like
> eeprom_write_block ("Apple", s, sizeof("Apple"));
> eeprom_write_dword (3.14159, 0);
> do not type any warnings.
> 
> . It is impossible to get address of eeprom function
> to inderect call.
> 
> . Avr-gcc can not to optimize the EEPROM reading, like it
> can do this in case of SRAM.
> 
> 
> Summarizes the Eric's "eeprom.h" and all ideas from above
> (Wouter, Shaun, Rick) I have prepare two projects.
> 
> Project 1.
> It is a very simple: use an inderect calls (not indirect
> registers). It is eliminates big space expense and notes
> above: eeprom functions are pure functions. It is needed
> to add only 6 very short functions into Avr-libc. At this
> moment this project is ready for test. I can to commite
> at this week-end.
> 
> Project 2.
> Use a set of high quality asm functions. This is not only
> space effective, also it is fast. Now the set of funtions is
> ready for test. Some efforts are needed to include into
> Avr-libc: I am not happy to do this manualy.
> 
> In attach the "eeprom.h" of project 1.
> 
> Opinions?


- In eeprom.h, I had changed it to "inline static" because I received a
comment from a tester that 4.1.x gave warnings on "static inline". But
"inline static" was ok. So you may want to test your version with
previous versions of GCC (4.1.x) to avoid the same issue.

- We can't have library functions until avr-libc moves to a
library-per-device design. We have to be able to conditionally compile
the code to change it for certain devices.

- The ability to taking the addresses of these functions is not that
critical. How often would this be done in a real AVR application? It's
not likely.

- Yes there is no type checking, but that requires functions, which
requires library-per-device design.

At this point, I do NOT care if the generated code is twice the size as
used to be, as long as the code:
- Works correctly for *all* AVR devices in the toolchain that has EEPROM
(see avr-libc bug #21410), with all locations of EEPROM registers
- Fixes the GCC bug #31644 test case
- Has a means to allow future handling of the new EEPROM design in the
XMEGA devices

It would be nice if we can, in the future, remove all instances of
__EEPROM_REG_LOCATIONS__, as that was a kludge to begin with. This means
that we should only depend on typical register definitions in the IO
header file like EECR, EEDR, EEARL, EEARH, EEAR, etc.

Oh, and can it be done in a week? I need a short-term fix, now. This
discussion has gone on way too long. If you wish to debate the various
merits/demerits of the design, then please provide working examples that
meet the criteria above. I have seen Wouter and Dmitry provide code.
Shaun, you provided the dword routines (even though they've been
modified).

Eric Weddington



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Saturday, March 01, 2008 12:43 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Hi all.
> 
> 
>   New variant of EEPROM functions: inline byte procedures 
> and library
>   multibyte envelopes.
>   * include/avr/eeprom.h: Rewrite on the base of project 
> by Eric B.
>   Weddington.
>   * libc/misc/eeprom.S: Remove file.
>   * libc/misc/ee_rb.S: Remove file.
>   * libc/misc/ee_rblk.S: Remove file.
>   * libc/misc/ee_rw.S: Remove file.
>   * libc/misc/ee_wb.S: Remove file.
>   * libc/misc/ee_wblk.S: Remove file.
>   * libc/misc/ee_ww.S: Remove file.
>   * libc/misc/eerd_block.c: New file.
>   * libc/misc/eerd_dword.c: New file.
>   * libc/misc/eerd_word.c: New file.
>   * libc/misc/eewr_block.c: New file.
>   * libc/misc/eewr_dword.c: New file.
>   * libc/misc/eewr_word.c: New file.
>   * libc/misc/Files.am: Remove old sources, add new.
>   * libc/misc/Makefile.am: Include $(misc_a_c_sources) to 
> EXTRA_DIST.
>   * libc/misc/Rules.am: Remove rules to build 
> chip-specific objects.
>   * tests/simulate/avr: New directory (for AVR-specific 
> functions).
>   * tests/simulate/avr/eeprom-1.c: New file.
> 
> Eric, I wait yours approval to commit into CVS HEAD.
> 

Hi Dmitry,

Thanks for taking the initiative on this and optimizing the code space.

I'm ok to commit to HEAD if these conditions are met:
- builds for all current AVR devices that have EEPROM
- fixes avr-libc bug #21410
- fixes gcc bug #31644

I would like Joerg's opinion on whether this should be committed to 1.6
branch. Joerg?

Thanks,
Eric 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Saturday, March 01, 2008 4:04 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Shaun Jackman wrote:

> > In the standard use of avr-libc with gcc and binutils, you will get
> > one copy of the function per object file that uses it.
> > 
> 
> For my programs at least, I would not see that as a problem - 
> I always 
> have eeprom access from a single module anyway.  While other people 
> might not be as strict as that, I don't think it is common to have 
> eeprom access from many files.
> 

I tend to agree. 


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] Avr-libc test results

[Weddington, Eric]

Hi All,

I finally got around to trying the avr-libc test suite on MSYS. Attached
are the test results.

Eric Weddington
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Avr-libc test results

[Weddington, Eric]

 

> -Original Message-
> From: Kevin Rosenberg [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 14, 2008 11:25 AM
> To: Weddington, Eric
> Cc: avr-libc-dev@nongnu.org; Dmitry K.
> Subject: Re: [avr-libc-dev] Avr-libc test results
> 
> Weddington, Eric wrote:
> > I finally got around to trying the avr-libc test suite on 
> MSYS. Attached
> > are the test results.
> 
> Eric, I didn't find an attachment to your message. Would you mind
> rechecking to ensure the attachment was present?

Oh, stupid me. I keep forgetting that Savannah mailing lists don't like
my Outlook settings (not that I like Outlook anyway).

Here it is again. Should be uuencoded.


begin 666 test.log
M4VEM=6QA=&4Z(')E9W)E"YC(&%T.3!S.#4Q-2 [EMAIL PROTECTED]
M=&4Z('-T9&QI8B]D=&]S=')F+6UI;FUA>"YC(&%T;65G83@@+BXN($]+"E-I
M;75L871E.B!S=&1L:6(O9'1O&ET+3$N8R!A
M=&UE9V$X("XN+B!/2PI3:6UU;&%T93H@&1I9VET+3$N8R!A
M=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]($]+"E-I;75L871E.B!S=&1L:6(O:7-X9&EG:70M,2YC
M(&%T;65G83@@+BXN($]+"E-I;75L871E.B!S=&1L:6(O'0K,'@S,"DZ('5N9&5F:6YE9"!R969E<[EMAIL PROTECTED]&\@
M8%]?9F9S:&DR)PT*9F9S+3$N8SHH+G1E>'0K,'AB92DZ('5N9&5F:6YE9"!R
M969E<[EMAIL PROTECTED]&[EMAIL PROTECTED]:&DR)PT*9F9S+3$N8SHH+G1E>'0K,'AE-BDZ
M('5N9&5F:6YE9"!R969E<[EMAIL PROTECTED]&[EMAIL PROTECTED]:&DR)PT*9F9S+3$N8SHH
M+G1E>'0K,'@Q,3 I.B!U;F1E9FEN960@#$N8R O
M#(N8R O#,N8R!A=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]
M($]+"E-I;75L871E.B!S8V%N9B]S#,N8R!A=&UE9V$X("XN+B!/
M2PI3:6UU;&%T93H@#,N8R 
O#,N8R O7-I9VXM,#$N8R!A
M=&UE9V$X("XN+B!/2PI3:6UU;&%T93H@;6%T:"]C;W,M,#$N8R!A=#DP<[EMAIL PROTECTED]
M,[EMAIL PROTECTED]($]+"E-I;75L871E.B!M871H+V-O"TU,# N8R!A=&UE9V$X("XN+B!/
M2PI3:6UU;&%T93H@;6%T:"]F;6EN+3 Q+F,@870Y,',X-3$U("XN+B!/2PI3
M:6UU;&%T93H@;6%T:"]F;6EN+3 Q+F,@871M96=A." [EMAIL PROTECTED]
M=&4Z(&UA=&@O9FUI;BTU,# N8R!A=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]($]+"E-I;75L871E
M.B!M871H+V9M:6XM-3 P+F,@871M96=A." [EMAIL PROTECTED]&4Z(&UA
M=&@O9FUO9"TP,2YC(&%T.3!S.#4Q-2 [EMAIL PROTECTED]&4Z(&UA=&@O
M9FUO9"TP,2YC(&%T;65G83@@+BXN($]+"E-I;75L871E.B!M871H+V9M;V0M
M-3 P+F,@870Y,',X-3$U("XN+B!/2PI3:6UU;&%T93H@;6%T:"]F;6]D+34P
M,"YC(&%T;65G83@@+BXN($]+"E-I;75L871E.B!M871H+V9M;V0M;F%N+F,@
M870Y,',X-3$U("XN+B!/2PI3:6UU;&%T93H@;6%T:"]F;6]D+6YA;BYC(&%T
M;65G83@@+BXN($]+"E-I;75L871E.B!M871H+V9R97AP+3 Q+F,@870Y,',X
M-3$U("XN+B!/2PI3:6UU;&%T93H@;6%T:"]F7!O="TP,2YC(&%T;65G83@@+BXN($]+
M"E-I;75L871E.B!M871H+VAY<&]T+34P,"YC(&%T.3!S.#4Q-2 [EMAIL PROTECTED]
M4VEM=6QA=&4Z(&UA=&@O:'EP;W0M-3 P+F,@871M96=A." [EMAIL PROTECTED]
M=6QA=&4Z(&UA=&@O:7-F:6YI=&4M,#$N8R!A=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]($]+"E-I
M;75L871E.B!M871H+VES9FEN:71E+3 Q+F,@871M96=A." [EMAIL PROTECTED]
M=6QA=&4Z(&UA=&@O:7-I;F8M,#$N8R!A=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]("HJ*B!S:6UU
M;&%T92!F86EL960Z(#(R"E-I;75L871E.B!M871H+VES:6YF+3 Q+F,@871M
M96=A." [EMAIL PROTECTED]('-I;75L871E(&9A:6QE9#H@,C(*4VEM=6QA=&4Z(&UA
M=&@O:7-N86XM,#$N8R!A=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]($]+"E-I;75L871E.B!M871H
M+VES;F%N+3 Q+F,@871M96=A." [EMAIL PROTECTED]&4Z(&UA=&@O;&1E
M>' M,#$N8R!A=#DP<[EMAIL PROTECTED],[EMAIL 
PROTECTED]($]+"E-I;75L871E.B!M871H+VQD97AP
M+3 Q+F,@871M96=A." [EMAIL PROTECTED]&4Z(&UA=&@O;&1E>' M;F%N
M+F,@870Y,',X-3$U("XN+B!/2PI3:6UU;&%T93H@;6%T:"]L9&5X<"UN86XN
M8R!A=&UE9V$X("XN+B!/2PI3:6UU;&%T93H@;6%T:"]L;V"UI;F8N8R!A=#DP
M<[EMAIL PROTECTED],[EMAIL 
PROTECTED]($]+"E-I;75L871E.B!M871H+WAX>"UI;F8N8R!A=&UE9V$X
M("XN+B!/2PI3:6UU;&%T93H@;6%T:"]X>'@M;F%N+F,@870Y,',X-3$U("XN
M+B!/2PI3:6UU;&%T93H@;6%T:"]X>'@M;F%N+F,@871M96=A." [EMAIL PROTECTED]
M4VEM=6QA=&4Z(&]T:&5R+V%L;&]C82YC(&%T.3!S.#4Q-2 [EMAIL PROTECTED]
M=6QA=&4Z(&]T:&5R+V%L;&]C82YC(&%T;65G83@@+BXN($]+"E-I;75L871E
M.B!A=G(O965Phttp://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Avr-libc test results

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Friday, March 14, 2008 7:43 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Avr-libc test results
> 
> On Saturday 15 March 2008 03:15, Weddington, Eric wrote:
> > Hi All,
> >
> > I finally got around to trying the avr-libc test suite on 
> MSYS. Attached
> > are the test results.
> >
> > Eric Weddington
> 
> Simulate: avr/eeprom-1.c at90s2313 ... *** simulate failed: 22
> Simulate: avr/eeprom-1.c at90s4414 ... *** simulate failed: 22
> Simulate: avr/eeprom-1.c at90s8515 ... *** simulate failed: 22
> Simulate: avr/eeprom-1.c atmega8 ... *** simulate failed: 22
> Simulate: avr/eeprom-1.c atmega16 ... *** simulate failed: 22
>It is strange...  The 22 line is the first EEPROM read
> operation.  Now I try to build and test CVS HEAD 2008-03-09... OK.
> Later I will update and try once more.
> 
> Eric, please, mail what compiler version are you use?
> And version of simulavr.
> 

Binutils 2.18
GCC 4.3.0
Avr-libc latest from 1.6 branch
Simulavr 0.1.2.3

Thanks for the response! I will look into the bug reports that you
mentioned.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Avr-libc test results

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Friday, March 14, 2008 9:51 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Avr-libc test results
> 
> On Saturday 15 March 2008 12:53, Weddington, Eric wrote:
> > > Simulate: avr/eeprom-1.c at90s2313 ... *** simulate failed: 22
> > > Simulate: avr/eeprom-1.c at90s4414 ... *** simulate failed: 22
> > > Simulate: avr/eeprom-1.c at90s8515 ... *** simulate failed: 22
> > > Simulate: avr/eeprom-1.c atmega8 ... *** simulate failed: 22
> > > Simulate: avr/eeprom-1.c atmega16 ... *** simulate failed: 22
> > >It is strange...  The 22 line is the first EEPROM read
> > > operation.  Now I try to build and test CVS HEAD 2008-03-09... OK.
> > > Later I will update and try once more.
> > >
> > > Eric, please, mail what compiler version are you use?
> > > And version of simulavr.
> >
> > Binutils 2.18
> > GCC 4.3.0
> > Avr-libc latest from 1.6 branch
> > Simulavr 0.1.2.3
> 
> Oh, I see that Simulavr is live!

Not really. Joerg just has some minor patches that he finally got
committed. This will probably be the last version of the simulavr code
base, unless something is seriously broken.

> simulavr-0.1.2.3/src/avrcore.c avr_core_new()
> differs from 0.1.2.1:
>...
>core->eeprom = NULL;
>...
> 
> Is it a reason of test fault?
> 

Honestly I don't know. I'm not that familiar with the internals.

Dmitry, do you think that the avr-libc test suite can be run with the
new "avrtest" program that is in the WinAVR repository?


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Avr-libc test results

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Weddington, Eric
> Sent: Saturday, March 15, 2008 6:30 AM
> To: Dmitry K.; avr-libc-dev@nongnu.org
> Cc: Joerg Wunsch
> Subject: RE: [avr-libc-dev] Avr-libc test results
> 
> > > Simulavr 0.1.2.3
> > 
> > Oh, I see that Simulavr is live!
> 
> Not really. Joerg just has some minor patches that he finally got
> committed. This will probably be the last version of the simulavr code
> base, unless something is seriously broken.
> 

Sorry, the latest version is 0.1.2.4.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] Delay stuff

[Weddington, Eric]

Hi Joerg,

When you have a chance, could you take a look at all the various
outstanding delay stuff:

2 Feature requests:



And a Patch:



___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Avr-libc test results

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Paulo Marques
> Sent: Monday, March 17, 2008 3:02 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] Avr-libc test results
> 
 
> Is there somewhere a nice summary table of which instructions are
> supported for each architecture? I can certainly dig it up, but if
> someone has a direct link to something like that, it could 
> save me some
> digging...
> 

Unfortunately there is just the binutils source for the AVR target,
AFAIK.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [bug #21410] Incorrect use of 16-bit eepromaddresses in devices with 8-Bit address registers

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Wednesday, March 19, 2008 4:59 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [bug #21410] Incorrect use of 
> 16-bit eepromaddresses in devices with 8-Bit address registers
> 
> On Thursday 20 March 2008 08:28, Eric Weddington wrote:
> > Update of bug #21410 (project avr-libc):
> >
> >  Open/Closed:Open => Closed
> 
> I have not close consciously:
> 
> > > And a general question: what is the best method to
> > > do in this case: a bug is fixed only in CVS and there
> > > is no realise?  If a bug is declared as fixed it is
> > > removed from a view.
> >
> > One suggestion:
> > Set Status to Fixed. Set Percent Complete to 100%. Leave 
> Open/Closed as
> > Open. Add a Comment to say where the bug is fixed (e.g. CVS 
> HEAD, future
> > version x.y).
> > 
> > Eric

Yeah, I know, and I'm sorry for the hassle. But I'd like to do a release
soon, which will include these fixed bugs. I'm going down the bug list
to see what is left and it helps to see which bugs are left.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] Plan for new release: 1.6.2.

[Weddington, Eric]

Hi All,

I'm doing a new release of WinAVR soon. A release candidate some time
this week, with a planned release on April 2. This release is mainly to
support the XMEGA devices, fix various bugs (avr-libc, WinAVR), and
support other new devices (ATmega32M1, ATmega32C1).

I've been going through the bug list recently. Is there anything else
that any of the developers would like to get fixed, or patches to get
in? I would like to add support for 2 more devices: ATmega32U4, and
ATtiny167. I'm hoping to get this in by the end of Friday (local time).

Thanks,
Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] RE: Plan for new release: 1.6.2.

[Weddington, Eric]

 

> -Original Message-
> From: Weddington, Eric 
> Sent: Wednesday, March 19, 2008 5:23 PM
> To: avr-libc-dev@nongnu.org
> Subject: Plan for new release: 1.6.2.
> 
> Hi All,
> 
> I'm doing a new release of WinAVR soon. A release candidate 
> some time this week, with a planned release on April 2. This 
> release is mainly to support the XMEGA devices, fix various 
> bugs (avr-libc, WinAVR), and support other new devices 
> (ATmega32M1, ATmega32C1).
> 
> I've been going through the bug list recently. Is there 
> anything else that any of the developers would like to get 
> fixed, or patches to get in? I would like to add support for 
> 2 more devices: ATmega32U4, and ATtiny167. I'm hoping to get 
> this in by the end of Friday (local time).
> 

Oh, and yes, I will also commit the XMEGA changes for avr-libc during
that time.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [bug #21410] Incorrect use of 16-biteepromaddresses in devices with 8-Bit address registers

[Weddington, Eric]

 

> > -Original Message-
> > From: 
> > [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED]
> > org] On Behalf Of Dmitry K.
> > Sent: Wednesday, March 19, 2008 4:59 PM
> > To: avr-libc-dev@nongnu.org
> > Subject: Re: [avr-libc-dev] [bug #21410] Incorrect use of 
> > 16-bit eepromaddresses in devices with 8-Bit address registers
> > 
> Yeah, I know, and I'm sorry for the hassle. But I'd like to 
> do a release
> soon, which will include these fixed bugs. I'm going down the bug list
> to see what is left and it helps to see which bugs are left.
> 

Hey! I think I found the solution to our problem:

There are additional field we can use for the Bug Tracker. One of those
fields is "Fixed Release", which is the release number in which the bug
is fixed. I have now enabled the use of this field. That way we can
close the bug, but set which release it will be fixed in.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] RE: [bug #22276] wdt_reset fails with devices with large WDTCSR addresses

[Weddington, Eric]

 

> -Original Message-
> From: CurtVM [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 19, 2008 7:56 PM
> To: Weddington, Eric; Dean Camera; CurtVM; avr-libc-dev@nongnu.org
> Subject: [bug #22276] wdt_reset fails with devices with large 
> WDTCSR addresses
> 
> 
> Follow-up Comment #4, bug #22276 (project avr-libc):
> 
> The changes you made will not work unless you get 
> '_WDT_CONTROL_REG' into
> something you can test in this line-
> 
> #if (_WDT_CONTROL_REG > 0x5F)

Duh. Of course. Thanks for pointing this out.
 
> which is why I surrounded that with temporarily redefining 
> _MMIO_BYTE, so
> that test could be made.
> 
> Maybe there is a better way to end up with a number that can 
> be tested, I
> don't know.

See attached wdt.h. Would this work?
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[avr-libc-dev] 1.6.2 release?

[Weddington, Eric]

Hi All,

I now have all the new device support into avr-libc. I would like to do
a 1.6.2 release before April 2.

Thoughts, objections?

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] 1.6.2 release?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Thursday, March 27, 2008 4:47 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] 1.6.2 release?
> 
> On Thursday 27 March 2008 04:27, Weddington, Eric wrote:
> > Hi All,
> >
> > I now have all the new device support into avr-libc. I 
> would like to do
> > a 1.6.2 release before April 2.
> >
> > Thoughts, objections?
> 
> I doubt that it is posible to work with XMEGA
> without doc of GCC ABI.

Hi Dmitry,

Actually, this toolchain is already being used internally in Atmel.


> It is interesting:
>   - sizeof(void *) ?

Pointer sizes have not changed. 16-bits.

>   - where use/save/reload RAMPX/Y/Z/D,EIND (and plus?)

True. I don't think that all of these issues have been addressed yet.

>   - how to use (void *)0 ?

Could you explain? How would it be any different than it is now?

>   - predefined macroses

Could you explain?

> The begin of Avr-libc TODO list:
> 
> * Remove indirect access to common registers.

True, that needs to be done. But IIRC, they're not really being used
right now anyway, so there is no harm right now.

> * Upgrade the SFR_OFFSET/SFR_IO_ADDR/SFR_MEM_ADDR
> to obtain source code compatibility.

Agreed. This could be done in the next week.

> * EEPROM

This is one reason why I needed to have the EEPROM implementation
redone. I agree that we need more in this area, especially with the
ability to memory map the EEPROM area. However, the EEPROM can be
accessed in the classic method like the megaAVRs. So I think it is OK
for now, but yes this needs more work.

I understand that you want all the issues to be worked out. I really
appreciate this. :-) However, I have to follow the philosophy of
"release early, release often". This toolchain is being used right now.
I know that the support for the xmega devices is not perfect. It needs
to be improved over time.

I *will* be releasing this xmega support in the April 2 release of
WinAVR, whether avr-libc is released or not. I would prefer to have a
released version, rather than a checkout from cvs. But if a release is
not available, then I will include a cvs checkout.

Eric Weddington


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] 1.6.2 release?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Friday, March 28, 2008 11:40 PM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] 1.6.2 release?
> 
> On Friday 28 March 2008 13:48, Weddington, Eric wrote:
> [...]
> 
> > >   - how to use (void *)0 ?
> >
> > Could you explain? How would it be any different than it is now?
> I have check this.
> The Avr-gcc 4.2.3 and 4.3.0 have not any problems.
> The Avr-gcc 4.1.2 and early are too agressive in manipulations
> with 0 address (XMEGA's GPIO0 has address 0).

Good point. We'll have to keep an eye on this in the future.

> 
> > >   - predefined macroses
> >
> > Could you explain?
> What macroses must to use in source code?
> __AVR_XMEGA__ or '__AVR_ARCH__ > 100'?
> The 'common.h' uses '>= 100': what is arch 100 ?

Ah, I see. Architectures above 100 are currently XMEGA devices. I agree
that we will need to change this construct in the future to remove the
"magic numbers". But I think it is ok for this early stage.


> 
> > > The begin of Avr-libc TODO list:
> > >
> > > * Remove indirect access to common registers.
> >
> > True, that needs to be done. But IIRC, they're not really being used
> > right now anyway, so there is no harm right now.
> I have find:
>Avr-libc 1.4: exp.S
>Avr-libc 1.6: frexp.S (fixed now)
> It is needed to continue a check.

Thanks for checking.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] XMEGA: are SP, EEAR 16-bit registers?

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Saturday, March 29, 2008 12:03 AM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] XMEGA: are SP, EEAR 16-bit registers?
> 
> Hi.
> 
> The common X-less AVR has a set of 16-bit registers
> (those have 16-bit atomic access). This registers are
> listed implicitly, for example, with ATmega48p they
> are: TCNT1, OCR1A/B, ICR1, TCNT2, ...
> 
> But the 'ATxmega A manual' says (page 9):
> ... each 16-bit register has an 8-bit register for
> temporary storing the high byte...
> 
> Is it true with SP? If so it is needed to verify all
> sources: low byte must read first, high byte must
> write first.
> 

Dmitry,

Anatoly and I made sure that the 16-bit registers are accessed
correctly. You can see this with the GCC patch that I sent to you.

The SP is the only one that I am unsure of, and I will check into it,
but it will have to be on Monday.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] eeprom_write_block() incompatibility

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Thursday, April 03, 2008 4:25 PM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] eeprom_write_block() incompatibility
> 
> Hi.
> 
> I have accidentally revert the operands in eeprom.h:
> 
> Old order:  eeprom_write_block (src, dst, number)
> New order:  eeprom_write_block (dst, src, number)
> 
> What about to restore the old order?
> 

Ouch. Yes, can you restore the old order. IIRC, we wanted to keep the
API the same with the new implementation.

Thanks for bringing this up. I was re-rolling a new WinAVR release. I'll
hold off on that until this is fixed.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] Patch for Signal Interrupts

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ron Kreymborg
> Sent: Monday, April 07, 2008 6:05 AM
> To: avr-libc-dev@nongnu.org
> Subject: [avr-libc-dev] Patch for Signal Interrupts
> 
> A patch to add an argument to the signal attribute has been 
> proposed over on
> the avr-gcc-list. This is based on an original proposal by Marek
> Michalkiewicz which in turn was based on an msp430 version of gcc. The
> intent is to link the jump vector to the interrupt function 
> address rather
> than indirectly through the function name. The interrupt 
> function name can
> therefore be any name including a mangled C++ name. 
> 
> The existing ISR macros remain unchanged and work as before.
> 
> Is there any further discussion on this?
> 

Overall I think it's a very good idea, and I appreciate your work on
this and the dedication to see it through. :-)

Is this patch in a Patch Tracker on the avr-libc project? I didn't see
it there with a cursory glance.

Eric


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-libc installation error

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Aurélien Francillon
> Sent: Monday, April 07, 2008 10:41 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-libc installation error
> 
> 
> on gentoo you can also use crossdev which builds the cross toolchain 
info/avr-libc-dev

No, you cannot use crossdev for an AVR toolchain, as it has bugs.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] avr-libc installation error

[Weddington, Eric]

 

> -Original Message-
> From: Aurélien Francillon [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 07, 2008 11:53 AM
> To: Weddington, Eric
> Cc: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] avr-libc installation error
> 
> Le Monday 07 April 2008 18:47:13 Weddington, Eric, vous avez écrit :
> > > -Original Message-
> > > From:
> > > [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]
> > > org] On Behalf Of Aurélien Francillon
> > > Sent: Monday, April 07, 2008 10:41 AM
> > > To: avr-libc-dev@nongnu.org
> > > Subject: Re: [avr-libc-dev] avr-libc installation error
> > >
> > >
> > > on gentoo you can also use crossdev which builds the 
> cross toolchain
> 
> > No, you cannot use crossdev for an AVR toolchain, as it has bugs.
> 
> Well, I do without too much trouble,  if you are thinking about 
> the "ldscripts/xxx.x: No such file or directory" bug [1], 
> well I agree it 
> pops out from time to time, and it's ugly.
> But the workaround is a one liner ... 
> ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts/ 
> /usr/avr/lib/ldscripts
> or 
> ln -s /usr/i686-pc-linux-gnu/usr/avr/lib/ldscripts 
> /usr/avr/lib/ldscripts
> if you run on 32 bits ...
> I don't have any other problems with crossdev for avr ...

Yes, but it's an ugly workaround, because you are supposed to not need it. The 
only reason why you have to have that workaround is because crossdev builds a 
broken compiler.


___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: [avr-libc-dev] [bug #22878] eeprom_*_word/dword/block cause hangin ATmega256x

[Weddington, Eric]

 

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Dmitry K.
> Sent: Wednesday, April 09, 2008 12:24 AM
> To: avr-libc-dev@nongnu.org
> Subject: Re: [avr-libc-dev] [bug #22878] 
> eeprom_*_word/dword/block cause hangin ATmega256x
> 
> Hm...
> 
> Is avr-gcc for avr6 ready to use?
> 
> I have try avr-gcc 4.4-20080404 (4.3.0 does not support avr6)
> with binutils 2.18.  

You need to try either 4.4 with Andy's combine.c patch committed (only
recently) or 4.3 with his patch. See attached. 

I will try your test case later on today with Andy's patch. I will also
try re-running the avr-libc tests too with patch.

Eric Weddington

___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev