Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes

On Saturday 10 September 2005 01:48, Dave Hansen wrote: [...] > Has anyone put any thought into how we might get avr-gcc to do something > other than silently generate incorrect code when the user specifies an > incorrect SIG_* (or *_vect) symbol? For example, if I try to write > >SIGNAL(SIG_I

[avr-libc-dev] Usage of 'FILE *' in base put/get seems doubtful

Hi all. Now (Avr-libc 1.2.5 and previous) it is possible to appoint different i/o functions to different streams, for example: uart0_stream = fdevopen (uart0_put, 0, 0); uart1_stream = fdevopen (uart1_put, 0, 0); At desire different functions can be united in one, for example: int uar

Re: [avr-libc-dev] Re: [bug #12739] Gcc assumes that target libc provides ffs function

On Saturday 10 September 2005 07:31, Eric wrote: > Joerg Wunsch wrote: > >As Dmitry K. wrote: > >>It is possible to include 'ffs' in Avr-libc now. Will pass a lot of > >>time before it will be accessible in the reliable release of the new > >>Avr-gcc. Whether there will be 'ffsl' and 'ffsll'? > >

[avr-libc-dev] [bug #12735] No support for AT94K devices in sleep.h

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

Re: [avr-libc-dev] RFD: more avr-libc API changes

As Björn Haase wrote: > In fact, I don't think so. The planned change in the main function > (so that main() does no longer initialize the stack pointer) should > not be a problem, IIUC, since the stack pointer is already > initialized by the device-specific crt.? Yes, it is, and I recently fixed

[avr-libc-dev] [bug #14486] some macros from boot.h doesn't compile correctly

Update of bug #14486 (project avr-libc): Priority: 5 - Normal => 7 - High Assigned to:None => arcanum ___ Reply to this item at:

Re: [avr-libc-dev] RFD: more avr-libc API changes

As Joerg Wunsch wrote: > Would it make sense to have that on the schedule for GCC 5.x (plus > avr-libc 2.x)? Perhaps it would also be a good idea to change the interrupt vector table to the same way as MSP430-gcc is using by the same time. The new scheme definately does have some merit, but not

Re: [avr-libc-dev] RFD: more avr-libc API changes

I did some more work on an experimetal utility to parse the part description XML files from AVRStudio into device specific include files. Umm, but you know that Atmel already ships such a utility as part of AVR Studio, do you? Unfortunately, it's Windows-only, and as it apparently uses Microsof

Re: [avr-libc-dev] RFD: more avr-libc API changes

Joerg Wunsch wrote on Freitag, 9. September 2005 23:39 : > Our release policy says a major # bump is required iff an > incompatibility with some GCC version arises. This is currently not > the case (but if I understood Björn right, that could happen in the > near future). In fact, I don't think so

[avr-libc-dev] [bug #14486] some macros from boot.h doesn't compile correctly

URL: Summary: some macros from boot.h doesn't compile correctly Project: AVR C Runtime Library Submitted by: None Submitted on: Sat 09/10/05 at 07:01 Catego