Update of bug #32086 (project avr-libc):
Status: Need Info = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #5:
Now you can see
As Joerg Wunsch wrote:
Please do not commit anything to the repository right now.
Sylvain Beucler restored the SVN repository, so it's ready to
go again.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never
As some of you might have noticed, savannah has been the vitim of a
hacker last weekend. While the admins restored backup copies of the
SVN repository, it appears the current SVN repo lacks the latest
commits.
As I've got a sane backup of the repository that is newer than the
repository they
Update of bug #31768 (project avr-libc):
Status:None = Works For Me
Assigned to:None = aboyapati
___
Follow-up Comment #1:
To me, it seems
Update of bug #31613 (project avr-libc):
Status:None = Invalid
___
Follow-up Comment #1:
You are confusing the pointer with the object it points to:
the object is 8 bits wide, but the
Update of bug #31613 (project avr-libc):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?31613
___
Follow-up Comment #3, bug #31613 (project avr-libc):
but I cannot see an error in the attached example.
The error is:
unsigned int *ptab;
Make this:
unsigned char *ptab;
and it will work as expected. The pointer *points* to a
char object, yet the pointer itself (i.e., the temporary
Follow-up Comment #1, bug #31267 (project avr-libc):
Well, our policy is that the header file matches the device XML file,
so Atmel would have to change the XML file first.
However, this case is particularly difficult. As I understand it, the
vector is physically there, so we cannot just omit
As Joerg Wunsch wrote:
Also, any reason why _ticks is chosen to be uint8_t type (but not
uint16_t or uint32_t)?
Because the underlying _delay_loop_1 uses an 8-bit value.
p.s.: Of course, that doesn't apply to the case where the underlying
implementation can be based
As Boyapati, Anitha wrote:
The above link says, the maximal possible delay for _delay_us() is
768 us / F_CPU in MHz. However, as per the below computation, it
should be 765us. (Max value of _ticks when it is of uint8_t type is
255.)
No, the max value is 256, even though it is represented as
As Boyapati, Anitha wrote:
I am trying to see what factors influenced to go for a 16-bit
counter in one case and only 8-bit counter in the other. Why not
16-bit counter for both?
_delay_loop_2 has a coarser granularity (4 ticks vs. 3 for
_delay_loop_1).
Basically, both these functions were
As Simone Zamboni wrote:
Sorry, my fault. Change the =r constraint into =a.
Shouldn't be =d? ldi instruction requires upper registers from r16
to r31 but =a constrains registers only to r23 (works, but
limited).
OK. I only looked at the table, describing a as simple upper
registers, and
As Bob Paddock wrote:
From the error that I'm getting, below, I belive that __data_load_end
is only 16 bits wide?
No, obviously it's wider:
0x0003c370 __data_load_start = LOADADDR (.data)
0x0003c378 __data_load_end = (__data_load_start + SIZEOF (.data))
(That's from a map file.)
Note
As Bob Paddock wrote:
0x0003c370 __data_load_start = LOADADDR (.data)
0x0003c378 __data_load_end = (__data_load_start + SIZEOF (.data))
My map files has:
0xff22__data_load_start = LOADADDR (.data)
0xffc0
As Bob Paddock wrote:
Results in Register number above 15 required, a couple of times.
Sorry, my fault. Change the =r constraint into =a.
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an
Update of bug #31136 (project avr-libc):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Duplicate for bug
As Boyapati, Anitha wrote:
Can someone explain why this is intended only for ADC
Because adc is an opcode, so it should not be hidden by a macro
(as opcodes are case-insensitive).
and that too only for some devices?
(For e.g., iom32u4.h doesn't have)
That's an oversight then.
--
cheers,
As Rolf Ebert wrote:
I have just rebuilt a new compiler from pristine gcc-4.5.1
sources. If I want to compile avr-libc-1.7.0 the compiler stops when
building gcrt1.o for attiny2313a: unknown MCU specified.
The problem is that GCC doesn't exit with an error when encountering
an unknown -mmcu
Update of bug #30783 (project avr-libc):
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:None = 1.7.1
Update of bug #30783 (project avr-libc):
Status:None = Fixed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?30783
___
Update of bug #30757 (project avr-libc):
Status:None = Duplicate
Assigned to:None = aboyapati
___
Follow-up Comment #1:
This appears to be
Follow-up Comment #3, bug #30757 (project avr-libc):
This appears to be intentional:
r2116 | aboyapati | 2010-04-06 05:57:30 +0200 (Tue, 06 Apr 2010) | 20 lines
2010-03-31 Anitha Boyapati anitha.boyap...@atmel.com
Fix bug #28901.
* include/avr/iox128a1.h - Removed GPIO and
As DarkDragon wrote:
I initially submitted this bug under GCC bugzilla, but upon further
investigation, it looks like this comes from AVR-LibC as I can take
the LibC from the toolchain, insert it in WinAVR2010 and get the
same stack prologue code.
Please submit some code (and compilation
Update of bug #30745 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Update of bug #29704 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #8, patch #6951 (project avr-libc):
There are some news on my patch?
It would definitely speed up the acceptance of the patch if
you were digging up the licenses of all newly added files,
and place an appropriate copyright+license statement on top
of each file. Ideally, they
Follow-up Comment #2, bug #30363 (project avr-libc):
The define define value for __HAS_DELAY_CYCLES
in the new util/delah.h seems backwards.
This define is generated by the configure script, as it is
probing the compiler features. This is the only way I could
see how to find out whether
As Weddington, Eric wrote:
I would actually suggest using GCC 4.4.3. It's gotten more testing
than the bleeding edge.
Nevertheless, wouldn't an ICE be worth a (GCC) bug report anyway?
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
As Thomas Carsten Franke wrote:
I did not restored the NVM CMD because I
didn't know that it would has to be.
This is correct. We recently added a note to the documentation in the
header file avr/pgmspace.h telling that on Xmega devices, all the
functions will only work as designed if NVM_CMD
As Wouter van Gulik wrote:
Although true, I rather think this is a GCC bug. The avr instruction
documentation says LPM R31, Z+ has undefined results. In the example
it was oke to use LPM R31, Z.
IMHO, the respective code is hand-crafted asm code in avr-libc.
Please file a bug report.
--
As Wouter van Gulik wrote:
IMHO, the respective code is hand-crafted asm code in avr-libc.
Are you sure? The code is about a jump table, is that in avr-libc?
Errm, you are right...
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/
As Joerg Wunsch wrote:
That's my fault and shows clearly how unexperienced I am.
Next time, it's as simple as running one
./bootstrap
./configure --build=`./config.guess` --host=avr
make
cycle with the patched header file for a first test.
Speaking about simple tests: after adding
As Jan Waclawek wrote:
Maybe a bit more narrative than standard documentation, but I wanted
to spawn a discussion first, I did not expect it will be included
that soon.
Jan, we all appreciate your effort and contributions, but please, if
you want something discussed, start the discussion
Update of bug #30104 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Update of bug #30018 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Update of bug #20778 (project avr-libc):
Status:None = Works For Me
Open/Closed:Open = Closed
___
Follow-up Comment #3:
No feedback within
Update of bug #19178 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Release:
Update of bug #22163 (project avr-libc):
Severity: 3 - Normal = 4 - Important
Priority: 3 - Low = 7 - High
___
Reply to this item at:
Update of bug #22539 (project avr-libc):
Status:None = Need Info
Release:None = 1.6.1
___
Follow-up Comment #1:
We've never heard
As Dean Camera wrote:
Haven't tested it, however I can see how the C++ version would
work. I'd argue that the version maintaining the same API as the C
version should be the one adopted, since different APIs for C and
C++ are a bad thing.
Of course, maintaining the same API as the C version
Update of bug #26995 (project avr-libc):
Status:None = Need Info
___
Follow-up Comment #1:
Not confirmed:
$ cat bar.c
#include avr/io.h
FUSES =
{
.low = LFUSE_DEFAULT,
.high =
Update of bug #28108 (project avr-libc):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #5:
The resulting code
Update of bug #26995 (project avr-libc):
Status: Need Info = Works For Me
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #28921 (project avr-libc):
Category:None = Documentation
Item Group:None = Documentation
Status:None = Fixed
Assigned to:
As Dean Camera wrote:
I concur - it makes sense to move the memory barrier to the
definitions of the cli() and sei() macros,
(where it is now)
There's no good reason why the user would want the compiler to
re-order the assembly around cli() and sei(), as that's just asking
for trouble.
As Stu Bell wrote:
Before the rant below, let me make sure: I interpret this command to
mean that there is no way for the AVR GCC compiler writers to tell
the optimizer, Thou Shalt Not Reorder Code Around This Boundary.
Even more, there is no way for any mechanism (even #pragma?) for C
As Weddington, Eric wrote:
As a side note, wouldn't declaring some_temp_variable as volatile
solve the issue above?
I think it does, but it's another pessimization... It forces the
function to get a stack frame even if it otherwise doesn't need it,
and adds memory access cycles. The
As David Brown wrote:
Eric suggested making some_temp_variable volatile, which is the
traditional way to enforce ordering in C programming. Strictly
speaking, you don't have to make it volatile - it's enough to make
sure it is in memory if cli() and sei() have memory blocks.
Yes, but again:
As Weddington, Eric wrote:
The problem is actually in the original XML data, e.g., the
ATtiny40.xml file. The data below has extra characters in it
(parens, slash) that don't belong, which of course breaks any
semblence of a correct format.
PIN4
NAME[(PCINT3:ADC3]/NAME
As David Brown wrote:
It's been a while since I wrote that code!
But I still don't know whether I should include it or not. ;-)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you
With a bit of fiddling for those testscripts that failed in the
AT90S8515 simulation due to resource exhaustion on that rather small
controller, the testsuite now causes the following failures:
Simulate: math/isinf-01.c atmega128 ... *** simulate failed: 22
Simulate: math/isinf-01.c at90s8515 ...
Update of bug #30031 (project avr-libc):
Status:None = Works For Me
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of bug #29950 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
Update of patch #7073 (project avr-libc):
Status:None = Need Info
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
Did you actually
Update of patch #6935 (project avr-libc):
Status:None = Need Info
Assigned to:None = joerg_wunsch
___
Follow-up Comment #1:
I reimplemented
Update of patch #6791 (project avr-libc):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of patch #6680 (project avr-libc):
Assigned to:None = dmix
___
Follow-up Comment #1:
Dmitry is our Mr. libm.
___
Reply
Update of patch #6690 (project avr-libc):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Update of patch #6555 (project avr-libc):
Status:None = Done
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Patch applied,
Update of patch #3729 (project avr-libc):
Assigned to:joerg_wunsch = dmix
___
Follow-up Comment #6:
These are Dmitry's own patches.
___
Update of patch #6194 (project avr-libc):
Status:None = Done
Open/Closed:Open = Closed
___
Follow-up Comment #2:
I applied your
Update of patch #6891 (project avr-libc):
Status:None = Done
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
I'm about to commit a new header file, avr/cpufunc.h which will
include access to CPU (and compiler) functions that don't fit into any
other header file. First candidates are _NOP() (has been requested as
an enhancement) and _MemoryBarrier() (can sometimes be useful).
This raises the question:
Update of patch #6935 (project avr-libc):
Status: Need Info = Wont Do
Open/Closed:Open = Closed
___
Follow-up Comment #3:
OK, we can close
As Paulo Marques wrote:
One thing we could do for the programmers that want to use the raw
cli version and know what they are doing is to keep a __cli or
__raw_cli version (or some other name) that just emits a single
cli instruction.
I guess it's simple enough then to just write
asm
As Jan Waclawek wrote:
_MemoryBarrier() (can sometimes be useful).
Is this something already implemented in the compiler, or are you
just preparing for future?
It's always been there: it's an empty inline asm instruction with a
memory clobber.
Maybe this sounds trivial, but what about an
Update of bug #30085 (project avr-libc):
Status:None = Fixed
Assigned to:None = joerg_wunsch
Open/Closed:Open = Closed
Fixed Release:
As Jan Waclawek wrote:
I don't know what are similar aspects.
It's a little unfair that you repost a message to the list which
you've sent me personally only before, and which I've already replied
to.
I won't have the time to craft a public reply as well, sorry.
--
cheers, Jorg
Follow-up Comment #4, bug #27235 (project avr-libc):
Stefan, in bug #27242, you are talking about test cases you've
got for this bug here. I'm interested in getting them into
the tree, if you still have them.
___
Reply to this item at:
Follow-up Comment #5, bug #27235 (project avr-libc):
Sorry, I confused that with bug #25723.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?27235
___
Message sent via/by
Update of bug #27243 (project avr-libc):
Item Group:None = libc code
Status:None = Fixed
Open/Closed:Open = Closed
Update of bug #27242 (project avr-libc):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Thanks,
Update of bug #27235 (project avr-libc):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #6:
I backed out your
Update of bug #28135 (project avr-libc):
Status:None = Works For Me
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Thanks for your
As Weddington, Eric wrote:
I'm thinking that an avr-libc release ought to be done
soon-ish. There have been some recent bug submissions that I want to
take a quick look at, and get fixed, say within the next week.
Would it be reasonable to target June 4?
Sorry for missing the June 4 target,
As Matthias Fechner wrote:
Is that a wanted behaviour or maybe a bug?
The library functions are not meant to be used in an interrupt-
controlled access scheme. Users who want interrupt controlled EEPROM
writes are expected to create their own library.
That doesn't mean it couldn't be useful
As Weddington, Eric wrote:
int main () {
while (1) {
PORTC.OUT = 0x00;
PORTD.OUT = 0xff;
}
}
main:
/* prologue: function */
/* frame size = 0 */
ldi r26,lo8(1600)
ldi r27,hi8(1600)
ldi r30,lo8(1632)
ldi r31,hi8(1632)
ldi r24,lo8(-1)
As Matthias Fechner wrote:
Or is it a site-effect that this bit it reseted to 0?
It's a side-effect of the way it is currently implemented, which
simply assumes it owns the EECR register.
For the Xmega devices, things are completely different, btw.
--
cheers, Jorg .-.-. --...
Update of bug #27235 (project avr-libc):
Status:None = In Progress
Percent Complete: 0% = 30%
___
Follow-up Comment #3:
Patch for first
As Leiu wrote:
Please tell me why?
Because you didn't show us full, compilable code so nobody
could ever possibly reproduce your problem.
Please use avr-gcc-l...@nongnu.org for that kind of questions.
avr-libc-dev is meant for people who like to develop on avr-libc, or
have in-depth
As Jose Torres wrote:
Consider it my first patch proposal. :)
OK, fine, but where's the actual (and tested) patch? ;)
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't
Follow-up Comment #1, bug #29964 (project avr-libc):
What do you think is incorrect?
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?29964
___
Message sent via/by Savannah
As Karl Edler wrote:
The reason why I wanted them unified was so that I could write one
piece of UART code that would work with all avr micro-controllers.
Well, there are (unfortunately) more stumbling blocks along that road.
That starts with older devices naming their registers just UDR,
As Jan Waclawek wrote:
Again, why couldn't both be listed for the older ones?
Because it's extra work, and doesn't gain anything to the end user:
older devices (like the ATmega16) have *so many* differences, just
renaming the strange IRQ vectors doesn't help.
--
cheers, Jorg
As Karl Edler wrote:
I think that these definitions should be unified. Am I right?
Our policy is to match whatever the datasheet uses. As the datasheet
of the ATmega16 Co. used USART,TXC, we have it that way, too.
I don't think anyone is going to modify these very old datasheets
anymore.
--
As Steve Franks wrote:
Anyway, I've figured out my problem - set the library search path,
so I could find my libs, but now avr-gcc can't find the libs for the
m128. How do I go about merging those two concepts?
Normally, you don't have to hack those, they are supposed to be
derived from the
Update of bug #29774 (project avr-libc):
Status:None = Invalid
Open/Closed:Open = Closed
___
Follow-up Comment #1:
As you already
(Please subscribe to the list, you'll miss replies otherwise.)
As Vidar Vidnes wrote:
In file included from ../../../../common/macros.inc:39:0,
from ../../../../crt1/gcrt1.S:38:
../../../../include/avr/io.h:404:6: warning: #warning device type not
defined
Herein lies the
As Ivan Shmakov wrote:
So, what's about having, say, htonX () and ntohX () functions
in AVR Libc? These are standard [Posix], ...
Well, avr-libc doesn't aim to be a subset of Posix, but rather wants
to be a C standard library. Anyway, I wouldn't mind adding those to
the library,
Follow-up Comment #10, bug #28574 (project avr-libc):
As these reserved locations are part of a C struct, you
cannot have holes in them, so the C struct definition must
necessarily differ from the XML description (which can simply
omit the unused IO registers).
Filling these holes with
As Boyapati, Anitha wrote:
checking whether avr-gcc supports
__builtin_avr_delay_cycles... configure: error: link tests are not
allowed after AC_NO_EXECUTABLES
I am using autoconf-2.64.
Strange, must be something that only autoconf 2.64 complains about,
2.62 and 2.63 did work with the
As Boyapati, Anitha wrote:
checking whether avr-gcc supports
__builtin_avr_delay_cycles... configure: error: link tests are not
allowed after AC_NO_EXECUTABLES
On a second thought, I realized the message is correct, and I can also
reproduce it by deinstalling any prior instance of avr-libc.
As Joerg Wunsch wrote:
Seems I have to rewrite the check for __delay_cycles then.
I rewrote that check. Please test it on a Windows host, to make sure
I didn't break it there (in addition to the compiler itself, it uses
grep which I think is available even in the usual Windows build
As Boyapati, Anitha wrote:
Configure passes now. There is a build error w.r.t gcrt1.S
../../../../crt1/gcrt1.S:53: Error: non-constant expression in .if statement
All statements with 'vector' in gcrt1.S are shown as errors
Doesn't happen for me, I can compile the SVN trunk without
As Boyapati, Anitha wrote:
True. _VECTORS_SIZE is not replaced and hence the error. But this
happens for m3000 only. From what I observe, all avr/include/io*.h
files except iom3000.h define _VECTORS_SIZE. Since iom3000.h doesn't
have this definition, the variable should be defined somewhere.
As Boyapati, Anitha wrote:
While running bootstrap, I faced following config error. A quick
look at the dir structure shows that atxmega64a1u doesn't exist. Any
idea?
configure.ac:1279: required file`avr/lib/avrxmega5/atxmega64a1u/Makefile.in'
not found
When adding the ATxmega64A1U
Update of bug #29458 (project avr-libc):
Status:None = Need Info
___
Follow-up Comment #1:
*Which* errors do you get? Just claiming compile/link errors
is way too generic to judge
Update of bug #29458 (project avr-libc):
Status: Need Info = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #4:
This is
As Boyapati, Anitha wrote:
Both the trials are unsuccessful. They give me following error:
$ svn co http://svn.savannah.nongnu.org/svn/avr-libc
svn: Repository moved permanently to
'http://svn.savannah.gnu.org/svn/avr-libc'; please relocate
It seems the instructions given on savannah
As Boyapati, Anitha wrote:
Actually, several things are going wrong when I am trying to access
repository (either anonymously or as a member) using proxy
authentication (behind a firewall).
Must be a problem with your proxy setup. It works fine with my proxy
at home, but I could never get it
301 - 400 of 868 matches
Mail list logo
