Picdude wrote:
>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 ....
you can
- 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 ;-)
cheers,
Stef
{Quote hidden}
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspam_OUT
mitvma.mit.edu with SET PICList DIGEST in the body
BY
:
Stef email (remove spam text)