Paulo Marques wrote:
Weddington, Eric wrote:
[...]
If ATOMIC_BLOCK() is *the* way to do it, perhaps the docs
could be improved a little by emphasizing the use of
ATOMIC_BLOCK() as a necessity rather than as a convenience.
I'll go a step further: Is there any reason to NOT include the memory
Hi guys,
pointer size increments, in a snippet below, work with
WinAVR-20060421 (avr-gcc 3.4.6), but does not in WinAVR-20071221
(avr-gcc 4.2.2).
Compiler claims casted pointer as not an lvalue.
Is this correct behaviour ?
unsigned char *p_received_data;
On May 22, 2008, at 4:26 PM, Dusan Ferbas wrote:
Hi guys,
pointer size increments, in a snippet below, work with
WinAVR-20060421 (avr-gcc 3.4.6), but does not in WinAVR-20071221
(avr-gcc 4.2.2).
Compiler claims casted pointer as not an lvalue.
Is this correct behaviour ?
Yes, post/pre
Hi.
An alternative way to handle this sort of thing would be to implement a
critical function attribute like in the msp430 port of gcc - a
function with this attribute has interrupts disabled at the start, and
restored at the end.
It will work for for tiny and mega devices, but xmega
You can do it this way but you won't have precise control over
disable/restore timing. So you will typically disable interrupts longer
than is needed.
Also disabling all interrupts is often not what you need. Disabling
specfic interrupts is more palatable on real time systems.
NMI is a
-Original Message-
From: Anatoly Sokolov [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 22, 2008 11:09 AM
To: Weddington, Eric; David Brown; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
Hi.
An alternative way to handle this
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 22, 2008 11:48 AM
To: [EMAIL PROTECTED]; Weddington, Eric; [EMAIL PROTECTED];
avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
You can do it
Eric,
The problem with the function is typical housekeeping overhead gets
wrapped up.
To take a silly example:
Say you want to send some message to ISR (via memory) using critical
function
critical void function(int *buffer, int *cValue)
{
*cValue++ = *buffer++;
}
Getting *buffer++ does
[EMAIL PROTECTED] wrote:
Eric,
The problem with the function is typical housekeeping overhead gets
wrapped up.
To take a silly example:
Say you want to send some message to ISR (via memory) using critical
function
critical void function(int *buffer, int *cValue)
{
*cValue++ = *buffer++;
http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html
David Brown wrote:
[EMAIL PROTECTED] wrote:
Eric,
The problem with the function is typical housekeeping overhead gets
wrapped up.
To take a silly example:
Say you want to send some message to ISR (via memory) using
BTW
I believe the common attribute/keyword for this should be monitor as in
monitor void dostuff(void)
{
putchar ( ’Z’ );
}
This will give a degree of compatibility with other compilers.
David Brown wrote:
[EMAIL PROTECTED] wrote:
Eric,
The problem with the function is typical
Don't worry about being shot down. Nobody hear can shoot straight,
unless it's their foot.
(myself included)
This is very similar to what we do. It can also be targeted to
specific interrupts (or tasks).
We have to do it like this - or latency will loose us data.
Like your it CAPITALISED
12 matches
Mail list logo
