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
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.
- Dean
--
From: Joerg Wunsch
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:
On 09/06/2010 10:23, Joerg Wunsch wrote:
https://savannah.nongnu.org/bugs/?22163
The bug looks serious enough to me so I'd like to include David's
alternative C++ implementation. Did anyone else test this? Any
objections?
It's been a while since I wrote that code!
Looking back at it,
Hi Joerg,
I saw the issue but haven't looked into it yet. Is it a problem in the script
generation? Or was the XML data file also bad? The script needs to be fixed to
catch this issue in the verification step for sure. But I want to make sure
that there isn't a problem in the XML.
Eric
On 6/8/2010 10:31 AM, Bob Paddock wrote:
There are several places that handle SP adjustment:
avr.c: output_movhi, expand_prologue, expand_epilogue
avr.md: movhi_sp_r_irq_off, movhi_sp_r_irq_on (both generated in
epilogue/prologue)
libgcc.S: __prologue_saves__, __epilogue_restores__
For
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.
VQFN
NMB_PIN20/NMB_PIN
PIN1
NAME[PCINT6:ADC6]/NAME
If the memory clobbers are added to the definitions of cli() and sei(), as
well as an sreg set macro (or inline function), then these should be
used in the code here instead of writing the inline assembly explicitly.
I concur - it makes sense to move the memory barrier to the definitions of
Follow-up Comment #2, bug #22539 (project avr-libc):
I had a similar problem, which I think was due to an incorrect patch. There
was a wildcard in one of the config / header files which incorrectly pulled
some of the MCU types into the wrong AVR architecture group. When I replaced
the wildcard
Hi,
first of all thanks for the great work on AVR support.
I'm trying to access the EEPROM of a xmega128A1 device using libc, but
it's not working. Should it work in principle or is xmega support
currently missing ?
Best regards,
Moritz
___
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.
On Wed, Jun 9, 2010 at 1:55 PM, Moritz v. Buttlar
i...@baltic-microsolutions.de wrote:
Hi,
first of all thanks for the great work on AVR support.
I'm trying to access the EEPROM of a xmega128A1 device using libc, but
it's not working. Should it work in principle or is xmega support
currently
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.
There's a common miscomprehension: a memory barrier ensures
that all write operations are committed to memory, and memory
locations will
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
-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, June 09, 2010 1:20 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] Re:
As Jorg Wunsch wrote:
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
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
-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, June 09, 2010 1:50 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] Re:
Joerg Wunsch wrote:
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
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 ...
-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, June 09, 2010 3:08 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] RE:
Update of bug #29653 (project avr-libc):
Status:None = Fixed
Percent Complete: 0% = 100%
Assigned to:None = arcanum
Open/Closed:
Update of bug #29502 (project avr-libc):
Status:None = Fixed
Percent Complete: 0% = 100%
Assigned to:None = arcanum
Open/Closed:
Follow-up Comment #1, bug #30091 (project avr-libc):
Another thing that needs to be changed in the convertor script is to be able
to generate double-word registers.
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?30091
Update of bug #28582 (project avr-libc):
Status:None = Fixed
Percent Complete: 0% = 100%
Assigned to:None = arcanum
Open/Closed:
Update of bug #28574 (project avr-libc):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?28574
___
37 matches
Mail list logo
