[avr-gcc-list] Placing variable at absolute memory locations

2005-09-09 Thread Henrik Maier
Is there any way to place a variable [in my case an array of char] at an absolute position using just C statements ? I am aware of the method of defining a section, placing the variable into the section and then using a linker flag to define where this section is supposed to be located. I

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

2005-09-09 Thread Joerg Wunsch
As Wojtek Kaniewski wrote: What about the SIG_ prefix? If we'll move to something else than SIGNAL(), I think that it should be dropped or somehow hidden from the users. Very good point. I've been thinking about adding a second set of vector names anyway. Our names are completely

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

2005-09-09 Thread Szikra István
For the whole SIGNAL vs INTERRUPT flame: I'm with 'deprecate booth', cause of ambiguous (and maybe a bit stupid) naming. SIGNAL is a normal interrupt, (I'd like INT for it, but integer is already int, so) i really like the ISR name idea. since INTERRUPT is an eXtended interrupt (with a sei) it

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

2005-09-09 Thread Szikra Istvan
Joerg Wunsch wrote: As Wojtek Kaniewski wrote: What about the SIG_ prefix? If we'll move to something else than SIGNAL(), I think that it should be dropped or somehow hidden from the users. Very good point. I've been thinking about adding a second set of vector names anyway. Our names

Re: [avr-gcc-list] How Hot does a 62256-15 SRAM Get?

2005-09-09 Thread David Kelly
On Sep 9, 2005, at 2:33 AM, [EMAIL PROTECTED] wrote: Be careful ! You use an 15ns SRAM (as I see so far in the part number). They will draw a bit more current than 70ns SRAM's. Can you post the Currents from the datasheet ? Back in the bad old days a -15 was a 150 ns part. To answer the

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

2005-09-09 Thread Wojtek Kaniewski
On Fri, 9 Sep 2005, Szikra István wrote: BTW, util/... would be a good place for avr/crc16.h too. Unfortunately crc16.h is not completely independent from avr hw on the account it uses inline asm, and not (ansi) c. I believe that it's about functionality, not implementation. Delays and CRC

Re: [avr-gcc-list] How Hot does a 62256-15 SRAM Get?

2005-09-09 Thread User Tomdean
I purchased the part from Jameco. I wanted the NS62256H-15NC, Jameco shows ATT7C199P-15. . The part I receied was UM61m256K-15, with a fancy 'm'. The data sheet is for an AS7C256(5v)/ From the data sheet, Max operating current is 115 ma. Standby is 4 ma. I do not have the exact datasheet for

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

2005-09-09 Thread Francisco Silva
2005/9/9, E. Weddington [EMAIL PROTECTED]: - I do like the idea that Royce has (above) about naming the ISR function any name. However, I agree with Joerg, in that it would take an awful lot of effort. Perhaps someday, but not now. mspgcc interrupts are handled that way. Quoting from the

Re: [avr-gcc-list] Placing variable at absolute memory locations

2005-09-09 Thread Henrik Maier
Dave, This creates a pointer to a specific memory location but does *not* allocate the memory. The linker will still place other variables into this memory space. What I actually want to achieve is reserving a memory space from 0x100 onwards by allocating an absolute variable or a memory

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

2005-09-09 Thread Szikra Istvan
Wojtek Kaniewski wrote: Joerg Wunsch wrote: My only concern is to not pollute the include/avr subdirectory itself too much. I'd prefer those functions to be in util/* than avr/generic/*. Me too and, if it avr specific than rather avr/util/* than avr/generic/* i also suggest moving

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

2005-09-09 Thread Darcy Watkins
Hi, I did some more work on an experimetal utility to parse the part description XML files from AVRStudio into device specific include files. I still have to do a bit more work on it, but I think that the idea will work. I was able to generate vector macros, register macros and bit macros from

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

2005-09-09 Thread E. Weddington
Joerg Wunsch wrote: As Wojtek Kaniewski wrote: Very good point. I've been thinking about adding a second set of vector names anyway. Our names are completely self-invented. In the long run, I'd rather like to migrate the names as they appear in the Atmel XML files, which incidentally

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

2005-09-09 Thread Joerg Wunsch
Oh well, yet another mass followup. Sorry if that's messing up your thread displays. ;-) As Szikra Istvan wrote: I'd prefer those functions to be in util/* than avr/generic/*. Me too and, if it avr specific than rather avr/util/* than avr/generic/* As that still has the problem of adding

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

2005-09-09 Thread E. Weddington
Joerg Wunsch wrote: Oh well, yet another mass followup. Sorry if that's messing up your thread displays. ;-) I think it's hopeless now. :-) Do we still need copies to avr-gcc-list? Or can everyone agree to go take this to avr-libc-dev only? (I'd like to not get two copies of