Searching \ for '[PIC] finger triggered circuit' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'finger triggered circuit'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] finger triggered circuit'
2005\08\22@045557 by Andrew

flavicon
face
Hi,

This is my first PIC project so be gentle! :-)

My circuit consists of a 12V battery (giving off 13V according to my
meter) connected to a 7805. The 7805 has a 35uF capacitor from ground
to output. The multimeter says the output voltage is 4.98V. This 5V
supply is connect to a 12F629 which has LEDs on pins 2 & 4 and a DC
operated piezo on pin 5 (the LEDs and piezo are just for debugging -
I'll try to do something useful when this works!). pins 0, 1 & 3 are
configured as inputs. Pin 0 is tied to -ve, 1 & 3 are unconnected. All
this is wired on a breadboard.

My problem is that the chip doesn't always seem to start - it's
programmed to give a short burst on the piezo at boot. The thing that
makes it start when it doesn't want to is me placing my finger above
the chip (sometimes I need to actually touch the plastic case of the
PIC). Even once booted nothing much works but one problem at a time :-)

Having a look on the web I find the piclist page re floating inputs
with the line:

"Some of these chips froze just  by placing a finger near them, some
won't start, some start but run 'funny'."

Seems to be my problem however all the internal pull-up resistors
should be enabled - WPU is 0x37, OPTION_REG is 0x7F - so all inputs
(apart from GP0) should read as 1 if I have understood correctly.

Any suggestions?

Thanks,

Andrew

2005\08\22@050350 by Michael Rigby-Jones

picon face


{Quote hidden}

What are your configuration fuse settings? Specifically, do you have Pin4 set as MCLR or GP3?

Also note that an LED on pin 4 isn't going to help you much, this is the MCLR/GP3 line and it's an input only.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\08\22@051444 by Wouter van Ooijen

face picon face

> This is my first PIC project so be gentle! :-)

Did you enable internal reset? If so maybe don't do that for a first
project.

To rule out any static problems you could simple connect all pins to
ground or +5V with a suitable resistor, I would take something like 100k
or 220k.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\22@051929 by Chen Xiao Fan

face
flavicon
face
Never mind. We will be gentle. :)

First thing first, what is pin 0?
>From Datasheet ( not all the alternative functions are listed here) :
Pin 1: Vdd
Pin 2: GP5
Pin 3: GP4
Pin 4: GP3 (input only) or /MCLR
Pin 5: GP2
Pin 6: GP1
Pin 7: GP0
Pin 8: Vss

So please re-describe your connection using this pin definition
in the datasheet. Another thing is the configuration?

Regards,
Xiaofan

{Original Message removed}

2005\08\22@053201 by Andrew

flavicon
face

On 22/08/2005, at 10:03 AM, Michael Rigby-Jones wrote:

> What are your configuration fuse settings? Specifically, do you have
> Pin4 set as MCLR or GP3?

_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _CP_OFF

> Also note that an LED on pin 4 isn't going to help you much, this is
> the MCLR/GP3 line and it's an input only.

Sorry when I said pin 1, 2 etc I meant GP1, GP2 etc. There is nothing
connected to GP3.

GP0 is tied to -ve and configured as an input.
GP1 is unconnected and configured as an input.
GP2 is connected to a LED and configured as an output.
GP3 is unconnected and configured as an input.
GP4 is connected to a LED and configured as an output.
GP5 is connected to a piezo and configured as an output.

All internal pullups should be enabled.

Sorry for the confusion,

Thanks,

Andrew

2005\08\22@054405 by Andrew

flavicon
face

On 22/08/2005, at 10:12 AM, Wouter van Ooijen wrote:

> Did you enable internal reset? If so maybe don't do that for a first
> project.

I left it on its default setting which is internal it seems. I'll
configure it for external and see if it helps.

> To rule out any static problems you could simple connect all pins to
> ground or +5V with a suitable resistor, I would take something like
> 100k
> or 220k.

I just quickly tried connecting GP1 and GP3 (the 2 unconnected inputs)
to ground via a 9.1K resistor (which is all I have at hand) and it
didn't help (in fact it doesn't seem to start even with the help of a
finger). Tonight I'll try the reset setting above and removing all the
actuators bar one LED, and making everything else and input tied to
ground.

Thanks,

Andrew

