Debugging code in the chip
Stef email (remove spam text)
>Among all the other great suggestions offered here, I'll add...
>- Slow it down with a big cap (use RC osc mode). In this case, 0.1uf is
>usually big enough. This way, you can see anything timing-critical, and
>watch LED's being multiplexed, etc.
That's indeed a good trick, but with a simulator ....
- slow down
- set breakpoints
- trace code
- single step
- manipulate registers
>- I usually max out my PIC usage, so if I don't have spare I/O's, I'll use a
>larger PIC until the code is sorted out. Then, I'll convert back for the
>original target PIC.
Yes, that's whatt most of us (especially hobbyists) are doing.
But 1 free pin (at least temporary), must be possible ?
So now I'm still looking for a circuit and code to connect that 1 pin
with a PDA,
resulting in a bidirectional communication !
>- The SIM is great except when dealing with external influences. I'm not
>thrilled with the way MPASM SIM handles pin stimulus.
I'm not familiar with mplab sim, but a good simulator should have a
whole bunch of stimulus generators
- internal generators
- generators through some scripting language
- real recorded signals from a file
> But it's great for
>testing/tweaking algorithms. It's also great for figuring out that I used
>the wrong destination on some instruction (,F vs ,W).
>- Finally, incremental development.
Very good point !
> Create/test one part. Create/test
>another part, using independent registers (even for scratch stuff). Later
>on, optimize it to re-use registers and free up some ram for additional code.
Or use a good compiler, that does the job for you ;-)
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email mitvma.mit.edu with SET PICList DIGEST in the body listserv
In reply to: <firstname.lastname@example.org>
See also: www.piclist.com/techref/microchip/devices.htm?key=pic
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the