Re: [avr-gcc-list] Strange issues with 16-bit values

I had a quick look... a guess: since the interrupt handler is polling the counter that triggers the interrupt, the mcu may spend its whole time in the interrupt handler. Could you time the interrupt handler? Are you sure that the delay loop is really 'stuck'? I'd rather bet that it crawls

Re: [avr-gcc-list] Strange issues with 16-bit values

On Tue, Nov 11, 2008 at 12:30:10PM -0500, Brian Neltner wrote: I compiled with -Wall and minus a few unused variables there are no warnings. Although I'm not sure how it could cause the problem, I am curious why it would be doing 32 bit calculations in the polling. I do this:

Re: [avr-gcc-list] Strange issues with 16-bit values

On Tue, 2008-11-11 at 12:16 -0600, David Kelly wrote: You use 224UL in your expression and wonder why the comparison is promoted to 32 bits? The comparison is always the size of the biggest and your cast only sticks to the first item. Aha! Thanks =) I'm a novice at C (my job is in

Re: [avr-gcc-list] Strange issues with 16-bit values

while(TCNT3(uint16_t)benc_period*224UL/255); One can never have to many parenthesise when writing something like the above. I did not look at your code so the following may not be relevant. If you are having issues with 16-bit register values, make sure that you are not accessing the same

Re: [avr-gcc-list] Strange issues with 16-bit values

Hi Bob! Hmm, I agree that this would definitely cause problems, and am glad I now know to watch out for it, but I don't believe this is happening here. I only read the timer value inside the interrupt. I've tried now compiling the exact same source code on my windows computer running AVR Studio,

Re: [avr-gcc-list] Strange issues with 16-bit values

Hi Bernard, Thanks for your ideas! I think that the interrupt handler does exit fine in terms of logic, because when I downgrade my compiler to 4.2.2, it works fine, so I can just use the older version until I have more time to deal with it. I actually have an even stranger issue now. My rand()

Re: [avr-gcc-list] Strange issues with 16-bit values

Brian Neltner sez, I've tried now compiling the exact same source code on my windows computer running AVR Studio, and the hex file produced by that compilation works exactly as expected. rand() produces a sequence which doesn't repeat after only seven calls, and it is not halting or

[avr-gcc-list] foo++, subi vs inc?

Why does foo++; compile to subi Rd,lo8(-(1)) instead of inc Rd? I am keeping global register variables in registers below 16, which are not valid for subi so they get duplicated to perform the increment. I am preparing to check out the machine description for the avr target, but thought I would

RE: [avr-gcc-list] foo++, subi vs inc?

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Sparr Sent: Tuesday, November 11, 2008 4:24 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] foo++, subi vs inc? Why does foo++; compile to subi Rd,lo8(-(1)) instead of inc Rd? I

Re: [avr-gcc-list] foo++, subi vs inc?

Does it really matter which instruction the compiler chooses? Both constructs consume the same amount of memory and execution time. I understand your concern that potentially more time and memory could be used if the compiler resisted the use of inc and the register was below R16, but unless

Re: [avr-gcc-list] foo++, subi vs inc?

On Tue, Nov 11, 2008 at 7:00 PM, Weddington, Eric [EMAIL PROTECTED] wrote: What is the type of foo? register unsigned char foo asm(r5); On Tue, Nov 11, 2008 at 7:03 PM, Gre7g Luterman [EMAIL PROTECTED] wrote: Does it really matter which instruction the compiler chooses? Both constructs

RE: [avr-gcc-list] foo++, subi vs inc?

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Sparr Sent: Tuesday, November 11, 2008 5:53 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] foo++, subi vs inc? On Tue, Nov 11, 2008 at 7:00 PM, Weddington, Eric [EMAIL

[avr-gcc-list] AVR LLVM backend?

Sorry if this is off-topic, but I was wondering whether anyone has considered adding an AVR backend to the LLVM compiler. The LLVM team claims that it is much easier to create an LLVM backend for a new processor/architecture than it is for gcc, and LLVM has a much more powerful optimization

RE: [avr-gcc-list] AVR LLVM backend?

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Colin D Bennett Sent: Tuesday, November 11, 2008 7:10 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] AVR LLVM backend? Sorry if this is off-topic, but I was wondering whether

Re: [avr-gcc-list] AVR LLVM backend?

On Tue, 11 Nov 2008 20:14:10 -0700 Weddington, Eric [EMAIL PROTECTED] wrote: Sorry if this is off-topic, but I was wondering whether anyone has considered adding an AVR backend to the LLVM compiler. Yes. Cool. ___ AVR-GCC-list mailing list

Re: [avr-gcc-list] AVR LLVM backend?

On Wed, 12 Nov 2008 16:14:10 Weddington, Eric wrote: Sorry if this is off-topic, but I was wondering whether anyone has considered adding an AVR backend to the LLVM compiler. Yes. ... this is off-topic, or considered adding an AVR back end to LLVM? If the latter, can this be talked

RE: [avr-gcc-list] AVR LLVM backend?

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Arnim Littek Sent: Tuesday, November 11, 2008 8:32 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] AVR LLVM backend? On Wed, 12 Nov 2008 16:14:10 Weddington, Eric wrote: