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

>
>Cheers,
>-Neil.
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email listserv@mitvma.mit.edu with SET PICList DIGEST in the body
>
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body