2005\08\22@054528 by Michael Rigby-Jones

picon face


{Quote hidden}

No problem, it looks like you have pin 4 configured as the MCLR (reset) pin.  This means you absolutely need a pullup to Vdd.  The consequences of not having a pullup are exactly as you describe, i.e. flaky, intermittant operation, affected by bringing a finger near.

If you want to use GP3 as an input, you need to add '& _MCLRE_OFF' to you config line, though I find it's handy to have an external reset pin during the debugging stage so you don't have to cycle the power to reset the micro.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\08\22@060503 by Wouter van Ooijen

face picon face
> I left it on its default setting which is internal it seems.

Don't trust any defaults, specify everything you want to be sure of!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\22@081041 by olin piclist

face picon face
Andrew wrote:
> My problem is that the chip doesn't always seem to start - it's
> programmed to give a short burst on the piezo at boot. The thing that
> makes it start when it doesn't want to is me placing my finger above
> the chip (sometimes I need to actually touch the plastic case of the
> PIC).

First suspect is that you have the MCLR pin enabled for the MCLR function
and it's not tied anywhere.  If you are using it in the MCLR role, tie it to
Vdd via 20K ohms or so.

Second suspect is that LVP is enabled and the PGM pin is floating.  Either
disable LVP or make sure PGM is tied low.

What is the oscillator mode?  It's a good idea to start with internal RC
until you know the rest of the circuit is working.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\22@082733 by Wouter van Ooijen

face picon face
> Second suspect is that LVP is enabled and the PGM pin is
> floating.

wow, LVP on an 8-pin PIC :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\22@085624 by olin piclist

face picon face
Wouter van Ooijen wrote:
> wow, LVP on an 8-pin PIC :)

Why do you say that?  Does this PIC not have LVP?  I haven't checked.
Floating PGM pin is just a stock answer for a problem like the OP described,
as is floating MCLR, and oscillator problems.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\22@095407 by Wouter van Ooijen

face picon face
> Wouter van Ooijen wrote:
> > wow, LVP on an 8-pin PIC :)
>
> Why do you say that?  Does this PIC not have LVP?  I haven't checked.

because the OP talked about an 12F629

> Floating PGM pin is just a stock answer for a problem like
> the OP described, as is floating MCLR, and oscillator problems.

Indeed. In this case floating MCLR is probably bulls eye, osc problems
seem less likely given the symptoms but is still a good thing to check,
and floating PGM is nonsense on a 12F629.

Which should not be taken as me flogging you for your answer, as long as
you don't flog me for my follow-up :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\22@202241 by Sean Schouten

face picon face
Switch the watchdog timer off if you haven't allready. It causes havoc
if you don't know how to handle it and why should you have it on if
you don't need it anyway? I presume that that's what Wouter meant when
he spoke of the 'internal reset'.

My configuration bits are set as following:  

; ## Begin Conf-Bits ##
__CONFIG   _CP_OFF & _CPD_OFF & _BOD_OFF & _MCLRE_OFF & _WDT_OFF &
_PWRTE_ON & _INTRC_OSC_NOCLKOUT

; ## End Conf-Bits ##


Sean

2005\08\22@203549 by Chen Xiao Fan

face
flavicon
face
No. Internal reset means using internal MCLR and thus free
up one pin (input only). For example, Pin 4 of 12F629 is
GP3/Vpp//MCLR. It can be configured as the /MCLR pin or
an input only pin GP3. This is the same for all the new
8/14/20 pin PICs.

By the way, it is a good practice to enable Watchdog timer.

Regards,
Xiaofan

{Original Message removed}

2005\08\22@204816 by Sean Schouten

face picon face
> By the way, it is a good practice to enable Watchdog timer.

I agree. But I must also admit that I, as a 'beginner', have other
things to worry about like getting the algorithms that are on paper
into the pic in perfect working order etc etc. WDT can definately wait
till my coding skills have improved beyond the point of me having to
worry about why that one little miserable thing doesn't quite do what
it should, or do you beg to differ?

2005\08\22@205203 by Chen Xiao Fan

face
flavicon
face
Ooops, Olin. You need to check. It is quite obvious to me
that you have never worked with 12F629/675/...

They are quite unique MCUs.

Regards,
Xiaofan

Some of my observation with using the 12F629 for one year:

