AVR-Chat

On Dec 20, 2004, at 10:10 PM, wbounce wrote:

>
> What do you mean full speed? I have a 500 ms delay at the start of my
> program so I can get my fingers off the switch before my robot moves. 
> If
> I set a break point after this and just tell the debugger to run it
> takes 10 minutes to get past the .5 second delay. My Program makes 
> heavy
> use of TWI (I2C) And the functions I am using for that have a timeout 
> of
> 1 seconds. So they are just as bad as the delay at the start. So it
> takes me several minutes of run to here, skip of that, run top there
> skip over this, substitute a value that should have been returned, etc
> before I can get to the part I need to really step through. I was
> thinking the has to be a beter way hence my question.
>
> Playing with the divisor may be a viable solution to thanks
>
> -----Original Message-----
> From: David Kelly [mailto:dkelly@hiwaay.net]
> Sent: Monday, December 20, 2004 8:52 PM
> To: AVR-Chat@yahoogroups.com
> Subject: Re: [AVR-Chat] 3 debugging questions
>
>
>
>
> On Dec 19, 2004, at 11:06 PM, wbounce wrote:
>>
>> Even small values for pnDelay take a long time in the simulator.  Is
>> there some setting in AVR Studio that affects this?
>
> I remember looking and not finding a way to set the timer0 clock
> frequency different than the main CPU clock in the simulator. Thought
> it would be nice to have a 32kHz clock in the simulator the way my real
> hardware would.
>
> So while playing in the simulator I moved the timer0 clock back to he
> main CPU and set the divisor so that it ran very fast.
>
> Another way to deal with it is to set breakpoints at the places you are
> interested in seeing. Then let the simulator run at its full speed
> until it gets there.
>
> Another way to say it is, "Learn to choose your battles. Only debug
> broken or suspect code."  :-)  (as if it were that easy)

Then either bypass your startup delay with a compile-time define or 
manually advance your PC (program counter) to the code of interest. 
Hence the "choose your battles" advice. Only debug the broken code. No 
need to debug the startup delay.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.