Noobie Question

[mel4853]

I'm using a 12f675 to control a camera to take pictures of wildlife.I have a motion sensor hooked to gp3 which is a input only, but can't figure out why it never reads this. I need to hold that input low until the motion sensor sees motion which will bring this input high. Here's the code.********************************************* *******************
'* Name : hpcam.BAS *
'* Author : [select VIEW...EDITOR OPTIONS] *
'* Notice : Copyright (c) 2006 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 6/22/2006 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************
symbol cambut=4
symbol pir=pin3
symbol on=2
symbol lite=1
symbol led=0
symbol counter=5
symbol CMCON=$19
symbol ANSEL=$9f

main:
poke ANSEL,$00
poke CMCON,$07
high on
pause 250

loop:
if pir=1 then takepic
high led
pause 250
low led
pause 250
b1=b1+1
if b1>230 then camoff
goto loop

camoff:
low on
pause 2000
high on
pause 8000
b1=0
goto loop

takepic:
high lite
pause 250
high cambut
pause 1000
low lite
low cambut
pulsout 5,2
pause 250
for b0=1 to 4
pause 60000
high led
pause 250
low led
next b0
goto camoff

[mister_e]

as i'm not familiar with the PBC lines i can just ask if you correctly set the configuration fuse when you program your device?

Be sure you set MCLR to i/o, internal or INTRC depending of the syntax of your device programmer software.

If your PIR signal is comming from a relay (wich i suspect) be sure you're using pull down/up resistor... uneless this pin is floating and it may work sometimes, sometime not.

EDIT: by reading your post again... i suspect you miss the pull-down resistor

I need to hold that input low until the motion sensor sees motion which will bring this input high.

[mel4853]

I have a 10k pulldown resistor on board, the motion sensor gives a +5 volts when triggered, which should pull this input high. I have one of these working using a PICAXE chip, but switched chips to gain the extra I/O. I just need to know how to configure the GP3 pin. Sorry for not making this clear on first post. Thanks for any help.

[mister_e]

O.K.
whe you program your PIC, your device programmer software MUST allow you to set the configuration fuse somewhere. Find it first..

Got it?

Now it must have at least 1 place to configure the MCLR pin and one other for the Oscillator

YES... set it to I/O, INTRC, or something else than MCLR or RESET.

This is a ScreenShot of PICSTART (MPLAB)
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=942&stc=1&d=1151464220 ">

This is a screenshot of BK precision 844a
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=941&stc=1&d=1151464220 ">


About now?

[paul borgmeier]

In addition to Steve's comments ...

Does your LED blink while waiting for PIR to go high? (i.e., Is your PIC alive - are you sure the PIC is working.)

What happens if you hardwire GP3 high – does your IF THEN catch it and turn on your camera?

Have you measured GP3 with a meter to make sure it really goes high when the PIR is triggered?

Is there a chance you could be missing the PIR high signal? Your loop only looks for high signal once (for a singe uS) every ½ second.

You have not initialized b1 to zero at the beginning of your code. It gets set later but you should set it early as well.

Is this the same program you used with your axe?

I just need to know how to configure the GP3 pin

you have no choice it is auto configured as an input, which is what you want.

Out of interest, what are you going to film? A guy a few weeks ago set one of these up to video hedgehogs.

Paul Borgmeier
Salt Lake City, Utah
USA

[dhouston]

you have no choice it is auto configured as an input, which is what you want.

Only if you set the config fuse to disable MCLR and make GPIO.3 an input.

[paul borgmeier]

Only if you set the config fuse to disable MCLR and make GPIO.3 an input.

For clarity, I guess I should have added the bold to my original comment so that it read

"if GP3 is set as MCLR internal you have no choice since it is auto configured as an input, which is what you want."

With Steve's discussion above and before mine, I thought this was clear but after rereading my response this morning, I see that it was not - good catch.

Paul

[dhouston]

Paul,

It gets confusing because all of the various programmers use different terminology to refer to the MCLR config setting so it's hard to create a universal "how to".

[mister_e]

and more, pretty bad that PBC don't allow to set the config fuses in the code.. that would be so much convenient. Yet another real limitation of PBC.

    @ __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_OFF & _BODEN_ON
         ' Internal Oscillator
         ' Enable watch dog timer
         ' Enable power up timer
         ' Disable MCLR pin
         ' Enable brown out detect

[paul borgmeier]

and more, pretty bad that PBC don't allow to set the config fuses in the code.. that would be so much convenient. Yet another real limitation of PBC.

    @ __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_OFF & _BODEN_ON
         ' Internal Oscillator
         ' Enable watch dog timer
         ' Enable power up timer
         ' Disable MCLR pin
         ' Enable brown out detect

Without PBC, I cannot test or look at the "supplied" files but if the fuses are not dropped in by a .inc file like they are in PBP, I wonder if the user could include them in the following manner (at the top of their program):

ASM
device pic12F675, intrc_osc_noclkout, wdt_off, mclr_0ff, protect_off
ENDASM

I do remember that PBC supports inline ASM – shouldn't this work?.

(I use MPASM - I am not sure if the format for PM is correct above).

