headers
Joerg Wunsch | 12 May 16:12
Picon

[bug #36454] string.h: Error for long long in C90

Follow-up Comment #3, bug #36454 (project avr-libc):

Another try:

Index: include/string.h
===================================================================
--- include/string.h    (revision 2291)
+++ include/string.h    (working copy)
@@ -110,7 +110,7 @@

 extern int ffs (int __val) __ATTR_CONST__;
 extern int ffsl (long __val) __ATTR_CONST__;
-extern int ffsll (long long __val) __ATTR_CONST__;
+__extension__ extern int ffsll (long long __val) __ATTR_CONST__;
 extern void *memccpy(void *, const void *, int, size_t);
 extern void *memchr(const void *, int, size_t) __ATTR_PURE__;
 extern int memcmp(const void *, const void *, size_t) __ATTR_PURE__;

The advantage of using __extension__ over the #ifdef solution
is that it also covers the -std=gnu89 case.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?36454>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Georg-Johann Lay | 12 May 10:27
Picon

[bug #36454] string.h: Error for long long in C90

URL:
  <http://savannah.nongnu.org/bugs/?36454>

                 Summary: string.h: Error for long long in C90
                 Project: AVR C Runtime Library
            Submitted by: gjlayde
            Submitted on: Sa 12 Mai 2012 08:27:10 GMT
                Category: Header
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.8.0
           Fixed Release: None

    _______________________________________________________

Details:

string.h contains the following lines:

# define __ATTR_CONST__	__attribute__((__const__))
extern int ffsll (long long __val) __ATTR_CONST__;

long long is available since C99. Consequently, compiling or syntax-checking
the above line with C90 may run into
(Continue reading)

Permalink | Reply | 1 comment |
headers
Axel Wachtler | 6 May 11:00
Picon

[bug #36410] avr/boot.h: poisoned SPMCR for ATmega128

URL:
  <http://savannah.nongnu.org/bugs/?36410>

                 Summary: avr/boot.h: poisoned SPMCR for ATmega128
                 Project: AVR C Runtime Library
            Submitted by: awachtler
            Submitted on: So 06 Mai 2012 09:00:05 GMT
                Category: Header
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Header files
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.8.0
           Fixed Release: None

    _______________________________________________________

Details:

If avr/boot.h is just included in a source file and the file is compiled for
atmega128, the compiler raises an error.

Here are the steps to reproduce the issue:
--------------------------------------------
$ cat foo.c
#include <avr/version.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
uracolix | 5 May 16:50
Picon
Favicon

avr/boot.h: poisoned SPMCR for ATmega128

Hallo list,

I recently stumbled across the following error with avr-libc 1.8.0.

--------------------------------------------
$ cat foo.c
#include <avr/version.h>
#include <avr/boot.h>

$ avr-gcc -c  -mmcu=atmega128 foo.c
In file included from foo.c:2:0:
/home/myavrtools/avr-gcc470/lib/gcc/avr/4.7.0/../../../../avr/include/avr/boot.h:112:16: 
error: attempt to use poisoned "SPMCR"

$ avr-gcc -c  -mmcu=atmega1281 foo.c
--------------------------------------------
For atmega1281 it works with no error.

My compiler is either avr-gcc 4.5.1 or 4.7.0, both compilers use
avr-libc 1.8.0

Thanks for any help, Axel
Permalink | Reply | 5 comments |
headers
Omar Choudary | 30 Apr 18:29
Picon

including avr/boot.h for xmega devices

Hello,

I am trying to adapt LUFA for a project using the atxmega256a3u.

I took the last svn version and added the VirtualSerialX provided by
Dean in a post:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=117994&highlight=lufa

This code includes avr/boot.h at some point. However, avr-libc (I'm
using 1.7.1) is complaining about the SMP instruction:

/usr/local/avr/lib/gcc/avr/4.5.1/../../../../avr/include/avr/boot.h:115:4:
error: #error AVR processor does not provide bootloader support!
/usr/local/avr/lib/gcc/avr/4.5.1/../../../../avr/include/avr/boot.h:125:4:
error: #error Cannot find SPM Enable bit definition!

I've checked the forum and it seems this problem was reported:
http://savannah.nongnu.org/bugs/?29187

there is also a post about how to build your bootloader:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=79592&postdays=0&postorder=asc

but... I don't want a bootloader. I just want LUFA to work. Therefore
I was looking for the quickest way to do this.

On the avr-libc release for 1.6 I found this among the "bux fixed"
http://svn.savannah.gnu.org/svn/avr-libc/branches/avr-libc-1_6-branch/avr-libc/NEWS
"[#25925] <avr/boot.h> cannot be included on Xmega devices"

Although it doesn't really seem to be fixed (also the bug report
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joerg Wunsch | 30 Apr 13:50
Picon

[bug #36350] FUSE4_DEFAULT wrong for Xmega A devices

URL:
  <http://savannah.nongnu.org/bugs/?36350>

                 Summary: FUSE4_DEFAULT wrong for Xmega A devices
                 Project: AVR C Runtime Library
            Submitted by: joerg_wunsch
            Submitted on: Mon 30 Apr 2012 01:50:42 PM CEST
                Category: Header
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Header files
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.7.1
           Fixed Release: None

    _______________________________________________________

Details:

j <at> uriah 55% fgrep FUSE4_DEFAULT include/avr/iox*
include/avr/iox128a1.h:#define FUSE4_DEFAULT  (0xFF)
include/avr/iox128a3.h:#define FUSE4_DEFAULT  (0xFF)
include/avr/iox128d3.h:#define FUSE4_DEFAULT  (0xFF)
include/avr/iox16a4.h:#define FUSE4_DEFAULT  (0xFF)
include/avr/iox16d4.h:#define FUSE4_DEFAULT  (0xFF)
include/avr/iox192a3.h:#define FUSE4_DEFAULT  (0xFF)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Spitzenpfeil | 13 Apr 17:01
Picon

[bug #36168] LUFA BuildTests fails for xmega device - incorrect header files

URL:
  <http://savannah.nongnu.org/bugs/?36168>

                 Summary: LUFA BuildTests fails for xmega device - incorrect
header files
                 Project: AVR C Runtime Library
            Submitted by: madworm
            Submitted on: Fri 13 Apr 2012 03:01:37 PM GMT
                Category: Header
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Header files
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.8.0
           Fixed Release: None

    _______________________________________________________

Details:

See: http://code.google.com/p/lufa-lib/issues/detail?id=47

    _______________________________________________________

Reply to this item at:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Waclawek | 7 Apr 16:02
Picon

[bug #36124] Improve documentation on .bss clear when used in assembler

URL:
  <http://savannah.nongnu.org/bugs/?36124>

                 Summary: Improve documentation on .bss clear when used in
assembler
                 Project: AVR C Runtime Library
            Submitted by: wek
            Submitted on: Sat 07 Apr 2012 02:02:23 PM GMT
                Category: Documentation
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Documentation
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: Any
           Fixed Release: None

    _______________________________________________________

Details:

Newer builds of the avr-gcc toolchain, such as WinAVR20100110, or builds
including the PR18145 fixup (4.7+), contain a patch which results in
conditional linking of the .bss cleanup loop only if it is needed for the C
source (similarly for the initialized .data). This may lead to surprising
behaviour when such variables are defined only in assembler parts of a
project.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Omar Choudary | 6 Apr 15:03
Picon

Possibly incorrect wdt implementation for xmega

Hello,

I was trying to compile a program that used the WDTO_4S value with an
xmega (ATXMEGA256A3U) and I got a compilation error (value not
defined).

Looking at the source (avr/include/avr/wdt.h) it seems that indeed the
values above 2S are not defined for the xmega family:

/** \ingroup avr_watchdog
    See \c WDT0_15MS
    Note: This is only available on the
    ATtiny2313,
    ATtiny24, ATtiny44, ATtiny84, ATtiny84A,
    ATtiny25, ATtiny45, ATtiny85,
    ATtiny261, ATtiny461, ATtiny861,
    ATmega48, ATmega88, ATmega168,
    ATmega48P, ATmega88P, ATmega168P, ATmega328P,
    ATmega164P, ATmega324P, ATmega644P, ATmega644,
    ATmega640, ATmega1280, ATmega1281, ATmega2560, ATmega2561,
    ATmega8HVA, ATmega16HVA, ATmega32HVB,
    ATmega406, ATmega1284P,
    AT90PWM1, AT90PWM2, AT90PWM2B, AT90PWM3, AT90PWM3B, AT90PWM216, AT90PWM316,
    AT90PWM81,
    AT90USB82, AT90USB162,
    AT90USB646, AT90USB647, AT90USB1286, AT90USB1287,
    ATtiny48, ATtiny88.
    */
#define WDTO_4S     8
(Continue reading)

Permalink | Reply | 2 comments |
headers
Barnabas Bodnar | 31 Mar 16:00
Picon

[bug #36053] Declaration of the register USIBR missing for ATtiny 2313a/4313

URL:
  <http://savannah.nongnu.org/bugs/?36053>

                 Summary: Declaration of the register USIBR missing for ATtiny
2313a/4313
                 Project: AVR C Runtime Library
            Submitted by: bbodnar
            Submitted on: Sat 31 Mar 2012 02:00:56 PM GMT
                Category: Header
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Header files
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.8.0
           Fixed Release: None

    _______________________________________________________

Details:

The USI buffer register (USIBR) isn't declared in the header-files of the
devices ATtiny 2313a and 4313, although they possess it (see
http://www.atmel.com/Images/doc8246.pdf page 167).

    _______________________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Spitzenpfeil | 24 Mar 00:50
Picon

[bug #35971] attiny4313 (2313a) pin-change interrupts PCINT[0...2]_vect etc.

URL:
  <http://savannah.nongnu.org/bugs/?35971>

                 Summary: attiny4313 (2313a) pin-change interrupts
PCINT[0...2]_vect etc.
                 Project: AVR C Runtime Library
            Submitted by: madworm
            Submitted on: Fri 23 Mar 2012 11:50:40 PM GMT
                Category: Header
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Header files
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.8.0
           Fixed Release: None

    _______________________________________________________

Details:

According to the datasheet these mcus support pin-change interrupts in 3
groups and hence also 3 pin-change interrupts:

PCINT0_vect ( vector #12 - avr-libc counting: 11 )
PCINT1_vect ( vector #20 -                    19 )
PCINT2_vect ( vector #21 -                    20 )
(Continue reading)

Permalink | Reply | 0 comments |

Gmane