it’s difficult to figure out what is going on with code execution, how do you figure out what is the state of the code, registers, variables, etc…
I usually just put in small LED blink routines that tell me what I want to know.
There are AVR simulators that I guess could help but I’ve never bothered to try them: http://www.amctools.com/
I was thinking abut that could be used, but hoping for a different answer, such a way to use the SOIC8 clip to somehow read the status of inside.
Yeah, I know what you meant, but can’t help you there.
I have problems with some functions when the clip is attached as it is feeding the MCU with a little power. In order to fully test accurate functionality I have to unclip the MCU or pull the USB programmer out of the USB port/cable. Having the clip attached for debugging might provide unpredictable results, at least if you have off time caps on board.
Yes, I experienced similar strange unpredictable behaviour while the clip was attached. Oh well then I’ll just have to blink out the status.
You guys are obviously far more advanced than I am. I just hit build--if it builds without errors then I flash it--if that works, then 
; if it doesn't work, then 
.
hehe well, I’m a software developer so I NEED to be able debug my code, even if it is just a flashlight driver 
seriously, it can be bothersome to clip on-clip off tens of time for trying out things. Especially if it’s a bigger alteration, not just adjusting levels.
Avr studio has a simulator for debugging build in.
If you want to debug the controller itself just buy an avrdragon.
Oh! So there is a way! It seems to cost around $50, not too much. Still, just bought a €150 yihua 853D 5A 30V, so this new toy will have to wait
Think the more advanced dev tools was posted about here on BLF somewhere, naybe the Roche F6 thread? ToyKeeper has been doing some dev, not sure if she's using any emulator. Would be nice to single step, break, etc... I know I've been winging it, but keep my mods simple. Anyway, it's hard to get in much trouble with so little program space 
.
The test clip has to be pull out, after programming, in order to properly test the driver.
Before this, I used to do clip on clip off, but it is troublesome and wearing out the clip.
To avoid that, I use 10way connector to plug/unplug the programmer from the MCU, while leaving the clip [A] on the MCU.
Sometimes I use [B] if the MCU pins are hidden / not easily accessible (normally the case if I want to fine tune an already installed/deployed driver inside a flashlight)
I just don’t see the point. What would you achieve with this tool and an ATtiny13A? EDIT, less confrontational: Please explain to me how this would be useful, I do not understand.
When coding, you’re trying a new feature, and it’s not working the way you want, the only way to get it working is to try dozens, if not hundreds of times to flash, unclip, run, and see if it behaves the way you want. If it’s not behaving the way you want, it’s tricky to figure out why, what’s the state of the variables.
Normally when coding, you can insert breakpoints, printout statements, use debugger, to see what you did wrong. With the only possible output being the flashing of the led, it’s challenging.
So with the debugger, what specifically would you be able to see? You’d be able to identify variables (by name?) and see their states? Breakpoints would pause the operation of the code until the debugger allowed it to continue?
Ideally yes, see variable names, values, and set breakpoints to inspect states at particular point in execution. How this particular debugger works, I don’t know.
I’ve never used a “debugger” as far as I recall. Interesting stuff.