RE: [avr-gcc-list] xmega support in fedora/upstream gcc

2011-02-10 Thread Boyapati, Anitha
>-Original Message- >From: avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org >[mailto:avr-gcc-list-bounces+anitha.boyapati=atmel@nongnu.org] On >Behalf Of Paul Thomas >Sent: Friday, February 04, 2011 3:04 AM >To: avr-gcc-list@nongnu.org >Subject: [avr-gc

[avr-gcc-list] xmega support in fedora/upstream gcc

2011-02-03 Thread Paul Thomas
OK, I'm on Fedora and the default avr-libc (1.6.7) has the iox128a1.h file, but avr-gcc (4.5.1) doesn't like the -mmcu=atxmega128a1 option. Is the mmcu= option still the proper way to select the target? Will it be in upstream gcc at some point? Looking at the latest gcc svn gcc/config/avr/avr-dev

Re: [avr-gcc-list] Xmega support

2009-08-19 Thread Parthasaradhi Nayani
: [avr-gcc-list] Xmega support To: "Steven Michalske" Cc: "avr-gcc-list" Date: Thursday, August 20, 2009, 3:11 AM On Wed, Aug 19, 2009 at 02:23:10PM -0700, Steven Michalske wrote: > This message got buried in a thread, because you used a reply to a  > previous message fro

Re: [avr-gcc-list] Xmega support

2009-08-19 Thread David Kelly
On Wed, Aug 19, 2009 at 02:23:10PM -0700, Steven Michalske wrote: > This message got buried in a thread, because you used a reply to a > previous message from the list. > > It's poor manners to hijack threads, and can cause some users not to > reply. Same applies to top-post without trim. --

Re: [avr-gcc-list] Xmega support

2009-08-19 Thread Steven Michalske
This message got buried in a thread, because you used a reply to a previous message from the list. It's poor manners to hijack threads, and can cause some users not to reply. not much in terms of help though, writing up a quick, complete test case may help us help you. is globalbuf

[avr-gcc-list] Xmega support

2009-08-19 Thread Parthasaradhi Nayani
Hello all, I have just started testing an XMEGA64 chip and I find a peculiar problem when I use sprintf. Following are the environment/specs: XMEGA64 running at 32MHz (using the internal freq generator) USART on PC0, operating at 115K BAUD. One timer in port D being used in compare capture mode.

Re: [avr-gcc-list] xmega support

2009-01-14 Thread Colin D Bennett
vr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of > Colin D Bennett > Sent: Wednesday, January 14, 2009 9:48 AM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] xmega support > > On Tue, 6 Jan 2009 22:37:15 -0800 > "larry barello" wrote: >

RE: [avr-gcc-list] xmega support

2009-01-14 Thread larry barello
To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] xmega support On Tue, 6 Jan 2009 22:37:15 -0800 "larry barello" wrote: > Thanks for the response. I dug a bit further into the manual and I > see that EEPROM can be mapped to SRAM space eliminating the need for > librar

Re: [avr-gcc-list] xmega support

2009-01-14 Thread Colin D Bennett
On Tue, 6 Jan 2009 22:37:15 -0800 "larry barello" wrote: > Thanks for the response. I dug a bit further into the manual and I > see that EEPROM can be mapped to SRAM space eliminating the need for > library EEPROM support in GCC. Does this EEPROM->SRAM mapping support writing, though? Regards

RE: [avr-gcc-list] xmega support

2009-01-06 Thread larry barello
M To: larry barello; AVR GCC List Subject: RE: [avr-gcc-list] xmega support > -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of larry barello > Sen

RE: [avr-gcc-list] xmega support

2009-01-06 Thread Weddington, Eric
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of larry barello > Sent: Tuesday, January 06, 2009 5:33 PM > To: AVR GCC List > Subje

[avr-gcc-list] xmega support

2009-01-06 Thread larry barello
I am trying to bring a project developed on a mega128 up on an xmega128A1. Aside from the very different I/O structure (which is actually pretty nice) the non-volatile memory stuff is totally different. Is there some libc support for reading/writing the EEPROM? How about self-programming support