If it does work, I think this would be easier than having to edit the .inc file like we do in PBP. Thoughts?

Paul Borgmeier
Salt Lake City, Utah
USA

[dhouston]

ASM
device pic12F675, intrc_osc_noclkout, wdt_off, mclr_0ff, protect_off
ENDASM

I don't think it will work because the programmer does not look at the file. The fuses have to be set by the programmer. With PBP and the MEL programmer, the @device statements are read by the programmer and it, in turn, sets the fuses.

[mel4853]

Thanks for all the help, the program is working like a champion. My resistor on GP3 pulling to ground was not pushed into proto board all the way.
Also for Paul, I'm using this to run a digital camera to photograph deer.THANKS again for everybody's help. I'm sure you'll be hearing from me again, as I'm building a solar charger for this camera setup, just not sure what I want it to do yet.

[paul borgmeier]

I don't think it will work because the programmer does not look at the file. The fuses have to be set by the programmer. With PBP and the MEL programmer, the @device statements are read by the programmer and it, in turn, sets the fuses.

I must be from Missouri because I still do not see why it will not work. When I write in pure ASM, I include the __Config in my ASM file and MPLAB takes care of my fuses. When I write in PBP, I edit the inc. file for my fuse choice and the fuses are set by MPLAB.

I have not used PM or the EPIC for years but doesn't one, when using PBP with these two, edit the .inc file for the proper device settings and then the fuse settings are automatically set when programming?

I have PBC somewhere and an old EPIC somewhere – maybe I need to see it not work to believe it. (I hope I can find them).

Paul

[dhouston]

You can refer to Melanies post for how to set config fuses with PBP depending on whether you use PM or MPLAB.

• http://www.picbasic.co.uk/forum/show...iguration+fuse

The Epic Windows software will read the file and, if you have this option enabled, set the config items.

With PBC you will get a compiler error at @.

[paul borgmeier]

You can refer to Melanies post for how to set config fuses with PBP depending on whether you use PM or MPLAB.

I am (at least I thought I was) fully up to speed on how to set fuses in PBP (or MPASM for that matter) - great post though for the community at large.

With PBC you will get a compiler error at @.

Why I care, I am not sure since I do not use PBC, but I am still intrigued that it does not work. I would have guessed MELABS would have built PBC and PBP around the same PM code – this is my assumption and not noted anywhere except both manuals use the term PM (and I beleive it true ).

The PBC manual (online) says you can insert ASM code and it will be inserted verbatim in the ASM file (with errors or not). The difference is PBC makes no mention of using @ before ASM code but does show ASM/ENDASM as the way to do it. If PBC is choking on the @, maybe the format I originally suggested would be inserted and hence work. If anything - the PBC PM should choke if it is not supproted, not PBC. Thoughts yet again? (I hope you can save me from having to find my old soft/hardware


Paul

[dhouston]

Using your formulation, PBC throws an error, saying "OPCODE expected instead of pic12f675".

[paul borgmeier]

Using your formulation, PBC throws an error, saying "OPCODE expected instead of pic12f675".

If you would be kind enough to test one more ...

I think "my formulation" was not 100% correct because the word "device" was in Column 1 (I did not add code formating). What happens if you use this.

ASM
     device pic12F675, intrc_osc_noclkout, wdt_off, mclr_0ff, protect_off
ENDASM

Paul

[dhouston]

It chokes on mclr_Off as an "undefined symbol".

When I replaced that with "mclr_off", it compiles and EPICWin appears to set the config fuse settings as defined in the file.

[paul borgmeier]

pretty bad that PBC don't allow to set the config fuses in the code.. that would be so much convenient. Yet another real limitation of PBC.

It looks like the PBC folks DO have an option for auto handling fuse settings. Not directly like in PBP, but with a nice workaround.

dhouston, thanks for helping to make this work. It would still be a mystery without your efforts.

The hard part for them now will be to find the proper format for the device statement.

Here are few to get them going:

12F675
device pic12F675, intrc_osc_noclkout, wdt_on, mclr_on, protect_off

16F628
device pic16F628, xt_osc, wdt_on, pwrt_on, mclr_on, lvp_off, protect_off

16F84A
device pic16F84A, xt_osc, wdt_on, protect_off

16F877
device pic16F877, xt_osc, wdt_on, pwrt_on, lvp_off, protect_off

Now, if only I used PBC I would be all set ...

Paul Borgmeier
Salt Lake City, Utah
USA

[dhouston]

dhouston, thanks for helping to make this work. It would still be a mystery without your efforts.
The hard part for them now will be to find the proper format for the device statement.

This notation also seems to work...

asm
   	device pic12f629, intrc_osc_noclkout
   	device pic12f629, wdt_off
   	device pic12f629, pwrt_on
   	device pic12f629, mclr_off
   	device pic12f629, bod_on
   	device pic12f629, protect_off
   	device pic12f629, cpd_off
endasm

It also works with upper case or even mixed case.

At first, I thought your mclr_0ff failed because it was mixed case. Now, I think you typed a zero (0) instead of the letter O.

While I haven't tested it, I expect this notation will also work with PBP.