On Fri, 2007-07-06 at 14:55 -0600, Eric Weddington wrote:
>
> > -Original Message-
> > From:
> > [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > org] On Behalf Of Ken Lauffenburger
> > Sent: Wednesday, June 06, 2007 10:26 PM
> > To: avr-gcc-list@nongnu.org
> > Subject: [avr-gcc-list] a
> -Original Message-
> From: Per-Tore Aasestrand [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 06, 2007 5:40 PM
> To: Eric Weddington; avr-gcc-list@nongnu.org
> Subject: RE: [avr-gcc-list] Strange delay behavior
>
> Hello,
>
> At 23:20 06.07.2007, Eric Weddington wrote:
>
>
>
>
> >
Hi Eric,
However, I am curious. What do you get with this:
uint8_t temp = (tx_producer_index++) % 64;
The wrong answer :)
It would need to be
uint8_t temp = (++tx_producer_index) % 64;
to give a functionally equivalent result.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.c
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Daniel Barkalow
> Sent: Thursday, May 10, 2007 1:56 PM
> To: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] GCC does useless 16-bit operations
>
> For the C code:
>
> uint8_t tx_producer_in
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Jan Menzel
> Sent: Thursday, May 24, 2007 5:55 AM
> To: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] jump_to_null question
>
> Hi all!
> I'm currently working on a bootloader for Me
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) flas
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Per-Tore Aasestrand
> Sent: Saturday, June 09, 2007 12:06 PM
> To: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] Strange delay behavior
>
> Hello list,
>
> I've suddenly run into something
As Shaun Jackman wrote:
> >I just committed the required modifications for both, AVRDUDE and
> >AVaRICE.
> Any plans to release a version of AVaRICE that supports the
> AT90PWM3B?
I'm still not really confident with the soft BP code in
AVaRICE-current. I've got one ATmega1280 completely damaged
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Ken Lauffenburger
> Sent: Wednesday, June 06, 2007 10:26 PM
> To: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] avr-gcc toolchain problem
>
> Hello,
>
> I'm a newbie to this list, so pleas
As Shaun Jackman wrote:
> I've submitted bug 1749358 with the diff and debug logs attached.
Thanks, I saw it.
> >Thanks for investigating!
> No problem! Do you have an AVR Dragon?
Yes, I do.
> I should mention I was using
> debugWire to communicate with a AT90PWM3B.
I don't have an AT90PWM3B
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 fo
Some debug trace info for you. The problem seems to be that the AVR
Dragon sends two packets with a sequence number of 110 in a row, when
avarice is expecting the sequence number 111.
Thanks,
Shaun
command[0x0b, 1]: 0B 01
recv: 0xbf
command[0x0b, 2]: 0B 01
recv: 0x1b
recv: 0x6e
recv: 0x00
recv:
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 the best mailing list for avarice-related questions?
Thanks,
Shaun
$ avarice -gwjusb -B1000 -vf foo.bin
AVaRICE version 2.
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 committ
Hello list,
I've suddenly run into something odd. I am using AVR Studio Version
4.12 Service Pack 4 with WinAVR 20060421. Have been using this setup
for a while without any problems.
Now, running the following test program on a ATmega128 @ 8 MHz,
produces pulses on PC3. However, with 'off' p
Hello,
I'm a newbie to this list, so please forgive me if this is an elementary
problem.
I recently built the avr-gcc toolchain on my Gentoo AMD-64 system. I
used the following command to build it:
crossdev --target avr
It seemed to work fine. However to test the installation I downloaded
t
Hi all
I want to debug my program through Rs232 interface of the PC.
But why the "scanf" and "scanf_P" function doesn't work while printf works?
I have googled and find only the example of using printf,but no scanf.
Does avr-gcc not support scanf very well?Or there is something wrong in th
Hi all!
I'm currently working on a bootloader for Mega8 and 88 and found a
problem I do not yet understand. At the end of the bootloader the code
has to jump to the main reset vector at address 0x. If I do the
usual way
void (*jump_to_null)(void) = 0x;
gcc 3.4.6 complies:
For the C code:
uint8_t tx_producer_index;
...
{
...
uint8_t temp = (tx_producer_index + 1) % 64;
I get the assembly from gcc 3.4.4:
13a2: e0 91 f7 00 lds r30, 0x00F7
13a6: 8e 2f mov r24, r30
13a8: 99 27 eor r25, r25
13aa:
As Shaun Jackman wrote:
> Good and bad news! The good news is I was able to make my AVR Dragon
> work and have a patch. The bad news is the oddness of the
> solution. I incremented JTAG_RESPONSE_TIMEOUT from 1000 ms to 1010
> ms and it works now! I've attached two debug logs. The 1000 ms log
> is
20 matches
Mail list logo
