[avr-libc-dev] [bug #21931] Wrong fuses defined for the ATMEGA88/168

Follow-up Comment #1, bug #21931 (project avr-libc): Update: The iom88p.h and the iom168p.h have the same bug. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?21931 ___

[avr-libc-dev] [bug #21931] Wrong fuses defined for the ATMEGA88/168

Update of bug #21931 (project avr-libc): Severity: 3 - Normal = 5 - Blocker Priority: 5 - Normal = 7 - High Assigned to:None = arcanum

[avr-libc-dev] [bug #21869] Multiple defines in iotn2313.h

Update of bug #21869 (project avr-libc): Severity: 3 - Normal = 5 - Blocker Priority: 5 - Normal = 7 - High Assigned to:None = arcanum

[avr-libc-dev] [task #7355] Add support for ATtiny43U.

Update of task #7355 (project avr-libc): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.nongnu.org/task/?7355 ___

[avr-libc-dev] [task #6954] Add support to toolchain for AT90PWM2B/AT90PWM3B.

Update of task #6954 (project avr-libc): Percent Complete: 50% = 100% Open/Closed:Open = Closed ___ Reply to this item at:

[avr-libc-dev] [task #7232] Add support for: ATmega48P-88P-168P-328P

Update of task #7232 (project avr-libc): Status: In Progress = Done Percent Complete: 80% = 100% Open/Closed:Open = Closed

[avr-libc-dev] [task #5090] Add new architecture 'avr35' in gcc toolchain for AT76C712-713 devices.

Update of task #5090 (project avr-libc): Percent Complete:100% = 90% Assigned to: aesok = arcanum Open/Closed: Closed = Open

[avr-libc-dev] [task #3692] Add new device: mega406

Update of task #3692 (project avr-libc): Status:None = Done Percent Complete: 90% = 100% Open/Closed:Open = Closed

[avr-libc-dev] [task #3693] Add new devices: mega 640-1280-1281-2560-2561

Update of task #3693 (project avr-libc): Assigned to:None = aesok ___ Follow-up Comment #11: Needed: Fix binutils bug #5523: http://sourceware.org/bugzilla/show_bug.cgi?id=5523 Patch to

Re: [avr-libc-dev] avr-lib-c-extentions library

As Weddington, Eric wrote: Dean Camera wrote: What sort of contributions did you have in mind? Would the util library code be moved over to the new library? How would you imagine it structured? I really thought of things that are currently available in libraries like Procyon AVRlib.

RE: [avr-libc-dev] avr-lib-c-extentions library

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Wednesday, January 02, 2008 2:13 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] avr-lib-c-extentions library As Weddington, Eric wrote: Dean Camera

RE: [avr-libc-dev] avr-lib-c-extentions library

On Wed, 2 Jan 2008, Weddington, Eric wrote: I'm open to having the LGPL license on such a library project. (Definitely not the GPL, though.) I can be persuaded to either the BSD or LGPL license. There's another (I'd argue, better) alternative: the CDDL. Certianly worth evaluating... --

RE: [avr-libc-dev] avr-lib-c-extentions library

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Joerg Wunsch Sent: Wednesday, January 02, 2008 3:00 PM To: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] avr-lib-c-extentions library As Rich Teer wrote: There's another (I'd

Re: [avr-libc-dev] avr-lib-c-extentions library

Weddington, Eric wrote: . same license as avr-libc to improve re-usability in closed source projects (that's the major distinction from Procyon AVRlib) I'm open to having the LGPL license on such a library project. (Definitely not the GPL, though.) I can be persuaded to either the BSD or

Re: [avr-libc-dev] avr-lib-c-extentions library

As Rich Teer wrote: ... In other words, under BSD, someone could take the AVRlibC code and change it, but not be obliged to return those changes back to the community. And this is exactly intentional for our purpose. In the embedded world, people can quickly become nervous if they even feel