Hi list! I am something of a newbie with PICs, though I have a fair
amount of past (ca. 1986) experience with electronics. I have really
enjoyed learning about PICs and getting several projects to work
with them. It is great to be able to do things in software that I
used to have to do with discrete chips and transistors. And of course
this list has been a wonderful resource.

I just wanted to mention a debugging technique I have used recently
that worked very well. I'm sure this is nothing new to the experienced
picsters on the list, but maybe it can help out another newbie.

I'm working on a monochrome 640x480 LCD display I have. It doesn't
have any graphical memory or refresh logic on board, I have to do all
that myself (all it has are some serial-to-parallel data latches to
latch in the pixel data, pixel-by-pixel, line-by-line). So I'm using
a 16F628 (as well as some external counters and latches and of course
RAM), and the timing is getting fairly complicated. One evening I was
getting very confused by what I was seeing on the scope and trying to
relate it to what was in my code, when I had the idea of slowing
everything WAY down. I replaced the 20MHz crystal with a 555 running
at about 10Hz into CLKIN, put some LEDs on the main signal lines,
and suddenly I could watch my program run in human time! Within an
hour I had figured out what I was doing wrong and solved the problem!

Of course the PIC simulator can be used in a similar way (slowing things
down so you can see what is going on), but in my case I had a lot
of external electronics interacting with the PIC code. So I
recommend this if you are stuck with a problem involving delicate
timing: try slowing things down by a factor of a million or so.

Michael V

Thank you for reading my little posting.


_________________________________________________________________
Join the world s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu