Hello,
I'm just back from vacation, so I've read this thread only right now. I've had
a brief look at the issue. I come to the conclusion that we are having two
issues to fix the warning bug.
1.) gcc generates code that refers to the jump table address as if it were a
code label address. I.e.
anonymous wrote on Samstag, 9. September 2006 00:30 :
URL:
http://savannah.nongnu.org/patch/?5377
Summary: Fix for multiple dufinition error
Project: AVR C Runtime Library
Submitted by: None
Submitted on: Friday 09/08/2006 at 22:30
Eric Weddington wrote on Donnerstag, 24. August 2006 18:53 :
-Original Message-
From: Joerg Wunsch [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 24, 2006 10:13 AM
To: Ned Konz; Levi Harper; Joerg Wunsch; Eric Weddington;
avr-libc-dev@nongnu.org
Subject: [bug #16411]
Joerg Desch wrote on Dienstag, 6. Juni 2006 09:07 :
On Fri, 2 Jun 2006 05:53:51 +0200
Björn Haase [EMAIL PROTECTED] wrote:
The most recent versions carry the suffix _6. The header files for
256x should rather be taken from Anatoly's (aesok) post than from my the
_5 patch:
Thanks
Joerg Desch wrote on Freitag, 2. Juni 2006 13:35 :
First of all I want to say thanks to Björn Haase for his 256x patches.
I've built the avr toolchain today. I'm using Ubuntu Warty (nearly the
same as debian sarge) as host system. The toolchain is built with gcc
3.3.4 (default of warty
David Carr wrote on Montag, 24. April 2006 09:30 :
Just for fun I ran the savage benchmark on my Mega16 at 6MHz. I
attempted to use double precision everywhere. (I say attempted because
I'm no expert at this.)
A further test reveals (to me) that sizeof(float) == sizeof(double) == 4.
Is
Joerg Wunsch wrote on Samstag, 22. April 2006 21:46 :
As Eric Weddington wrote:
Atmel distributes a lot of this information in AVR Studio as XML
files.
database ---HEADER_FILE_GENERATOR1--- header file for gcc
database ---HEADER_FILE_GENERATOR2--- header file for binutils
It would be
Hi,
I'd like to discuss the issue that presently the individual device properties
for the avr family is scattered all over the different files of the
toolchain. Also the avrX family concept has shown to be sub-optimal since
there are, some tiny-devices that have some of the enhanced
Fabrizio Tironi wrote on Freitag, 21. April 2006 17:42 :
Björn Haase wrote:
It would, thus, be quite helpful if you or somebody else could test
the patch.
We have just tried your patch.
Thanks for the rapid answer :-).
Here is our config:
Debian stable, kernel 2.6.13, avr-gcc 4.0.2
Uwe Fechner wrote on Freitag, 21. April 2006 18:41 :
Björn Haase wrote:
In this case, however, I'd like to
suggest to try to find a format that could be edited by some sort of GUI.
Any suggestions would be appreciated.
Bjoern
I think, xml is the format of choice.
I made the same
Selbst wrote on Mittwoch, 12. April 2006 23:43 :
Hi,
i just read about the more or less new feature of the newer avr devices
that allows more efficient eeprom write operations. Basically it allows to
save some erase cycles if bits only need to be set but none erased:
Bernd Trog wrote on Donnerstag, 9. März 2006 20:10 :
Björn,
why don't you become a co-maintainer with write privileges for
gcc/config/avr/?
Maybe because I am having had by far too long days for my paid work during the
last 4 months? And possibly because I don't know enough about gcc right now
[EMAIL PROTECTED] wrote on Mittwoch, 8. März 2006 14:10 :
- Original Message -
From: Haase Bjoern (PT-BEU/EMT) * [EMAIL PROTECTED]
Date: Wednesday, March 8, 2006 2:02 am
Subject: AW: [avr-gcc-list] multiple -Tdata options passed to the linker
forsome AVRs
The code of this database
Dmitry K. wrote on Sonntag, 5. März 2006 06:22 :
On Saturday 04 March 2006 20:23, you wrote:
Björn and Dmitry,
have you tried program-at-once compilation (avr-gcc -combine
-fwhole-program *.c ..)? This may save some more bytes with recent gccs.
In result:
Options: rlx
Dmitry K. wrote on Freitag, 3. März 2006 07:45 :
Congratulation!
I have try a one project. Not the best example:
a very large part consists from asm-writen libraries
where short rcall/rjmp are used. Nevertheless,
a considerable effect is.
Hi,
I just recognized that I forgot to include the
Dmitry K. wrote on Sonntag, 29. Januar 2006 23:10 :
Hi.
In two right columns time of operations after addition of
the IEEE 754 rules is shown. After little changes speed has
increased even, sometimes - considerably. Measurements are
lead on files of random numbers (on 500 pieces). Files are
Joerg Wunsch wrote on Sonntag, 22. Januar 2006 15:22 :
As David Carr wrote:
I just rebuilt my toolchain with gcc 3.4.5 (and Jorg's FreeBSD
patches). How does the performance of 4.0.2 compare? I see that
the 3.4.x series is still reccommended in the avr-libc
documentation.
Well, the
Ingo Heffe wrote on Sonntag, 29. Januar 2006 12:19 :
Hello,
i'm using the cdk4avr environment for programming an Atmel-Mega64
controller on a Mandrake-10.1-PC.
If a division-command with a divisor, that can't be expressed by a
shift-operation (e.g. variable /= 10;) is implemented, the linker
Joerg Wunsch wrote on Montag, 12. Dezember 2005 23:01 :
The original author of that bug report has meanwhile analyzed the
behaviour he saw as a bug in his respective version of GCC, and IIRC
admitted that no memory clobber for sei/cli is really needed. At
least, that's what I've gathered from
Björn has prepared extended linker optimizations
(http://lists.gnu.org/archive/html/avr-libc-dev/2005-10/msg00042.html)
that also cover the --gc-sections bit. That work is currently integrated
in the binutils development.
The most recent discussions are available on the binutils mailing
Joerg Wunsch wrote on Montag, 14. November 2005 20:43 :
As david wrote:
I have a atmega2560 with the stk500 w/ 503 adapter.
I'm trying to get something to work.
I think Björn once posted a patch that has the side-effect of
also getting the ATmega256x supported. I haven't tried it
Dmitry K. wrote on Montag, 7. November 2005 08:43
So I think that bug should be resolved by using XJMP instead of
RJMP.
No!
The error is to mix the libraries. Is inadmissible to replace
a part of library another if the author did not project such
replacement initially. 'libm' uses some
Eric Weddington wrote on Montag, 17. Oktober 2005 17:44 :
Björn Haase wrote:
In reply to a message from July this year posted on avr-libc-list:
Yes I think, Thorsten, that you found a bug.
It seems that the binutils mainline does no longer assemble correctly the
dwarf2 informations. E.g
Will you detail how I can duplicate your results? This weekend I was
unable to get simulavr installed on Debian - even after setting the
compiler to locate the bfd and libiberty.a files.
IIRC for the old simulavr you will need binutils 2.14. I myself never got a
successfull build for
Bernd Trog wrote on Sonntag, 16. Oktober 2005 11:28 :
Björn, can you please give me your cvs-checkout date?
I get this with cvs-head-today:
patching file gas/config/tc-avr.h
Hunk #1 FAILED at 44.
patching file gas/config/tc-avr.c
Hunk #1 FAILED at 8.
Hunk #2 FAILED at 162.
Hunk #3 FAILED
Bernd Trog wrote on Sonntag, 16. Oktober 2005 12:30 :
On Sun, 16 Oct 2005, Björn Haase wrote:
Now I get:
../../src/bfd/elf32-avr.c: In function `elf32_avr_relax_section':
../../src/bfd/elf32-avr.c:1269: parse error before `int'
I think my old-fashioned gcc-2.95 doesn't like your
new C(99
Dmitry K. wrote on Freitag, 14. Oktober 2005 05:23 :
On Thursday 13 October 2005 21:46, Russell Strong wrote:
You have exclude frame pointer (r28/r29) initialization
by defining 'naked' for main.
But with automatic string 'heading_tmp' this is not work:
frame pointer is used as base
Peeter Vois wrote on Dienstag, 11. Oktober 2005 21:31 :
Hi,
I would like to inform that i have implemented the multiplication but I
have not tested it. As you can quess it was not hard. I have been
looking for the simulavr but looks like it is lots of work to make some
tests running with it.
Dmitry K. wrote on Dienstag, 27. September 2005 05:03 :
On Tuesday 27 September 2005 01:54, Björn wrote:
Follow-up Comment #5, bug #14616 (project avr-libc):
The unfortunate thing is, that using volatile is not enough. Even if it
works for your extremely simple test case: I am having a
Darcy Watkins wrote on Dienstag, 20. September 2005 00:40 :
Do you mean like this type of file? ... (except following the current
scheme instead of what I schemed up here).
This one was generated by my experimental parser using the XML file for the
ATmega2561.
Unthough I didn't check it so
Uwe Fechner wrote on Montag, 19. September 2005 13:56 :
Björn Haase schrieb:
Hi,
since there has been quite some discussion about the new large devices.
The attached patch is a summary of my present working directory for the
AVR port. Yet it does not have reached production quality
David Brown wrote on Montag, 19. September 2005 09:53 :
An alternative idea might be to use individual sections such as
.text1_foo for the stub for function foo(), and make use of the
--gc-sections option in the linker to remove any such section that is not
used. I'm thinking of the same idea
varsha wrote on Dienstag, 20. September 2005 06:57 :
__asm__ __volatile__
(
lsl crc0 \n\t//this doesn't work
rol crc1 \n\t//it gives error as
constant value required rol crc2 \n\t
rol crc3
);
You need to learn how
Joerg Wunsch wrote on Donnerstag, 8. September 2005 20:50 :
As Matthew MacClary wrote:
(About whether to keep avr/interrupt.h or avr/signal.h after
merging their contents.)
My suggestion would be to change INTERRUPT to be the same as
SIGNAL, and then deprecate SIGNAL.
Sorry, but I
Joerg Wunsch wrote on Mittwoch, 7. September 2005 21:49 :
Follow-up Comment #4, bug #12739 (project avr-libc):
Is there any news from any of those who discussed that item
previously? Otherwise, I'd go ahead and commit what's there.
I think now that It would be best to integrate support in
Bernard Foche wrote:
Now why not have an alloca(3) in libc? Sure it is not the best way to
manage dynamic memory but vfprintf/scanf are typicall applications where it
is acceptable. And a functionning alloca() is always handy.
We *are* already having a working alloca. It's within gcc. Only
Russell Shaw wrote on Dienstag, 6. September 2005 04:45 :
- The INTERRUPT() macro has been deprecated, and it will be
removed in a future version. Use __attribute__((interrupt))
explicitly if this functionality is really needed.
Maybe instead of interrupt, you could use
2005 22:43 :
I wished I were in a position (in terms of proper knowledge) of how to do
that rewrite. Could definitely use it :)
Mark E. Scott, Jr.
[EMAIL PROTECTED]
AWS, Inc.
512-478-7727 x 122
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Björn
Russell Shaw wrote on Montag, 5. September 2005 02:39 :
I'd rather adapt to a newer and better api than continue with old junk.
I agree. One should be prepared to face a flaming war on this list, but I
think that a substantial improvement is worth to endure this.
Bjoern
Anatoly Sokolov wrote on Freitag, 2. September 2005 20:42 :
URL:
http://savannah.nongnu.org/bugs/?func=detailitemitem_id=14378
Summary: EEPROM library d'not support at86rf401 device
What's the problem? Does at86rf401 have different EEPROM registers or what is
the issue?
IIUC, Marek has at least been starting to think about how to implement it. The
difficulty is, IIUC, that unless one is using tricks one no longer gets away
with 16 bit addresses for program memory.
Also the ram layout changes since when calling a function, the return address
now takes three
I think after your work the layout is much better than the old one.
Yours,
Björn
Joerg Wunsch wrote on Sonntag, 14. August 2005 23:57 :
As Joerg Wunsch wrote:
I've made a stab on a slightly new layout for our documentation.
Please have a look at
I'd even go so far to write it in the preamble that unless explicitly
stated, none of the library functions claims interrupt-safety.
Any opinions about that?
I think that it would be appropriate to add such a statement. One should, IMO,
try to find a wording that is also understood by
Dmitry K. wrote on Sonntag, 31. Juli 2005 06:34 :
Hi, Björn and all.
Many thanks!
Notes about 'eeprom_patch_take2.patch':
1. eeprom_read_block: operands sequence is changed.
OK, fixed in take 3
2. function definitions: 'static inline' must before type of return
value. Compiler give
Joerg Wunsch wrote
If we could agree (and implement) to Björn Haase's solution to the
EEPROM problem (at least as a workaround that can easily be done
inside the 1.2 release line), I'm more than happy if that could be in
1.2.5 as well.
in my today's opinion two issues need to be fixed and one
Nigel Winterbottom wrote on Donnerstag, 21. Juli 2005 17:41 :
Hello All,
I am aware of 3 problems with the eeprom support in avr-libc.
1. The SFR addresses are wrong for mega48, mega169, mega329 and the like.
2. eeprom_write_block takes a very long time even for small blocks.
(56-Bytes
The workaround/fix for the EEPROM access routines for ATmega169 has to
wait a bit. A couple of suggestions has been thrown into
consideration (a complete inlined solution on one hand, and Bjoern
Haase's suggested patch),
Hi,
concerning a completly inlined solution I have the follwing
47 matches
Mail list logo
