Nabble - AVR

[patch #6649] sqrt.s in libm changes

2008-10-12T23:42:10Z

URL:
<http://savannah.nongnu.org/patch/?6649>

Summary: sqrt.s in libm changes
Project: AVR C Runtime Library
Submitted by: ruud62
Submitted on: Mon Oct 13 06:42:08 2008
Category: None
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any

_______________________________________________________

Details:

I have attached a new sqrt.s file which I propose for libm. Tested for all 23
bits mantissa, for both odd and even exponent.

Statistics relative to version 1.8 if __Optimizesize__ defined:
17 code words shorter, 120-244 cycles faster (average 169)

Statistics relative to version 1.8 if __Optimizesize__ not defined:
12 code words shorter, 184-294 cycles faster (average 231)

Regards
Ruud

_______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Mon Oct 13 06:42:08 2008 Name: sqrt.S Size: 5kB By: ruud62

<http://savannah.nongnu.org/patch/download.php?file_id=16664>

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?6649>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

Re: New square root?

2008-10-12T08:35:15Z

As Ruudje wrote:

> I'm new to this list and project. So I don't really know how things
> work here.

Hi, and thanks for the contribution!

The normal way for that kind of submission is to file it as a patch
under

http://savannah.nongnu.org/patch/?group=avr-libc

Contributions sent in email messages have a tendency to eventually get
lost in the daily email flood.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

Re: Link script question

2008-10-10T13:38:28Z

Freakin' awesome. Thanks, tons!
 
Gre7g

----- Original Message ----
From: Dave Hylands <dhylands@...>
To: Gre7g Luterman <hafeliel@...>
Cc: avr-gcc-list@...
Sent: Friday, October 10, 2008 2:12:21 PM
Subject: Re: [avr-gcc-list] Link script question

Gu Gre7g,

Try this version of mega32.ld

I think it does everything you need without having to use any .c files.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Link script question

2008-10-10T13:27:44Z

Dave Hylands wrote:
> Gu Gre7g,
>
> Try this version of mega32.ld
>
> I think it does everything you need without having to use any .c files.

Yes, better. I didn't know you could stuff data from the linker script.

-dave

>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Link script question

2008-10-10T13:24:51Z

Gre7g Luterman wrote:

> From: Dave N6NZ <n6nz@...> To: Gre7g Luterman
> <hafeliel@...> Cc: avr-gcc-list@... Sent: Friday,
> October 10, 2008 11:02:21 AM Subject: Re: [avr-gcc-list] Link script
> question
>
>>> That would work, of course, but I'd have to designate a constant
>>> address for the block, right?
>> No, not at all. That's the point of putting it in the linker script
>> and letting the linker compute the address.
>>
>>> The script as I have it now, automagically selects the first
>>> available block after my code. I really like having this done
>>> automatically for me.
>> And that is exactly what this does. Take a look at the linker
>> script and how it works. All my addition does is declare a named
>> section that starts at exactly the place that your
>> __user_prog_start symbol is defined. It's really your solution,
>> but with an additional name that you can use as an attribute to a
>> data section.
>
> Well, I don't get it. I tried sticking your solution in and I get:
>
> ld.exe:mega32.ld:177: syntax error
>
> Obviously I'm missing something. Your section definitions don't look
> like the others in the script. I'll attach the patched script to this
> e-mail. Perhaps someone can correct the syntax error and show me what
> I'm missing.

OK, well first let me say that I am not a linker script guru, I simply
manage to get by.

I think the syntax error is coming from two things, the ';' terminating
the line, and the '*.('. I don't think the ';' should be at the end of
a section call out, just at the end of linker expressions, and the
period in *.( is extraneous, I believe.

Secondly, I think the .userprog section should be inside the braces for
the data section to accomplish what you want. (I'm a little fuzzy here,
though, so double check the documentation.) Also, I think it should be
called out as *(.userprog), which says: "any file, the section
'.userprog'", on the assumption that you don't have any '.userprog.foo'
sections that you want to pick up with a *(.userprog.*) call out.

Here is your file, tweaked.

-dave

>
> Gre7g
>
>
>

/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")
OUTPUT_ARCH(avr:1)
MEMORY
{
text (rx) : ORIGIN = 0x000000, LENGTH = 0x7D00
changes (rx) : ORIGIN = 0x007D00, LENGTH = 0x0080
update (rx) : ORIGIN = 0x007D80, LENGTH = 0x0280
data (rw!x) : ORIGIN = 0x800060, LENGTH = 0x0800
eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 0x03FF
eelayver (rw!x) : ORIGIN = 0x8103FF, LENGTH = 0x0001
}
SECTIONS
{
/* Read-only sections, merged into text segment: */
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.text :
{
*(.rel.text)
*(.rel.text.*)
*(.rel.gnu.linkonce.t*)
}
.rela.text :
{
*(.rela.text)
*(.rela.text.*)
*(.rela.gnu.linkonce.t*)
}
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.rodata :
{
*(.rel.rodata)
*(.rel.rodata.*)
*(.rel.gnu.linkonce.r*)
}
.rela.rodata :
{
*(.rela.rodata)
*(.rela.rodata.*)
*(.rela.gnu.linkonce.r*)
}
.rel.data :
{
*(.rel.data)
*(.rel.data.*)
*(.rel.gnu.linkonce.d*)
}
.rela.data :
{
*(.rela.data)
*(.rela.data.*)
*(.rela.gnu.linkonce.d*)
}
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.got : { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.bss : { *(.rel.bss) }
.rela.bss : { *(.rela.bss) }
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
/* Internal text space or external memory. */
.changes :
{
changes_start = . ;
*(.changes)
changes_end = . ;
} > changes
.update :
{
update_start = . ;
*(.update)
update_end = . ;
} > update
.text :
{
*(.vectors)
KEEP(*(.vectors))
/* For data that needs to reside in the lower 64k of progmem. */
*(.progmem.gcc*)
*(.progmem*)
. = ALIGN(2);
__trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here. */
*(.trampolines)
*(.trampolines*)
__trampolines_end = . ;
/* For future tablejump instruction arrays for 3 byte pc devices.
We don't relax jump/call instructions within these sections. */
*(.jumptables)
*(.jumptables*)
/* For code that needs to reside in the lower 128k progmem. */
*(.lowtext)
*(.lowtext*)
__ctors_start = . ;
*(.ctors)
__ctors_end = . ;
__dtors_start = . ;
*(.dtors)
__dtors_end = . ;
KEEP(SORT(*)(.ctors))
KEEP(SORT(*)(.dtors))
/* From this point on, we don't bother about wether the insns are
below or above the 16 bits boundary. */
*(.init0) /* Start here after reset. */
KEEP (*(.init0))
*(.init1)
KEEP (*(.init1))
*(.init2) /* Clear __zero_reg__, set up stack pointer. */
KEEP (*(.init2))
*(.init3)
KEEP (*(.init3))
*(.init4) /* Initialize data and BSS. */
KEEP (*(.init4))
*(.init5)
KEEP (*(.init5))
*(.init6) /* C++ constructors. */
KEEP (*(.init6))
*(.init7)
KEEP (*(.init7))
*(.init8)
KEEP (*(.init8))
*(.init9) /* Call main(). */
KEEP (*(.init9))
*(.text)
. = ALIGN(2);
*(.text.*)
. = ALIGN(2);
*(.fini9) /* _exit() starts here. */
KEEP (*(.fini9))
*(.fini8)
KEEP (*(.fini8))
*(.fini7)
KEEP (*(.fini7))
*(.fini6) /* C++ destructors. */
KEEP (*(.fini6))
*(.fini5)
KEEP (*(.fini5))
*(.fini4)
KEEP (*(.fini4))
*(.fini3)
KEEP (*(.fini3))
*(.fini2)
KEEP (*(.fini2))
*(.fini1)
KEEP (*(.fini1))
*(.fini0) /* Infinite loop after program termination. */
KEEP (*(.fini0))
_etext = . ;
} > text
.data : AT (ADDR (.text) + SIZEOF (.text))
{
PROVIDE (__data_start = .) ;
*(.data)
*(.data*)
*(.rodata) /* We need to include .rodata here if gcc is used */
*(.rodata*) /* with -fdata-sections. */
*(.gnu.linkonce.d*)
. = ALIGN(2);
_edata = . ;
PROVIDE (__data_end = .) ;
. = ALIGN(128);
__user_prog_start = .;
*(.userprog)
} > data
/* User-programming space */
. = _etext + SIZEOF(.data);
.bss SIZEOF(.data) + ADDR(.data):
{
PROVIDE (__bss_start = .) ;
*(.bss)
*(.bss*)
*(COMMON)
PROVIDE (__bss_end = .) ;
} > data
__data_load_start = LOADADDR(.data);
__data_load_end = __data_load_start + SIZEOF(.data);
/* Global data not cleared after reset. */
.noinit SIZEOF(.bss) + ADDR(.bss) :
{
PROVIDE (__noinit_start = .) ;
*(.noinit*)
PROVIDE (__noinit_end = .) ;
_end = . ;
PROVIDE (__heap_start = .) ;
} > data
.eeprom :
{
*(.eeprom*)
__eeprom_end = . ;
} > eeprom
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) *(.gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
}

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Link script question

2008-10-10T13:12:21Z

Gu Gre7g,

Try this version of mega32.ld

I think it does everything you need without having to use any .c files.

--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

mega32.ld (8K) Download Attachment

From forum: AVR - gcc

Re: Link script question

2008-10-10T12:08:15Z

I freakin' hate Yahoo! mail. Here's the attachment I was trying to include.

/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")
OUTPUT_ARCH(avr:1)
MEMORY
{
text (rx) : ORIGIN = 0x000000, LENGTH = 0x7D00
changes (rx) : ORIGIN = 0x007D00, LENGTH = 0x0080
update (rx) : ORIGIN = 0x007D80, LENGTH = 0x0280
data (rw!x) : ORIGIN = 0x800060, LENGTH = 0x0800
eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 0x03FF
eelayver (rw!x) : ORIGIN = 0x8103FF, LENGTH = 0x0001
}
SECTIONS
{
/* Read-only sections, merged into text segment: */
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.text :
{
*(.rel.text)
*(.rel.text.*)
*(.rel.gnu.linkonce.t*)
}
.rela.text :
{
*(.rela.text)
*(.rela.text.*)
*(.rela.gnu.linkonce.t*)
}
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.rodata :
{
*(.rel.rodata)
*(.rel.rodata.*)
*(.rel.gnu.linkonce.r*)
}
.rela.rodata :
{
*(.rela.rodata)
*(.rela.rodata.*)
*(.rela.gnu.linkonce.r*)
}
.rel.data :
{
*(.rel.data)
*(.rel.data.*)
*(.rel.gnu.linkonce.d*)
}
.rela.data :
{
*(.rela.data)
*(.rela.data.*)
*(.rela.gnu.linkonce.d*)
}
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.got : { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.bss : { *(.rel.bss) }
.rela.bss : { *(.rela.bss) }
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
/* Internal text space or external memory. */
.changes :
{
changes_start = . ;
*(.changes)
changes_end = . ;
} > changes
.update :
{
update_start = . ;
*(.update)
update_end = . ;
} > update
.text :
{
*(.vectors)
KEEP(*(.vectors))
/* For data that needs to reside in the lower 64k of progmem. */
*(.progmem.gcc*)
*(.progmem*)
. = ALIGN(2);
__trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here. */
*(.trampolines)
*(.trampolines*)
__trampolines_end = . ;
/* For future tablejump instruction arrays for 3 byte pc devices.
We don't relax jump/call instructions within these sections. */
*(.jumptables)
*(.jumptables*)
/* For code that needs to reside in the lower 128k progmem. */
*(.lowtext)
*(.lowtext*)
__ctors_start = . ;
*(.ctors)
__ctors_end = . ;
__dtors_start = . ;
*(.dtors)
__dtors_end = . ;
KEEP(SORT(*)(.ctors))
KEEP(SORT(*)(.dtors))
/* From this point on, we don't bother about wether the insns are
below or above the 16 bits boundary. */
*(.init0) /* Start here after reset. */
KEEP (*(.init0))
*(.init1)
KEEP (*(.init1))
*(.init2) /* Clear __zero_reg__, set up stack pointer. */
KEEP (*(.init2))
*(.init3)
KEEP (*(.init3))
*(.init4) /* Initialize data and BSS. */
KEEP (*(.init4))
*(.init5)
KEEP (*(.init5))
*(.init6) /* C++ constructors. */
KEEP (*(.init6))
*(.init7)
KEEP (*(.init7))
*(.init8)
KEEP (*(.init8))
*(.init9) /* Call main(). */
KEEP (*(.init9))
*(.text)
. = ALIGN(2);
*(.text.*)
. = ALIGN(2);
*(.fini9) /* _exit() starts here. */
KEEP (*(.fini9))
*(.fini8)
KEEP (*(.fini8))
*(.fini7)
KEEP (*(.fini7))
*(.fini6) /* C++ destructors. */
KEEP (*(.fini6))
*(.fini5)
KEEP (*(.fini5))
*(.fini4)
KEEP (*(.fini4))
*(.fini3)
KEEP (*(.fini3))
*(.fini2)
KEEP (*(.fini2))
*(.fini1)
KEEP (*(.fini1))
*(.fini0) /* Infinite loop after program termination. */
KEEP (*(.fini0))
_etext = . ;
} > text
.data : AT (ADDR (.text) + SIZEOF (.text))
{
PROVIDE (__data_start = .) ;
*(.data)
*(.data*)
*(.rodata) /* We need to include .rodata here if gcc is used */
*(.rodata*) /* with -fdata-sections. */
*(.gnu.linkonce.d*)
. = ALIGN(2);
_edata = . ;
PROVIDE (__data_end = .) ;
} > data
/* User-programming space */
. = _etext + SIZEOF(.data);
. = ALIGN(128);
__user_prog_start = .;
*.(.userprog.*) ;
.bss SIZEOF(.data) + ADDR(.data):
{
PROVIDE (__bss_start = .) ;
*(.bss)
*(.bss*)
*(COMMON)
PROVIDE (__bss_end = .) ;
} > data
__data_load_start = LOADADDR(.data);
__data_load_end = __data_load_start + SIZEOF(.data);
/* Global data not cleared after reset. */
.noinit SIZEOF(.bss) + ADDR(.bss) :
{
PROVIDE (__noinit_start = .) ;
*(.noinit*)
PROVIDE (__noinit_end = .) ;
_end = . ;
PROVIDE (__heap_start = .) ;
} > data
.eeprom :
{
*(.eeprom*)
__eeprom_end = . ;
} > eeprom
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) *(.gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
}

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Link script question

2008-10-10T12:04:01Z

From: Dave N6NZ <n6nz@...>
To: Gre7g Luterman <hafeliel@...>
Cc: avr-gcc-list@...
Sent: Friday, October 10, 2008 11:02:21 AM
Subject: Re: [avr-gcc-list] Link script question

>> That would work, of course, but I'd have to designate a constant
>> address for the block, right? 
>
> No, not at all. That's the point of putting it in the linker script and 
> letting the linker compute the address.
>
>> The script as I have it now,
>> automagically selects the first available block after my code. I
>> really like having this done automatically for me.
>
> And that is exactly what this does.  Take a look at the linker script 
> and how it works.  All my addition does is declare a named section that 
> starts at exactly the place that your __user_prog_start symbol is 
> defined.  It's really your solution, but with an additional name that 
> you can use as an attribute to a data section.

Well, I don't get it. I tried sticking your solution in and I get:

ld.exe:mega32.ld:177: syntax error

Obviously I'm missing something. Your section definitions don't look like the others in the script. I'll attach the patched script to this e-mail. Perhaps someone can correct the syntax error and show me what I'm missing.

Gre7g

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Link script question

2008-10-10T10:02:21Z

Gre7g Luterman wrote:

>> From: Dave N6NZ <n6nz@...> To: Gre7g Luterman
>> <hafeliel@...> Cc: avr-gcc-list@... Sent: Thursday,
>> October 9, 2008 8:56:07 PM Subject: Re: [avr-gcc-list] Link script
>> question
>>
>> I would take very slightly different approach. Make that a section
>> of it's own, and put it in the linker script just after your
>> exported symbol:
>>
>> __user_prog_start = .;

>> *.(.userprog.*) ;
>
> That would work, of course, but I'd have to designate a constant
> address for the block, right?

No, not at all. That's the point of putting it in the linker script and
letting the linker compute the address.

> The script as I have it now,
> automagically selects the first available block after my code. I
> really like having this done automatically for me.

And that is exactly what this does. Take a look at the linker script
and how it works. All my addition does is declare a named section that
starts at exactly the place that your __user_prog_start symbol is
defined. It's really your solution, but with an additional name that
you can use as an attribute to a data section.

-dave

>
> Does anyone out there have a different solution I can try?
>
> Gre7g
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________ AVR-GCC-list mailing
> list AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Re: Link script question

2008-10-10T09:39:38Z

> From: Dave N6NZ <n6nz@...>

> To: Gre7g Luterman <hafeliel@...>
> Cc: avr-gcc-list@...
> Sent: Thursday, October 9, 2008 8:56:07 PM
> Subject: Re: [avr-gcc-list] Link script question
>
> I would take very slightly different approach.  Make that a section of 
> it's own, and put it in the linker script just after your exported symbol:
>
>  __user_prog_start = .;
>  *.(.userprog.*) ;

That would work, of course, but I'd have to designate a constant address for the block, right? The script as I have it now, automagically selects the first available block after my code. I really like having this done automatically for me.
 
Does anyone out there have a different solution I can try?
 
Gre7g

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

New square root?

2008-10-10T07:08:06Z

Hi all,

I'm new to this list and project. So I don't really know how things work
here.

Anyway. I have attached a proposed new SQRT.S file for LIBM. The sqrt
routine in this file is fully tested (i.e. I have only tested the 2^24
possible mantissa, I didn't change any exponent handling) the result of the
test gave the same outcome for any value of rA2-rA0 for odd and even
exponents. The proposed routine uses 16 code words less than the original
and is 99-221 cycles faster..

Hope this is of help

Ruud

/* Copyright (c) 2002 Michael Stumpf <mistumpf@...>
Copyright (c) 2006 Dmitry Xmelkov
Copyright (c) 2008 Ruud v Gessel

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
* Neither the name of the copyright holders nor the names of
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE. */

/* $Id: sqrt.S,v 1.8 2007/01/14 15:13:10 dmix Exp $ */

#include "fp32def.h"
#include "asmdef.h"

/* double sqrt (double);
Square root function.
*/

FUNCTION sqrt

.L_nf: brne .L_pk ; NaN, return as is
brtc .L_pk ; sqrt(+Inf) --> +Inf
.L_nan: rjmp _U(__fp_nan)
.L_pk: rjmp _U(__fp_mpack)

ENTRY sqrt
; split and check arg.
rcall _U(__fp_splitA)
brcs .L_nf ; !isfinite(A)
tst rA3
breq .L_pk ; return 0 with original sign
brts .L_nan ; sqrt(negative) --> NaN
; exponent bias
subi rA3, 127
sbc rB3, rB3 ; exponent high byte
; normalize, if A is subnormal
sbrs rA2, 7
rcall _U(__fp_norm2)

#define msk0 ZL
#define msk1 ZH
#define msk2 rBE

clr R0 ; R0=0
ldi msk2,0x60
X_movw msk0,R0 ; Initial rotation mask = 011000000000000000000000
ldi rB2,0xa0
X_movw rB0,R0 ; Initial developing root = 101000000000000000000000
subi rA2,0x40
sbrc rA3,0
rjmp 3f
subi rA2,0x40

.Loop: brcs 1f ; C --> Bit is always 1
cp msk2,R0
cpc rA0,rB0
cpc rA1,rB1
cpc rA2,rB2 ; Does test value fit?
brcs 2f ; C --> nope, bit is 0

1: cp msk2,R0
sbc rA0,rB0
sbc rA1,rB1
sbc rA2,rB2 ; Adjust argument for next bit
or rB0,msk0
or rB1,msk1
or rB2,msk2 ; Set bit to 1

2: lsr msk2
ror msk1
ror msk0 ; Shift right mask, C --> end loop
eor rB0,msk0
eor rB1,msk1
eor rB2,msk2 ; Shift right only test bit in result

rol R0 ; Bit 0 now set if end of loop
3: lsl rA0
rol rA1
rol rA2 ; Shift left remaining argument (C used at .Loop)

sbrs R0,1 ; Skip if 24 bits developed
rjmp .Loop ; Develop 24 bits of the sqrt

brcs 4f ; C--> Last bits always 1
cp rB0,rA0
cpc rB1,rA1
cpc rB2,rA2 ; Test for last bit 1
4: adc rB0,R1
adc rB1,R1
adc rB2,R1

X_movw rA0, rB0
mov rA2, rB2

; calculate result exponent

lsr rB3
ror rA3

subi rA3, lo8(-127) ; exponent bias
lsl rA2
lsr rA3
ror rA2
ret
ENDFUNC

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

Re: Link script question

2008-10-09T19:56:07Z

I would take very slightly different approach. Make that a section of
it's own, and put it in the linker script just after your exported symbol:

__user_prog_start = .;
*.(.userprog.*) ;

then create a simple .S

.section .userprog
.byte 0xff ; is this the correct directive? I forget
.end

anyway, that should put the 0xff into .userprog, which I presume will
then be overwritten by your user data at a later time using the
mechanism that you have currently defined.

-dave

Gre7g Luterman wrote:

> I've got an avrgcc application that uses free Flash blocks to hold user code. To maximize the space available for the user, I start this area at the beginning of the first block following my application code. To locate this, I added the following to my linker script:
>
> --- mega32.orig 2008-10-09 17:14:10.921875000 -0600
> +++ mega32.ld 2008-10-09 12:48:58.281250000 -0600
> @@ -170,6 +170,10 @@
> _edata = . ;
> PROVIDE (__data_end = .) ;
> } > data
> + /* User-programming space */
> + . = _etext + SIZEOF(.data);
> + . = ALIGN(128);
> + __user_prog_start = .;
> .bss SIZEOF(.data) + ADDR(.data) :
> {
> PROVIDE (__bss_start = .) ;
>
> This works great. It creates __user_prog_start at the correct location. Then, in my application, I can initialize a variable to this value with:
>
> prog_uint8_t *VPC = (prog_uint8_t *) &__user_prog_start;
>
> This also works great. The problem is that this user space is completely uninitialized. I need to have at least one 0xFF at this location in my .hex file to insure that uploading a new version of my code will wipe out any user code that might have been there previously.
>
> Can anyone suggest an easy way to do this? Is there something I can add to my script to include an 0xFF at location __user_prog_start? Perhaps something I can do in one of the .c files .S files to stuff a single 0xFF there? Otherwise I'm going to have to write a program to alter the .hex file after its creation and that's awful Kludgey.
>
> Thanks!
> Gre7g
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

Link script question

2008-10-09T16:27:10Z

I've got an avrgcc application that uses free Flash blocks to hold user code. To maximize the space available for the user, I start this area at the beginning of the first block following my application code. To locate this, I added the following to my linker script:

--- mega32.orig 2008-10-09 17:14:10.921875000 -0600
+++ mega32.ld   2008-10-09 12:48:58.281250000 -0600
@@ -170,6 +170,10 @@
      _edata = . ;
      PROVIDE (__data_end = .) ;
   } > data
+ /* User-programming space */
+ . = _etext + SIZEOF(.data);
+ . = ALIGN(128);
+ __user_prog_start = .;
   .bss SIZEOF(.data) + ADDR(.data) :
   {
      PROVIDE (__bss_start = .) ;

This works great. It creates __user_prog_start at the correct location. Then, in my application, I can initialize a variable to this value with:

prog_uint8_t *VPC = (prog_uint8_t *) &__user_prog_start;

This also works great. The problem is that this user space is completely uninitialized. I need to have at least one 0xFF at this location in my .hex file to insure that uploading a new version of my code will wipe out any user code that might have been there previously.

Can anyone suggest an easy way to do this? Is there something I can add to my script to include an 0xFF at location __user_prog_start? Perhaps something I can do in one of the .c files .S files to stuff a single 0xFF there? Otherwise I'm going to have to write a program to alter the .hex file after its creation and that's awful Kludgey.

Thanks!

Gre7g

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

From forum: AVR - gcc

[bug #24446] _attribute_ should be attribute (with double underscores)

2008-10-04T06:55:44Z

Update of bug #24446 (project avr-libc):

Fixed Release: None => 1.6.3

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?24446>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

[bug #24446] _attribute_ should be attribute (with double underscores)

2008-10-04T06:55:19Z

Update of bug #24446 (project avr-libc):

Status: None => Fixed
Assigned to: None => joerg_wunsch
Open/Closed: Open => Closed

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?24446>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

[bug #24446] _attribute_ should be attribute (with double underscores)

2008-10-03T16:55:07Z

URL:
<http://savannah.nongnu.org/bugs/?24446>

Summary: _attribute_ should be __attribute__ (with double
underscores)
Project: AVR C Runtime Library
Submitted by: jnweiger
Submitted on: Fri 03 Oct 2008 11:55:04 PM GMT
Category: Documentation
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.6.2
Fixed Release: None

_______________________________________________________

Details:

the suggested code needs this to compile:

avr/include/avr/wdt.h 2008-09-26 10:25:48.000000000 +0200
+++ ./wdt.h 2008-10-04 01:55:38.000000000 +0200
@@ -70,7 +70,7 @@
#include <stdint.h>
#include <avr/wdt.h>

- uint8_t mcusr_mirror _attribute_ ((section (".noinit")));
+ uint8_t mcusr_mirror __attribute__ ((section (".noinit")));

void get_mcusr(void) \
__attribute__((naked)) \
user-manual-1.6.2/group__avr__watchdog.html 2008-04-02
23:03:07.000000000 +0200
+++ ./group__avr__watchdog.html 2008-10-04 01:51:45.000000000 +0200
@@ -34,7 +34,7 @@
<div class="fragment"><pre class="fragment">
#include <<a class="code" href="stdint_8h.html">stdint.h</a>>
 #include <<a class="code"
href="wdt_8h.html">avr/wdt.h</a>>

- <a class="code"
href="group__avr__stdint.html#gba7bc1797add20fe3efdf37ced1182c5">uint8_t</a>
mcusr_mirror _attribute_ ((section (".noinit")));
+ <a class="code"
href="group__avr__stdint.html#gba7bc1797add20fe3efdf37ced1182c5">uint8_t</a>
mcusr_mirror __attribute__ ((section (".noinit")));

void get_mcusr(void) \
__attribute__((naked)) \

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?24446>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

From forum: AVR - Libc - Dev

Re: What does potential Microchip buy out of Atmel mean forfuture of AVR?

2008-10-03T16:43:59Z

On Fri, Oct 3, 2008 at 6:08 PM, Bob Paddock <bob.paddock@...> wrote:

> On Thursday 02 October 2008 05:22:18 pm Weddington, Eric wrote:
>
>> Remember, the news reports says that this an *offer* to buy the company.
>> The news reports also say that discussions between the CEO took place in
>> early September and that Atmel's Board of Directors *declined* the offer at
>> that time.
>
> Yes, that did happen in September, this happened yesterday (Oct 2/2008):
>
> http://www.eetimes.eu/showArticle.jhtml?articleID=210605347&cid=NL_eeteu
>
> "We feel our offer is too compelling not to take it to shareholders," said
> Steve Sanghi, chairman, president and CEO at Microchip, during a conference
> call with analysts following the announcement of the offer on Thursday (Oct.
> 2). "We came to this point after we heard from Atmel that they were not
> interested."
>

Rest assured that they will keep AVR lines, and majority of the MCU
lines like ARM7/ARM9 and the to be released Cortex M3 line and hopefully
the 8051 line (not so sure about AVR32 and the 4bit line).

Microchip's Sanghi: Why we want Atmel
http://www.eetimes.com/showArticle.jhtml?articleID=210605543&cid=NL_eet

With Microchip's stand of not obsoleting a product (they almost never do it),
the AVR customers will be happy. In my previous job, we used PIC and
AVR at the same time. In my current job, we use Atmel 8051 and ARM7
MCUs, I am not worried about the bid should the bid goes through. I
will no longer worry about the product obsolescence issue. Atmel just
obsoleted some 5V EEPROMs which caused us a few redesigns
switching to Microchip EEPROMs.

Xiaofan

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

micaz development

2008-10-03T13:45:44Z

I was wondering if anyone has work on the micaz(atmega 128 based) hardware platform using libraries other than tinyos?

The programming interface is the mib510/520.

I have heard that avrDUDE now supports those programmers, but I have never compiled avrDude for use in windows so I am not sure what type of headache i am looking at (I am not a linux/cygwin power user, so I can follow directions but have limited problem solving skills when dealing with linux/cygwin stuff)

Thanks in advance!

mike.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: Is this efficient?

2008-10-03T12:55:37Z

On Friday 03 October 2008 19:57, you wrote:
> > I cannot test it with _SFR_IO_REG_P, although that macro seems to be
> > meant for the purpose:
> > Somewhere i am missing the point i guess.

> The _SFR_IO_REG_P() macro is designed to be used in the C code itself,
> not in any preprocessor statements. Something like:
> if (_SFR_IO_REG_P(TIMSK)) ...

Ok that is the point i was missing. Stupid of me. However i really need
this on preprocessor level, so i guess my solution was not that
bad after all. Only disadvantage is it cannot be placed in header
files also being used in .s files. Well, you cannot have everthing in life ;-)

Thanks.
Ruud

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

RE: Is this efficient?

2008-10-03T11:03:30Z

> -----Original Message-----
> From: avr-chat-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-chat-bounces+eweddington=cso.atmel.com@...]
> On Behalf Of Weddington, Eric
> Sent: Friday, October 03, 2008 11:57 AM
> To: Ruud Vlaming; avr-chat@...
> Subject: RE: [avr-chat] Is this efficient?
>
> The _SFR_IO_REG_P() macro is designed to be used in the C
> code itself, not in any preprocessor statements. Something like:
>
> if _SFR_IO_REG_P(TIMSK)

Obvious missing parens:

> if (_SFR_IO_REG_P(TIMSK))

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

RE: Is this efficient?

2008-10-03T10:57:11Z

> -----Original Message-----
> From: avr-chat-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-chat-bounces+eweddington=cso.atmel.com@...]
> On Behalf Of Ruud Vlaming
> Sent: Friday, October 03, 2008 10:28 AM
> To: avr-chat@...
> Subject: [avr-chat] Is this efficient?
>
> To find out if a register is in the io space in .c files,
> i use the following, ugly, construct:
>
> #undef _SFR_IO8
> #define _SFR_IO8(arg) (arg)
> #if (TIMSK < 0x40)
> blah blah
> #else
> bloh bloh
> #endif
> #undef _SFR_IO8
> #define _SFR_IO8(arg) (*(volatile uint8_t *)((arg) + 0x20))
>
> I cannot test it with _SFR_IO_REG_P, although that macro seems to be
> meant for the purpose:
>
> #if _SFR_IO_REG_P(TIMSK)
>
> for that gives the error:
> error: operator '*' has no left operand
>
> Somewhere i am missing the point i guess.
> Who knows the proper way to do such things?

The _SFR_IO_REG_P() macro is designed to be used in the C code itself, not in any preprocessor statements. Something like:

if _SFR_IO_REG_P(TIMSK)
{
// TIMSK is an IO register.
}
else
{
// TIMSK is not an IO register.
}

Thoroughly untested. And yes it creates more code, as it does not conditional compilation.

If you look at the implementation of the _SFR_IO_REG_P() macro, it is taking the address of the register and typecasting. IIRC, the preprocessor is not that smart. It is not enough C-aware to be able to handle this in preprocessor statements. But it should work in regular C code.

HTH
Eric

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Is this efficient?

2008-10-03T09:27:36Z

To find out if a register is in the io space in .c files,
i use the following, ugly, construct:

#undef _SFR_IO8
#define _SFR_IO8(arg) (arg)
#if (TIMSK < 0x40)
blah blah
#else
bloh bloh
#endif
#undef _SFR_IO8
#define _SFR_IO8(arg) (*(volatile uint8_t *)((arg) + 0x20))

I cannot test it with _SFR_IO_REG_P, although that macro seems to be
meant for the purpose:

#if _SFR_IO_REG_P(TIMSK)

for that gives the error:
error: operator '*' has no left operand

Somewhere i am missing the point i guess.
Who knows the proper way to do such things?

Ruud

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: What does potential Microchip buy out of Atmel mean forfuture of AVR?

2008-10-03T03:08:42Z

On Thursday 02 October 2008 05:22:18 pm Weddington, Eric wrote:

> Remember, the news reports says that this an *offer* to buy the company.
> The news reports also say that discussions between the CEO took place in
> early September and that Atmel's Board of Directors *declined* the offer at
> that time.

Yes, that did happen in September, this happened yesterday (Oct 2/2008):

http://www.eetimes.eu/showArticle.jhtml?articleID=210605347&cid=NL_eeteu

"We feel our offer is too compelling not to take it to shareholders," said
Steve Sanghi, chairman, president and CEO at Microchip, during a conference
call with analysts following the announcement of the offer on Thursday (Oct.
2). "We came to this point after we heard from Atmel that they were not
interested."

--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/ http://www.designer-iii.com/
http://www.unusualresearch.com/

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: "#pragma reentrant" no effect in avr-GCC ?

2008-10-02T22:55:47Z

David Kelly <dkelly@...> wrote:

> Would not be surprised if there are gcc targets which require this
> pragma.

GCC never uses pragmas except where mandated by the C standard.

If at all, it would be a function attribute. However, als already
mentioned, GCC-compiled functions are as reentrant as the developer
designed them by default. There are occasionally /negative/
attributes that affect reentrancy, like the new OS_main and OS_task
attributes in AVR-GCC.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: What does potential Microchip buy out of Atmel mean for future of AVR?

2008-10-02T16:21:46Z

On Fri, Oct 3, 2008 at 3:49 AM, David VanHorn <microbrix@...> wrote:
> On Thu, Oct 2, 2008 at 3:35 PM, Bob Paddock <graceindustries@...> wrote:
>> My boss just came in my cube in a panic asked "What have
>> you heard about Microchip and On Semi. buying Atmel?
>> Is this going to be a problem for us?"
>
> On the other hand, maybe they'll dump the PIC! (evil grin)
>
> Seriously, it's possible that they will keep the AVR, and give us
> tools that work, and real support!

If the offer will be successful (it has been rejected), I guess
it is hard for Microchip to keep all 8-bit MCU lines
(Atmel's 8051 and AVR, Microchop's PIC12/16/18).
I hope they keep all the lines though. At work, we
are using Atmel's 8051. And I was using PIC12/16
in the previous job. And AVR apparently beats most
of the PIC18 handsomely in terms of price and
performance. That is why Microchip started to
offer PIC18J and PIC18K.

Atmel's ARM line is quite good, maybe AVR32 would
be killed. And maybe PIC32 line would be killed as well.

Xiaofan

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

RE: What does potential Microchip buy out of Atmel mean forfuture of AVR?

2008-10-02T14:22:18Z

Hi Bob,

Remember, the news reports says that this an *offer* to buy the company. The news reports also say that discussions between the CEO took place in early September and that Atmel's Board of Directors *declined* the offer at that time.

> -----Original Message-----
> From: avr-chat-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-chat-bounces+eweddington=cso.atmel.com@...]
> On Behalf Of Bob Paddock
> Sent: Thursday, October 02, 2008 1:36 PM
> To: avr-chat@...
> Subject: [avr-chat] What does potential Microchip buy out of
> Atmel mean forfuture of AVR?
>
> My boss just came in my cube in a panic asked "What have
> you heard about Microchip and On Semi. buying Atmel?
> Is this going to be a problem for us?"
>
> He is worried that Microchip will kill the AVR, that
> we use by the tens of thousands per year.
>
> http://www.eetimes.com/news/latest/showArticle.jhtml?articleID
> =210605267
>
> Microchip has already said:
>
> "Microchip said it intends to dispose of Atmel's ASIC business after
> completing the acquisition."
>
> What else will they dispose of?
>
> "Microchip (Chandler, Ariz.) says ON Semiconductor (Phoenix)
> would acquire the
> assets related to Atmel's nonvolatile memory and RF and
> automotive businesses
> immediately prior to the closing of a merger. "
>
> Do the Dataflash (vs EEPROM division) parts go to Microchip
> or On Semi?
>
>
> _______________________________________________
> AVR-chat mailing list
> AVR-chat@...
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: What does potential Microchip buy out of Atmel mean for future of AVR?

2008-10-02T13:06:09Z

On Thursday 02 October 2008 21:35, Bob Paddock wrote:
> My boss just came in my cube in a panic asked "What have
> you heard about Microchip and On Semi. buying Atmel?
> Is this going to be a problem for us?"
>
> He is worried that Microchip will kill the AVR, that
> we use by the tens of thousands per year.
Although it is unlikely that the will stop production
of a chip that is sure business, they can easily stop
innovation and development in that direction.
AVR is still very much "alive and kicking", and it
should stay that way.

> http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=210605267
It is realy bad news. I sincerely hope the management
of Atmel is able to withstand the pressure and keep off
this deal.

Ruud.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: What does potential Microchip buy out of Atmel mean for future of AVR?

2008-10-02T12:49:03Z

On Thu, Oct 2, 2008 at 3:35 PM, Bob Paddock <graceindustries@...> wrote:
> My boss just came in my cube in a panic asked "What have
> you heard about Microchip and On Semi. buying Atmel?
> Is this going to be a problem for us?"

HOLY SHIT BATMAN!

On the other hand, maybe they'll dump the PIC! (evil grin)

Seriously, it's possible that they will keep the AVR, and give us
tools that work, and real support!

Possible....

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

What does potential Microchip buy out of Atmel mean for future of AVR?

2008-10-02T12:35:42Z

My boss just came in my cube in a panic asked "What have
you heard about Microchip and On Semi. buying Atmel?
Is this going to be a problem for us?"

He is worried that Microchip will kill the AVR, that
we use by the tens of thousands per year.

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=210605267

Microchip has already said:

"Microchip said it intends to dispose of Atmel's ASIC business after
completing the acquisition."

What else will they dispose of?

"Microchip (Chandler, Ariz.) says ON Semiconductor (Phoenix) would acquire the
assets related to Atmel's nonvolatile memory and RF and automotive businesses
immediately prior to the closing of a merger. "

Do the Dataflash (vs EEPROM division) parts go to Microchip or On Semi?

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Re: "#pragma reentrant" no effect in avr-GCC ?

2008-10-02T04:34:52Z

On Oct 2, 2008, at 1:52 AM, Tobias Drößler wrote:

> Hey,
>
> my question is in the subject-line ...
>
> i try to understand some c-sources ...
>
> i read that this line in "genearal" c (compiler depended) means
> that the function(s) can be re-entered while it is already running.
> but compiled with the avr-gcc -- there is no effect in the
> programcode, or is that wrong?

I haven't seen any need for it in avr-gcc, but Metrowerks C for the
HC12 requires a similar modification to a function definition if it
is to be reentrant. Metrowerks rewrites and reorders one's code much
more aggressively than I've seen of avr-gcc.

Would not be surprised if there are gcc targets which require this
pragma.

--
David Kelly N4HHE, dkelly@...
========================================================================
Whom computers would destroy, they must first drive mad.

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

From forum: AVR - General

Nabble - AVR

[patch #6649] sqrt.s in libm changes

Re: New square root?

Re: Link script question

Re: Link script question

Re: Link script question

Re: Link script question

Re: Link script question

Link script question

Re: Link script question

Re: Link script question

New square root?

Re: Link script question

Link script question

[bug #24446] _attribute_ should be __attribute__ (with double underscores)

[bug #24446] _attribute_ should be __attribute__ (with double underscores)

[bug #24446] _attribute_ should be __attribute__ (with double underscores)

Re: What does potential Microchip buy out of Atmel mean forfuture of AVR?

micaz development

Re: Is this efficient?

RE: Is this efficient?

RE: Is this efficient?

Is this efficient?

Re: What does potential Microchip buy out of Atmel mean forfuture of AVR?

Re: "#pragma reentrant" no effect in avr-GCC ?

Re: What does potential Microchip buy out of Atmel mean for future of AVR?

RE: What does potential Microchip buy out of Atmel mean forfuture of AVR?

Re: What does potential Microchip buy out of Atmel mean for future of AVR?

Re: What does potential Microchip buy out of Atmel mean for future of AVR?

What does potential Microchip buy out of Atmel mean for future of AVR?

Re: "#pragma reentrant" no effect in avr-GCC ?

[bug #24446] _attribute_ should be attribute (with double underscores)

[bug #24446] _attribute_ should be attribute (with double underscores)

[bug #24446] _attribute_ should be attribute (with double underscores)