Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Daniel O'Connor
On Thursday 15 January 2009 11:57:37 Dave Hylands wrote: > Hi Daniel, > > >> And here's some code that implements such a ring buffer. As David > >> Kelly points out, as long as the index type is uint8_t, then nothing > >> special is required (which for this particular implementation means > >> that

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Dave Hylands
Hi David, > You will notice Dave Hyland's code is C++. It's actually got a C portion, which is the macros, and it has a template, which is only compiled in if you're using C++. Personally, I don't use the C++ stuff very much. I just posted a couple links to my C based UART code which uses the C

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Dave Hylands
Hi Daniel, >> And here's some code that implements such a ring buffer. As David >> Kelly points out, as long as the index type is uint8_t, then nothing >> special is required (which for this particular implementation means >> that buffers upto 128 entries would be supported) >> >>

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread David Kelly
On Jan 14, 2009, at 5:58 PM, Daniel O'Connor wrote: On Thursday 15 January 2009 04:15:14 Dave Hylands wrote: And here's some code that implements such a ring buffer. As David Kelly points out, as long as the index type is uint8_t, then nothing special is required (which for this particular im

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Daniel O'Connor
On Thursday 15 January 2009 04:15:14 Dave Hylands wrote: > Hi Lin (and Dennis), > > >> And the function ISR(USART1_RX_vect) in Linux saves even fewer > >> registers. > > > > The solution is to NOT call functions from within your ISR. That is > > just evil. Get your data in the ISR, put it in a m

Re: [avr-gcc-list] xmega support

2009-01-14 Thread Colin D Bennett
On Wed, 14 Jan 2009 16:32:04 -0700 "larry barello" wrote: > Read the data sheet. > http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf OK, thanks. Since the data sheet says that both load and store instructions can be used with EEPROM mapped into the RAM space, it sounds like writing

RE: [avr-gcc-list] xmega support

2009-01-14 Thread larry barello
Read the data sheet. http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf -Original Message- From: avr-gcc-list-bounces+larry=barello@nongnu.org [mailto:avr-gcc-list-bounces+larry=barello@nongnu.org] On Behalf Of Colin D Bennett Sent: Wednesday, January 14, 2009 9:48 AM T

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread David Kelly
On Wed, Jan 14, 2009 at 01:41:33PM -0700, dlc wrote: > I guess that we agree. :) > > My biggest problem was getting variables established that gcc > wouldn't try to save when the ISR started. I've tried "REGISTER", but > I couldn't guarantee that the register I'd fixed an index to was > reall

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Preston Wilson
>>> The solution is to NOT call functions from within your ISR. That is >>> just evil. Get your data in the ISR, put it in a mailbox or buffer >>> and have a regularly scheduled function handle the details from >>> outside the ISR. I like to use ring buffers to store data from an >>> ISR. Whe

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread dlc
I guess that we agree. :) My biggest problem was getting variables established that gcc wouldn't try to save when the ISR started. I've tried "REGISTER", but I couldn't guarantee that the register I'd fixed an index to was really not being used elsewhere, I had one instance where it clearl

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread David Kelly
On Wed, Jan 14, 2009 at 12:06:54PM -0700, dlc wrote: > > >Don't quite understand the push/popped reference, but if a variable is > >accessed in both interrupt space and "user" space it needs to be > >protected so that its uses "atomically". > > Here is where I disagree with the gcc implementati

Re: [avr-gcc-list] Tiny88 C++ code optimized out of existence?

2009-01-14 Thread Bob Paddock
>> Still not sure why I was getting the warning about byte_u8 >> not being used, when it was not in the loop, which >> is how it got in there in the first place, trying to figure >> out where the warning was coming from. >> >> I deleted the .dep directory and OBJs then recompiled, and it went >> aw

Re: [avr-gcc-list] Tiny88 C++ code optimized out of existence?

