-1

I am trying use one pin on PIC12F675 for button, another pin for LED. I wrote this code but button did not work. LED is still on. GPIO0 is connected to +LED, GPIO1 is connected to button, button is connected to ground. Please help. Thank you.

#pragma config FOSC = INTRCIO   // Oscillator Selection bits (INTOSC oscillator: I/O function on GP4/OSC2/CLKOUT pin, I/O function on GP5/OSC1/CLKIN)
#pragma config WDTE = OFF       // Watchdog Timer Enable bit (WDT disabled)
#pragma config PWRTE = OFF      // Power-Up Timer Enable bit (PWRT disabled)
#pragma config MCLRE = OFF      // GP3/MCLR pin function select (GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD)
#pragma config BOREN = OFF      // Brown-out Detect Enable bit (BOD disabled)
#pragma config CP = OFF         // Code Protection bit (Program Memory code protection is disabled)
#pragma config CPD = OFF        // Data Code Protection bit (Data memory code protection is disabled)

#include <xc.h>

int main(void) {

    ANSEL=0x00;                 // ANALOG SELECT REGISTER (digital)
    CMCON=0x07;                 // COPMARATOR DISABLE
    nGPPU=0;                    // GPIO pull-ups are enabled by individual port latch values
    WPU1=1;                     // WEAK PULL-UP REGISTER
    TRISIO0=0;
    TRISIO1=1;

    while(1) {

    if(GPIO1)
      GPIO0=0;
    else
      GPIO0=1;

    }
    return 0;
}

Edit 1: If I comment everything in while(1) except GPIO0=1, LED is on. If I comment everything in while(1) except GPIO0=0, LED is off. So probably hardware is OK. I think debounce is not necessary in this program. If in original program swap GPIO0=1; and GPIO0=0; then LED is off. PIC executes what is in else.

Edit 2: I now tried use pin5 for button and it works. What does it mean? Is my PIC damaged or there is a bug in code?

Edit 3: Now I add CMCON=0x07; but no change. Still did not working. If button is on GPIO5, it works fine. If button is on GPIO1, it do not works.

Matej
  • 11
  • 1
  • 4
    "Does not work" is not a clear problem description. Use a debugger and provide details. Just a future hint: You should debunce (I will not explain, as you can serach for this!) a button in general (it is not necessary here). And check the vlotage at the button-GPIO. – too honest for this site Nov 04 '15 at 16:30
  • You probably should move your question to http://electronics.stackexchange.com/. – JimmyB Nov 04 '15 at 16:34
  • @HannoBinder Sure they welcome code there? – cadaniluk Nov 04 '15 at 16:36
  • @Olaf Typo: "debunce" may not be easy to search for :) -- Make sure you have debouncing circuitry and/or software in place. – JimmyB Nov 04 '15 at 16:36
  • They sure do if it's for µC. Asking for a check on whether or not you have an error in your initialization of the PIC peripherals is a pretty common question. – JimmyB Nov 04 '15 at 16:38
  • A quick test: What happens when you swap `GPIO0=1;` and `GPIO0=0;`? The LED should stay dark. If it does we can assume that the IO configuration of the LED pin is correct, and that the PIC is actually running and executing instructions. – JimmyB Nov 04 '15 at 16:40
  • 1
    yeah, we don't know whether the problem is software or hardware,and we can't debug hardware problems by blog. You posted nothing to indicate that the hardware is OK and, even if you did, nobody would believe you without a detailed explanation of how you proved it. – Martin James Nov 04 '15 at 16:55
  • 1
    @HannoBinder: Try googling "debunce". I got the dict.cc entry for "debounce" as first hit and the next ten were also about debouncing, e.g. Arduino. YMMV, however. (Not that you were wrong about the typo). – too honest for this site Nov 04 '15 at 17:00
  • What happens without considering the button? Modify your program so that you write a `1` to the LED pin in the `while` loop and observe the result. Next modify your program to instead write a `0` to the LED pin and observe the result. This will tell you if the program is running, the LED is connected correctly, and the logic sense of the LED. Only then should you consider the button. – Weather Vane Nov 04 '15 at 17:34
  • GPIO1/2 are ICSP pins, this is likely a hardware issue. – Mathieu L. Nov 04 '15 at 18:18
  • Updated question. Answered on your comments. – Matej Nov 04 '15 at 22:56
  • Now it works but I do not know why. Details in edited questions. – Matej Nov 04 '15 at 23:03

1 Answers1

1

I know you've "fixed" it by using a different pin, but the original problem is that GPIO1, as well as being an analog input by default (which you correctly disabled), is also used as input to the comparator, which you also need to disable.

Quoting two sections from the datasheet:

cmp1

and also

cmp2

So, you had dealt with the ANSEL register but not CMCON, therefore your initialisation section needs an additional line of code:

CMCON = 0x07;    // turn off comparator

If you try this, see if it now works with your original pin configuration. If you're wondering where the 0x07 came from, refer to page 37 of the datasheet where the setting for the lower three bits of CMCON are shown. To disable the comparator, these three bits should be set to 1, so binary 111 == 0x07.

cmp3

Roger Rowland
  • 25,885
  • 11
  • 72
  • 113