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
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:
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
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
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,
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()
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
Have you looked at the generated assembly code? (Add -Wa,-ahlsd to
your compiler options to generate a list file). And have you considered
other problems, such as watchdog resets causing problems for the slower
code?
mvh.,
David
Brian Neltner wrote:
Very oddly, the code runs when I
Hello,
Brian Neltner wrote:
Very oddly, the code runs when I compile it with -O3, but not with any
other optimization level.
This works:
int main(void) {
uint8_t i;
for(i=1;i0xFF;i++) asm volatile(nop/n/t);
PORTA=0x01;
while(1);
}
You are using /n and /t instead of
Since the 16 bits code should be running a little bit slower than the 8
bits version, maybe the target fires up its watchdog? Also how do you
test that PORTA is correctly set on the 8 bits version ? (I don't see
any DDRA setting to use bit zero of PORTA as an output)
Bernard
Brian Neltner
Sorry, typo. I was giving example code, not a literal copy of my source.
I haven't tried looking at the assembly code (I'm not very familiar with
AVR style assembler), but here is the makefile I am using to compile, as
well as the actual original source file (which compiled previously and
behaved
Apologies if this has been mentioned before.
I have some software that previously compiled perfectly on my computer,
but which now fails silently when uploaded (no compile-time errors or
warnings). I am hoping someone can help me!
This works:
int main(void) {
uint8_t i;
Very oddly, the code runs when I compile it with -O3, but not with any
other optimization level.
...
Is this a known bug?
On Fri, 2008-11-07 at 00:05 -0500, Brian Neltner wrote:
Apologies if this has been mentioned before.
I have some software that previously compiled perfectly on my
13 matches
Mail list logo