1. sharebank in the linker script
SHAREBANK  NAME=gpr0nobnk START=0x20     END=0x5F
SHAREBANK  NAME=gpr0nobnk START=0xA0     END=0xDF

2) They also need special header (with debug chip) to be used with ICD2.

3) Factory calibrated OSCCAL data is stored in 0x3FF. Programmers need to be
aware of this.

4) when using internal MCLR, there are some problems with ICD2 programming.
Wouter has a very good understanding of this and please refer to the
previous posts.

ICDWarn0033: You have selected Internal MCLR and Internal Oscillator in your
configuration settings. If your code makes use of port pins that correspond
to Clock and Data pins in programming mode, you may not be able to reprogram
your device. See on-line help for this warning for more information.
(OK/Cancel)

When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp and
Vdd are powered together, and then Vpp is pulled high to Vihh to enter
programming mode. This means that your code will be running before Vpp goes
to Vihh. If that code makes use of port pins that correspond to Clock and
Data pins in programming mode, there is a chance their values may not be 0,
as necessary to enter programming mode. Therefore, the device could not be
reprogrammed.

Click OK to continue programming or click Cancel to cancel the programming
operation.

Work-Around

When External MCLR is used, this is not a problem, as Vpp can go directly to
Vihh. Also, if External Oscillator is used, the external oscillator can be
kept from running, thus keeping the code from running, until Vpp is at Vihh.



-----Original Message-----
From: olin_piclistspamspam_OUTembedinc.com [@spam@olin_piclistKILLspamspamembedinc.com]
Sent: Monday, August 22, 2005 8:57 PM

Wouter van Ooijen wrote:
> wow, LVP on an 8-pin PIC :)

Why do you say that?  Does this PIC not have LVP?  I haven't checked.
Floating PGM pin is just a stock answer for a problem like the OP described,
as is floating MCLR, and oscillator problems.

2005\08\22@211042 by William Chops Westfield

face picon face

On Aug 22, 2005, at 5:51 PM, Chen Xiao Fan wrote:

>
> Some of my observation with using the 12F629 for one year:
>
> 2) They also need special header (with debug chip) to be used with
> ICD2.

Only for debugging, right?  You should be able to program them
with just the appropriate socket adaptor?

BillW

2005\08\22@213617 by Andrew

flavicon
face

On 22/08/2005, at 10:40 AM, Michael Rigby-Jones wrote:

> No problem, it looks like you have pin 4 configured as the MCLR
> (reset) pin.  This means you absolutely need a pullup to Vdd.  The
> consequences of not having a pullup are exactly as you describe, i.e.
> flaky, intermittant operation, affected by bringing a finger near.

That was exactly the problem. I misread the data sheet and thought
reset was internal by default. Tieing this pin to +ve or adding
_MCLRE_OFF to my _config line fixed my booting problem.

Thanks to everyone for their help - I'm sure I would have been staring
at it for a long time without it.

I have just got everything working on my breadboard and thought I'd
share with you the things that took me longest to work out, for the
benefit of the archives or for the benefit of anyone thinking of
writing a book for newbies :-)

1) The external/internal reset issue that was the subject of this thread
2) The analogue comparator is on by default and must be switched off
before GP0 and GP1 are available
3) Most instructions don't seem to work with a "special" register as
their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
MPLAB sim)
       You have to do your bit manipulation in W and then movwf the completed
value to the register in question. Incidentally thats how I assumed it
would have to be done before I read the data sheet. Something in the
data sheet (what I'm no longer sure) that gave me the impression I
didn't need to do it that way. I remember thinking it was pretty cool
you could use any register.

Thanks again to everyone for their help!

Andrew

2005\08\22@213735 by Chen Xiao Fan
face
flavicon
face
Yes programming with ICD2 is okay in normal cases (without internal
MCLR). With internal MCLR and internal RC OSC, programming with
ICD2 becomes a problem as well (ICDWarn0033). That is why I am
using PICkit 1 to program my 12F629. Okay I have a PM3 by my side
as well from yesterday. :)

Thanks for the correction.

Regards,
Xiaofan

{Original Message removed}

2005\08\22@214146 by Chen Xiao Fan

face
flavicon
face
I guess you are now better than a beginner and you can already
deal with WDT. I am not an expert in PIC software development
myself. My longest code is less than 2k words. Still I always
turn on WDT just to capture coding errors and for EMC reasons.

