On Nov 23, 2007 10:21 AM, Weddington, Eric [EMAIL PROTECTED] wrote:
...
This rather smells like a compiler bug to me, than something where
library support would be a real help. If the compiler offers the
feature to jump to an arbitrary address using goto, then it's
responsible to
On Nov 22, 2007 1:44 PM, Joerg Wunsch [EMAIL PROTECTED] wrote:
As Shaun Jackman wrote:
The assembler has a pm(a) operator for this very reason. It would be
useful for avr-libc to have a similar macro.
This rather smells like a compiler bug to me, than something where
library support would
On Nov 7, 2007 7:07 PM, Erik Christiansen [EMAIL PROTECTED] wrote:
On Wed, Nov 07, 2007 at 05:04:05PM -0700, Shaun Jackman wrote:
Is there a way in source code to use the rjmp instruction to jump to
an absolute address (not relative to the section offset) without using
a linker option
The instruction `rjmp 0' jumps to the beginning of the current
section. If I want to jump to the absolute address 0, the best
workaround I have at the moment is to use the linker option `--defsym
application=0' and `rjmp application' as described here [1]. Is there
any way in source code to use
On Nov 7, 2007 1:15 PM, Joerg Wunsch [EMAIL PROTECTED] wrote:
Shaun Jackman [EMAIL PROTECTED] wrote:
Is there any way in source code to use the rjmp instruction to jump
to an absolute address without using a linker option or a linker
script?
..set x,0
rjmp x
Great! Thanks
On Nov 7, 2007 1:15 PM, Joerg Wunsch [EMAIL PROTECTED] wrote:
Shaun Jackman [EMAIL PROTECTED] wrote:
Is there any way in source code to use the rjmp instruction to jump
to an absolute address without using a linker option or a linker
script?
..set x,0
rjmp x
Upon testing, using
On 7/9/07, Eric Weddington [EMAIL PROTECTED] wrote:
Hi Shaun,
Can you place this patch in a Patch Tracker on the avarice project site?:
http://sourceforge.net/projects/avarice
Patches in emails have a tendency to get lost rather quickly.
Thanks,
Eric Weddington
The patch is included in the
of CMND_RESET. This solution seems to work, although
other equally valid solutions surely exist.
I'm able to debug using avarice with GDB and an AVR Dragon and
debugWire now! I haven't yet tested breakpoints...
Cheers,
Shaun
2007-07-08 Shaun Jackman [EMAIL PROTECTED]
* src/jtag2bp.cc
On 7/6/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
I should mention I was using
debugWire to communicate with a AT90PWM3B.
I don't have an AT90PWM3B (only the older AT90PWM3), but I've
seen similar problems on other debugWire devices as well.
I initially suspected the new AVR Dragon I was
On 2/26/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
Shaun Jackman [EMAIL PROTECTED] wrote:
The AT90PWM2B has a different signature than AT90PWM2, but avrdude
5.3.1 doesn't seem to support the AT90PWM2B. What is the difference
between the AT90PWM2 and the AT90PWM2B?
...
I just committed
(command_sequence == 111)
got asynchronous event: 0xe0
recv: 0xbf
On 7/5/07, Shaun Jackman [EMAIL PROTECTED] wrote:
Reading the contents of flash using debugWire seemed to succeed, but
later failed with `Cannot synchronise'. Any idea why?
AVR Dragon HW 0106 SW 0101 0109
AT90PWM3B
What's
On 7/6/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
I won't be able to have a look at all this by the weekend.
In order for it not to be forgotten, please file a bug report on
the avarice project (at sourceforge.net).
I've submitted bug 1749358 with the diff and debug logs attached.
Thanks for
On 7/6/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
Well, now that you've filed your patch, I'll see to get that into the
tree as well, of course before rolling a new release.
My patch still needs some investigation and testing. It did fix for me
the case of verifying (that is, reading) flash
On 3/6/07, Dmitry K. [EMAIL PROTECTED] wrote:
Hi,
wrong code by avr-gcc 4.1.1:
...
I tested your snippet and found that GCC 4.1.0 produced incorrect
code, and GCC 4.3.0 20070226 from subversion produced correct code.
So, it looks as if this bug has been found and fixed.
Cheers,
Shaun
On 3/7/07, Eric Weddington [EMAIL PROTECTED] wrote:
Hi Shaun,
Thanks a lot for doing the leg work on this!
But I have a favor to ask: Can you find out approximately *when* this got
fixed? i.e., can you test 4.1.2, and the current 4.2.x branch to see if it's
fixed at either of those two points?
The avrdude man page indicates that debugWire doesn't support an
explicit flash erase command, but that the erase is handled implicity
by the JTAG ICE mkII during a write operation. debugWire is working
well, but the erasing part of the programming doesn't seem to be
working.
avrdude 5.3.1
JTAG
On 2/26/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
As Shaun Jackman wrote:
There's no equivalent set of command-line switches for each
-mmcu= option. Alas, it's really required to patch each and
any new AVR into a few locations in binutils and GCC.
So far it seems to work. It's very
The AT90PWM2B has a different signature than AT90PWM2, but avrdude
5.3.1 doesn't seem to support the AT90PWM2B. What is the difference
between the AT90PWM2 and the AT90PWM2B? I haven't been able to find
the answer in the data sheet. In any case, I used the entry for the
AT90PWM2 in avrdude.conf
On 2/26/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
Shaun Jackman [EMAIL PROTECTED] wrote:
The AT90PWM2B has a different signature than AT90PWM2, but avrdude
5.3.1 doesn't seem to support the AT90PWM2B. What is the difference
between the AT90PWM2 and the AT90PWM2B?
I think there's a migration
I'm attempting to use the AT90PWM2, which isn't yet supported by GCC
with a simple -mat90pwm2 switch. Are the following switches
equivalent?
avr-gcc -mmcu=avr4 -minit-stack=0x2ff -D__AVR_AT90PWM2__
Am I missing anything? My STK500/STK520 board isn't yet behaving
exactly `right'. That's a rather
On 2/26/07, Shaun Jackman [EMAIL PROTECTED] wrote:
I'm attempting to use the AT90PWM2, which isn't yet supported by GCC
with a simple -mat90pwm2 switch. Are the following switches
equivalent?
avr-gcc -mmcu=avr4 -minit-stack=0x2ff -D__AVR_AT90PWM2__
Am I missing anything? My STK500/STK520 board
On 2/26/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
David McNab [EMAIL PROTECTED] wrote:
The code in /doc/examples/asmdemo in the avr-libc tree is only
limited value, because all the assembler code seems to be just ISRs,
with no calling between C and assembler.
Sorry, I simply couldn't fit
On 2/26/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
Shaun Jackman [EMAIL PROTECTED] wrote:
I was definitely missing something!
You are missing even more, like the selection of the crtX.o file.
There's no equivalent set of command-line switches for each
-mmcu= option. Alas, it's really
On 1/13/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
Please change the delay value in the ATmega8 section of your
avrdude.conf from 6 to 10 for the flash memory, and from 10 to 20
for the eeprom memory area.
I made both these changes, but the flash write is still timing out:
avrdude:
On 1/15/07, Shaun Jackman [EMAIL PROTECTED] wrote:
On 1/13/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
Please change the delay value in the ATmega8 section of your
avrdude.conf from 6 to 10 for the flash memory, and from 10 to 20
for the eeprom memory area.
I made both these changes
Great! Thanks for the fix. I'll try it out on Monday.
Cheers,
Shaun
On 1/13/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
Well, it could probably handle the error more gracefully -- but it
would fail anyway.
Sigh. That's yet another case where Atmel has silently modified
parameters in their XML
On 1/8/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
...
If you run avrdude with -, it will dump the programmer
communication to stderr. Similarly, at the end of appnote AVR068,
there's a description how to produce a trace of the STK500
communication. You might try comparing the relevant part
On 1/12/07, Shaun Jackman [EMAIL PROTECTED] wrote:
I used avrdude - to capture the offending packet. I'll be happy to
provide any other information that's needed to help troubleshoot this.
...
avrdude: jtagmkII_recv():
...
avrdude: Recv: . [88] . [13] . [80]
...
avrdude: jtagmkII_recv
I attempted to use the AVR JTAG ICE mkII and the ATmega8 with both
avrdude and AVR Studio 4.12 Service Pack 2. Neither worked. I upgraded
to AVR Studio 4.12 Service Pack 4 and upgraded the firmware of the AVR
JTAG ICE mkII and now both avrdude and AVR Studio work.
Cheers,
Shaun
Hi Jürgen,
The JTAG ICE mkII is more expensive, but I already own one to program
the ATmega64 I use in other projects. So, it's also a convenient ISP
programmer.
It seems though that I need to qualify what I said earlier about using
the JTAG ICE mKII to program the ATmega8. Once I upgraded the
I'm attempting to use avrdude 5.3.1 to program a ATmega8 using a AVR
JTAG ICE mkII. To help troubleshooting, the same hardware setup works
in AVR Studio. Reading the Device ID and verifying the flash works,
but writing to the flash fails. The error message is
avrdude: stk500v2_command():
On 12/18/06, Anton Erasmus [EMAIL PROTECTED] wrote:
Hi,
Not a macro, but the following seems to generate reasonable code.
...
Thanks Anton,
I came to the same conclusion.
Cheers,
Shaun
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
On 12/18/06, Nils Springob [EMAIL PROTECTED] wrote:
Hi,
and it is possible to use an anonymous struct:
True. However, unnamed struct/union fields are an extension of the C
language provided by GCC and not strictly portable. It is a nice
feature though. It would be nice if it crept its way
On 12/7/06, Eric Weddington [EMAIL PROTECTED] wrote:
Hi Shaun,
Please add this to a Patch Tracker in the avr-libc project page on Savannah.
Emails have a tendency to get lost and I wouldn't want this to be forgotten.
Eric Weddington
Is there an email gateway to the Savannah patch tracker?
On 12/1/06, Galen Seitz [EMAIL PROTECTED] wrote:
Not exactly what you want, but this might help you get started.
galen
extern inline int16_t
mult_s16_u8s16(uint8_t a, int16_t b)
...
Thanks for the code snippet, Galen. Using your mult_s16_u8s16 for
inspiration, I wrote mul_16_8 (u16 * u8 -
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each
On 12/4/06, Shaun Jackman [EMAIL PROTECTED] wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand-coded 16x8
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit - 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
What's the best approach to place the length of a binary firmware
image in the image itself at a constant location in the image? If
possible, I'd like to avoid using a linker script. I suppose the ideal
location for the firmware length would be immediately following the
interrupt vector table. On
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) 8) 0xff) | (((x) 0xff) 8))
uint16_t bswap_16(uint16_t x)
{
0:9c 01 movwr18, r24
2:89 2f mov r24, r25
4:99 27 eor r25, r25
6:
From the AVR data-sheet:
The temporary buffer will auto-erase after a Page Write operation
or by writing the RWWSRE bit in SPMCSR.
Is it possible to avoid this RWWSRE auto-erase behaviour. I'd like to
be able to partly fill up the temporary page buffer, jump to
application
On 10/29/06, Anton Erasmus [EMAIL PROTECTED] wrote:
Hi,
The only way to add program memory to an AVR is if you have some sort of
interpreter
which can execute from data memory. Your actual application hence runs in the
internal
flash, and executes the user program in data memory. This data
On 10/2/06, dimax un [EMAIL PROTECTED] wrote:
If all you need is to program two hex files into flash why not to do it?
You can use following trick:
1. avr-objcopy hex1 to bin1
2. avr-objcopy hex2 to bin2
3. merge bin1 and bin2 (may require some scripting). Take care to add
bin2 to bin1 at the
Does avr-libc implement ntohs and friends?
Thanks,
Shaun
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
44 matches
Mail list logo
