12F683: I change GPIO.5 but GPIO.0 also changes...why?

[chicowoodhill]

Hi - I gotta believe I'm overlooking something incredibly simple, but I give up and beg for help:

This is a simple 12F683 program. It's not finished yet, but I'm stumped at this early point. In the code below, as I emulate it in Proteus, when I execute the instructions "GPIO.5 = 0" or "GPIO.5 = 1" (indicated by the "***" comments), GPIO.0, which is high, goes low. I can't figure out why it should be affected by the GPIO.5 commands, unless I'm missing something in my register setups.

Anybody see what I'm missing here? Please help me to say "Doh!".

Thanks.... chico


#CONFIG
__CONFIG _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF & _PWRTE_ON & _CP_OFF & _CPD_OFF & _BOD_OFF & _IESO_OFF & _FCMEN_OFF
#ENDCONFIG

DEFINE OSC 4

OPTION_REG = %00000000 'Bit 7 = 0: Internal Pull-ups enabled via WPU.

WPU = %11111111 ' (Weak Pull Ups) 1=Internal pull-ups = on

INTCON = %00000000 'Disable Interrupts

CMCON0 = %00001011 ' Analog comparator: Comparator w/ Output and with Internal Reference CM<2:0> = 011

VRCON = %10001111 'VOLTAGE REFERENCE REGISTER: Enabled (b7=1), High Range (b5=0), Range (3:0)

TRISIO = %00011010 ' GP5: output to relay, GP4: not used, GP3: input MCLR, GP2:comparator output, GP1 voltage input, GP0 output to LED,

ANSEL = %00000010 ' Set GP1 to analog

ADCON0 = 0 ' A/D off

GPIO = %11111111 ' All outputs = high on boot

ControllerOutputPin var GPIO.5 'Alias GPIO.5 to relay controller
LED var GPIO.0 ' Alias GPIO.0 to LED

'********** PROGRAM SETUP ***********************

' Main loop checks for signal and adjusts ControllerOutputPin (GPIO.5) if necessary
' also creates slow square wave on DIAGNOSTIC OUTPUT pin (GPIO.0)

Main:

if CMCON0.6 = 1 then 'COUT bit in CMCON0 register

' ***HERE'S THE PROBLEM. WHEN THE NEXT INSTRUCTION EXECUTES, BOTH GPIO.5 AND GPIO.0 GO LOW. WHY IS GPIO.0 AFFECTED BY THIS INSTRUCTION?

GPIO.5 = 0 'same thing as "low ControllerOutputPin" or "low GPIO.5" but uses less code
pause 1000
else

' ***SAME PROBLEM HERE. WHEN THE NEXT INSTRUCTION EXECUTES, GPIO.5 GOES HIGH BUT GPIO.0 GOES LOW. WHY IS GPIO.0 AFFECTED BY THIS INSTRUCTION?

GPIO.5 = 1 ' same thing, less code as: high GPIO.5 ' ControllerOutputPin
pause 1000
endif

'for testing:

' toggle LED

if GPIO.0 = 1 then 'DiagnosticOutputPin
GPIO.0 = 0 ' toggle diagnostic LED
else
GPIO.0 = 1 'high GPIO.0 'Send continuous blinky
endif
'
goto Main


END

[Acetronics2]

Hi,

are you sure of this line ??? :rolleyes:



CMCON0 = %00001011 ' Analog comparator: Comparator w/ Output and with Internal Reference CM<2:0> = 011


Alain

[HenrikOlsson]

Alain,
Care to elaborate on that one a bit?
I've been looking at the datasheet and I honestly can't see what the problem with that specific line might be. As usual I suspect a R-M-W issue and I was going to suggest that perhaps the simulator doesn't deal with all the features of the comparator (like internal Vref) but I have nothing to back that up with.

/Henrik.

[AvionicsMaster1]

I think what Ace is saying is look at bit 3. I think that will invert your output pins when using it that way in your program.

As usual, I could be full of egg nog too.

[chicowoodhill]

Hi,

are you sure of this line ??? :rolleyes:



CMCON0 = %00001011 ' Analog comparator: Comparator w/ Output and with Internal Reference CM<2:0> = 011


Alain

OK, closer examination of the datasheet shows:

bits <2:0>: 011 = CIN- pin is configured as analog, CIN+ pin is configured as I/O, COUT pin configured as
Comparator output, CVREF is non-inverting input.
bit <3>: 1
CIS: Comparator Input Switch bit When CM<2:0> = 110 or 101:
1 = CIN+ connects to VIN-
0 = CIN- connects to VIN-
When CM<2:0> = 0xx or 100 or 111: CIS has no effect.

So...I don't see how CMCON0 would be causing my issue...?


Alain,
I've been looking at the datasheet and I honestly can't see what the problem with that specific line might be. As usual I suspect a R-M-W issue and I was going to suggest that perhaps the simulator doesn't deal with all the features of the comparator (like internal Vref) but I have nothing to back that up with.

/Henrik.

Yeah, so now I'm kind of thinking the problem is in the Proteus simulator. I posted this because usually something like this means I've done something dumb in the setup. But since 3 smart people have looked at it and not seen an obvious problem (am I interpreting your responses correctly?) I think I'll next try the MPLAB simulator and then try a quick hardware prototype to see if indeed bit 0 actually changes when I change bit 5 in code. I kind of doubt it will.

Quick, everyone...last chance to solve my problem before I get out the soldering iron....;)