Keith Gudger <[EMAIL PROTECTED]> wrote:
> Now your main routine may have an old value
> for that variable.
Even with volatile, if the interrupt had happened a few clocks later,
you'd read the old value as well.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.
When the volatile attribute is used on a global variable, the compiler
will not
optimize away accesses to that variable.
If you are using a global variable to communicate between an ISR and a
"main" routine,
you probably need to use the volatile keyword in the variable
declaration in order t
Excuse me if I'm wrong, but the following statement:
>If the main
> function has interrupts turned off (either globally, or the specific ISR
> interrupt enable), then it can happily use a non-volatile variable
> shared with the ISR.
I think may cause trouble. When the compiler optimizes your code
- Original Message -
From: "Lars Noschinski" <[EMAIL PROTECTED]>
> * Lars Noschinski <[EMAIL PROTECTED]> [2005-09-06 21:59]:
> >You must declare the global variable as volatile (or as register), if
> >you want to modify in an ISR.
Wrong - that's neither necessary nor complete (there is
Wasn't it 14-Sep-2005, at 07:05PM, when Lars Noschinski said:
> Speaking of this, if I have an variable which is initialized during
> startup and only accessed /in/ an ISR, am I on the safe side, if don't
> declare it as volatile, right?
Yes.
--
Rich Nes
* Lars Noschinski <[EMAIL PROTECTED]> [2005-09-06 21:59]:
You must declare the global variable as volatile (or as register), if
you want to modify in an ISR.
Speaking of this, if I have an variable which is initialized during
startup and only accessed /in/ an ISR, am I on the safe side, if don'
- Original Message -
From: "Vincent Trouilliez" <[EMAIL PROTECTED]>
> > There's for sure a lot of potential for improvement, but declaring
> > something "top-priority" because that's your opinion won't do
> > anything. There are many similar minor improvements that could be
> > made, th
David Brown wrote:
I think most or all of the avr-gcc team follow this list. They are always
interested in ideas leading to a better compiler, but it is up to *them*
what is "top-priority".
Right, and that's because it's a volunteer project and there is a
limited amount of time.
Currently
- Original Message -
From: "Vincent Trouilliez" <[EMAIL PROTECTED]>
> On Wed, 2005-09-07 at 16:41 +0200, Joerg Wunsch wrote:
> > "David Brown" <[EMAIL PROTECTED]> wrote:
> >
> > > ..., and it will also change "multiply by constant" into a series of
> > > shifts and adds. The target chip
> There's for sure a lot of potential for improvement, but declaring
> something "top-priority" because that's your opinion won't do
> anything. There are many similar minor improvements that could be
> made, they probably sum up to maybe 10...20 % of possible savings if
> really *all* of them wer
Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
> Can't we just have an command line option to force the use of the
> H/W multiplier ?
Nope, because it doesn't make sense.
It needs to be fixed, OK, but it doesn't make the slightest sense to
start hacking up command-line option workarounds for not
Quoting Galen Seitz <[EMAIL PROTECTED]>:
> Because I wanted more control over multiplies, I've started creating
> routines like these:
>
>
> extern inline uint16_t
> mult_u16_u8u8(uint8_t a, uint8_t b)
> {
> uint16_t product;
> asm (
> "mul %1, %2""\n\t"
> "movw %0, r0"
Joerg Wunsch <[EMAIL PROTECTED]> wrote:
> "David Brown" <[EMAIL PROTECTED]> wrote:
>
> > ..., and it will also change "multiply by constant" into a series of
> > shifts and adds. The target chip has a hardware multiplier and
> > divider, but they are slower than the shift-and-add sequences.
>
>
On Wed, 2005-09-07 at 16:41 +0200, Joerg Wunsch wrote:
> "David Brown" <[EMAIL PROTECTED]> wrote:
>
> > ..., and it will also change "multiply by constant" into a series of
> > shifts and adds. The target chip has a hardware multiplier and
> > divider, but they are slower than the shift-and-add s
"David Brown" <[EMAIL PROTECTED]> wrote:
> ..., and it will also change "multiply by constant" into a series of
> shifts and adds. The target chip has a hardware multiplier and
> divider, but they are slower than the shift-and-add sequences.
Unfortunately, AVR-GCC also does this, even though the
> > For such things it is interessting to use fixed point math.
> > If you want to divide 200 data Bytes by 13 you can do
> >
> > fac = 256 / 13; (* Only one div needed *)
> > for i := 0 to 199 do
> >data[i] = data[i] shl 8 * fac;
> >
> > and you need only 1 div and man muls.
> >
> > For da
> For such things it is interessting to use fixed point math.
> If you want to divide 200 data Bytes by 13 you can do
>
> fac = 256 / 13; (* Only one div needed *)
> for i := 0 to 199 do
>data[i] = data[i] shl 8 * fac;
>
> and you need only 1 div and man muls.
>
> For data-filters you norm
On Wed, 2005-09-07 at 13:46 +0200, Joerg Wunsch wrote:
> Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
>
> > all I did was gather all the commands found in your avr-libc PWM
> > demo project, put them all in a bash script like this :
>
> If you use the Makefile that comes with the demo, you can
Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
> all I did was gather all the commands found in your avr-libc PWM
> demo project, put them all in a bash script like this :
If you use the Makefile that comes with the demo, you can say "make
demo.s" to see the compiler-generated assembly file. It h
Hello,
Vincent Trouilliez schrieb:
> Talking of instruction, I just noticed that there is a MUL instruction
> in my ATmega32 but no DIV instruction ! How is that even possible...
> even age old 8051 has a division instruction... so we can do quick
> multiplications with the AVR, but need 50 times
>
> Talking of instruction, I just noticed that there is a MUL instruction
> in my ATmega32 but no DIV instruction ! How is that even possible...
> even age old 8051 has a division instruction... so we can do quick
> multiplications with the AVR, but need 50 times more cycles to do a
> division ??
On Wed, 2005-09-07 at 11:54 +0200, Joerg Wunsch wrote:
> > Oh, that's interesting... because as soon as I compile my small
> > programs, I rush to check to have a look at the assembler output,
> > ...
>
> At the assembler output (filename.s), or at the disassembler output
> (filename.lss)? I gues
> ...Similarly, "CLR rx" is just "EOR rx, rx".
Oh yes, forgot to mention this one but I did notice it as well in my
programs ! Thanks for clearing this one too :-)
--
Vince
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu
> I guess, it's easier for the compiler to do things in a consistent way.
Yes I guess so too.. I didn't mean to complain about the looks of the
assembler output... after all if you use a compiler it's because you
don't want to write your own assembler to start with, so you can't
possibly complain
> > generated with basic -O optomisation is far easier to read and
understand than code
> > generated with -O0, since it keeps variables in registers instead of the
> > stack.
>
> Oh, that's interesting... because as soon as I compile my small
> programs, I rush to check to have a look at the asse
Vincent Trouilliez <[EMAIL PROTECTED]> wrote:
> Oh, that's interesting... because as soon as I compile my small
> programs, I rush to check to have a look at the assembler output,
> ...
At the assembler output (filename.s), or at the disassembler output
(filename.lss)? I guess it's the latter.
* Vincent Trouilliez <[EMAIL PROTECTED]> [2005-09-07 11:32]:
Oh, that's interesting... because as soon as I compile my small
programs, I rush to check to have a look at the assembler output, to get
the hang of things, and am often very confused by the way the compile
does things, it's often very
> There is a problem in your code also - you are not making
> flag=0 after you send back the character. HTH.
>
> Nayani
Hi Nayani, no it's not a problem at all, it only means that it would
react only once, which was all I wanted/needed it to do in order to
prove that ISR to main communication was
> generated with basic -O optomisation is far easier to read and understand
> than code
> generated with -O0, since it keeps variables in registers instead of the
> stack.
Oh, that's interesting... because as soon as I compile my small
programs, I rush to check to have a look at the assembler out
> Hello Vincent,
>
> To be able to modify/access a variable in interrupt,
> declare it as "volatile".
That's not good advice - there is no reason to use "volatile" on all
variables used by interrupt routines. That would lead to unnecessarily
slower code. All you need to do is remember what "vol
Hello Vincent,
To be able to modify/access a variable in interrupt,
declare it as "volatile". Secondly, to test your code,
turn off optimization (s=0) in your make file. There
is a problem in your code also - you are not making
flag=0 after you send back the character. HTH.
Nayani
--- Vincent T
Vincent Trouilliez wrote:
> unsigned char flag, bin; //global variables
Try making 'flag' volatile:
volatile unsigned char flag;
unsigned char bin;
What's probably happening is the compiler, not seeing that 'flag' is
modified anywhere in the while loop, isn't reloading it every loop
iteration
> Try making 'flag' volatile:
Thanks chaps, that did it :-)
> What's probably happening is the compiler, not seeing that 'flag' is
> modified anywhere in the while loop, isn't reloading it every loop
> iteration
Must be that, 'cause I looked at the assembler output closely enough to
see that t
On Tue, 6 Sep 2005, Vincent Trouilliez wrote:
> Problem : on my ATmega32, after several experiments (only just started
> using it, learning...), I am suffering a big problem. It seems that when
> I declare a variable as global, then modify it within an interrupt
> routine, the 'main' function can'
* Vincent Trouilliez <[EMAIL PROTECTED]> [2005-09-06 21:37]:
Problem : on my ATmega32, after several experiments (only just started
using it, learning...), I am suffering a big problem. It seems that when
I declare a variable as global, then modify it within an interrupt
routine, the 'main' funct
Hi gents,
After the highly technical thread that just ended today, I would like to
pick your brains on something much lower flying so to speak, sorry for
that ! ;-)
Problem : on my ATmega32, after several experiments (only just started
using it, learning...), I am suffering a big problem. It se
36 matches
Mail list logo
