As Boris Borisov wrote:
Assembler messages:
/var/tmp/cross/avr/portage/cross-avr/avr-libc-1.6.2/work/avr-libc-1.6.2/libc/stdlib/setjmp.S:81:
Error: missing model parameter
/var/tmp/cross/avr/portage/cross-avr/avr-libc-1.6.2/work/avr-libc-1.6.2/libc/stdlib/setjmp.S:128:
Error: missing
As Steve Franks wrote:
There should be a configure switch for that. IIRC it's --disable-doc.
Here's the exact error, by the way:
...
config.l1304: Internal error: Requested unknown option GENERATE_INDEXLOG!
I've seen this as well, yes. Did you try updating your doxygen port
again?
As Dave N6NZ wrote:
The structs for peripheral register definitions are hugely more
usable than the current header file design. Much more readable and
convenient.
What's really good about it is that this is a straight design now,
from the IC designers to the compiler/library. This would not
As Weddington, Eric wrote:
You are incorrect.
For example the ATtiny13A now includes registers PRR and BODCR, that
were not included in the ATtiny13.
That wasn't clear to me from the initial announcement I've seen. It
left the opinion in me that they are a full 1:1 replacement.
Of course,
As Weddington, Eric wrote:
atmega128a atmega168pa atmega16a atmega324pa atmega32a atmega32u6
atmega64a atmega88pa atmega8a attiny13a
Many of those devices you listed have not been formally released
yet, so support has not been added.
The question is whether we really want to do anything
Ahoj Pavle,
I've downloaded and compiled recently released version 1.6.3 of avr-libc.
There is a small compile/time bug in file avr/include/wdt.h. In the
attachment of this email is a little patch, that fixes it.
Hmm, no attachment in sight. Keep in mind that the list server setup
As Weddington, Eric wrote:
Would something like that be of interest to the avr-libc developers?
I can't speak for all avr-libc developers, but I would personally be
fine with it. I feel that it would adhere to the spirit of the
license and the spirit of the avr-libc project, in that you are
As Weddington, Eric wrote:
What's your opinion on this ? How did you deal with this ?
Yes avr-libc has been used in commercial products, without
problems. In practice, many people do not put the copyright notice
in their documentation even though they are supposed to. I don't
have a big
As Rick Altherr wrote:
What languages are you asking avr-gcc to build? I only build c and
c++. It may require the headers if you try to build java, fortran,
etc.
I don't think any of these languages is actually supported for the AVR
at all. The only language besides C and C++ that is at
As Weddington, Eric wrote:
I am hoping to finish up this work by the end of the week. So I was
thinking that a release would be rolled sometime over the weekend.
Tomorrow is a holiday here, and I'll be away for the weekend, so I
won't be able to roll a new release before Monday. Hope that's
As Steve Franks wrote:
I'm not looking at the error this instant (my ucom device is
crashing the latest stable freebsd bigtime), but I tried to build
avr-libc from ports a couple days ago, and it failed with some
errors about unsupported doxygen directives. Looked like doxygen
just changed
As Weddington, Eric wrote:
Is there a way to build avr-libc without the docs (and hence w/o
doxygen)?
Yes, if you define NOPORTDOCS, they won't be built.
There should be a configure switch for that. IIRC it's --disable-doc.
That's exactly what the NOPORTDOCS option does. It's just
Update of patch #6649 (project avr-libc):
Status: Wont Do = In Progress
___
Follow-up Comment #2:
I guess Dmitry simply misread the Wont do (which should be
Won't do as Want [to] do. ;-)
I
As Ruudje wrote:
I'm new to this list and project. So I don't really know how things
work here.
Hi, and thanks for the contribution!
The normal way for that kind of submission is to file it as a patch
under
http://savannah.nongnu.org/patch/?group=avr-libc
Contributions sent in email
Update of bug #24446 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #24446 (project avr-libc):
Fixed Release:None = 1.6.3
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?24446
___
As Andy H wrote:
double cbrt(const double x)
{
return pow(x,1.0/3.0);
}
If cbrt() is going to be more than just an alibi function to make GCC
tests happy, then it should probably be implemented similar to the
existing libm functions.
char * strdup( const char *str)
{
unsigned
As Weddington, Eric wrote:
IIRC, there's some other (obscure) backend in GCC where NULL !=
0. So I believe it is possible, though admittedly rare.
Quite possible, but the C standard requires that a numerical zero will
be automatically converted into a null pointer when being used in a
pointer
As Joerg Wunsch wrote:
However, that's only half of the story, and the other half is
frequently forgotten about by people sending patches (and wondering
why it takes forever to integrate them): the documentation is
missing.
Actually, it's only a third of the story. Documentation being
As Weddington, Eric wrote:
I always use if(!copy)...
That doesn't make it right.
In a purely technical sense, it's right. It's just a question
of style whether to explicitly write the test against NULL, and
I've seen several style guide requesting so.
--
cheers, Jorg .-.-.
As ahmed khadragi wrote:
I wish to used codeVision +STK500 topped by ATMEGA16 to read the
input of 5 slide sensors (potentiometers) and produce
different outputs for each reading.
Unfortunately, you ended up at a mailing list that is way beyond your
inquiry.
This mailing list is for
As Weddington, Eric wrote:
Are there any potential issues with this patch?
Hard to say without really testing it extensively, but my guess is
this is OK. As there is no IO offset on the Xmega, defining the
offset value to 0 for it ought to be OK.
--
cheers, Jorg .-.-. --...
Follow-up Comment #1, bug #23032 (project avr-libc):
Hmm, are you sure?
I see PORTxn, DDRxn, and PINxn bit names /are/ defined in
avr/iom1284p.h. However, the generic bit names (Pxn) are
not defined for that device. They should probably be
supplied through avr/portpins.h. However, the logic
As Dmitry K. wrote:
Is the __AVR_3_BYTE_PC__ macro the best for this purpose?
That should probably be only applied in situations where you are
interested in knowing how many bytes have been pushed onto the stack
by a CALL instruction.
I have find 2 another methods in Avr-libc:
a) if
As Dmitry K. wrote:
So it was incorrect to use 'AVR_ARCH == 6' (library per arch) or
'defined(EIND)' (library per device) in setjmp()/longjmp()
functions.
You're right, setjmp/longjmp is a candidate for __AVR_3_BYTE_PC__.
Thanks for catching that!
--
cheers, Jorg .-.-. --...
Update of bug #22667 (project avr-libc):
Status:None = Duplicate
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #14855 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #8:
This one has
Update of bug #3485 (project avr-libc):
Category: Documentation = Library
Item Group: Documentation = libm code
Open/Closed: Closed = Open
Fixed Release:
Follow-up Comment #4, bug #22593 (project avr-libc):
Will this patch be applied to the 1.4 branch ?
Nope, the 1.4 branch is now officially closed -- well, as
officially as possible. If there were a real killer
bug, we might consider another release, but otherwise no
CVS commits happen to that
URL:
http://savannah.nongnu.org/bugs/?22567
Summary: malloc() can occasionally run into an infinite loop
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Wednesday 03/12/2008 at 10:54
Category:
As [EMAIL PROTECTED] wrote:
First of all, I don't know if this is the appropriate way to report
a bug in AVR Libc. If not, please tell me the correct procedure.
Well, for a genuine bug report, the way to submit it would be via
https://savannah.nongnu.org/bugs/?group=avr-libc
However, what
(This is all related to GCC rather tahn avr-libc, so I redirected it
to avr-gcc-list. Please mind the mail-followup-to when continuing the
discussion.)
As Ron Kreymborg wrote:
Using the asm keyword in C++ code to directly vector interrupts to a
class handler (as in the CLASS_IRQ macro
Update of bug #22415 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
URL:
http://savannah.nongnu.org/bugs/?22377
Summary: Wrong XRAMEND for some recent ioXXX.h header files.
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Thursday 02/21/2008 at 15:38
Category:
As Dmitry K. wrote:
After testing with all GCC versions (3.3.6 - 4.3.X)
I intend to update vfscanf() in 1_6 branch (from HEAD).
Any objections?
Not at all! Thanks a lot for all your work with this!
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
As Dmitry K. wrote:
In the near future I am going to update vfscanf() function
- a core of all scanf family (first only the HEAD branch).
To me, all your changes sound very reasonable. Bolshoye spasibo za
vashuy trudu, Dmitry!
. The size of the minimal and standard versions has increased
As Weddington, Eric wrote:
And the old code is not disabling interrupts during eeprom
write... which is no good! Maybe this was the problem of the
report for the tiny13?
No, the old code is disabling the interrupts for the write
routines. You have to look in the libc/misc/eeprom.S file
Update of bug #22153 (project avr-libc):
Status:None = In Progress
Assigned to:None = joerg_wunsch
___
Reply to this item at:
As Weddington, Eric wrote:
I did not receive any attached source in any of the email in this
thread including this last email from you.
Trying again. Let me know if it's not attached this time.
Not there. Do you remember that the list processor strips attachments
of type
As Dean Camera wrote:
My solution:
#define CLASS_ISR(vector, ...) { vector(); } ISR(vector, __VA_ARGS__)
Thanks!
Which means you can name the function anything, and it should be
accessible as a normal function, but also link in as an ISR. As I
can't seem to get the intermixed
As Weddington, Eric wrote:
We've had a task in the list to make avr-libc -mint8 compatible:
https://savannah.nongnu.org/task/?3622
Is this still desired?
There are obviously no takers for it anyway.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
As Stu Bell wrote:
Would importing the code (in any form) into avr-libc violate GPLv2
by putting the code (modified though it will be) under the somewhat
more restrictive LGPL?
avr-libc is covered by the BSD license. Yes, porting GPLed code to
the BSD license is impossible because the GPL
As Andrew S wrote:
Investigating this further, I found that the following corresponded
with the microcontroller running the correct interrupt handler for
the interrupt in question:
ISR(_VECTOR(8))
{ .. }
That would be TIMER1_COMPB_vect. Are you sure you are running the
correct timer? ;-)
As Weddington, Eric wrote:
You're going to have to back up your claims on this one. I have
never seen, nor heard of such a limitation.
It's also what I recall from my last reading of the LGPL (which has
arguably been quite some time ago). The official reasoning for the
requirement to ship
As Weddington, Eric wrote:
Thanks for the reminder; you're right it's GPL+exception. Then I
would be OK with a library having such a license.
I find it quite complicated, compared to the plain old BSD-style
license we've been using for avr-libc for years now. Is there any
specific reason you
As Weddington, Eric wrote:
BTW, is there any way to get these XML files (other than
downloading AVR Studio)?
For most people, unfortunately, no. AVR Studio is the way to get
them.
Minor correction: I think they are also part of the AVR command-line
tools which are distributed
As Weddington, Eric wrote:
Dean Camera wrote:
What sort of contributions did you have in mind? Would the
util library code be moved over to the new library? How
would you imagine it structured?
I really thought of things that are currently available in libraries
like Procyon AVRlib.
As Rich Teer wrote:
... In other words, under BSD, someone could take the AVRlibC code
and change it, but not be obliged to return those changes back to
the community.
And this is exactly intentional for our purpose. In the embedded
world, people can quickly become nervous if they even feel
URL:
http://savannah.nongnu.org/task/?7546
Summary: Rework the default interrupt handler
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Saturday 12/22/2007 at 21:34
Should Start On: Saturday 12/22/2007
Update of bug #21872 (project avr-libc):
Assigned to:None = dmix
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?21872
___
As Anatoly Sokolov wrote:
CVSROOT: /sources/avr-libc
Module name: avr-libc
Branch: avr-libc-1_6-branch
Changes by: Anatoly Sokolov aesok 07/12/21 20:04:56
Modified files:
. : ChangeLog NEWS configure.ac
devtools : gen-avr-lib-tree.sh
As Joerg Wunsch wrote:
What about the head of CVS? You committed that only to the 1.4 and
1.6 branches.
OK, I see it's been in HEAD since last night. Somehow, I must have
missed that commit message.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg
Since I just opened the 1.6 branch, we've now got two open branches
around.
HEAD of CVS is for ongoing development work, eventually to become
avr-libc-1.8. The development name is 1.7.x.
1.6 is the stable branch where our next releases will primarily been
made of. Any trivial changes from HEAD
As Weddington, Eric wrote:
I'll re-roll it as 1.6.1 then, and never announce 1.6.0. Now that
the 1.6.0 label is already in the bug report, it makes no sense to
try sliding the tags.
Hmm. I just released WinAVR with 1.6.0. I just included the missing
file.
1.6.1 is done now. I'm too
As Dmitry K. wrote:
Is there a method to reduce the maintenance work
before there is not any severe reason? Merge or
freeze one of HEAD and 1.6 ?
Just don't do anything on 1.4 anymore, unless it's a real
serious bug to fix.
1.6 is the new stable branch which has just been forked
off, and
I've been too tired last night, so I did it now. The web pages are
now updated, the public documentation thus points to the 1.6.1 docs.
I also converted the Major changes part of NEWS into
changes-1.6.html for a quick overview.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
I got notified yesterday that my FreeBSD ports of avr-libc currently
don't build. The culprit turned out to be doxygen, and there's a real
bug in doxygen. I just filed a doxygen bug report:
http://bugzilla.gnome.org/show_bug.cgi?id=504650
For the time being, refrain from using doxygen 1.5.4
As Dmitry K. wrote:
Recently to the chapter Changes since avr-libc-1.5.1
a 4 notes are added, about of old float point bugs
fixed. It misleads a reader, since all this corrections
were maked before 1.5.1
However, the NEWS file is supposed to only add things on top of it,
and leave
As Weddington, Eric wrote:
. Peter Danneggers suggestion to call (rather than jump to) the
default handler, and then pop the topmost two (or three for
avr6) bytes off the stack has some merit.
I'm sorry, I must have missed this. Why does this have merit?
The default handler can then
Update of bug #21841 (project avr-libc):
Assigned to:joerg_wunsch = aesok
Open/Closed: Closed = Open
___
Follow-up Comment #1:
OK, I completely
As Dmitry K. wrote:
Corrections are needed:
Spasibo bolshoye, Dmitry! I've probably been too tired last night to
really catch the differences between exit and _exit in these source
files. I completely reverted the change, and re-opened the bug
tracker item. That way, the correct place to fix
Update of bug #21841 (project avr-libc):
Status: Fixed = Ready For Test
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?21841
___
As Dmitry Xmelkov wrote:
Log message:
Add CLI to abort() and exit() functions, since GCC's _exit() does not
disable interrupts today.
Umm, no, please don't. If it's _exit()'s respsonsibility to do so,
then let's leave it to libgcc.a instead. That's why I completely
backed out my
As Weddington, Eric wrote:
... There's no point in trying to plug libgcc's faults
and omissions inside avr-libc.
Why not?
Because that bug is completely unimportant and purely cosmetical.
Real embedded applications don't exit() anyway. Mind you, we (at
least you and me) have been
As Weddington, Eric wrote:
I won't touch the default handler right now.
Why not?
After some thorough thinking about it, I decided to leave it alone
right now. After all, there has to be a reason to eventually roll a
1.8 release some day. ;-)
Random thoughts:
. Peter Danneggers suggestion
Update of bug #21484 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
URL:
http://savannah.nongnu.org/bugs/?21841
Summary: Add CLI to exit() and abort() loops
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Tuesday 12/18/2007 at 21:55
Category: Library
Update of bug #11511 (project avr-libc):
Status:None = Fixed
Assigned to:None = dmix
Open/Closed:Open = Closed
Update of bug #13330 (project avr-libc):
Status:None = Fixed
Assigned to:None = dmix
Open/Closed:Open = Closed
Update of bug #11820 (project avr-libc):
Status:None = Fixed
Assigned to:joerg_wunsch = dmix
Open/Closed:Open = Closed
Update of bug #1929 (project avr-libc):
Status:None = Fixed
Assigned to:None = dmix
Open/Closed:Open = Closed
As Dmitry K. wrote:
I am bewildered. What is the difference between 'argument'
and 'parameter' in Doxygen usage?
I'm afraid you'll have to ask Dimitri van Heesch about his
intentions. It's not really clear to me either.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
As Dmitry Xmelkov wrote:
Move all CPP statements to '#ifndef __DOXYGEN__' scope to
reduce the volume of garbage in documentation. IMHO, the \file
doxygen directive is redundant here.
Well, if there's no real documentation inside these files, then yes,
\file can be omitted.
As Shaun Jackman wrote:
The assembler has a pm(a) operator for this very reason. It would be
useful for avr-libc to have a similar macro.
This rather smells like a compiler bug to me, than something where
library support would be a real help. If the compiler offers the
feature to jump to an
As Shaun Jackman wrote:
With GCC r130284 --target=avr, a 116 byte static function that is
called twice is inlined even with -Os, effectively doubling the
function's footprint.
Sorry, but that's really off-topic for avr-libc-dev. Use
[EMAIL PROTECTED] instead, please.
I've already filed
Follow-up Comment #1, bug #21621 (project avr-libc):
Is there any good reason for this version check?
autoconf/automake are known for their habit of breaking the
API between revisions, so we'd only like to allow known to
work versions. If you verified all works well with version
2.61, it's
Update of bug #20650 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #20248 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #19494 (project avr-libc):
Assigned to:None = arcanum
___
Follow-up Comment #1:
Sorry, I don't see what you are referring to exactly here.
Eric, would you please take care
Update of bug #20530 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #21204 (project avr-libc):
Status:None = Fixed
Assigned to: arcanum = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #21432 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
As Joerg Wunsch wrote:
Add TIMER0..._vect and TIMER1..._vect
names in addition to the TIM0... and TIM1... names to match
the recently changed datasheet.
p.s.: I opened ATTicket: 225863 to clarify the discrepency
between the datasheet and XML files.
--
cheers, Jorg
Update of patch #5644 (project avr-libc):
Status: In Progress = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #5644 (project avr-libc):
Status:None = In Progress
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
I looked at it,
Update of patch #5343 (project avr-libc):
Status:None = In Progress
Assigned to:None = joerg_wunsch
___
Reply to this item at:
Update of patch #5343 (project avr-libc):
Status: In Progress = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #6236 (project avr-libc):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
I plan to release the current state of HEAD as version 1.5.1 ASAP.
The idea behind that is to get more testing for all of our new
features, in particular for Dmitry's new libm.a code. Since releases
are also provided as binary releases (which are independent of the
underlying operating system),
URL:
http://savannah.nongnu.org/bugs/?21444
Summary: Undocument -minit-stack
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Saturday 10/27/2007 at 00:19
Category: Documentation
Follow-up Comment #1, bug #21432 (project avr-libc):
Confirmed. That appears to be a recent change. My older
datasheet used the names we've got in our header file, and
even the XML files from AVR Studio 4.13 b528 have it that
way. I hope they've fixed the XML meanwhile...
It appears that
As Eric Weddington wrote:
The latest XML device file for the ATtiny45 in the latest AVR Studio
version still has the TIM1_..._vect form. Our policy states that we
are compatible with the XML file.
Isn't Atmel's policy that the datasheet and XML files match? Who's
going to open the ATticket
As Anatoly Sokolov wrote:
Log message:
* include/avr/iocanxx.h (OVFG): Define.
Closes bug #21434.
I think that one also needs an ATticket, as the XML files have OVRG.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
Follow-up Comment #2, bug #21410 (project avr-libc):
If we skip this then we might be ok, if the eeprom.S
file is build per device not per architecture.
Unfortunately, it actually *is* per architecture, not per
device. That's the reason why it is compiled into two
different object files (for
Update of patch #3851 (project avr-libc):
Assigned to:None = dmix
___
Follow-up Comment #6:
Dmitry, this is your submission anyway. I've got no idea
whether this has already been
Update of patch #6161 (project avr-libc):
Priority: 5 - Normal = 3 - Low
___
Follow-up Comment #1:
Basically, I like that idea, thanks!
However, I'd like to defer the actual implementation
As Eric Weddington wrote:
The only way I'm seeing is to compile it into four different
object files (base address vs. 8- or 16-bit addressing), and
extend the macro wrapper logic in avr/eeprom.h.
Ugh. Please, let's not. I'd like to also consider future devices as
well. ;-)
Well, I
Update of bug #21174 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #20092 (project avr-libc):
Status:None = Invalid
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #19079 (project avr-libc):
Privacy: Private = Public
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?19079
___
501 - 600 of 868 matches
Mail list logo