It is good practice to turn off WDT during debugging. After
debugging, to turn on WDT is not so difficult anyway.

Regards,
Xiaofan

{Original Message removed}

2005\08\22@214514 by Chen Xiao Fan

face
flavicon
face
Strictly speaking, we do not need a socket adaptor. :) All the new
PIC MCUs support ICSP. Still I do not consider ICD2 a very good
programmer since it has quite some problems with ICSP. But it
is the only game in town for dsPICs in its price range.

Regards,
Xiaofan

-----Original Message-----
From: William "Chops" Westfield [KILLspamwestfwKILLspamspammac.com]
Sent: Tuesday, August 23, 2005 9:11 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] finger triggered circuit

Only for debugging, right?  You should be able to program them
with just the appropriate socket adaptor?

BillW

2005\08\23@041502 by Chris Emerson

flavicon
face
On Tue, Aug 23, 2005 at 02:36:11AM +0100, Andrew wrote:
> 3) Most instructions don't seem to work with a "special" register as
> their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
> MPLAB sim)

Are you sure?  Did you have the bank bits set correctly?

Those instructions certainly should, and do IME, work with any register.

Chris

2005\08\23@053938 by Andrew

flavicon
face

On 23/08/2005, at 9:14 AM, Chris Emerson wrote:

> On Tue, Aug 23, 2005 at 02:36:11AM +0100, Andrew wrote:
>> 3) Most instructions don't seem to work with a "special" register as
>> their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
>> MPLAB sim)
>
> Are you sure?  Did you have the bank bits set correctly?

I had a banksel CMCON just before it. I had the same thing with a few
other registers. I'll double check to be sure later today. This was
only with the simulator - I didn't try it on the hardware when it
didn't work in the simulator.

> Those instructions certainly should, and do IME, work with any
> register.

I'll give it another test tonight in the simulator and make sure it
wasn't just me doing something stupid (again :-))

Thanks,

Andrew

2005\08\23@074608 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Ooops, Olin. You need to check. It is quite obvious to me
> that you have never worked with 12F629/675/...

No, actually I've done a bunch of projects with them and 16F630 which is the
same as the 12F629 with more pins.  It's just that I do so many PIC projects
and there are so many PICs out there that after a while I don't remember the
details of each PIC off the top of my head.

For real projects of course I spend the extra minute to look up a detail
when I need it.  But for answering PIClist questions for free, I don't
usually go that far, especially when listing a few general things to try.

> 2) They also need special header (with debug chip) to be used with ICD2.

These are such simple chips I've never wanted more than the simulator for
debugging.

> 3) Factory calibrated OSCCAL data is stored in 0x3FF. Programmers need
> to be aware of this.

Yes, both the EasyProg and ProProg are aware of the calibration value.  It
is read before bulk erase, written to standard output for reference, and
restored during programming.

> 4) when using internal MCLR, there are some problems with ICD2
> programming. Wouter has a very good understanding of this and please
> refer to the previous posts.

I admit I've never attempted to program one of these with an ICD2.  I've got
rather a large number of programmers floating around that can be made to
program the chip automatically from a build script if I want.  There is no
reason to put up with the annoying clickety-click interface of the ICD2 for
programming.

> When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp
> and Vdd are powered together, and then Vpp is pulled high to Vihh to
> enter programming mode. This means that your code will be running
> before Vpp goes to Vihh. If that code makes use of port pins that
> correspond to Clock and Data pins in programming mode, there is a
> chance their values may not be 0, as necessary to enter programming
> mode. Therefore, the device could not be reprogrammed.

According to the programming spec DS41191C, page 4, figure 2.2, Vpp should
be raised to the programming voltage before Vdd, probably to avoid this very
problem.  This is what my programmers do, and I can't imagine why the ICD2
can't do the same thing in programming mode, at least in the case where it
is controlling Vdd as described above.  Duh!


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\23@075728 by olin piclist

face picon face
Andrew wrote:
> 2) The analogue comparator is on by default and must be switched off
> before GP0 and GP1 are available

