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
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 generation problems that
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
On Tue, 6 Jan 2009 22:37:15 -0800
larry barello la...@barello.net 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,
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 mailbox or
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 details
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 util/atomic.h macros. Check
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.
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 not in the loop,
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
away.
The
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 clearly
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. When using the
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
really not
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
On Wed, 14 Jan 2009 16:32:04 -0700
larry barello la...@barello.net 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
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 mailbox or
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
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)
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
19 matches
Mail list logo
