[avr-libc-dev] [bug #21484] Documentation build for avr/version.h does not susbstitute autoconf macros

Update of bug #21484 (project avr-libc): Status:None => Fixed Assigned to:None => joerg_wunsch Open/Closed:Open => Closed ___

Re: [avr-libc-dev] Re: [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...

On Thursday 20 December 2007 11:53, Weddington, Eric wrote: [...] > But I definitely don't want to forget about this issue. I think that > this is an important enough change. Dmitry, would you be willing to add > a Task to the Task Tracker on avr-libc for this? This bug (#21841) is open at present

Re: [avr-libc-dev] Wishlist: place static bool in GPIO registers

On Thursday 20 December 2007 07:12, Shaun Jackman wrote: [...] > So, my wishlist item is to be able to use an attribute on a static > bool to locate it in the GPIO section, similar to PROGMEM, such as > #define IOMEM __attribute__((__iomem__)) > static bool IOMEM my_flag; [...] A little note: PROG

[avr-libc-dev] Misleading in CVS's NEWS file

Hi. Recently to the chapter "Changes since avr-libc-1.5.1" a 4 notes are added, about of old float point bugs fixed. It misleads a reader, since all this corrections were maked before 1.5.1 More, this was a main reason to start the new Avr-libc branch. What about to move (or delete) this notes?

RE: [avr-libc-dev] Re: [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib...

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Dmitry K. > Sent: Wednesday, December 19, 2007 6:38 PM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] Re: > [avr-libc-commit]avr-libcChangeLoginclude/stdlib.h libc/stdlib... >

Re: [avr-libc-dev] Re: [avr-libc-commit] avr-libcChangeLoginclude/stdlib.h libc/stdlib...

On Thursday 20 December 2007 00:53, Weddington, Eric wrote: > > Because that bug is completely unimportant and purely cosmetical. > > Real embedded applications don't exit() anyway. Mind you, we (at > > least you and me) have been shipping compiler/library combinations > > where returning from mai

RE: [avr-libc-dev] What about to make 'reti' as a default behaviour?

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Joerg Wunsch > Sent: Wednesday, December 19, 2007 2:52 PM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] What about to make 'reti' as a > default behaviour? > > As Weddington

Re: [avr-libc-dev] Wishlist: place static bool in GPIO registers

On Dec 19, 2007 2:39 PM, Stu Bell <[EMAIL PROTECTED]> wrote: > > The bit-field approach solves my primary complaint by not needing any > > accessor functions. Both if (my_flag) and my_flag = true; work as > > expected. As for the declaration, perhaps #define my_flag > > (GPIOR0_BIT.bit0) would be s

Re: [avr-libc-dev] What about to make 'reti' as a default behaviour?

As Weddington, Eric wrote: > > I won't touch the default handler right now. > > Why not? After some thorough thinking about it, I decided to leave it alone right now. After all, there has to be a reason to eventually roll a 1.8 release some day. ;-) Random thoughts: . Peter Danneggers suggest

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

> The bit-field approach solves my primary complaint by not needing any > accessor functions. Both if (my_flag) and my_flag = true; work as > expected. As for the declaration, perhaps #define my_flag > (GPIOR0_BIT.bit0) would be sufficient, where GPIOR0_BIT is defined > by avr-libc as > > #de

Re: [avr-libc-dev] Wishlist: place static bool in GPIO registers

On Dec 19, 2007 1:24 PM, Stu Bell <[EMAIL PROTECTED]> wrote: ... > The real problem with a full workup would be a macro to help define > "bit" variables. For example it would be cool to do something like the > following: > > #define DECLARE_BIT_VARIABLE(var,port,bnum) \ > #define (name) ((volat

Re: [avr-libc-dev] Wishlist: place static bool in GPIO registers

On Dec 19, 2007 12:35 PM, Weddington, Eric <[EMAIL PROTECTED]> wrote: > > The General Purpose I/O Registers (GPIOR0 through GIPOR3) are directly > > bit-accessible. It would be a very handy feature to be able to place a > > static bool (or any variable, I suppose) in the GPIO registers. > > Hi Shau

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

> -Original Message- > From: Weddington, Eric [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 19, 2007 1:13 PM > . . . > BIT_receive_132 = 1; > BIT_recv_error = 0; > if (BIT_buffer_status == 1) {} > > > Thanks! > > Note that "true" and "false" are already defined in and any implem

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Stu Bell > Sent: Wednesday, December 19, 2007 12:21 PM > To: Shaun Jackman; avr-libc-dev@nongnu.org > Subject: RE: [avr-libc-dev] Wishlist: place static bool in > GPIO registers > > This

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

This was posted by Cliff Lawson on AVRFreaks. I've modified it for GPIOR0. typedef struct { unsigned char bit0:1; unsigned char bit1:1; unsigned char bit2:1; unsigned char bit3:1; unsigned char bit4:1; unsigned char bit5:1; unsigned char bit6:1; unsigned c

RE: [avr-libc-dev] Wishlist: place static bool in GPIO registers

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Shaun Jackman > Sent: Wednesday, December 19, 2007 12:00 PM > To: avr-libc-dev@nongnu.org > Subject: [avr-libc-dev] Wishlist: place static bool in GPIO registers > > The General Purpose I/

[avr-libc-dev] Wishlist: place static bool in GPIO registers

The General Purpose I/O Registers (GPIOR0 through GIPOR3) are directly bit-accessible. It would be a very handy feature to be able to place a static bool (or any variable, I suppose) in the GPIO registers. Cheers, Shaun ___ AVR-libc-dev mailing list AV

RE: [avr-libc-dev] Re: [avr-libc-commit] avr-libcChangeLoginclude/stdlib.h libc/stdlib...

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Joerg Wunsch > Sent: Wednesday, December 19, 2007 7:19 AM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] Re: [avr-libc-commit] > avr-libcChangeLoginclude/stdlib.h libc/stdlib.

Re: [avr-libc-dev] Re: [avr-libc-commit] avr-libc ChangeLoginclude/stdlib.h libc/stdlib...

As Weddington, Eric wrote: > > ... There's no point in trying to plug libgcc's faults > > and omissions inside avr-libc. > Why not? Because that bug is completely unimportant and purely cosmetical. Real embedded applications don't exit() anyway. Mind you, we (at least you and me) have been shi

RE: [avr-libc-dev] Re: [avr-libc-commit] avr-libc ChangeLoginclude/stdlib.h libc/stdlib...

> -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Joerg Wunsch > Sent: Wednesday, December 19, 2007 6:17 AM > To: avr-libc-dev@nongnu.org > Subject: [avr-libc-dev] Re: [avr-libc-commit] avr-libc > ChangeLoginclude/stdlib.h libc/stdlib...

[avr-libc-dev] Re: [avr-libc-commit] avr-libc ChangeLog include/stdlib.h libc/stdlib...

As Dmitry Xmelkov wrote: > Log message: > Add CLI to abort() and exit() functions, since GCC's _exit() does not > disable interrupts today. Umm, no, please don't. If it's _exit()'s respsonsibility to do so, then let's leave it to libgcc.a instead. That's why I completely backed out

Re: [avr-libc-dev] [bug #21841] Add CLI to exit() and abort() loops

As Dmitry K. wrote: > Corrections are needed: Spasibo bolshoye, Dmitry! I've probably been too tired last night to really catch the differences between exit and _exit in these source files. I completely reverted the change, and re-opened the bug tracker item. That way, the correct place to fix

[avr-libc-dev] [bug #21841] Add CLI to exit() and abort() loops

Update of bug #21841 (project avr-libc): Status: Fixed => Ready For Test ___ Reply to this item at: ___

[avr-libc-dev] [bug #21841] Add CLI to exit() and abort() loops

Update of bug #21841 (project avr-libc): Assigned to:joerg_wunsch => aesok Open/Closed: Closed => Open ___ Follow-up Comment #1: OK, I completely