This is true of all PIC analog inputs.  The standard PORT module of my PIC
development environment (http://www.embedinc.com/pic) together with the
/INBIT and /OUTBIT preprocessor directives automatically take care of this
so I never get caught by this issue.

> 3) Most instructions don't seem to work with a "special" register as
> their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
> MPLAB sim)

No, they definitely work.  You probably don't have the bank bits set right.
For a good way of dealing with banking, see the DBANKIF and related macros
in STD.INS.DSPIC at the web page listed above.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\23@080817 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [spamBeGonepiclist-bouncesspamBeGonespammit.edu]
>Sent: 23 August 2005 02:36
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] finger triggered circuit
>
>
>
>3) Most instructions don't seem to work with a "special" register as
>their target e.g. andwf CMCON, F doesn't affect CMCON (at least in the
>MPLAB sim)
>        You have to do your bit manipulation in W and then
>movwf the completed
>value to the register in question. Incidentally thats how I assumed it
>would have to be done before I read the data sheet. Something in the
>data sheet (what I'm no longer sure) that gave me the impression I
>didn't need to do it that way. I remember thinking it was pretty cool
>you could use any register.

Hmm, that sounds odd. If you specifiy F as the destination that's where the result should go.  Note that some bits in some registers may be "read only" so writing to them does nothing.  The beauty of the PICs architecture is that SFR's and GPR's can be treated in exactly the same way (in most cases).

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\08\23@120727 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> I admit I've never attempted to program one of these with an ICD2.  I've got
> rather a large number of programmers floating around that can be made to
> program the chip automatically from a build script if I want.  There is no
> reason to put up with the annoying clickety-click interface of the ICD2 for
> programming.

For the ones who are not so lucky, AutoIt3 may do the trick. This is a
scripting language that allows scripting of Windows GUI applications with
reasonable ease. With this, you can add a command line interface to most
GUI-only applications.

I just tried it (integrated Norton Ghost backups into my maintenance
script), and it's really easy to use.

Gerhard

2005\08\23@153030 by Gerhard Fiedler

picon face
Patrick Murphy wrote:

>> For the ones who are not so lucky, AutoIt3 may do the trick. This is a
>> scripting language that allows scripting of Windows GUI applications
>> with reasonable ease. With this, you can add a command line interface
>> to most GUI-only applications.

> I agree. Thanks to someone here on the PIClist (perhaps it was you,
> Gerhard?)

Possibly, but not probably. AutoIt3 has been on my plate to try for a
while, but I just recently got around to actually use it -- with a push by
the absence of a command line interface in the new Ghost. (Who's
interested: http://tinyurl.com/bl8s6)


For using MPLAB's programmer I had used PowerPro scripts so far -- but
that's only useful if you use PowerPro anyway. AutoIt3 is much better for
this type of task, and much easier to get started too. I'll probably write
something like a command line driver for MPLAB over the next weeks.

> WinActivate("MPLAB IDE v7.10")

Maybe use WinActivate("MPLAB IDE *") -- you don't need to touch your script
just because you update MPLAB (if nothing relevant in the menus and
shortcuts has changed).

> Send("{F5}") ; ...in case the debugger is running - this doesn't always work,
> Sleep(500)   ; as pressing F5 manually doesn't always halt the debugger.

Is there something in the window texts that comes up or goes away when the
debugger stops? (I don't use the debugger...)

Gerhard

2005\08\26@062854 by Gerhard Fiedler

picon face
Patrick Murphy wrote:

>>> WinActivate("MPLAB IDE v7.10")
>>Maybe use WinActivate("MPLAB IDE *")
> Thanks. I'll make that change.

Not so quickly... :) That didn't work out so well.

The first thing that was wrong is the asterisk. On reading the help, it
does partial matching by setting opt( "WinTitleMatchMode", 2 ), not by
using asterisks or something. I thought I saw this somewhere in the
examples, but I was probably wrong.

So then I had this:

opt( "WinTitleMatchMode", 2 )
WinActivate("MPLAB IDE")

but had at the same time an explorer window open with the MPLAB directory
(and "MPLAB IDE" in the title). Not good... :)

This is what I do now:

; in the header of the file
$mplabTitle = "MPLAB IDE v7.10"

; further down where referencing the title
WinActivate( $mplabTitle )


{Quote hidden}

Exactly. It can take some time to find the proper unique conditions... a
standardized way to retrieve application states would be /really/ nice :)

Gerhard

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...