Jim Brain wrote:
Which is why there is the util/atomic.h macros. Check out:
ATOMIC_BLOCK( ATOMIC_RESTORESTATE )
Can someone clarify why these macros are preferred over doing
cli()/sei()/SREG=sreg in code? I'm not trying to troll, but
wonder if there is something I am missing.
Jim:
Stu Bell wrote:
Jim Brain wrote:
[...]
Can someone clarify why these macros are preferred over doing
cli()/sei()/SREG=sreg in code? I'm not trying to troll, but
wonder if there is something I am missing.
[...]
More important, in my mind, is that the macros are written in such a way
that
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
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.
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
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
16 matches
Mail list logo
