http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6199 <pre>Update of bug #36454 (project avr-libc): Status: In Progress =&gt; Fixed Open/Closed: Open =&gt; Closed Fixed Release: None =&gt; 1.8.1 _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?36454&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Joerg Wunsch 2012-05-14T15:39:39 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6198 <pre>Follow-up Comment #4, bug #36454 (project avr-libc): Yes, looks better. No more complaints. Thanks. _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?36454&gt; _______________________________________________ Nachricht gesendet von/durch Savannah http://savannah.nongnu.org/ </pre> Georg-Johann Lay 2012-05-14T13:41:02 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6197 <pre>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) &lt; at &gt;&lt; at &gt; -110,7 +110,7 &lt; at &gt;&lt; at &gt; 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: &lt;http://savannah.nongnu.org/bugs/?36454&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Joerg Wunsch 2012-05-12T14:12:49 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6196 <pre>Update of bug #36454 (project avr-libc): Status: None =&gt; In Progress Assigned to: None =&gt; joerg_wunsch _______________________________________________________ Follow-up Comment #1: Would this help? Index: include/string.h =================================================================== --- include/string.h (revision 2291) +++ include/string.h (working copy) &lt; at &gt;&lt; at &gt; -110,7 +110,7 &lt; at &gt;&lt; at &gt; extern int ffs (int __val) __ATTR_CONST__; extern int ffsl (long __val) __ATTR_CONST__; -extern int ffsll (long long __val) __ATTR_CONST__; +extern int ffsll (__extension__ 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__; _______________________________________________________ Reply to this item at: &lt;http://savannah.nongnu.org/bugs/?36454&gt; _</pre> Joerg Wunsch 2012-05-12T09:15:47 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6195 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?36454&gt; 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 error: ISO C90 does not support 'long long' [-Wlong-long] This is particularly inconvenient</pre> Georg-Johann Lay 2012-05-12T08:27:11 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6194 <pre>It is now filed as bug #36410. Thanks, Axel </pre> uracolix 2012-05-06T09:01:44 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6193 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?36410&gt; 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 &lt;avr/version.h&gt; #include &lt;avr/boot.h&gt; $ avr-gcc -c -mmcu=atmega128 foo.c In file included from foo.c:2:0: </pre> Axel Wachtler 2012-05-06T09:00:06 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6192 <pre> Ouch. Point taken. Please file a bug report. </pre> Joerg Wunsch 2012-05-05T21:56:11 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6191 <pre> On 05.05.2012 22:43, Joerg Wunsch wrote: Yes, but just by inclusion of avr/boot.h a source file does not compile anymore. How can this be fixed from the user perspective? Axel </pre> uracolix 2012-05-05T21:29:17 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6190 <pre> ATmega128's IO register 0x68 has got the name SPMCSR, starting with the revision E datasheet 05/2002. This replaced the former name SMPCR. </pre> Joerg Wunsch 2012-05-05T20:43:53 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6189 <pre>I found on another machine an avr-gcc 4.3.5 with an avr-libc 1.6.8 and it works with atmega128. -- Axel </pre> uracolix 2012-05-05T14:54:25 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6188 <pre>Hallo list, I recently stumbled across the following error with avr-libc 1.8.0. -------------------------------------------- $ cat foo.c #include &lt;avr/version.h&gt; #include &lt;avr/boot.h&gt; $ 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 </pre> uracolix 2012-05-05T14:50:04 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6187 <pre>I've finally managed to get the stuff working (avr-libc was the main issue). To save me from some typing I simply copy paste below my message to Dean. Cheers, Omar. ----------------------- Hi Dean, I finally managed to integrate the new version with my xmega (still have to build smth ... but at least is compiling). I took the last git version from last week, then added the VirtualSerialX project you gave on the forum and then modified a bit the makefiles to suit my project. However it didn't work with the last .deb package containing avr-libc 1.7.1. With that version I get a bunch of errors, mostly relating to the fact that avr-libc 1.7.1 is behind on the support for XMega U's (the ones with USB). There is no avr/iox256a3u.h file for example. To give my point, here is what I got: In file included from xmega_lufa_virtual_serial/../LUFA/Drivers/USB/Core/XMEGA/../USBInterrupt.h:64:0, from xmega_lufa_virtual_serial/../LUFA/Drivers/USB/Core/XMEGA/USBController_XMEGA.h:56, from xmega_lufa_virtual_serial</pre> Omar Choudary 2012-05-01T19:42:47 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6186 <pre> I don't think boot.h has been systematically tested on xmega devices. It probably doesn't work. Eric </pre> Weddington, Eric 2012-04-30T17:54:56 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6185 <pre>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&amp;file=viewtopic&amp;t=117994&amp;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&amp;file=viewtopic&amp;t=79592&amp;postdays=0&amp;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</pre> Omar Choudary 2012-04-30T16:29:45 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6184 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?36350&gt; 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&lt; at &gt;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/iox19</pre> Joerg Wunsch 2012-04-30T11:50:43 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6183 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?36168&gt; 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: &lt;http://savannah.nongnu.org/bugs/?36168&gt; _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/ </pre> Robert Spitzenpfeil 2012-04-13T15:01:38 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6182 <pre>URL: &lt;http://savannah.nongnu.org/bugs/?36124&gt; 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 va</pre> Jan Waclawek 2012-04-07T14:02:24 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6181 <pre>I've found that the iox256a3.h file actually contains the more correct values: /* Period setting */ typedef enum WDT_PER_enum { WDT_PER_8CLK_gc = (0x00&lt;&lt;2), /* 8 cycles (8ms &lt; at &gt; 3.3V) */ WDT_PER_16CLK_gc = (0x01&lt;&lt;2), /* 16 cycles (16ms &lt; at &gt; 3.3V) */ WDT_PER_32CLK_gc = (0x02&lt;&lt;2), /* 32 cycles (32ms &lt; at &gt; 3.3V) */ WDT_PER_64CLK_gc = (0x03&lt;&lt;2), /* 64 cycles (64ms &lt; at &gt; 3.3V) */ WDT_PER_128CLK_gc = (0x04&lt;&lt;2), /* 128 cycles (0.125s &lt; at &gt; 3.3V) */ WDT_PER_256CLK_gc = (0x05&lt;&lt;2), /* 256 cycles (0.25s &lt; at &gt; 3.3V) */ WDT_PER_512CLK_gc = (0x06&lt;&lt;2), /* 512 cycles (0.5s &lt; at &gt; 3.3V) */ WDT_PER_1KCLK_gc = (0x07&lt;&lt;2), /* 1K cycles (1s &lt; at &gt; 3.3V) */ WDT_PER_2KCLK_gc = (0x08&lt;&lt;2), /* 2K cycles (2s &lt; at &gt; 3.3V) */ WDT_PER_4KCLK_gc = (0x09&lt;&lt;2), /* 4K cycles (4s &lt; at &gt; 3.3V) */ WDT_PER_8KCLK_gc = (0x0A&lt;&lt;2), /* 8K cycles (8s &lt; at &gt; 3.3V) */ } WDT_PER_t; However, as you mention, I doubt the code in the avr-libc is using that properly. At least not from what I've seen. On Fri, Apr 6, 2012 at 4:46 PM, Erik Walthinsen &lt;om</pre> Omar Choudary 2012-04-06T16:16:42 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6180 <pre>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 That is strange, since the </pre> Omar Choudary 2012-04-06T13:03:02 http://permalink.gmane.org/gmane.comp.hardware.avr.libc.devel/6179 <pre> I can confirm that the xmega WDT stuff is very broken, I've resorted to not only figuring the register values myself but ditching the entire wdt_enable/disable code and just doing it myself with the CCP register and all. I'd fix it if I had time, but.... ;-( </pre> Erik Walthinsen 2012-04-06T15:46:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.hardware.avr.libc.devel