2009-01-14 Thread Preston Wilson
"Bob Paddock" wrote: >>> for(;;) >>> { >>> uint8_t byte_u8 = LED2H; // Start LED >> >> You're initializing the variable inside the loop. > > I knew I was overlooking the obvious. Thanks. > > Still not sure why I was getting the warning about byte_u8 > not being used, when it was no

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread dlc
David Kelly wrote: On Wed, Jan 14, 2009 at 09:14:20AM -0700, dlc wrote: The solution is to NOT call functions from within your ISR. That is just evil. Get your data in the ISR, put it in a mailbox or buffer and have a regularly scheduled function handle the details from outside the ISR.

RE: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Stu Bell
> > Which is why there is the macros. Check out: > > > > ATOMIC_BLOCK( ATOMIC_RESTORESTATE ) > > { > >... Mangle pointers > > } > > Interesting. Don't recall those being there 3 or 4 years ago > back in the days of avr-gcc 3.3 and 3.4. Dean Camera (sp?) added them a year or two back. Very

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread David Kelly
On Wed, Jan 14, 2009 at 10:02:48AM -0700, Stu Bell wrote: > > > > Don't quite understand the push/popped reference, but if a variable > > is accessed in both interrupt space and "user" space it needs to be > > protected so that its uses "atomically". > > Which is why there is the macros. Check

Re: [avr-gcc-list] Tiny88 C++ code optimized out of existence?

2009-01-14 Thread Bob Paddock
>> for(;;) >> { >> uint8_t byte_u8 = LED2H; // Start LED > > You're initializing the variable inside the loop. I knew I was overlooking the obvious. Thanks. Still not sure why I was getting the warning about byte_u8 not being used, when it was not in the loop, which is how it got in

Re: [avr-gcc-list] Tiny88 C++ code optimized out of existence?

2009-01-14 Thread Paulo Marques
Bob Paddock wrote: > I'm trying to bring up a new board that uses a Tiny88. > I'm compiling the code as C++ code, using WinAVR 20081205/4.3.2, > using -Os. Makefile was produced by MFile. > > This is the test program, main.cpp: > > [...] > for(;;) > { > uint8_t byte_u8 = LED2H; // St

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Dave Hylands
Hi Lin (and Dennis), >> And the function ISR(USART1_RX_vect) in Linux saves even fewer registers. > > The solution is to NOT call functions from within your ISR. That is just > evil. Get your data in the ISR, put it in a mailbox or buffer and have a > regularly scheduled function handle the det

[avr-gcc-list] Tiny88 C++ code optimized out of existence?

2009-01-14 Thread Bob Paddock
I'm trying to bring up a new board that uses a Tiny88. I'm compiling the code as C++ code, using WinAVR 20081205/4.3.2, using -Os. Makefile was produced by MFile. This is the test program, main.cpp: = #if defined(__cplusplus) && __cplusplus extern "C" { #endif #include #include

RE: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Stu Bell
> > The solution is to NOT call functions from within your > > ISR. That is just evil. Perhaps. And yet, there are occasions when even the reviled "goto" is useful, and even correct. "All generalizations fail at some point. Including this one." > > Get your data in the ISR, put it in a mailb

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] About context saving in Vectors

2009-01-14 Thread David Kelly
On Wed, Jan 14, 2009 at 09:14:20AM -0700, dlc wrote: > > The solution is to NOT call functions from within your ISR. That is > just evil. Get your data in the ISR, put it in a mailbox or buffer > and have a regularly scheduled function handle the details from > outside the ISR. I like to use

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread dlc
Lin Nan wrote: Hi all, I have been focused on a problem for three days. My program does not work if compiled with –Os in Ubuntu Linux 8.10 (Avr Gcc 4.3.0), but works if compiled with –Os in Windows+WinAVR(20080512). After quite a long time of digging, I found that a piece of code

Re: [avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Preston Wilson
"Weddington, Eric" wrote: >> I have been focused on a problem for three days. >> >> >> >> My program does not work if compiled with -Os in Ubuntu Linux >> 8.10 (Avr Gcc 4.3.0), but works if compiled with -Os in >> Windows+WinAVR(20080512). > > > Version 4.3.0 of AVR GCC has known code genera

RE: [avr-gcc-list] About context saving in Vectors

2009-01-14 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 Lin Nan > Sent: Wednesday, January 14, 2009 10:03 AM > To: avr-gcc-list@nongnu.org > Subject: [avr-gcc-list] Abo

[avr-gcc-list] About context saving in Vectors

2009-01-14 Thread Lin Nan
Hi all, I have been focused on a problem for three days. My program does not work if compiled with -Os in Ubuntu Linux 8.10 (Avr Gcc 4.3.0), but works if compiled with -Os in Windows+WinAVR(20080512). After quite a long time of digging, I found that a piece of code does not work corre