/sigh/ I know I'm going to regret this...

First, I DO use the simulator, and I do understand that it has (a lot of)
advantages. But it always works, and the real device does NOT always work,
and that is why I "don't like" simulators: They are doomed to succeed.=20

In this specific case: I have a pot connected to AN0 and set so that 2.5v i=
s
on the pin. Now I want to know exactly what ADC count the chip is reading s=
o
I can set that as the midpoint in my code and turn the motors one direction
when the voltage is lower and the other when it is higher.=20

With a debugger, I simply read the ADC output register and I'm done.

How would you get that value without the debugger?=20

Go on; tell me how I'm an idiot for not "just" reading the complete ADC
documentation and calculating the correct count reading based on that. Tell
me that you would plug in some code you already have that transmits the
register value on a single pin to a serial port on your PC. Tell me the
simulator has a mode for that, AND that the simulation will, in fact, match
the real output. No, no, better yet, tell me that it's stupid to run motors
off a pot reading and that I'm a moron for even thinking that way. Or some
other abuse I haven't even dared to imagine.=20

I'm your bitch, bring it "Master".

--
James Newton
1-970-462-7764=20

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Olin Lathrop
Sent: Saturday, November 20, 2010 05:11
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] pickit2 unreliable debug 12F675

James Newton wrote:
> I considered buying a PICKit 3 out of pocket just to see if it would
> work, but I think, based on your experience and the comments of
> others, that I will wait and try to save my pennies for an ICD2 or
> ICD3.

James, you are really going a long way around to avoid the simulator.  What
exactly is going into and coming out of this PIC?  Most people that think
the simulator can't help with their project don't realize how flexible the
stimulus facility is.  Yes, the user interface is needlessly squirrely, but
it's also quite capable.  You haven't explained why you don't want to try i=
t
other than you "don't like" simulators, which is no answer at all.

If inputs can be simulated well enough (and most likely they can), then the
simulator is the best debugger of all the choices in MPLAB.  It's fast, it
gives you access to everything, it has trace back capability, it doesn't
skid on breakpoints, and it can have a unlimited number of breakpoints.

If you're not familiar enough with the simulator to think of it as a tool t=
o
use whenever it's appropriate then it would be worth spending some time
getting there.  This sounds like the perfect project to do that with.  Give
us some more info, and we can help with that.

> Why is the 2 more expensive than the 3?

Because it's older maybe?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.