Thank you, Björn and Jörg,
I really did not think about using a struct for all of the variables,
but this is obviously the best solution.
Regards,
Wolfgang
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
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 volatile
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
* 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
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.
-
Hi again,
after having sorted out my EEPROM variables, I am now trying to debug
using AVRstudio4 (only have a JTAGIce mkII, which seems not to work
with avarice, neither cygwin nor linux).
The problem is that AVRstudio and the gnu tools seem to have
different line numbers: debugging somewhat
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
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
...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
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 ?? I
Hi,
On 7 Sep 2005 at 12:36, Torleif Sandnes wrote:
Your problem may be that you are compiling with optimization on.
Try to use -O0 instead of -Os, -O1 or whatever you are using.
You could also just remove the -O flag altogether.
the problem is that I can not remove the -O, because the code gets
Torleif Sandnes [EMAIL PROTECTED] wrote:
Your problem may be that you are compiling with optimization on.
Try to use -O0 instead of -Os, -O1 or whatever you are using.
But of course, he'll debug an entirely different program then.
My own experience says that it's best to get used to the
Hi Jörg,
On 7 Sep 2005 at 12:50, Joerg Wunsch wrote:
The CVS version of AVaRICE does support the mkII device, even over
libusb.
I know, and I tried it - but I only get that far with USB:
MP-Wegner:~# avarice --mkII -d -C -P atmega128 -j usb
AVaRICE version 2.3.20050527, Sep 6 2005 13:18:55
Hardware division requires far more chip area than hardware multiplication,
and division is very seldom used compared to multiplication. So almost no
small microcontroller has one these days - you have look at high-end 32-bit
chips to get hardware division, and even then it is significantly
On Sep 7, 2005, at 2:34 AM, Wolfgang Wegner wrote:
Thank you, Björn and Jörg,
I really did not think about using a struct for all of the variables,
but this is obviously the best solution.
And if you name the struct something like ee then you have a visual
naming reminder of how the
Wolfgang Wegner [EMAIL PROTECTED] wrote:
... but at the moment, the combination WinAVR - AVRstudio is
unusable for debugging.
But you're using ELF/DWARF-2 as debugging format, aren't you?
--
Jorg Wunsch Unix support engineer
[EMAIL PROTECTED]
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
Yes, I
Wolfgang Wegner [EMAIL PROTECTED] wrote:
command[0x01, 1]: 01
USB daemon died
Hmm, please talk offline with me about that, I'd be interested in
finding the actual problem here.
Obtw., I never managed it on Linux to access these USB devices without
being root (even chmod of /proc/bus/usb/...
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 normaly can
On 7 Sep 2005 at 14:39, Joerg Wunsch wrote:
But you're using ELF/DWARF-2 as debugging format, aren't you?
um, no - I was using coff/stabs because I understood the manual such
that elf/dwarf was still experimental. Sorry for that!
Switching to ELF/DWARF-2 is not working out of the box either,
Wolfgang Wegner [EMAIL PROTECTED] wrote:
um, no - I was using coff/stabs because I understood the manual such
that elf/dwarf was still experimental. Sorry for that!
It's still somewhat experimental, but probably has less bugs than our
COFF conversion, and AVR Studio doesn't understand stabs
Joerg Wunsch wrote:
Torleif Sandnes [EMAIL PROTECTED] wrote:
Your problem may be that you are compiling with optimization on.
Try to use -O0 instead of -Os, -O1 or whatever you are using.
But of course, he'll debug an entirely different program then.
My own experience says that it's best to
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
Russell Shaw [EMAIL PROTECTED] wrote:
When you use gdb on code that has been optimized with -O2, the
source highlighter bar jumps all over the place making it hard to
follow the code.
Sure. Get used to it...
With -O0, the bar follows every source line as you'd imagine.
Sure. No
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 sequences.
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.
Unfortunately,
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 \n\t
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 were
As the impending switch to avr-libc 1.4 allows us to make API changes,
I'd like to get people's opinions on the following:
. I'd like to get avr/signal.h and avr/interrupt.h to eventually
be merged. As a next step, we could deprecate one of those, and
issue a #warning if it gets included.
Joerg Wunsch wrote:
As the impending switch to avr-libc 1.4 allows us to make API changes,
I'd like to get people's opinions on the following:
. I'd like to get avr/signal.h and avr/interrupt.h to eventually
be merged. As a next step, we could deprecate one of those, and
issue a #warning if
30 matches
Mail list logo
