Re: [avr-libc-dev] Faster integer division
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Ambroz Bizjak Sent: Friday, June 07, 2013 8:34 PM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Faster integer division Hi! I've found 32bit integer division in gcc too slow, and I managed to implement division in asm that's faster than what gcc 4.8 produces at -O4, about 2/3 the time (but I'm not sure if any of this is due to inlining). The algorithm is restoring division but unrolled and heavily optimized. Could this get in gcc or avr-libc, wherever the right place is? Hi Ambroz, What's difficult is to balance different needs of different users. For the most part, and there are always exceptions to this, most of the AVR GCC users are interested in code size, rather than speed. They would rather see the smallest way to do division, even if it is slower. But I also recognize that there are definitely times where speed is the most desired. So given that, where do you think it best for your algorithm to generated? Should it be generated at a specific optimization level in gcc? Should it be a specialized inline-assembly function call in avr-libc that is specifically called by the user? You said that it's faster than what gcc produces about 2/3 of the time, but you're not sure if that is due to inlining. Can you do some further testing to see if it's due to inlining? Or whether it's because your algorithm is better? This is important to know, to see if it's worth the time and effort to get it in gcc or avr-libc. Thanks, Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] SPMCR poisoning workaround for ATmega128
Hi John, Since this will be on your local installation, there's really no right or wrong way to do it. Like you said, if you toggle the *DEPRECATED_ENABLE identifier, then it unpoisons everything else; you may not want to do that. If you remove the poison from the header file, then you may unknowingly use it elsewhere. The real issue, the way I see it, is that boot.h uses SPMCR, when it shouldn't. Therefore I would recommend removing the check from boot.h. And of course the real fix should be done in avr-libc. Eric -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of John Beard Sent: Thursday, May 30, 2013 9:06 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] SPMCR poisoning workaround for ATmega128 Hi, I have run in bug #36410 while trying to compile for a mega128: In file included from main.c:13:0: /usr/lib/gcc/avr/4.7.0/../../../avr/include/avr/boot.h:112:16: error: attempt to use poisoned SPMCR The poisoning is in iom128.h, line 1246: #pragma GCC poison SPMCR I know this is in the bug tracker, but I was wondering how best to patch my local code for now. I could remove the poison from iom128.h, toggle __AVR_LIBC_DEPRECATED_ENABLE__ (but also unpoison everything else), or define out the check in boot.h for this device. Which of these (or some other alternative) is most advisable? Best regards, John ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [avr-libc-commit] [2386] Submitted by Fr?\195?\169d?\195?\169ric Nadeau:
-Original Message- From: avr-libc-commit-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-commit-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Friday, May 03, 2013 9:04 AM To: avr-libc-com...@nongnu.org Subject: [avr-libc-commit] [2386] Submitted by Fr?\195?\169d?\195?\169ric Nadeau: Revision: 2386 http://svn.sv.gnu.org/viewvc/?view=revroot=avr- libcrevision=2386 Author: joerg_wunsch Date: 2013-05-03 15:04:06 + (Fri, 03 May 2013) Log Message: --- Submitted by Fr?\195?\169d?\195?\169ric Nadeau: There are ASCII codes for those characters. Which system doesn't like them? ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [avr-libc-commit] [2386] Submitted by Fr?\195?\169d?\195?\169ric Nadeau:
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Weddington, Eric Sent: Friday, May 03, 2013 9:47 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [avr-libc-commit] [2386] Submitted by Fr?\195?\169d?\195?\169ric Nadeau: Revision: 2386 http://svn.sv.gnu.org/viewvc/?view=revroot=avr- libcrevision=2386 Author: joerg_wunsch Date: 2013-05-03 15:04:06 + (Fri, 03 May 2013) Log Message: --- Submitted by Fr?\195?\169d?\195?\169ric Nadeau: There are ASCII codes for those characters. Which system doesn't like them? Nevermind. Just saw your answer... ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [avr-libc-commit] [2358] Reverted month_length() back to using the 'knuckles' algorithm.
Hi Mike,
See inline below...
-Original Message-
From: avr-libc-commit-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-libc-commit-bounces+eric.weddington=atmel@nongnu.org]
On Behalf Of Mike Rice
Sent: Tuesday, April 23, 2013 3:30 PM
To: avr-libc-com...@nongnu.org
Subject: [avr-libc-commit] [2358] Reverted month_length() back to using
the 'knuckles' algorithm.
Log Message:
---
Reverted month_length() back to using the 'knuckles' algorithm. Easier
to understand, and a couple words less FLASH.
snip
===
--- trunk/avr-libc/libc/time/month_length.c 2013-04-21 16:25:30 UTC
(rev 2357)
+++ trunk/avr-libc/libc/time/month_length.c 2013-04-23 22:30:20 UTC
(rev 2358)
@@ -38,7 +38,11 @@
uint8_t
month_length(int year, uint8_t month)
{
-if (month == 2) return 28 + is_leap_year(year);
+if (month == 2)
+return 28 + is_leap_year(year);
Thanks for putting that on two lines. It reads better.
-return 30 + ((month + month / 8) 1);
You're dividing by 8. Did you try replacing the divide with a right shift?
Would that get you better code size?
+/* 'knuckles' algorithm */
+if (month 7)
+month++;
+return 30 + (month 1);
}
___
avr-libc-commit mailing list
avr-libc-com...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-commit
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] A few questions
I concur with Joerg on all items below. Eric -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Saturday, April 20, 2013 1:40 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] A few questions As Michael Rice wrote: If there are no objections, I will change set_system_time( struct tm *) into set_system_time(time_t) Your reasoning makes sense. As there's no released version of the time (sub)library in avr-libc yet, we don't have to care much for backwards compatibility, so right now is probably the best time to still change it. If there are no objections, the above mentioned functions will be declared with __attribute__((weak)) I don't think that's necessary. Your library is modularized well. As the linker only pulls modules out of the archive that satisfy an unresolved external symbol, modules for things which are already present in the user's application (like time()) simply won't be considered for inclusion from the library at all. Personally, I feel that if is best left as is, and that second best is ... uint8_t month_length( struct tm *); I would like to hear from you about your opinion, what works best for you? It's probably really a matter of opinion. I don't see a need to change it, frankly. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Time after time
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Michael Rice Sent: Friday, April 05, 2013 12:22 PM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Time after time I think I will back off now, and wait for feedback. The time functions compile with -Wall -Wextra -Werror -pedantic , under 4.3.2 and 4.7.2 Cool! :-) I saw a bugzilla report that 4.8 apparently does not like my usage of _MEMX in strftime(). Since I have not yet built the 4.8 toolchain, I have no insight, but it appears to be an issue with 4.8 itself. However, I am keeping watch on the issue. Excellent. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Time
w00t! :-) -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Michael Rice Sent: Friday, March 29, 2013 3:15 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Time Amazing what a few hours sleep can do for ones attitude! I fixed my svn problem, time is now in the repository. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Time library
Hi Mike,
With avr-libc, where the functions are implementing some standard, we try to
adhere to that standard.
There are Standard C library functions. Users know this and don't create
functions that collide with the Standard C library. If someone includes
time.h (or avr/time.h, as the case may be), then they should expect that the
time API is available and they shouldn't create functions that collide with it.
We should not have to create a configuration switch --without-time, because
that also implies we should create a configuration switch for every single API
grouping in avr-libc; that's just ridiculous. Same with prefixing all the
functions; again that's ridiculous because most of them are Standard C
functions that have standard names anyway.
I'll be the first to admit that I'm not that familiar with various time API
standards. Is there a particular standard that you're implementing? If so, that
should basically inform you, and the users, how to implement and use it the
best.
HTH,
Eric
-Original Message-
From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On
Behalf Of Michael Rice
Sent: Wednesday, March 27, 2013 2:54 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] Time library
A question has arisen about the possibility of 'collisions' of
application defined functions, with the avr-libc time functions.
Is this something we should worry about? Personally I do not think it
will be an important issue, but I would like to have the opinion of
the developers.
I spent some time on Google, searching various combinations of time,
time.h, atmel, avr, atmega, time(), time_t and mktime(). I did not
find much, mostly complaints that time.h is not implemented in avr-
libc.: {
My personal ( read: biased! ) opinion is to implement time.h more or
less as-is, and provide a configuration switch, --without-time perhaps.
Another palliative may be to split time.h into ephemera.h,
time_extras.h, and time.h... or something along those lines.
A third palliative is to prefix all our functions, for example with
avr_. I really don't like that one.
I would like to hear the opinion of others on this issue, perhaps some
has a better solution.
===
In other news, I have rearranged some things, added copyright and $ID
$to each file, and have a good start on the Doxygen stuff, its really
going faster than what I expected!
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Porting RTEMS patches to avr-libc
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Rolf Ebert Sent: Sunday, January 20, 2013 3:34 AM To: Cynthia Rempel Cc: avr-libc-dev@nongnu.org; Joel Sherrill Subject: Re: [avr-libc-dev] Porting RTEMS patches to avr-libc The patches in AVR-Ada are mostly kludges to get gcc going with my limited knowledge and they are not worth to be submitted upstream. Hi Rolf, But at some point it would be great to be able to have the Ada compiler for the AVR build out-of-the-box. Whatever patches are needed should eventually get upstream. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Porting RTEMS patches to avr-libc
Hi Cynthia, Joel!
Happy New Year to you both! (We just got done watching the Rose Parade. ;-)
I've added the avr-libc-dev mailing list on this email, so the other developers
are aware of this and can comment.
First, I think it's great that you're working on this, and I'm all for having
RTEMS synced with avr-libc, as much as is feasible.
The current release of avr-libc is 1.8.0, though we've been discussing recently
about fixing a bunch of bugs on HEAD for a future 1.8.1 release. So, I would
definitely suggest taking a look at porting 1.8.0, or even better making sure
that it works with HEAD.
Avrtest is what is being used to test with the GCC testsuite. Although I
thought some work was also being done with simulAVR to make it work with the
GCC testsuite (perhaps someone else on this list can confirm or correct me if
I'm wrong).
Additional recommendations: IIRC, there are some specific GCC bugs that are
avr-rtems specific (though less than a handful). Eventually, you, or someone
else on the RTEMS team, may want to take a look at those.
Joel and I have talked off and on over the years, and as I understood it, RTEMS
was using newlib for its C library. Does RTEMS now use avr-libc? Or just a
portion of avr-libc?
If RTEMS will be using avr-libc on a more permanent basis for the future, then
perhaps we'll want to make sure that we coordinate testing, bug fixing, etc.
@Joel: I'm curious, do you know of any commercial uses of RTEMS on the AVR
(that you can mention)? (You can send that to me privately if you need to.)
HTH,
Eric Weddington
-Original Message-
From: Cynthia Rempel [mailto:cynt6...@vandals.uidaho.edu]
Sent: Tuesday, January 01, 2013 10:43 AM
To: joel.sherr...@oarcorp.com; Weddington, Eric
Subject: Porting RTEMS patches to avr-libc
Hi Eric Weddington,
Happy New Year!
I'm looking at helping with updating the avr port of RTEMS, and came
across some of the differences between the RTEMS avr-libc and avr-libc-
1.6.8 (the version that is currently in RTEMS). I went ahead and used
subversion to generate a patch for avr-libc that should provide some of
the same functionality that is in RTEMS avr-libc. There are only three
for the subversion version of interrupt.h, because one of the changes
appears to already have been applied. It appears that Ralf Corsepius
ralf.corsep...@rtems.org made the changes to the RTEMS tree on 2011-02-
11...
I do have some questions though:
Should we still use the avrtest, as opposed to another simulator, such
as simulAVR?
Should we look at porting avr-libc 1.8.0, or should we look to port
another version of avr-libc to RTEMS?
Do you have any additional recommendations / hints for updating the
RTEMS AVR port?
Thanks!
Cynthia Rempel
Index: interrupt.h
===
--- interrupt.h (revision 2303)
+++ interrupt.h (working copy)
@@ -228,21 +228,21 @@
# if defined(__AVR_MEGA__) __AVR_MEGA__
#define ISR_ALIAS(vector, tgt) extern C void vector (void) \
__attribute__((signal, naked, __INTR_ATTRS)); \
- void vector (void) { asm volatile (jmp __STRINGIFY(tgt) ::);
}
+ void vector (void) { __asm__ volatile (jmp __STRINGIFY(tgt)
::); }
# else /* !__AVR_MEGA */
#define ISR_ALIAS(vector, tgt) extern C void vector (void) \
__attribute__((signal, naked, __INTR_ATTRS)); \
- void vector (void) { asm volatile (rjmp __STRINGIFY(tgt)
::); }
+ void vector (void) { __asm__ volatile (rjmp __STRINGIFY(tgt)
::); }
# endif /* __AVR_MEGA__ */
#else/* !__cplusplus */
# if defined(__AVR_MEGA__) __AVR_MEGA__
# define ISR_ALIAS(vector, tgt) void vector (void) \
__attribute__((signal, naked, __INTR_ATTRS)); \
- void vector (void) { asm volatile (jmp __STRINGIFY(tgt) ::);
}
+ void vector (void) { __asm__ volatile (jmp __STRINGIFY(tgt)
::); }
# else /* !__AVR_MEGA */
# define ISR_ALIAS(vector, tgt) void vector (void) \
__attribute__((signal, naked, __INTR_ATTRS)); \
- void vector (void) { asm volatile (rjmp __STRINGIFY(tgt)
::); }
+ void vector (void) { __asm__ volatile (rjmp __STRINGIFY(tgt)
::); }
# endif /* __AVR_MEGA__ */
#endif /* __cplusplus */
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Porting RTEMS patches to avr-libc
Hi Cynthia,
[Be sure to Reply All, and keep the avr-libc-dev mailing list in the CC
section when replying.]
You may have quicker success with using avrtest, but do keep simulavr on the
back burner.
I (and probably others here too) will be interested in your progress! :-)
Eric
-Original Message-
From: Cynthia Rempel [mailto:cynt6...@vandals.uidaho.edu]
Sent: Tuesday, January 01, 2013 2:44 PM
To: Weddington, Eric; joel.sherr...@oarcorp.com
Subject: Porting RTEMS patches to avr-libc
Hi Eric,
Thanks for the fast response!
Now that I know simulAVR may be a desirable target, I'll keep
researching the feasibility of running RTEMS on simulAVR then.
Depending on the feed-back, we'll look into porting to the head until
there is an 1.8.1 release...
Most of RTEMS uses newlib as it's C library... It appears that avr-
libc/include/avr and rtems/cpukit/score/cpu/avr/avr have VERY similar
files. Figuring out what white space is important will be an
interesting challenge, the patch addresses all the differences aside
from white space and comments in those two directories...
The other folder with avr specific support is: c/src/lib/libbsp/avr it
appears there are some files written by the AVR community in there as
well, and so differences there will need to be identified.
As there is less than a handful of rtems specific bugs, I could look at
them (no guarantee we could fix them :)... Thanks for the suggestion!
Cynthia Rempel
From: Weddington, Eric [eric.wedding...@atmel.com]
Sent: Tuesday, January 01, 2013 10:31 AM
To: Cynthia Rempel; joel.sherr...@oarcorp.com
Cc: avr-libc-dev@nongnu.org
Subject: RE: Porting RTEMS patches to avr-libc
Hi Cynthia, Joel!
Happy New Year to you both! (We just got done watching the Rose Parade.
;-)
I've added the avr-libc-dev mailing list on this email, so the other
developers are aware of this and can comment.
First, I think it's great that you're working on this, and I'm all for
having RTEMS synced with avr-libc, as much as is feasible.
The current release of avr-libc is 1.8.0, though we've been discussing
recently about fixing a bunch of bugs on HEAD for a future 1.8.1
release. So, I would definitely suggest taking a look at porting 1.8.0,
or even better making sure that it works with HEAD.
Avrtest is what is being used to test with the GCC testsuite. Although
I thought some work was also being done with simulAVR to make it work
with the GCC testsuite (perhaps someone else on this list can confirm
or correct me if I'm wrong).
Additional recommendations: IIRC, there are some specific GCC bugs that
are avr-rtems specific (though less than a handful). Eventually, you,
or someone else on the RTEMS team, may want to take a look at those.
Joel and I have talked off and on over the years, and as I understood
it, RTEMS was using newlib for its C library. Does RTEMS now use avr-
libc? Or just a portion of avr-libc?
If RTEMS will be using avr-libc on a more permanent basis for the
future, then perhaps we'll want to make sure that we coordinate
testing, bug fixing, etc.
@Joel: I'm curious, do you know of any commercial uses of RTEMS on the
AVR (that you can mention)? (You can send that to me privately if you
need to.)
HTH,
Eric Weddington
-Original Message-
From: Cynthia Rempel [mailto:cynt6...@vandals.uidaho.edu]
Sent: Tuesday, January 01, 2013 10:43 AM
To: joel.sherr...@oarcorp.com; Weddington, Eric
Subject: Porting RTEMS patches to avr-libc
Hi Eric Weddington,
Happy New Year!
I'm looking at helping with updating the avr port of RTEMS, and came
across some of the differences between the RTEMS avr-libc and avr-
libc-
1.6.8 (the version that is currently in RTEMS). I went ahead and
used
subversion to generate a patch for avr-libc that should provide some
of
the same functionality that is in RTEMS avr-libc. There are only
three
for the subversion version of interrupt.h, because one of the changes
appears to already have been applied. It appears that Ralf Corsepius
ralf.corsep...@rtems.org made the changes to the RTEMS tree on 2011-
02-
11...
I do have some questions though:
Should we still use the avrtest, as opposed to another simulator,
such
as simulAVR?
Should we look at porting avr-libc 1.8.0, or should we look to port
another version of avr-libc to RTEMS?
Do you have any additional recommendations / hints for updating the
RTEMS AVR port?
Thanks!
Cynthia Rempel
Index: interrupt.h
===
--- interrupt.h (revision 2303)
+++ interrupt.h (working copy)
@@ -228,21 +228,21 @@
# if defined(__AVR_MEGA__) __AVR_MEGA__
#define ISR_ALIAS(vector, tgt) extern C void vector (void) \
__attribute__((signal, naked, __INTR_ATTRS)); \
- void vector (void) { asm volatile (jmp __STRINGIFY
Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
Joerg, do you have any idea how much this function is actually used? I might be open to doing some renaming, if the pain that it would cause existing users is minimal. I think it would be a good idea to support xmega users too. Eric -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of mojo Sent: Tuesday, December 11, 2012 7:29 AM To: Joerg Wunsch; mojo; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect Follow-up Comment #2, bug #37901 (project avr-libc): Okay, but in that case I think that needs to be made clear. The standard CCITT CRC should produce an endian and bit-order independent result that is compatible with other implementations. I understand that it is designed to be compatible with the IRDA standard, but it appears to be a mistake on their part or at least the result of confusion over which version people are usually referring to by that name. As I pointed out, the biggest issue for me is that it is incompatible with the XMEGA CRC module's implementation. Renaming the functions is probably out of the question now, but the documentation should at least be amended to make it clear which one you might want to use. There are lots of threads on AVR Freaks from confused programmers wondering why it doesn't work. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?37901 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
-Original Message-
From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On
Behalf Of Joerg Wunsch
Sent: Tuesday, December 11, 2012 8:39 AM
To: avr-libc-dev@nongnu.org
Cc: mojo
Subject: Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
All the functions of this header file (_crc16_update which once
started the file but uses the IBM-CRC-16 polynomial,
_crc_xmodem_update, _crc_ccitt_update, and finally
_crc_ibutton_update) have been deliberately chosen to lie in the
implementation namespace so they don't collide with the application
namespace.
Thus, an application could do something like this:
#if defined(__AVR__) defined(__GNUC__)
# define crc_ccitt_update(c, v) _crc_ccitt_update(c, v)
#else
inline uint16_t crc_ccitt_update(uint16_t crc, uint8_t data)
{
data ^= crc 0xff;
data ^= data 4;
return uint16_t)data 8) | ((crc 0xff00) 8))
^ (uint8_t)(data 4)
^ ((uint16_t)data 3));
}
#endif
Then how about a name that is more meaningful intuitive?
From experience, you can tell users all day long in the documentation, and in
the FAQ, to use _crc_xmodem_update() and they still won't get it.
Can we create an alias macro? _crc_xmega_ccitt_update()? Then put the
explanation in the docs.
We need to support the xmega users better. If they're getting easily confused,
then we need to help.
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Tuesday, December 11, 2012 9:01 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect As Weddington, Eric wrote: Can we create an alias macro? _crc_xmega_ccitt_update()? Then put the explanation in the docs. Why not just _crc_xmega_update()? Sure. I don't really care about the specific name as long as it makes sense to our users. @mojo/Paul: Would you be willing (and able) to work up a patch for avr-libc to do this (once the details are agreed on)? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Erik Walthinsen Sent: Tuesday, December 11, 2012 9:03 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect On 12/11/2012 07:50 AM, Weddington, Eric wrote: We need to support the xmega users better. If they're getting easily confused, then we need to help. It took me a while to discover that the Xmega CCITT wasn't the same as the avr-libc function, and yes, the difference between _xmodem and _ccitt isn't all that well described (esp if/since they're actually inverse of each other polynomial-wise). Plenty of trouble finding the right Python code to insert into my passive bus sniffer too. Not looking forward to figuring out CRC-32 re: the NVM, the CRC module, and python. That *should* be easier since they claim it's 802.3 and afaik crc32 is quite a bit more standardized, but... The key for me was finding this page: http://www.lammertbies.nl/comm/info/crc-calculation.html Sorry for the hassle, Erik. Thanks for telling your story and providing the link. Please send ideas for improvement. We're always open-minded, but just sticklers for detail (as I'm sure you can tell). Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Erik Walthinsen Sent: Tuesday, December 11, 2012 9:20 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #37901] CRC-CCITT calculation incorrect On 12/11/2012 08:07 AM, Weddington, Eric wrote: Please send ideas for improvement. We're always open-minded, but just sticklers for detail (as I'm sure you can tell). One option might be to retain the current function solely as #defines, but make the *actual* functions strictly defined by their properties: __crc16_1021_() __crc16_8408_() etc. My only concern is that those names are not particularly mnemonic. :-P I much prefer descriptive names for functions, especially for a library. I would be ok with something like CCITT_little_endian, CCITT_big_endian (note these are just examples). Let's leave the hexadecimal for machine code, if possible. :-) Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Georg-Johann Lay Sent: Sunday, December 02, 2012 12:06 PM To: Joerg Wunsch Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? Ok, thanks for the feedback. Eric says the same. Conclusion: No matter how had it is needed to compile code for XYZ. No matter how well it is explained and documented. No matter how small the delta to -mmcu=xyz is People won't use it. Just so you know, I'm deeply sympathetic towards your viewpoint. I really wish it were different. It's only been my experience of doing this for a long period of time (and Joerg, even longer than I) that has taught me otherwise. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Erik Walthinsen Sent: Friday, November 30, 2012 9:38 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? On 11/29/2012 11:20 PM, Joerg Wunsch wrote: Still, if it's not the IDE that does it on their behalf, most of those professional ARM developers are hosed. They solely rely on their (often payware, like CodeSourcery) IDE to do it for them. If the IDE doesn't do it, they are standing in about the same rain as an AVR developer whose device is not supported by the toolchain. I've looked at using a number of ARM chips (stm32, Freescale MC13224, and others) and constantly run into that problem. I will not use an IDE let alone a manufacturer's IDE, so I have to try to figure out all the arcana for that chip and hope I can get it working in one of the 17 generic Cortex toolchains, or roll my own. It's insane, especially when the manuf seems to provide multiple incompatible sets of files. Good feedback! The AVR approach is somewhat more user-friendly, in that you can add a single -mmcu option, and then compile your sources the same simple way as you would e.g. be able to compile code for your host computer. I gave a talk at DEFCON this last year about MC13224-based 6LowPAN hardware we're trying to get moving, Cool! Do you have any public links to your talk? and while I doubt most of the audience understood exactly what I was talking about here, the -mmcu function of the avr toolchain is *by far* the best lead AVR has on ARM at this point, for that exact reason. I know that ARM GCC has a similar switch. IIRC, it only selects the core. However, that's not the way the GNU tools would currently work. And no, the GCC specs file wasn't really an alternative: first, it would not work for binutils anyway. Then, it's got an incomprehensible syntax (even for seasoned developers), and changes were needed in many places to add a single device. In order to be really able to offload new device support to the end user, it has to be a one-liner (or perhaps, a one-record addition, like to an XML file), and it must be possible to do this at run-time, without recompilation. Honestly I've got to wonder if LLVM does this any better. I know basically nothing about it except that it's not quite up to GCC's standards yet, but it might have potential and be more properly layered. In terms of the code, yes it is, I think, better layered. But that's mainly because GCC is quite a mess. I'm not sure if LLVM necessarily solves the problem any better. FYI, there's an open source project that adds the AVR backend to LLVM. It's currently on SourceForge (name: avr-llvm). In the meantime I've built a python script that very carefully goes into all the files in gcc, binutils, and avr-libc that have references to the Xmega parts, and pulls from a master list I derived from Digikey to rewrite all those sections. It's a very poor substitute and doesn't scale to any of the other chips, but it should get the Xmega patch put together with the least possible inconsistency... For avr-libc, this would be even harder though, as some of the device support is really compiled in right now. But I think if the other tools agreed on such a central device definition file, we could start an effort to generalize avr-libc as well (perhaps accompanied by a script that recreates some of the device-dependant header files from a template file, based on those device definitions). I think extending AVR-style -mmcu into the ARM world is absolutely possible, *iff* there is a shift in how devices are described as you suggest. Short of entirely new instruction sets, it should be possible to *trivially* define a new processor in the same style as avrdude does currently, and have *all* the tools reference it at run-time. The only thing the toolchain should need a recompile for is new family opcodes, or updated optimizations. Would it be even remotely practical to do this within the existing binutils/gcc/avr-libc setup? It seems to me that if there were a way of removing the individual devices from the entire binutils/gcc codebase in favor of *nothing* but the families (avr5, avr6, atxmega5, etc.) and rewrite the -mmcu handling so it looks at a directory containing the relevant config, crt, linker, and even header files for each chip and hands them off internally (and to binutils) as appropriate. Basically it would be a thin *top*-level wrapper (inside gcc getopts) around what Johann suggests that people do now (which I've done *once* in coercing gcc to compile to the attiny15), rather than having the -mmcu decisions made all the way down the stack. Unfortunately as I've said before, I know *very* little about the structure of either binutils or gcc, having
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: Erik Walthinsen [mailto:om...@omegacs.net] Sent: Friday, November 30, 2012 10:49 AM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? On 11/29/2012 02:55 PM, Weddington, Eric wrote: Well, go ahead and post the patches then. :-) Let's get you up and going... Ironically I think I have all the *codebase* changes in place, but am having problems figuring out how to convert the XML files into headers Is that something I should be worrying about myself, or is that something you need to add to the patch yourself for copyright reasons? Not sure what you mean by that... The header files go into avr-libc, which just has the BSD license. All we require of submitters, is that they license their work with the same license (for consistency purposes). You would retain the copyright. Code going into binutils and gcc is a different matter as the FSF (owner of those projects) require a copyright assignment for any non-trivial work (defined as greater than 10 lines of code). Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: Erik Walthinsen [mailto:om...@omegacs.net] Sent: Friday, November 30, 2012 3:40 PM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? I thought I read a while back that since the headers are strictly derived (by scripts, the part I haven't worked out yet) Yes, there are conversion scripts of a sort. from the Atmel-owned XML that there were some ownership issues. Since my solution here to make things built was to literally straight-copy the headers from the ASF install on my Windows VM, it's even more dodgy in that sense. That is dodgy; Atmel owns the copyright on those files. It's not within your right to submit a work that you don't own the copyright on. That's why I suggested it would be better to let device support, or at least the header file part, come from Atmel. I'd class these as trivial patches (they're done in a for() loop...) but they're more than 10 lines. If they're more than 10 lines, the FSF does not classify that as trivial. I can do the copyright assignment, or I can just email you my script and let you take ownership of the binutils and gcc changes if that's more expedient. Well, we can talk about it. Obviously it would be better if you did the copyright assignment. But from experience, it's also a giant PITA, especially if you have an employer who might have a claim on your work (because you would need their permission to do this). But if the work is small enough, and you don't care, then we could probably work out some arrangement. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Friday, November 30, 2012 4:18 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? As Weddington, Eric wrote: (XML) That is dodgy; Atmel owns the copyright on those files. It's not within your right to submit a work that you don't own the copyright on. Well, back in the era when Ted Roth did most of the work here, the statement he got from Atmel was that using (or copying) the XML file literally is prohibited, but taking whatever information out of it, and store just that information separately is fine. This statement is what eventually led to the idea that's still present in the xml/ subdirectory: convert the Atmel XML files into a format that belongs to avr-libc, and create all the avr-libc internal information from that format. Bottom line: if anyone derives a header file from the Atmel XML files, the original Atmel copyright (for the XML file) does not apply to the derived work. Totally agreed. To be clear, I was referring to the header files that *Atmel* has generated from their own XML files. It's those header files that can't be submitted by anyone outside Atmel. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
Hi Erik XMega device support is coming out of Atmel. I'm reviewing a second draft of patches for binutils at the moment. Joerg and Georg-Johann have been reviewing this patches as well. Regarding device support, I would hold off doing any work until I can confirm that everything is in order for gcc and avr-libc. The main thing I was interested in was if anyone would be interested in helping a bit on the bug list. Thanks, Eric -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Erik Walthinsen Sent: Thursday, November 29, 2012 2:05 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? On 11/16/2012 11:05 AM, Weddington, Eric wrote: Any help from those of you who are *not* regular contributors would be very much appreciated. Ways that you can help: If you think you know how to fix a particular bug (and header file bugs are generally the easiest to fix), then you can help by working up a patch that we can immediately apply. It helps to provide a full patch, with changes to the NEWS file and a Changelog entry, according to policy. If SVN trunk is considered accurate, then a large amount of Xmega device support is missing (e.g. every -U device for instance). The fact that it's also missing from binutils and gcc doesn't help, but I'll see if I can put together a patch for avr-libc SVN at least. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Erik Walthinsen Sent: Thursday, November 29, 2012 3:52 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? I really don't have that option, since I'm shipping products based on chips that are not supported in this toolchain. I have to maintain my own patches to all the tools in order to do my job. I've been fighting this exact problem for over 3 years now. Hmm. Good point. Well, go ahead and post the patches then. :-) Let's get you up and going... ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Friday, November 16, 2012 9:59 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? I agree that we should at least have a glance at the bugs and patches before rolling a new release. Yes, it seems to have been accumulating... BTW, do we have an up-to-date list of tool prerequisites to properly build avr-libc and documentation? It seems I'm failing to build the documentation properly (fails building refman.pdf in doc/api/latex_src). ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 1.8.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Weddington, Eric Sent: Friday, November 16, 2012 11:04 AM To: Joerg Wunsch; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] 1.8.1? I agree that we should at least have a glance at the bugs and patches before rolling a new release. Yes, it seems to have been accumulating... I've gone through the bug list. A lot of old issues, new issues, stuff half-fixed (which I'm guilty of that too), etc. I've marked bugs that we need to either get fixed, or addressed in some way, with a Priority of 9-Immediate. That gives us a list of 41 bugs, some of which go back 4 years. :-P Any help from those of you who are *not* regular contributors would be very much appreciated. Ways that you can help: If you think you know how to fix a particular bug (and header file bugs are generally the easiest to fix), then you can help by working up a patch that we can immediately apply. It helps to provide a full patch, with changes to the NEWS file and a Changelog entry, according to policy. Thanks, Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] 1.8.1?
Hi All, It seems like it's been forever since we've had a discussion... Do you think we have enough changes in the repo to warrant a 1.8.1 release? Or should we get some bugs fixed and devices supported (yes, I know that last one is a discussion) before such a release? Thanks, Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Possible hole in the assembler interrupt documentation
Hi Brendan, Thanks for pointing this out. Admittedly, there are not a lot of people who write their ISR in assembly. Most are able to write their ISRs in C. Would you be willing to fill out a bug report on the avr-libc project? Emails have a tendency to be forgotten about over time and we want to make sure that we capture this issue in our system so we can get the documentation fixed. Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Brendan Hanna Sent: Thursday, November 01, 2012 6:09 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Possible hole in the assembler interrupt documentation Hello, I have just spent some time trying to get my freshly minted interrupt vector to linked into my executable and appear in the vector table at the start of flash. I feel that there is a small, but non-obvious hole in the interrupt documentation that could be patched up. I had written my ISR in assembler but for the life of me could not figure why it had not been linked into the main application. I thought the 1.6.4 libc documentation was implying that all I needed to do was name the vector with one of the standard vector names (PCINT0_vect in my case), and like magic all the pieces would come together. It took me some time to realise that the vector would not be considered for linking unless its object file contained a dependency required by the main object file. In real life this would probably be achieved with some ISR initialisation code defined in the assembly source file and called at start up. My organically growing code did not have this yet - so I had to falsify it with a global variable accessed by the main application but defined in assembly. I thought raising this issue here could help improve the documentation a little. Thanks, bOfWagg ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Possible hole in the assembler interrupt documentation
You're right. That's exactly what we need. Eric -Original Message- From: Dale [mailto:d...@4drealtime.co.za] Sent: Thursday, November 01, 2012 9:05 AM To: Weddington, Eric Cc: brend...@computer.org; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Possible hole in the assembler interrupt documentation Hi, Its not just an assembler issue, I've been bitten by this with 'C' code as well. If the ISR is the only code compiled into an object module, ie. with no references to code or variables in other object modules, it won't be linked into the app. It would be useful if there was an attribute on all ISR declarations which indicate to the linker that they are to be kept regardless of whether they are referenced by other code. Hi Brendan, Thanks for pointing this out. Admittedly, there are not a lot of people who write their ISR in assembly. Most are able to write their ISRs in C. Would you be willing to fill out a bug report on the avr-libc project? Emails have a tendency to be forgotten about over time and we want to make sure that we capture this issue in our system so we can get the documentation fixed. Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Brendan Hanna Sent: Thursday, November 01, 2012 6:09 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Possible hole in the assembler interrupt documentation Hello, I have just spent some time trying to get my freshly minted interrupt vector to linked into my executable and appear in the vector table at the start of flash. I feel that there is a small, but non-obvious hole in the interrupt documentation that could be patched up. I had written my ISR in assembler but for the life of me could not figure why it had not been linked into the main application. I thought the 1.6.4 libc documentation was implying that all I needed to do was name the vector with one of the standard vector names (PCINT0_vect in my case), and like magic all the pieces would come together. It took me some time to realise that the vector would not be considered for linking unless its object file contained a dependency required by the main object file. In real life this would probably be achieved with some ISR initialisation code defined in the assembly source file and called at start up. My organically growing code did not have this yet - so I had to falsify it with a global variable accessed by the main application but defined in assembly. I thought raising this issue here could help improve the documentation a little. Thanks, bOfWagg ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #37627] #define PA0_DDR DDRADC without ever defining DDRADC
Hi Frédéric, I think we'll need your help to get it in. I don't have the time at the moment to look into it. :-/ Eric -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Frédéric Nadeau Sent: Wednesday, October 24, 2012 9:40 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #37627] #define PA0_DDR DDRADC without ever defining DDRADC Did the Device Pin Definitions made it into avr-libc yet? It kinda look like what I did a while ago. http://svn.savannah.nongnu.org/viewvc/trunk/avr- libc/include/avr/iotn261a.h?revision=2063root=avr-libcview=markup https://code.google.com/p/avr- drv/source/browse/trunk/src/io_pin/iotn261a_pin.h Eric Weddington: Would you like to integrate part of my project into avr-libc so that device pin definition would be available for most devices? If so, let me know I'll be willing to help. On Wed, Oct 24, 2012 at 11:13 AM, anonymous invalid.nore...@gnu.org wrote: URL: http://savannah.nongnu.org/bugs/?37627 Summary: #define PA0_DDR DDRADC without ever defining DDRADC Project: AVR C Runtime Library Submitted by: None Submitted on: Wed 24 Oct 2012 03:13:11 PM UTC Category: Header Severity: 3 - Normal Priority: 5 - Normal Item Group: Header files Status: None Percent Complete: 0% Assigned to: None Originator Email: samwise.gam...@gmx.net Open/Closed: Open Discussion Lock: Any Release: 1.8.0 Fixed Release: None ___ Details: A number of header files contains macros definitions like: #define PA0_DDR DDRADC #define PA0_PORT PORTADC #define PA0_PIN PINADC #define PA0_BIT ADC0 or #define PCINT1_DDR DDRADC #define PCINT1_PORT PORTADC #define PCINT1_PIN PINADC #define PCINT1_BIT ADC1 without ever defining DDRADC, PORTADC, ADC0... I assume these lines were supposed to read: #define PA0_DDR DDRA #define PA0_PORT PORTA #define PA0_PIN PINA #define PA0_BIT 0 ?? This applies to all device pin definitions in: avr/iotn861a.h avr/iom88pa.h avr/iotn20.h avr/iotn461a.h avr/iotn40.h avr/iotn261a.h ___ Reply to this item at: http://savannah.nongnu.org/bugs/?37627 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Missing _vect_num defined for older devices
Hi Uwe, Older devices, *may* not have the vector number defined. But I thought that our intention was to make sure to add this information to all device header files. Certainly, some of the older device header files may have been accidently overlooked. You can file a bug report at the avr-libc project and let us know which devices are missing this information. Even better is if you have a patch that fixes the problem. :-) Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Uwe Bonnes Sent: Monday, September 10, 2012 3:24 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Missing _vect_num defined for older devices Hello, is iit intended that older devices like e.g. iom128.h don't define the vector number like newer device, e.g. iousbxx6_7.h do? Thanks -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] fflush() implementation
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Monday, August 27, 2012 10:45 AM To: AVR-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] fflush() implementation As Philipp Schafft wrote: Please note that fflush() doesn't do that on any system. It only flushes the buffers within the FILE* object. This is the most convincing argument so far. As avr-libc's stdio does not perform any buffering at the stdio level, fflush() can only be implemented as a no-op. Hmm. Very good point. Thanks for catching that Philipp and Joerg. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] fflush() implementation
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Daniel Otte Sent: Friday, August 24, 2012 1:55 PM To: AVR-libc-dev@nongnu.org Subject: [avr-libc-dev] fflush() implementation So a possible solution would be to extend the __file struct with a field containing a pointer to a driver provided flush-function and registering this function via a dedicated function. This has the two cons, that the structure would require more space (2 bytes) and that another auxiliary function is required. I would prefer this solution over changing the prototype of the supplied put-function. Of course, I don't like much adding a couple of bytes to the FILE structure for a field that is rarely used. But then again, there are tradeoffs wherever you go and resources of some sort will be needed to implement this functionality. The registration function could be an inline function or macro, since all it will do will be to assign the function pointer to the structure field. It's a simple matter to add code to fflush() to check if the field is not NULL and to call the registered callback function. BTW, thank you for offering to write up the patch! :-) That helps immensely when proposing new functionality! I'll wait to see what Joerg has to say about all this... Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] fflush() implementation
-Original Message-
From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-
libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Georg-
Johann Lay
Sent: Friday, August 24, 2012 4:19 PM
To: Daniel Otte
Cc: AVR-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] fflush() implementation
Daniel Otte schrieb:
Hi,
the current state of fflush() according to stdio.h is:
Flush \c stream.
This is a null operation provided for source-code compatibility
only, as the standard IO implementation currently does not perform
any buffering.
This is ok for the stream implementation itself if it is not buffering, but
if
the device driver which forms the base of the stream performs buffering it
may
be would like to be informed if fflush() is called to flush its own buffers.
I currently run into this case because I have an interrupt-driven UART
component
which manages its own buffers. And especially during debugging fflush() is
very
helpful as messages may get stuck in the buffer before a crash and you are
searching for the problem at the wrong location.
A possible solution would be using a dedicated flush-function provided by
the
driver but this is neither elegant nor very portable.
Well, if it's only about debugging an application by ad-hoc sprinkling
commands over the file, I think portability is no issue. Changing the
ABI for a transient use case like this is not appropriate, IMO.
By the same token, having a non-functional fflush() in avr-libc that doesn't do
anything, just so it can offer source code compatibility seems a bit silly. At
least the proposed feature actually does something with it.
I'm not opposed to changing the ABI, provided we do it with intent to offer
good functionality as a trade-off. Of course, I agree that we should do it
carefully.
You could write your application as usual:
#include stdio.h
int main (void)
{
return fflush (stdout);
}
In Projects where you use AVR-Libc, supply a C module fflush.c and
a header fflush.h
fflush.c implements fflush to whatever you deem appropriate.
When linking, you link fflush.o to your application, and when
compiling, you compile with -include fflush.h
fflush.h could look like that:
#ifndef FFLUSH_H
#define FFLUSH_H
#define fflush fflush_be_gone
#include stdio.h
#undef fflush
extern int fflush (FILE*);
#endif /* FFLUSH_H */
That's it.
No need to change the tools or the ABI.
No need to change yours or others system headers.
No need to explicitly #include fflush.h
It' all hidden behind two command options in your Makefile
or build script.
And if you want to run your code without the fflush you
can simply make fflush void or activate in fflush.h a line like
#define fflush(X) (void)(X)
That's certainly another good way of doing it. :-)
Do we have fflush() as a weak symbol?
Eric
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated
-Original Message- From: David Brown [mailto:da...@westcontrol.com] Sent: Wednesday, August 15, 2012 1:04 AM To: Weddington, Eric Cc: John Voltz; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated On 14/08/2012 22:50, Weddington, Eric wrote: Ah, ok. That package contains *patches* to the indicated released versions. Since the avr-libc and avr-gdb subdirectories are empty, that means that there were no patches to the released versions that was used in building the AVR Toolchain. We're working right now to correct that for the next (upcoming) release of AVR Toolchain to make sure that we also offer the full modified source in addition to the patches. Will you keep the patches clearly available as well? Yes, I said above that we working to provide both. Incidentally, is there a source of the patches other than via Atmel's website and the toolchain downloads? It doesn't hinder me unduly that you have to fill in a form to register for each download (though it irritates me immensely), but I can imagine that some people disapprove of it. I would expect that people making packages for Debian, for example, would be uncomfortable with the idea. Is there any sort of publicly available website showing the current list of patches, or an overview of what they are? (This is just out of curiosity on my part.) We're working on that part, too. Stay tuned. ;-) Of course, the ideal situation is that there are no patches - but gcc development does not tend to work like that! And it's unrealistic. New devices are always coming out, and support for those devices has to be added, and it doesn't always match the release cycles of GCC and of toolchain distributions. There's just too many tools and projects involved, each with their own release cycle. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #37104] ATtiny5/9/10/20/40 interrupt wrapper uses invalid register
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Dean Camera Sent: Wednesday, August 15, 2012 10:04 AM To: Joerg Wunsch; Dean Camera; Jonathan Oakley; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #37104] ATtiny5/9/10/20/40 interrupt wrapper uses invalid register Follow-up Comment #3, bug #37104 (project avr-libc): I don't have access to the internal tracker at home, but this specific issue has been corrected in an internal build of the toolchain and should be released soon. Joerg: can upstream GCC not use the patches Atmel provides in their toolchain releases? Hi Dean, I'm working with our compiler team to get patches upstream. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated
-Original Message- From: John Voltz [mailto:invalid.nore...@gnu.org] Sent: Tuesday, August 14, 2012 8:23 AM To: Weddington, Eric; John Voltz; avr-libc-dev@nongnu.org Subject: [patch #7830] avr-libc headers are very outdated Follow-up Comment #2, patch #7830 (project avr-libc): Specifically, avr-libc doesn't have the headers or libs for the XMEGA A4U, and from what my diff shows, a lot of other new devices are missing as well. New device support is not technically a bug report. Yes, I'm aware that there are new devices in the Atmel toolchain that is not reflected in the upstream projects of binutils, gcc, and avr-libc. I'm working with our internal team to get patches upstream. Eric Weddington Marketing Manager Open Source Community Atmel ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated
-Original Message- From: John Voltz [mailto:john.vo...@gmail.com] Sent: Tuesday, August 14, 2012 8:38 AM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [patch #7830] avr-libc headers are very outdated Eric, I have also submitted a bug report to Atmel. I'm hoping to get the toolchain patches included with Atmel Studio 6 in sync with the upstream. Again, it's being worked on, but there may be a number of formatting issues that have to be ironed out. I'm trying to use Studio 6 more, but we have a Linux build/programming system here that will not accept the A4U as a valid target for these reasons. I completely understand. We want to make sure that the work that has been done is in the upstream projects to make sure that users on other platforms are supported. Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated
-Original Message- From: John Voltz [mailto:john.vo...@gmail.com] Sent: Tuesday, August 14, 2012 9:06 AM To: David Brown Cc: Weddington, Eric; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [patch #7830] avr-libc headers are very outdated Thanks David, I just downloaded the toolchain source from Atmel's website. I opened up the zip file and the directories for avr-libc and avr-gdb are empty. :( :-( What location did you download from? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of David Brown Sent: Tuesday, July 24, 2012 1:40 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline... On 23/07/12 21:00, Joerg Wunsch wrote: As Weddington, Eric wrote: I would hate to say, We have to use C99 for some avr-libc modules (atomic.h), but we guarantee C89 compliance for other avr-libc modules (delay.h). We really should be consistent across the whole project. Which means that if we guarantee C89 compliance for one module, then it needs to be guaranteed for everything in avr-libc, and we document what standard we comply too. I'd say we *guarantee* C99 compliance, but wherever compliance to older standards could be reasonably had, I don't mind maintaining it that way. Whenever compliance to C89/C90 would require a tradeoff, C99 takes precedence. However, writing a couple of underscores in front of a keyword is nothing worth talking about, I think. Another data point: In the somewhat standard Makefile that we put together for AVR applications, we always set the --std flag to gnu99 for compiling AVR applications. Well, gnu99 is yet another thing, we should make sure everything works with c99 (i.e., without the GNU extensions). For my 2 øre, I agree mostly with this. In the case of adding a couple of underscores, it should not be too much hardship. But I also see Erik's point - how much should people bother making headers C89 compatible if few people use it that way, and other headers will never be C89 compatible? Is it really practical to use avr gcc without gnu extensions? What about pedantic mode? One case that springs to mind here is when people have to follow a particular coding standard, such as Misra (which is C89 based, IIRC), or who have to program in a particular variant such as strict ANSI. It is very useful in such cases to be able to compile the code in C89 or ANSI mode, since that lets the compiler spot errors better. Should these users be told that they can use most of the library, excluding specific parts such as atomic.h, or should they be told that nothing is going to work? Do the C99-specific headers check __STDC_VERSION__ to give a user-friendly error message if someone tries to use them in C89 mode? Finally, I hope all the headers are also C11 compliant for the future... (from what I've read of C11, I can't see any reason why not). A lot of great points above. I agree that talking about 2 underscores is really not that much. I guess it's the larger issue of What standard does avr-libc comply to? And what standard should avr-libc comply to? that I'm concerned about. I can agree that we meet some *minimum* standard, such as C99. Obviously that's a reasonable goal. Is it ok to have some modules that comply to C89, and others that can never comply to C89? How would that benefit the user? The MISRA standard could be important. We would need to find out what C standard it is based on. However, GCC itself does not have a feature to compile to MISRA (AFAIK) so it makes it difficult to fully comply. (Though I've wanted to add that feature to GCC for years.) I do think that perhaps we ought to start using __STDC_VERSION__ to give user-friendly error messages so that way we don't run into this issue again. This goes beyond just the adding of two underscores for delay.h. And lastly, I don't know much about C11 to say, but I would think that at the least it would be a superset of C99. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Tuesday, July 24, 2012 9:44 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline... As David Brown wrote: Agreed - though it is possible that some parts might require gcc extensions to C99. What should be done if gcc extensions are not required, but would allow the generation of better (smaller/faster) code? One possible situation here is when attributes such as const or pure would allow better optimisation. So far, I don't know of any of the GCC extensions which could not be brought in by either escaping them with two underscores, or explicitly declaring them being __extension__. That way, you can still compile the code with either -std=c89 -pedantic or -std=c99 -pedantic without getting complaints. After all, we (as vendor of a system library) are the prime reason for allowing that kind of properly marked extensions. Ok. The above seems reasonable to me. Sorry for the long discussion over two underscores. ;-) Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Monday, July 23, 2012 9:10 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline... As Weddington, Eric wrote: ...instead of __inline or similar to make it work together with -std=c89 Sorry, but what's the bug here? That our library code is supposed to be compatible to any -std= option (except where documentation explains something else, e.g. in the util/atomic.h stuff). Oh, so it needs to be __inline to comply with that? Sorry, but Johann's English was a little confusing to me as to what was the intention. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Monday, July 23, 2012 9:36 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline... As Weddington, Eric wrote: Oh, so it needs to be __inline to comply with that? Right. The counter argument, though, is that C89 is already pretty old. Do we need to comply with that standard? Or are we just going to comply with the C99 standard? What is our policy? (Sorry, but it's been a while since we've had this discussion that I've forgotten.) I thought at one point we said that we would comply with C99, but no earlier. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Monday, July 23, 2012 9:56 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline... The policy is to be as liberal as reasonably possible. ;-) Well, is it? We can make whatever policy is reasonable... In the current case, replacing the inline by __inline (to force it into the implementation namespace) is no big deal, so I'd take that route. OTOH, Dean Camera's util/atomic.h implementation would not be possible that way without using the C99 addition to declare a variable within a for statement, so we documented it that way. Most of GCC's extensions are available even with -std=c89 mode, by properly marking them as extensions, so that's what I meant with as liberal as reasonably possible. It doesn't cost us anything, but gives users the most possible flexibility. Note that even GCC did not switch to default C99 mode yet; the default mode is still (as of GCC 4.7) gnu89. What GCC does for their project is, I think, somewhat irrelevant to us. GCC is in the (painfully slow) process of making sure that their code base compiles with the latest C++ compiler, so they can eventually start using C++ in their code base. I would hate to say, We have to use C99 for some avr-libc modules (atomic.h), but we guarantee C89 compliance for other avr-libc modules (delay.h). We really should be consistent across the whole project. Which means that if we guarantee C89 compliance for one module, then it needs to be guaranteed for everything in avr-libc, and we document what standard we comply too. Personally, I think that C89 is pretty old, and it's stupid when there is arguably a later existing standard: C99. Another data point: In the somewhat standard Makefile that we put together for AVR applications, we always set the --std flag to gnu99 for compiling AVR applications. I *think* (I would have to look it up for sure) that even Atmel Studio 6 probably uses --std=gnu99 for compilation of AVR applications. Given all this, then why does avr-libc have to be tied to a c89 standard? To be compatible with what? What user is having difficulty with avr-libc such that they need avr-libc to comply with a c89 standard? And is that user in such a small minority? What problem is solved by having avr-libc comply to the older c89 standard? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Some question regarding FP-math
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of David Brown Sent: Sunday, July 01, 2012 7:21 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Some question regarding FP-math Is there any interest in alternative implementations for some of these functions? I've got some code for calculating sines and cosines using a table with cubic interpolation which I used on another processor. It is probably a little bigger than the current avr-libc implementation, but not too bad - with cubic interpolation the table can be a lot smaller than with linear interpolation. It is also not quite as accurate as power-series implementations tend to be, but it is a lot faster, and accurate enough for many uses. I'm sure I could adapt the code to the avr. But I don't know the best way to include such code in avr-libc - because it is not accurate enough for IEEE standards, it can't replace the standard implementations. The goal of avr-libc is to be a Standard C library. Because of that, it does need to meet all relevant standards. However, you could still put together a library to be distributed separately. :-) Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Some question regarding FP-math
Hi Dr. Klein, Yes, this is the right place to ask those questions. However, avr-libc has had on-again, off-again maintenance for its floating point library code, with different maintainers over the years. If you see a place where you are willing to help out, we would certainly welcome the help... Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Dr. Alexander Klein Sent: Monday, June 18, 2012 1:53 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Some question regarding FP-math Hello, I just got myself an Arduino-board to evaluate some algorithms in a more real- world like environment than I get with the slowest Atom-Netbook around approach. I usually prototype the algorithms in GNU-Octave, so I wondered what errors I'd have to expect compared to IEEE double precision math. So, just for the fun of it, I started browsing the source of the FP- implementation and a few things occured to me: 1. Most if not all transcendental functions are implemented as power series approximations, but no hints are given as to their properties of approximation. Are the polynomials or maybe their derivatives optimal in any L_p-sense? Can a description be found anywhere? 2. All we have for the time being is single precision float. Are the functions for power series evaluation optimised so as to minimise summation error? 3. In an old post (http://lists.nongnu.org/archive/html/avr-libc-dev/2006- 04/msg00068.html) someone benchmarked basic arithmetic operations, but only for one platform. How do other platforms perform? Especially, would it be worthwhile to try to speed up multiplication? I hope this is the right place to ask these questions anyway ... Kind regards, Alex -- Dr. Alexander Klein, Diplom-Mathematiker Physiologisches Institut der JLU-Gießen Aulweg 129 35392 Gießen http://www.med.uni-giessen.de/physio/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] including avr/boot.h for xmega devices
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr- libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Omar Choudary Sent: Monday, April 30, 2012 10:30 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] including avr/boot.h for xmega devices I would be grateful if someone could let me know what is the current status on using avr/boot.h with xmega devices. I don't think boot.h has been systematically tested on xmega devices. It probably doesn't work. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #35003] wdt_enable() has a wrong code sequencefor many parts
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Wednesday, December 07, 2011 6:32 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #35003] wdt_enable() has a wrong code sequencefor many parts As Georg-Johann Lay wrote: If it's actually undocumented feature that can be found nowhere (instruction set manual, data sheets, ...) then this needs clarification by means of, e.g. Atmel support ticket. AFAICT, this has been clarified years before Atmel even installed a support ticket system. ;-) We probably have to ask Marek or Denis about the details. And it has been working on the AVR product line for years. In my mind, the question is really: does it work on the XMEGA product line? If not, then we need to change the code. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [avr-gcc-list] [bug #28837] using PSTR with c++ produces warnings
-Original Message-
From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On
Behalf Of Joerg Wunsch
Sent: Tuesday, November 01, 2011 10:08 AM
To: avr-libc-dev@nongnu.org
Cc: avr-gcc-l...@nongnu.org
Subject: Re: [avr-gcc-list] [avr-libc-dev] [bug #28837] using PSTR
with
c++ produces warnings
. use --disable-shared when configuring the gmp, mpc, and mpfr
libraries for your new compiler
(In the latter case, make sure that there are no .so libs from
previous attempts sitting around in ${prefix}/lib.)
Based on experience from previous toolchain compilations, it's also
always a good idea to reset PATH to the minimal elements that are
strictly needed for the compilation, like /bin/:/usr/bin, or
/bin:/usr/bin:/usr/local/bin.
The above advice always worked for me. Personally I don't like messing
around with shared libraries (DLLs) unless I have to. Simplifying the
PATH also has always made building things easier. I do this in my build
scripts. A lot of build problems that I have run into seems to get fixed
quickly by fixing the PATH.
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Saturday, October 29, 2011 4:25 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings As Volker Kuhlmann wrote: Just because someone at Arduino thinks ``4.4.x and 4.5.x seem to have various problems'' is enough to make you not using them? Yes, definitely. Why? I have no other information and know nothing about the avr-gcc specific issues in gcc. The least you could expect them is to explicitly mention *which* problems they have found, either (and preferrably) as references to GCC bug reports, or at least, as detailed descriptions about the problems someone encountered. Without that, it's just babbling. FUD. (Fear, uncertainty, and doubt.) I could tell you as well about GCC 4.3.x having ``several problems'', and by digging through the GCC bug database, I could probably even found this sentences with some substance. ;-) Volker, Joerg, To be fair, the Arduino project is like any other open source project in that they are chronically short of help and they can only focus on there area of expertise. I've talked quite a bit with one of the co-founders of the project, met the whole team, and various other people who help here and there on the Arduino project. The Arduino project focuses on a number of things: - Their hardware design - Their IDE / language - Their support libraries What they don't do is the toolchain themselves. Two reasons why Arduino was able to easily get off the ground is the fact that the AVR microcontroller itself is easy to use, and the fact that there is a free/open source toolchain (GCC) for the AVR. It also helped that WinAVR existed as they just dropped the WinAVR toolchain in their installer package for the Windows platform. So please realize that they are not *trying* to spread FUD. They just don't have the resources to tackle the toolchain issues in-depth. The last thing to remember is that they (Arduino) exercise different areas of the toolchain then most other people. Most users of the AVR GCC toolchain use the C compiler. The Arduino community is the first large set of users that use the C++ compiler for the AVR, which admittedly, hasn't gotten much attention previously. HTH, Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
-Original Message- From: Volker Kuhlmann [mailto:invalid.nore...@gnu.org] Sent: Monday, October 31, 2011 4:16 AM To: Volker Kuhlmann; Joerg Wunsch; Weddington, Eric; avr-libc- d...@nongnu.org Subject: [bug #34695] fixed width int types without __attribute__() Follow-up Comment #5, bug #34695 (project avr-libc): Eric, what changes are you thinking of for better lint-friendliness? I was hoping you could tell me. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings
Hi All, FYI, David Mellis (who wrote the message below) is a member of the core Arduino team. You can see him in a picture with this article: http://spectrum.ieee.org/geek-life/hands-on/the-making-of-arduino These are a group of really good guys. They like the AVR, and they like the AVR GCC toolchain, because of how quickly and easily it enabled them to do their project. One of the eye-opening things for me about the Arduino project is the fact that they generate C++ code for the AVR. Before, I had been on the fence about using C++ on the AVR. I thought that it might have been a bit on the overkill side. Perhaps I've been prejudiced because I grew up using C, a lot. But regardless of what any engineering professional here may think about the Arduino language itself, or the inexperience of their user base, I think that the Arduino project has proven is that C++ can be used on the AVR in real-world projects. I find this to be pretty exciting. It means, to me, that we (as developers working on the AVR toolchain) need to look at more than just the C compiler. That we need to continue to advance in the C++ compiler capabilities, e.g., Joerg and I have talked for years about trying to get libstdc++ built for the AVR. With on-again, off-again work on it. Now there is more of an incentive to continue with that. @David: The first step in working together to solve problems in the toolchain is the bug report. It's ok if you haven't investigated deeply as to the cause of the failure. But we need to know about the bugs to help you guys out. Submitting bug reports to either the binutils or GCC bug databases, that have reproducible bugs, with test code is what is really needed. And if you need any help with that then let us know, and we can walk you through the ropes. Eric Weddington -Original Message- From: David A. Mellis Sent: Monday, October 31, 2011 7:15 AM To: Weddington, Eric Cc: Joerg Wunsch; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings Thanks for the message, Eric. As you say, we don't really have enough time to properly investigate the toolchain and bugs. I've had various reports of various Arduino functions breaking with newer versions of binutils (2.21, I believe) and haven't had the resources to track those reports down to the underlying toolchain bugs or changes. Of course, I have lots of respect and appreciation for all the work you guys do. And I realize that vague reports of problems don't help you fix them. That's why in general I've just gone with whatever Eric packages up in WinAVR as the toolchain for Arduino. We're eagerly awaiting the next release. :) David On Oct 31, 2011, at 9:02 AM, Weddington, Eric wrote: -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Saturday, October 29, 2011 4:25 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings As Volker Kuhlmann wrote: Just because someone at Arduino thinks ``4.4.x and 4.5.x seem to have various problems'' is enough to make you not using them? Yes, definitely. Why? I have no other information and know nothing about the avr-gcc specific issues in gcc. The least you could expect them is to explicitly mention *which* problems they have found, either (and preferrably) as references to GCC bug reports, or at least, as detailed descriptions about the problems someone encountered. Without that, it's just babbling. FUD. (Fear, uncertainty, and doubt.) I could tell you as well about GCC 4.3.x having ``several problems'', and by digging through the GCC bug database, I could probably even found this sentences with some substance. ;-) Volker, Joerg, To be fair, the Arduino project is like any other open source project in that they are chronically short of help and they can only focus on there area of expertise. I've talked quite a bit with one of the co-founders of the project, met the whole team, and various other people who help here and there on the Arduino project. The Arduino project focuses on a number of things: - Their hardware design - Their IDE / language - Their support libraries What they don't do is the toolchain themselves. Two reasons why Arduino was able to easily get off the ground is the fact that the AVR microcontroller itself is easy to use, and the fact that there is a free/open source toolchain (GCC) for the AVR. It also helped that WinAVR existed as they just dropped the WinAVR toolchain in their installer package for the Windows platform. So please realize that they are not *trying* to spread FUD. They just don't have the resources to tackle the toolchain issues in-depth. The last thing to remember
Re: [avr-libc-dev] [bug #34695] fixed width int typeswithout __attribute__()
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Georg-Johann Lay Sent: Monday, October 31, 2011 3:30 PM To: Bob Paddock Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #34695] fixed width int typeswithout __attribute__() But why clutter avr-libc with lint? You will have __attribute__((progmem))from PROGMEM and PSTR macros __attribute__((signal)) from ISR macro __attribute__((interrupt)) for ISR code __attribute__((naked)) for custom startup/ISR bits __attribute__((OS_main))AVR-specific __attribute__((OS_task))AVR-specific __attribute__((noinline)) __attribute__((always_inline)) __attribute__((noclone)) __attribute__((const)) __attribute__((pure)) __attribute__((noreturn)) so you could just do #define __attribute__(...) or it's command line equivalent to get rid of all the messages. BTW: What will (sp)lint to with named address space qualifiers? Either it must be able to be told that there is special semantics or you end up dirscarding hundreds of potential RAM - Flask access failures when ignoring the qualifier. Ugh. You're right, Johann. Thanks for bringing up that point. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause relocation truncated to fit: R_AVR_13_PCREL linker error
-Original Message- From: Jan Waclawek [mailto:invalid.nore...@gnu.org] Sent: Tuesday, September 27, 2011 8:30 AM To: Jan Waclawek; Georg-Johann Lay; Weddington, Eric; avr-libc- d...@nongnu.org Subject: [bug #33698] Explicit use of RJMP/RCALL can cause relocation truncated to fit: R_AVR_13_PCREL linker error Follow-up Comment #4, bug #33698 (project avr-libc): It appears to me that most of those 135 places (those which rcall to external label, perhaps indentified by the _U() macro) are potential errors, e.g. http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=108109 and many more. But changing them to regular jumps, and then using -relax if minimal code is desired, should be an acceptable solution. I'd say this has been already discussed, see http://lists.gnu.org/archive/html/avr-gcc-list/2011-06/msg00025.html and other posts of that thread. Thanks for the discussion memory refresh! I agree, then, they all need to get fixed. I had forgotten about -ffunction-sections, which then the user could rearrange at will in a custom linker script, which could then easily fail. :-( ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
-Original Message- From: Jan Waclawek [mailto:konf...@efton.sk] Sent: Tuesday, September 27, 2011 1:37 AM To: Weddington, Eric; Bill Westfield; Jan Waclawek; Jan Waclawek; Georg- Johann Lay; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal What exactly do you mean by safe in this context, and how could that be discovered or shown? The user who wants to declare a variable to be positioned in FLASH (code memory), and obeys the deprecation warning, is now presumably recommended to write the PROGMEM keyword after the type, e.g. unsigned char PROGMEM. How exactly could a macro expanding into the same sequence be unsafe? Good question, which I don't have an immediate answer for. I guess I'm just trying to challenge interested parties to think of a way to come up with a counter-example where this macro might fail. If, after some thought, a counter-example can't be found, then it would be really helpful if one of you could post a patch to do the change to a macro (with the doxygen documentation change too). A little help with this would be appreciated. :-) Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Working towards a 1.8.0 release
Hi All, We're working towards a 1.8.0 release. So for those of you on this list who are not a regular developer on avr-libc, now would be a good time to get in any last minute bug reports or patches. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
-Original Message- From: Jan Waclawek [mailto:invalid.nore...@gnu.org] Sent: Monday, September 26, 2011 12:48 PM To: Jan Waclawek; Georg-Johann Lay; Bill Westfield; Weddington, Eric; avr- libc-...@nongnu.org Subject: [bug #33716] pgmspace typedefs not legal Follow-up Comment #3, bug #33716 (project avr-libc): Rather than deprecating the typedefs in pgmspace.h, I would suggest to replace them by respective macros. What macros do you want them replaced with? ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
Until such time that it can be shown that replacing them with macros is a safe alternative, then they will stay as deprecated, as deprecation is a known safe alternative. If someone should discover that replacing them with macros are deemed safe, then a patch should be provided. Eric -Original Message- From: Bill Westfield [mailto:wes...@yahoo.com] Sent: Monday, September 26, 2011 3:41 PM To: Jan Waclawek; Jan Waclawek; Georg-Johann Lay; Weddington, Eric; avr- libc-...@nongnu.org Subject: Re: [bug #33716] pgmspace typedefs not legal Rather than deprecating the typedefs in pgmspace.h, I would suggest to replace them by respective macros. That would be nice, but I don't think it's possible. There are too many places where: #define prog_uchar unsigned char PROGMEM would behave differently than typedef unsigned char PROGMEM prog_uchar; Although I confess I'm having a hard time thinking of them... BillW ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [avr-libc-commit] [2252] Add macro avr_libc_revision_suffix, to provide a potential suffix that
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Thursday, September 22, 2011 6:47 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [avr-libc-commit] [2252] Add macro avr_libc_revision_suffix, to provide a potential suffix that As Weddington, Eric wrote: The last time we talked about a release was to do 1.8.0, after we go through the bug list. Oops, you're right, I eventually forgot about that. ;-) OK, so consider it being a 1.8.0-rc, despite of its name ... After all, the reason for the 1.8 bump was the poisoning of the deprecated stuff, which is already present here anyway. Yeah, and we still need to go through that bug list. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Library per device
Hi All, What would it take to change avr-libc to build as a library-per-device? Right now, it's library-per-architecture. I would like to add some new code, but code that might really need to build per-device. Any thoughts on what the migration path might be? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Test suites?
There is a limited test suite for avr-libc. Though I can't recall if there's anything for pgmspace.h. What non-AVR processor are you building a shim for? -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Bill Westfield Sent: Saturday, August 13, 2011 6:00 PM To: AVR-libc-dev@nongnu.org Subject: [avr-libc-dev] Test suites? Are there any test suites of the avr-libc functions/etc? I'm particularly looking for things that test pgmspace.h; I've been working on a shim for non-AVR processors and it'd be nice to test most of it really quickly... Thanks Bill W ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Test suites?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Bill Westfield Sent: Sunday, August 14, 2011 4:36 PM To: Joerg Wunsch Cc: AVR-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Test suites? What non-AVR processor are you building a shim for? PIC32 (so that ChipKit can run more Arduino software, actually.) My apologies. Why would you want to do that? Do you work for Digilent? ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] UCSR1D register is not defined for ATmega16U4/32U4
Have you tried again recently? -Original Message- From: Alexander Saydakov [mailto:sandy_sayda...@yahoo.com] Sent: Tuesday, July 26, 2011 11:07 PM To: Weddington, Eric; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] UCSR1D register is not defined for ATmega16U4/32U4 Action Unavailable: Being logged-in is required to post on this tracker. I tried to register some time ago, and it did not work. - Original Message From: Weddington, Eric To: Alexander Saydakov; avr-libc-dev@nongnu.org Sent: Tue, July 26, 2011 9:27:23 AM Subject: RE: [avr-libc-dev] UCSR1D register is not defined for ATmega16U4/32U4 Hi Alexander, Could you please fill out a bug report at the avr-libc project here?: https://savannah.nongnu.org/bugs/?func=additemgroup=avr-libc Because emails get lost in our inbox very quickly. Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Alexander Saydakov Sent: Monday, July 25, 2011 11:18 PM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] UCSR1D register is not defined for ATmega16U4/32U4 Hi! ATmega16U4 and Amega32U4 have the control register D, which is not defined in both iom16U4.h and iom32U4.h Here is the datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc7766.pdf Please have a look at the page 209. Thanks. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] UCSR1D register is not defined for ATmega16U4/32U4
Hi Alexander, Could you please fill out a bug report at the avr-libc project here?: https://savannah.nongnu.org/bugs/?func=additemgroup=avr-libc Because emails get lost in our inbox very quickly. Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Alexander Saydakov Sent: Monday, July 25, 2011 11:18 PM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] UCSR1D register is not defined for ATmega16U4/32U4 Hi! ATmega16U4 and Amega32U4 have the control register D, which is not defined in both iom16U4.h and iom32U4.h Here is the datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc7766.pdf Please have a look at the page 209. Thanks. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Georg-Johann Lay Sent: Saturday, July 09, 2011 4:26 AM To: Georg-Johann Lay; Bill Westfield; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal Follow-up Comment #1, bug #33716 (project avr-libc): As Bill already wrote, attribute progmem just works by accident in avr-gcc ( and not at all in avr-g++). It appears that const prog_char c = 'a'; works for C and not for C++. However, there is *no* support for progmem in types it in avr-gcc and there is no guarantee that it will work for any code imagineable. I highly recommend to deprecate types like prog_char: typedef char __attribute__((progmem,deprecated)) prog_char; or typedef char __attribute__((progmem,deprecated(message))) prog_char; Notice that despite progmem, deprecated *is* documented for types. As the next release of avr-libc will come with bulk of poison, anyway, this bit of deprecation won't hurt and will help users to write more robust code. Agreed, Johann. This should be done before the next release of avr-libc which will be 1.8.0. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] avr-libc: optimization for ltoa/printf
Hi Dmitry, Thanks for looking at this optimization. I would be interested to know how the algorithm also compares on code size. This is another important metric for avr-libc. And could you please subscribe to the avr-libc mailing list? That way your posts do not have to be approved. :-) Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Dmitry E. Oboukhov Sent: Thursday, June 16, 2011 11:53 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] avr-libc: optimization for ltoa/printf Hi, There! Now avr-libc uses division cycles when it converts number to string. Benchmarks page (http://www.nongnu.org/avr-libc/user- manual/benchmarks.html) says that ltoa (12345L, s, 10) requires 3174 - 3136 cycles for the conversions. If we use the other algorithm, we can reduce the time more than three times. in attache I placed a test-file that contains 'my_ultoa' function. my_ultoa(12345L, s, 10) requires 924 MCU cycles. against ultoa(12345L, s, 10) - 3174 But that algorithm can be realized only for some radixes, so the function can be used if one of realized radixes is in third argument. Also function __ultoa_invert can use the algorithm (it is called from *printf), so using the algorithm we can spend less time then current variant. The algorithm can be realized for uint, it will more fast. Sometimes conversion time is very important (for example if we realize some text network protocols) so I think that algorithm can be used in functions ltoa/itoa/*printf :) What do You think about this algorithm? PS: sorry for my bad English -- . ''`. Dmitry E. Oboukhov : :' : email: un...@debian.org jabber://un...@uvw.ru `. `~' GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Bradley Jarvis Sent: Monday, May 23, 2011 10:46 PM To: Joerg Wunsch; Bradley Jarvis; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h Follow-up Comment #3, patch #7464 (project avr-libc): Ok then, I did not realise that iom186p.h is auto generated. My problem is that I have a board that started development life with an atmega168 on it, since it is now hard to get it has been replaced with the atmega168p (and there is also a atmega168v) I have updated to the newer chip. There are several differences with names between the iom168.h and iom168p.h that have caused re-compilation problems. One was the vector names, I though that SIG_ were the newer ones not the ones that have been replaced, no problems I can update my code for this to work. I took a look at our current documentation for interrupt names: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html Section Choosing the vector: Interrupt vector names. It describes the two different naming systems, but you're right, it doesn't seem to explicitly say that the SIG_ names are deprecated. Joerg, we will need to change that. There is a problem however with the port bit names though. iom168.h (or iomx8.h) names them PA0 PB0 etc, iom168p.h names them PORTA0 PORTB0 etc. and neither file have the other definition. Maybe a better fix then for this instance is to add the PORTA0, PORTB0 etc #defines to the iomx8.h file. I can make this change and update the patch files to add the PORTxx #define if you want. Take a look at avr/portpins.h. This header is automatically included when you include avr/io.h Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h
-Original Message- From: Bradley Jarvis [mailto:b...@pocketinnovations.com.au] Sent: Tuesday, May 24, 2011 7:51 AM To: Weddington, Eric Cc: Joerg Wunsch; avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h Take a look at avr/portpins.h. This header is automatically included when you include avr/io.h Eric Thanks Eric, I don't know how I missed this since portpins.h was around in 2009, I'm sure I remember compiler complaints about the port pin names, but it was a while ago(at least a few years maybe) that I ran into this problem. I just removed my patch and recompiled the code and now the only complaint is about the vector names. So please ignore this patch, I will use the _vect vectors from now on. No worries. Sometimes it seems that there's actually a lot more in avr-libc then is really advertised. Usually because we've run into these situations before. We know that the documentation for avr-libc could use a little bit of work (as almost all software projects could). Like Joerg said, I'm glad it's working for you! :-) Let us know if there's anything else that needs fixing. We always appreciate input. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Tuesday, May 24, 2011 3:17 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [patch #7464] Fix iom168p.h to be compatible withiom168.h snip I took that idea to generate the avr-libc XML format (but never committed those files itself to the tree), and used that as a base for the interrupt documentation. This also included a kind of backannotation of the SIG_* vector names (which cannot be safely deduced from the Atmel XML files). But that's now all obsolete, as I never maintained that flow, and we've now got yet another converter, basically required for the Xmega stuff (which was not covered by Ted's design). Ah, I see. There is also the issue of deprecations. Deprecations in the IO header files can't easily be automated. You end up with exceptions to a build script for almost every single header file. This necessitates maintaining the header files by hand after the *initial* header file generation. No, it could have been handled by adding an attribute in the avr-libc XML. The only downside I see with that, is that the XML files then have to be maintained by hand. Something has to be maintained by hand, whether source XML file, or header file. At least with the current system, we only have one set of files (headers) to maintain. Speaking of which, you closed a bug or two recently with some renamed values. You haven't answered yet my email about if you want to deprecate the old names using our new deprecation system... Sorry, I forgot. No, I wouldn't deprecate them. After all, users might have written code based on a (once) legitimate copy of that AVR's datasheet, using a name described there. Even though the current datasheet doesn't mention that name anymore (and in many cases, it doesn't even mention that renaming in the datasheet history), it has once been valid, and it's not the user's fault. After all, renaming actions like this one have been very rare. Except that the older names were always commented as deprecated. We need to decide on a policy and stick with it. I would think that if an identifier in the XML file was renamed, that we deprecate the old one, and add the new one. Btw., with all the poisoning of the SIG_* vector names, some existing code out in the field won't compile out of the box anymore, Well, that's kind of the point. It can be recompiled successfully with a conditional definition before the headers are included. so I think the next avr-libc version will be named 1.8.0 (rather than 1.7.2) to make the users aware of the larger change. Ok, I support that. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] at90usbxx2.h missing CLKSEL0/1 and CLKSTA registers
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Markus Lampert Sent: Saturday, May 14, 2011 12:43 PM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] at90usbxx2.h missing CLKSEL0/1 and CLKSTA registers I just noticed that declarations for CLKSEL0, CLKSEL1 and CLKSTA are missing in the at90usbxx2.h header file. Did you check the datasheet? Did you check the latest XML device files that come with AVR Studio? Did you check which version you're using and compare that with the latest header file in the SVN repository in avr-libc? Did you fill out a bug report on the avr-libc project? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] at90usbxx2.h missing CLKSEL0/1 and CLKSTAregisters
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Markus Lampert Sent: Saturday, May 14, 2011 1:21 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] at90usbxx2.h missing CLKSEL0/1 and CLKSTAregisters - yes I did check the datasheet (that's how I know they exist). - no I did not check XML device files, I don't have AVR Studio - I did check the svn repo (trunk) Ok, thanks. - couldn't find instructions on how to fill out a bug report - pointers appreciated Avr-libc project here: https://savannah.nongnu.org/projects/avr-libc Scroll down to Bug Tracker, click on Submit New Item. Note, you have to have a Savannah login ID/password to add a new bug report. That way information about the status of the bug report is automatically emailed to you, and we can also contact you if we have any questions. Thanks for letting us know about this bug. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] at90usbxx2.h missing CLKSEL0/1 and CLKSTA registers
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Saturday, May 14, 2011 1:54 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] at90usbxx2.h missing CLKSEL0/1 and CLKSTA registers As Weddington, Eric wrote: Did you check the latest XML device files that come with AVR Studio? I've got earlier XML files around, they contain these definitions, yes. Thanks for checking, Joerg. :-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] Thoughts on release?
Hi All, Any thoughts to the timing of a 1.7.2 release? Thanks, Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] Thoughts on release?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Wednesday, May 11, 2011 2:33 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Thoughts on release? Give me some time for a thorough sweep through the bug and patch list before. Hey, I had a thought. (Scary, I know.) Do you think that we might be able to do a first and completely clear out the bug list for avr-libc? I don't even remember the last time we did that. It was probably when Ted was on board... ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a
Hi Chris, Mostly, yes. Libgcc is absolutely needed as it contains certain math library routines and other routines that gets used in the startup code. Libgcov is generally not needed, and I'm not sure that it even works for the AVR. Yes, the include files that GCC installs are useful. For example GCC installs stdbool.h and stdint.h. I use bot of those extensively in an AVR application. Other header files may not be used as much, but typically they are standard files so should be available for any conforming target. Yes, there is fixed point math available for the AVR via a patch from a volunteer, and should be in the latest AVR Toolchain release from Atmel. We're currently working on getting that patch committed upstream along with some others. So overall, yes most of them are absolutlely needed, or very useful to have. Avr-libc does not provide everything. Sure there are some things that are borderline, but at this point it hasn't been worth the time to go in and pinpoint disable certain things. I know that there has been some recent work on the GCC toplevel to reorganize how it works. Perhaps when this work is done it might be easier to do that. HTH, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Chris Marrin Sent: Wednesday, May 04, 2011 11:16 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a I'm building avr-gcc from source and along with it, the two above mentioned libraries get built for several avr architectures: avr2 through avr5.1. It also provides a version of libiberty.a and installs some includes such as stdint.h and varargs.h. Are any of these libraries and includes needed for AVR development or does avr-libc provide everything you need? Do any of these things even work for AVR? There is also an include for stdfix.h and I know fixed point in particular is not yet supported. So, when I package up avr-gcc and avr-libc do I need to worry about these other libraries? - ~Chris ch...@marrin.com ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a
-Original Message- From: Chris Marrin [mailto:ch...@marrin.com] Sent: Wednesday, May 04, 2011 7:21 PM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] avr-gcc, libgcc.a and libgcov.a Yes, it is very helpful. One other question is what is the purpose of libiberty.a? It's in the path lib/ which seems very odd if it's an AVR specific library. Is it just there to allow building the tools? Can I ignore it? Libiberty is a library that comes with GCC (though it can be it's own separate library) that has common functionality across multiple platforms, including various Linux flavors and Windows. It's known as a compatability library. It's mainly used in building GCC itself for whatever host is specified. The reason for the weird name has to do with library names and what GCC searches for. GCC uses the -l switch to specify the name of the library to link in. However the library name must be in the form of libname.a. So, for example, on the linking command line you will see -lc given to GCC. This means that GCC will search for the filename libc.a, which happens to usually be the Standard C library for the target compiled for. Well since the filename of the library is libiberty.a, this means that the linker switch to find the file must be: -liberty, i.e. 'freedom' from the host system's idiosyncrasies. Get it? ;-) snip I Like this hierarchy because it keeps all the things that run on the host in directories that correspond to the system structure (in fact, you could install them in /usr or /usr/local directly and not have any conflicts). And it keeps target libraries and includes in avr/. But in looking at how gcc does it, they put all the target files into 'lib/gcc/target/version. That's nice because it allows you to have different libraries for each version of gcc you have. This is something avr-libc doesn't do. You just have to either build the libraries with the version of avr-gcc on your machine, or hope they're compatible with the compiler you're using. So it seems like it would be best to have avr-libc install itself alongside the other system files, i.e.: lib/ gcc/ avr/ 4.5.2/ include/ the avr-libc include hierarchy the avr-libc lib hierarchy A structure like this would allow you to install everything in /usr/local without any avr specific directory paths. Everything in bin has an avr prefix, the only thing in etc is avrdude.conf, things in lib are designed to go in target specific places, and the man pages all have avr prefixes like the binaries. I'm going to try to make an installer with this structure, just to see how it feels. I'd be happy to work on patching the avr-libc if it seems like it would be useful. Unfortunately, no, it would just add more confusion. The GCC compiler driver program understands that there may be multiple versions of GCC installed. This program driver understands how to look for the proper version for it's internal libraries, like libgcc. But you need to understand that the C library is always a separate project. Any target could use different kinds of C libraries, and there are several different projects: glibc (gnu c library), newlib, uclibc, eglibc, and others. Avr-libc is yet another one in that list, with one beneficial difference: it's specific to the AVR target. This means that it's optimized well for the AVR and it also contains other AVR specific functionality beyond just the standard C library, which in our case is a good thing. Because all of these C libraries are not a part of GCC, GCC does not internally know what to do if multiple versions of the C library are installed. How could it know? Which one should it link to? Especially in our case, the C library is built after the compiler is already built. This is why there is only one version of the C library installed at a time. Also, most users would be confused if confronted with multiple C libraries in their installation. Which one should they use? Typically the latest version of avr-libc is the best one to choose, unless there is something really broken on the latest release (we've had one of those recently, but luckily those instances are rare). So my best advice to you: pick the latest release of avr-libc, build and and install it. You usually can't go wrong. This philosophy has been working for users of WinAVR for the last 8 years, typically without much issue or complaint. HTH, Eric Weddington ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Patches for 1.7.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Per Arnold Blaasmo Sent: Friday, March 25, 2011 2:29 AM To: avr-libc-dev@nongnu.org Subject: FW: [avr-libc-dev] Patches for 1.7.1? Hi, You guys must remember that these patches is the one Atmel currently uses in the toolchain built for AVR Studio 5. It is not the official avr-libc patches. The avr-libc might or might not accept these patches in the future and make a new version of avr-libc with these patches. Atmel hope the project will want to use them. Atmel will always be in front of the community project internally so Atmel will probably always have patches to the latest public version. Regarding build errors, they should of course not be there. But currently the state of the AVR Studio 5 is changing before a public release and there might be error. Putting those patches on the website is an answer to the debate about whether waiting until we do a official public release of AVR Studio 5 or doing it with each beta release. Putting Atmel's patches on the website was only required to conform to the GPLv3 license. It is required to conform to the GPLv3 license regardless of how AVR Studio 5 is labeled. The GPLv3 doesn't care if you call it a beta release or not. If you convey the executable (object) code to a user, you are required to provide the source code. And this was only required for GNU Binutils, GCC, and GDB as they are the ones with a GPLv3 license. Putting patches to other projects on the Atmel website is only a nice convenience to the rest of the user community. But if Atmel is going to provide such a convenience, then it behooves you to make sure that it actually works. Regarding public or non-public devices. Atmel do have some devices that needs some basic support and Atmel wants to have that in the toolchain. For the non-public parts Atmel need to keep header files and some other description files away from public. I am sure you all can understand that. Yes, absolutely. Then don't provide those avr-libc patches in the publicly available patch set. That should solve the build error problem. avr-libc has made itself dependent on some header file info to be able to generate a crt0.o file for each device. I would like that dependency to be removed (like other libc project is not dependent on each devices header files), so that Atmel can release non-public packages to customers that are entitled to that to get support for an non-public device without recompiling avr-libc. I hope that can be possible in the future. Probably not. This is the way that is has been working for years. Recompiling avr-libc is not that big of a hassle. You have to recompile binutils and gcc anyway. I was able to provide private part support for customers without requiring any changes. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Patches for 1.7.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Ruud Vlaming Sent: Thursday, March 24, 2011 7:29 AM To: avr-libc-dev@nongnu.org Cc: Per Arnold Blaasmo; Boyapati, Anitha Subject: Re: [avr-libc-dev] Patches for 1.7.1? On Thursday 24 March 2011, Per Arnold Blaasmo wrote: You guys must remember that these patches is the one Atmel currently uses in the toolchain built for AVR Studio 5. It is not the official avr-libc patches. The avr-libc might or might not accept these patches in the future and make a new version of avr-libc with these patches. Atmel hope the project will want to use them. Good point! Would it be an idea to introduce a naming convention so that is clear to anyone? So instead of 40-avr-libc-1.7.1-xmega32X1.patch we would have: 40-avr-libc-1.7.1-atmel-xmega32X1.patch and when the official one comes out: 40-avr-libc-1.7.1-official-xmega32X1.patch These patches could be identical when it is adopted as such by the developers in charge. But it could also be a further improved one. I think this is adding some needless overhead. In reality there is not much time between the avr-libc patches that are used in any toolchain release and getting them accepted into avr-libc. In fact, most of the time, the patches get into the avr-libc release before the toolchain distribution release. This would solve: Atmel will always be in front of the community project internally so Atmel will probably always have patches to the latest public version. Not really. It has always been this and it has never been a problem before. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Patches for 1.7.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Ruud Vlaming Sent: Monday, March 21, 2011 6:37 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Patches for 1.7.1? On Atmels website: http://distribute.atmel.no/tools/opensource/as5-beta/avr8-gnu-toolchain- 3.2.0.255-source.zip there are patches for libc 1.7.1 snip But version 1.7.1 is very new and does it need patching? Furthermore, the first two patches (40, 41) can be applied, but compilation results in an error: snip I am curious at your opinion. Hi Ruud, First off, does binutils and gcc patch cleanly and build correctly? Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Patches for 1.7.1?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Monday, March 21, 2011 9:00 AM To: Ruud Vlaming; avr-libc-dev@nongnu.org Subject: RE: [avr-libc-dev] Patches for 1.7.1? Furthermore, the first two patches (40, 41) can be applied, but compilation results in an error: ... avr-libc-1.7.1/crt1/gcrt1.S:179: Error: non-constant expression in .if statement The last application cannot be applied at all: patching file ./include/avr/power.h Hunk #1 FAILED at 74. Hunk #2 FAILED at 146. Hunk #3 FAILED at 170. Hunk #4 FAILED at 254. Hunk #5 FAILED at 338. I am curious at your opinion. I think those patches are meant for some test devices. They contain dummy header files. Hence build errors. They can be ignored. Are they for test devices? Or are they for new devices? And, really, if they cause build errors and can be ignored, then they should not be in the bundled source code on the Atmel Norway website to begin with. This causes a disservice to the user community. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #32698] power.h has additional endif that willbreak the build system when power_all_disable() is used
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Anitha Boyapati Sent: Tuesday, March 08, 2011 6:17 AM To: Boyapati, Anitha; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #32698] power.h has additional endif that willbreak the build system when power_all_disable() is used Follow-up Comment #1, bug #32698 (project avr-libc): This bug appears in 1.7.1 release. Anitha, there is a separate drop-down box for this information that needs to be set, rather than putting a comment in the bug report. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #32698] power.h has additional endif thatwillbreak the build system when power_all_disable() is used
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Tuesday, March 08, 2011 6:31 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #32698] power.h has additional endif thatwillbreak the build system when power_all_disable() is used As Weddington, Eric wrote: Anitha, there is a separate drop-down box for this information that needs to be set, rather than putting a comment in the bug report. ... which I forgot to update when I rolled the 1.7.1 release. Anitha just reminded me. Oh! Well that would be a problem, then. ;-) Thanks for taking care of that. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Re: [bug #17216] change to the ../util/delay.h header for increased functionality
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Sunday, March 06, 2011 12:14 PM To: Bill Perry; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Re: [bug #17216] change to the ../util/delay.h header for increased functionality As Bill Perry wrote: The only thing left (for me) is the possibility of adding a _delay_ns() function. Are you willing to submit that as a patch against the current SVN version? If so, please don't forget the documentation (which is just the doxygen comment on top of it). The documentation should clearly point out the limits in the applicability of this function, so it's immediately obvious that nobody could expect a 12.5 ns delay on a CPU clocked with 1 MHz. ;-) I question the whole viability of a _delay_ns() function. If someone wants a resolution that small, then they should be able to do the calculation and use the __builtin_avr_delay_cycles() builtin function instead. It should be no more than a few cycles anyway at the clock rates that we're talking about. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Re: [bug #17216] change to the ../util/delay.hheader for increased functionality
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Sunday, March 06, 2011 2:02 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Re: [bug #17216] change to the ../util/delay.hheader for increased functionality But that way, you might as well question the other _delay_*s functions. ;-) They have been created to take off the actual cycle count calculation from the user, to the computer, that's their only purpose. Yes, it's only a few cycles, but the same is true for e.g. _delay_us(12) on a standard AVR running at its default clock of 1 MHz. I don't see a difference here to writing _delay_ns(300) on a modern mega or xmega device running at 20 MHz, and be it only the auto-documentation effect. Ok. I'm convinced. Personally, I just never liked dealing with the whole cycle-rounding bit, and it seemed a bit much for these short delays. But, again, that's just me. I guess now we just need code... ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #32650] Missing include in util/delay.h
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Stu Bell Sent: Thursday, March 03, 2011 9:49 PM To: Alastair D'Silva; Stu Bell; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #32650] Missing include in util/delay.h Follow-up Comment #1, bug #32650 (project avr-libc): The math library is not needed if you do not pass a variable to _delay_ms (or _delay_us) as the instructions to avr-libc warn you not to do. Only constants can be supplied to the delay functions. In fact, following your path will bring in the floating-point library unnecessarily and will cause the delay functions to generate far more delay that requested. Remember, just including a header file (like math.h) does not mean that the library is automatically linked in. The library is only linked in if the linker detects that it is needed. And even then it doesn't pull in the entire library, just the module that is needed. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [RFC] Conditional poisoning of deprecated items
-Original Message- From: John Myers [mailto:atomicdog@gmail.com] Sent: Sunday, February 27, 2011 9:45 PM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [RFC] Conditional poisoning of deprecated items I don't think the type of people that continue to use deprecated symbols will bother with using that define either. I think the default should be to have poisoning on. I would normally agree with that. However, with poisoning on, the macro definitions still generate a warning. I don't want to give the user who uses all up-to-date features a whole bunch of new warnings just to point out deprecated items. If you can figure out a way to have gcc to only give an error on *usage* of a symbol (and not also a warning on the #define) then I think we can certainly do what you suggested. 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] Conditional poisoning of deprecated items
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of David A. Mellis Sent: Monday, February 28, 2011 6:14 AM To: John Myers Cc: avr-libc-dev@nongnu.org; Weddington, Eric Subject: Re: [avr-libc-dev] [RFC] Conditional poisoning of deprecated items Alternatively, is there a way to make this the default, but generate warnings, not errors, for the use of deprecated items? That would make it clear that people are using something that's been deprecated, but allow them to ignore the warning and proceed if they wish. Then there could be an option to disable the warnings, or to turn the warnings into errors. (Or are warnings already generated for deprecated items?) That would be good too. Unfortunately, this method is all I've been able to find so far. If someone discovers a different method that would allow these other capabilities, then I think we could easily change the intent. Whatever method is discovered and used, it has to work on C preprocessor macros too. 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] Conditional poisoning of deprecated items
-Original Message- From: John Myers [mailto:atomicdog@gmail.com] Sent: Monday, February 28, 2011 7:17 PM To: Weddington, Eric Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [RFC] Conditional poisoning of deprecated items The system header pragma suppresses the warnings. #pragma GCC system_header #define xyz 3 #pragma GCC poison xyz Thanks for finding that, John! Yes, it looks like that could work. It looks like it would have some other side-effects, however, the documentation says that it only affects the code that comes after that pragmas. So we could implement this by putting the poisoning of symbols at the bottom of a header file (e.g. at the bottom of an I/O header file, with the pragmas system_header just right before the poisoning. We could then have it default on, with a conditional compilation symbol to turn OFF the poisoning of deprecated items. For example: -- // I/O header file // A bunch of defined stuff... #if !defined(__AVR_LIBC_DEPRECATED_ENABLE__) #pragma GCC system_header #pragma GCC poison abc // Poisoned definitions. #pragma GCC poison xyz #endif -- How does that sound? Joerg, do you have any objections to this implementation? 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] Feature wishlisht
-Original Message- From: Boyapati, Anitha Sent: Sunday, February 27, 2011 7:52 PM To: Boyapati, Anitha; Weddington, Eric; Joerg Wunsch; avr-libc- d...@nongnu.org Subject: RE: [avr-libc-dev] Feature wishlisht The other point I would like to know is test strategy - how is avr-libc being tested currently? Do we use simulator for executing tests or some set of devices per family... How blind can I be? I am taking this back! I just realized that tests folder exists and that atmega128, at90s8515 (and 4 more- in short arch 2,4,5) are used on simulavr. Ever since delay cycles regression, I was thinking if there is a way to catch such bugs much before. Well, certainly there is *some* testing, but as you can see it could certainly use improvement. Ideally, it should be tested for all devices, but that's now well over 100 devices. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [RFC] Conditional poisoning of deprecated items
Hi All,
We haven't had an RFC (Request For Comments) in a long time.
I've been going through a bunch of the I/O header files recently for one of the
bug reports/feature requests. I noticed, and also remembered, that we have an
awful lot of deprecated items, e.g. old ISR vector names.
Deprecated items, usually, are supposed to be eventually removed from a project
over time. However, we have users who tend to continue to use deprecated items,
blissfully unaware of the fact that they are deprecated and *might* be
eventually removed (e.g. the sbi/cbi macro debacle of a few years back).
A lot of this problem falls on us. We don't really document the deprecated
items very well, if at all. And we haven't let the user easily find out, via
the toolchain, which items are deprecated so they can go change their source
code. We need to change this so we can eventually clean up avr-libc.
GCC has a #pragma that will poison identifiers which will cause a hard error
if they are used in a program.
For example, this source code:
-
#define __AVR_LIBC_DEPRECATED_DISABLE__
#define xyz 3
#if defined(__AVR_LIBC_DEPRECATED_DISABLE__)
#pragma GCC poison xyz
#endif
int main(void)
{
volatile int a;
a = xyz;
return 0;
}
-
Will return this output:
+ avr-gcc -mmcu=atmega128 -Os -save-temps -c test.c -o test.o
test.c:7:20: warning: poisoning existing macro xyz
test.c:15:9: error: attempt to use poisoned xyz
A few things to point out:
- The poisoning happens *after* the macro definition. This will allow the
warning to happen about the existing macro definition. The error will only
occur on usage of the macro.
- The poisoning happens only on a conditional define. The
__AVR_LIBC_DEPRECATED_DISABLE__ must be defined in the user's source code,
preferably before any system (avr-libc) header files are included.
I propose that this poisoning be done in avr-libc header files, as needed,
using such a conditional define. The default would be to have the poisoning
OFF, like above, which allows all deprecated items exist as before. A user
would define the symbol above to turn on the poisoning of all deprecated items
in avr-libc, for the purpose of discovering and fixing all deprecated items in
their application code.
I'm not stuck on the name of the conditional define to use. I'm open to better
ideas.
Thoughts?
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] Feature wishlisht
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Friday, February 25, 2011 11:08 AM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] Feature wishlisht Likewise, 64-bit doubles are on the wishlist (as an option to the current implementation), but again, this is much of a compiler issue rather than library only. My preference would be a compiler option much like we've got -mint8, so perhaps -mdouble32 which enables the current behaviour, defaulting to double being 64 bits as this is what the ISO C standard asks for (well, sort of, but they're asking for *more* than 32-bit FP for the double datatype, and while 48 bits would satisfy their requirements, it's IMHO not possible to implement a 48-bit datatype in GCC). On the other hand, I don't like it as an option. -mint8 already breaks avr-libc. I would rather see 64-bit doubles, 32-bit floats, and library routines to support the user who can then decide which routines to use. Don't make it optional, as that would mean some toolchains in the field with one set of features, others with another set of features. I think this would just lead to maintenance problems. As an admittedly weird side-benefit: IIRC, I think that all we need is to implement 64-bit doubles in order to build the Fortran compiler of GCC for the AVR target. That is if anyone really cares about writing Fortran for the AVR. ;-) I think the standard feature set of avr-libc is pretty much settled, and does not call for many more extensions. (Disclaimer: that's my very personal opinion.) And in my opinion, there are other things that we can do to improve and extend avr-libc even more. IIRC, there are some routines that we could add to improve XMEGA support, including some of those timed sequences inline assembly routines. We also talked about making avr-libc build per device, instead of build per architecture like we do now. Did that get ever fully settled? Anitha, there is also a TODO file in the source tree (I think under /doc) which contains a lot of old ideas that we've had over the years. I still want to do the corelib project, but that would technically be in addition to avr-libc, not a part of it. Eric ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Feature wishlisht
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Friday, February 25, 2011 12:28 PM To: Joerg Wunsch; avr-libc-dev@nongnu.org Subject: RE: [avr-libc-dev] Feature wishlisht Yes, libstdc++ support is on the wishlist, even though it's beyond the scope of the avr-libc project. Here comes my basic question - we do have libstdc++ in gcc already. However we are not building it for AVR-8 as of now. So what is the requirement for another library? To me it appears that libstdc++ can be built with a bootstrapped compiler (if it is possible). No, no, no. We don't mean it as a *new*, separate library. We do mean it as you said: Building libstdc++ that comes with GCC. If it was easy, we would have already done it by now. ;-) Both Joerg and I have looked into doing this many years ago. It doesn't seem straightforward, and both of us ran out of time to look into it. You have to remember that many years ago, there weren't that many C++ users on the AVR. Perhaps, now that some time has passed, there are enough C++ users on the AVR to warrant the time to look deeper into how to get that darn library built for the AVR. If you have some ideas on how to do this, then it would certainly be appreciated. :-) Likewise, 64-bit doubles are on the wishlist (as an option to the current implementation), but again, this is much of a compiler issue rather than library only. My preference would be a compiler option much like we've got -mint8, so perhaps -mdouble32 which enables the current behaviour, defaulting to double being 64 bits as this is what the ISO C standard asks for (well, sort of, but they're asking for *more* than 32-bit FP for the double datatype, and while 48 bits would satisfy their requirements, it's IMHO not possible to implement a 48-bit datatype in GCC). This is still a mystery to me. When BITS_PER_UNIT/WORD is modified, the sizes of INT/LONG get affected. Implementing 48-bit double is definitely not straight forward (or may be not possible? To be confirmed) No, not 48-bit double. We want full-blown 64-bit doubles. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [avr-libc-commit] [2224] . Honour $(DESTDIR) in man page installation, so the user can re-root
Thanks for the help, Joerg! :-) Eric Weddington -Original Message- From: avr-libc-commit-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-commit-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Joerg Wunsch Sent: Wednesday, February 23, 2011 12:25 PM To: avr-libc-com...@nongnu.org Subject: [avr-libc-commit] [2224] . Honour $(DESTDIR) in man page installation, so the user can re-root Revision: 2224 http://svn.sv.gnu.org/viewvc/?view=revroot=avr- libcrevision=2224 Author: joerg_wunsch Date: 2011-02-23 19:25:28 + (Wed, 23 Feb 2011) Log Message: --- . Honour $(DESTDIR) in man page installation, so the user can re-root the target three by time of installation. . Replace the GNUism install -t dir file... by its generic counterpart intall file... dir so it works everywhere, not just on GNU systems. Modified Paths: -- trunk/avr-libc/doc/api/Makefile.am Modified: trunk/avr-libc/doc/api/Makefile.am === --- trunk/avr-libc/doc/api/Makefile.am2011-02-23 18:15:04 UTC (rev 2223) +++ trunk/avr-libc/doc/api/Makefile.am2011-02-23 19:25:28 UTC (rev 2224) @@ -239,8 +239,8 @@ $(INSTALL_DATA) $(USER_MANUAL).pdf $(DOC_INST_DIR)/$(USER_MANUAL).pdf install-dox-man: dox-html - $(mkinstalldirs) $(mandir)/man3 - $(INSTALL_DATA) -t $(mandir)/man3 man/man3/*.3 + $(mkinstalldirs) $(DESTDIR)$(mandir)/man3 + $(INSTALL_DATA) man/man3/*.3 $(DESTDIR)$(mandir)/man3 .PHONY: html latex pdf demo demodox \ dox-html dox-pdf install-pdf install-html \ ___ avr-libc-commit mailing list avr-libc-com...@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-commit ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] [bug #30363] _delay_xx() functions in util/delay.hare broken
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Anitha Boyapati Sent: Monday, February 14, 2011 11:43 PM To: Boyapati, Anitha; Bill Perry; Joerg Wunsch; avr-libc-dev@nongnu.org Subject: [avr-libc-dev] [bug #30363] _delay_xx() functions in util/delay.hare broken Update of bug #30363 (project avr-libc): Status: In Progress = Fixed Discussion Lock: Any = Locked Hi Anitha, I think that we would prefer that you not lock the discussion on a bug unless the conversation in the bug comments have turned into some sort of flame war. Even if the bug is fixed, a user may come back and re-open the bug and they will need to make a comment. 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] 1.7.1 release-Next Week?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Wednesday, February 09, 2011 10:55 PM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] 1.7.1 release-Next Week? Hello, Hi All, I have some list of devices to be supported. Probably I can commit them. This is just a heads up. I'll come back with the list shortly. What's the list and how long do you think it will take to commit it? How about planning for 1.7.1 release next week? Did you want the new device support in this 1.7.1 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] 1.7.1 release-Next Week?
-Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Thursday, February 10, 2011 9:37 PM To: Joerg Wunsch; avr-libc-dev@nongnu.org Subject: RE: [avr-libc-dev] 1.7.1 release-Next Week? Hello Joerg, Then, let's see how many of all the other fixes and enhancements can be committed to the tree within the next weeks, and let's roll another release shortly after (I was thinking of a 1 ... 2 months timeframe here). 1...2 months?! I am hoping for somewhat lesser time frame :( We have an AVR Toolchain release coming up (around Feb end). So I thought next week would be kind of nice. Clarification: We were discussing doing a 1.7.1 release ASAP, probably within the next week. After that, do a 1.7.2 release in the 1-2 month time frame. Does that make sense? If so, then *anything* that is needed in the 1.7.1 release needs to get committed very soon. 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.7.1 release-Next Week?
-Original Message- From: Boyapati, Anitha Sent: Thursday, February 10, 2011 10:16 PM To: Weddington, Eric; 'Joerg Wunsch'; 'avr-libc-dev@nongnu.org' Subject: RE: [avr-libc-dev] 1.7.1 release-Next Week? Clarification: We were discussing doing a 1.7.1 release ASAP, probably within the next week. After that, do a 1.7.2 release in the 1-2 month time frame. Does that make sense? It is great if things can happen that way! If so, then *anything* that is needed in the 1.7.1 release needs to get committed very soon. From my side, I can get every device patch committed by Monday. Ok, that sounds good. Apart from that 2 bugs can be fixed: https://savannah.nongnu.org/bugs/?31873 https://savannah.nongnu.org/bugs/?31990 Ok, let's take a look at them... ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] RE: [patch #6951] Time posix patch.
-Original Message- From: Daniele Basile [mailto:invalid.nore...@gnu.org] Sent: Sunday, January 02, 2011 9:58 AM To: Dmitry Xmelkov; joerg_wun...@uriah.heep.sax.de; Daniele Basile; Frank Ennert; Joerg Wunsch; Weddington, Eric; avr-libc-dev@nongnu.org Subject: [patch #6951] Time posix patch. Follow-up Comment #10, patch #6951 (project avr-libc): I agree with you, and if you don't have hurry I can rewrite the patch to round on to the license trouble. Let me now what do you think. We need to avoid licensing problems at all cost if anything is going into the official avr-libc repository. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Intro, and how can I help?
Hi Buddy, Thanks for your interest! :-) Yes, we could always use a bit of help here and there. Are you familiar with using SVN (Subversion) and creating and using patches using the 'diff' and 'patch' unix utilities? Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Buddy Smith Sent: Saturday, December 25, 2010 6:30 PM To: AVR-libc-dev@nongnu.org Subject: [avr-libc-dev] Intro, and how can I help? Hi! I'm an embedded developer with some experience with AVRs, embedded linux, and lots of other tiny devices. Lately I've been wanting to contribute something back, and I remembered how much I liked using AVR-LIBC, so here I am. I'd love to help out where needed. I'm fairly proficient with C and assembler, but not with GCC. I'm looking through the bug list / task list to see if there's anything that I could jump in on, but it's not obvious from there what's needed, as most of them are 2 years old. If there's anything particular I can look at, please let me know. I know that's silly since you have no idea of my experience level, but I have to start somewhere :) Is avr-libc still looking for a floating point maintainer? --buddy ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
RE: [avr-libc-dev] Regarding power reduction registers in At90pwm81
Hi Praveen, The XML files come with AVR Studio 5, not WinAVR. The header file is supposed to match the XML file, not necessarily the datasheet. If the header file does not match the XML file, then please file a bug report at the avr-libc project. Thanks, Eric Weddington -Original Message- From: avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-libc-dev-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Kaushik, Praveen_Kumar Sent: Thursday, December 23, 2010 12:01 AM To: avr-libc-dev@nongnu.org Subject: [avr-libc-dev] Regarding power reduction registers in At90pwm81 Hi, In avr-libc/include/avr/power.h, under AT90PWM81, macro PRPSC0 is used but the datasheet specifies this as PRPSCR. The XML file that came with WinAVR-2010 release also specifies this as PRPSCR. Is there any particular reason for this or the header file is not updated while the XML file has been upgraded? The datasheet can be found at: http://www.atmel.com/dyn/resources/prod_documents/doc77340.pdf Regards, Praveen Kaushik ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
