Hi guys,


Need a simple (really simple) sanity check for my design. I want to design a push button switch that will turn on my application ON after the switch has been pressed for 5 seconds. I thought that this would be easiest with a microprocessor.


I chose an ultra low power PIC, the PIC16F1827. Once a battery is connected to my device, the microprocessor will go through its hardware initialization (setting frequency registers, interrupt registers, etc) and immediately go into sleep mode. When the end user does press the button, the microprocessor will receive an active low signal and immediately wake up. From there, the microprocessor will go into its main routine and start a timer as long as the button is pressed.


Once the timer counts up to 5 seconds (meaning the user held the button for that long), I will send a signal to my devices main microprocessor do fully turn on the device.


A schematic has been attached for review. I know this is a really simple design, but I always learn something new from other people’s viewpoints. Maybe I am making it too complicated? I am mainly looking for suggestions.

Thank you!

 

Using the 16f1827 just for a wake up switch is a major waste of resources. The 16f1827 should be the main processor, including the wake up function.

Here is link (see post #14) for a software based button switch made for a 10f200. It will detect no press, short, or long button press. Then based on the nested conditional IF statements, will execute the appropriate code. This takes a little time, but well spent when everything is sorted.

The 16f1827 have interrupt capability, which the 10f200 doesn't have. So try the interrupt on pin change function to wake up. Then keep watching the button per the 10f code. Substitute similar conditionals, per user's language of choice. See if the 5 sec wait is met before going/jumping on to the main code, or simply going back to sleep.

 

Using the 16f1827 just for a wake up switch is a major waste of resources. The 16f1827 should be the main processor, including the wake up function.

Here is link (see post #14) for a software based button switch made for a 10f200. It will detect no press, short, or long button press. Then based on the nested conditional IF statements, will execute the appropriate code. This takes a little time, but well spent when everything is sorted.

The 16f1827 have interrupt capability, which the 10f200 doesn't have. So try the interrupt on pin change function to wake up. Then keep watching the button per the 10f code. Substitute similar conditionals, per user's language of choice. See if the 5 sec wait is met before going/jumping on to the main code, or simply going back to sleep.

Thanks for the reply nickleflipper. Yes you are right the 16f it would be a waste of resource for a simple turn on/off device.

For my design I would need at least input (button) and one output (to the other microprocessor). Looking at the available pins for the 10f series, I would need to utilize three pins alone for programming/emulation the PIC (MCLR, ICSPCLK, ICSPDAT ). My question is, when these pins are not used for programming/emulating, can they be used as standard IO pins? If not, I would not have any available output pins.

Thanks!

 

Thanks for the reply nickleflipper. Yes you are right the 16f it would be a waste of resource for a simple turn on/off device.

For my design I would need at least input (button) and one output (to the other microprocessor). Looking at the available pins for the 10f series, I would need to utilize three pins alone for programming/emulation the PIC (MCLR, ICSPCLK, ICSPDAT ). My question is, when these pins are not used for programming/emulating, can they be used as standard IO pins? If not, I would not have any available output pins.

Thanks!

You're welcome. Should be no problem using the stated GPIO pins after programming, they are multiplexed/multi-purpose pins after all.

The GPIO.2 pin is not affected by programming, and could be also used as the output. Just be sure that the OPTION.T0CS bit is cleared in the software initialization, as it takes priority over TRIS GPIO.2 function, on the Baseline (12bit instr.) PICS.

The previously stated example made full use of the 10f200. The MCLR pin was used as the button input, with the other three avaiable GPIO used for controlling a RGB led.

P.S. still confused as to why the 16f couldn't operate as both wakeup and main controller.

 

You're welcome. Should be no problem using the stated GPIO pins after programming, they are multiplexed/multi-purpose pins after all.

The GPIO.2 pin is not affected by programming, and could be also used as the output. Just be sure that the OPTION.T0CS bit is cleared in the software initialization, as it takes priority over TRIS GPIO.2 function, on the Baseline (12bit instr.) PICS.

The previously stated example made full use of the 10f200. The MCLR pin was used as the button input, with the other three avaiable GPIO used for controlling a RGB led.

P.S. still confused as to why the 16f couldn't operate as both wakeup and main controller.

Looks like I will need to buy a header (PN: AC162059) in order to debug this chip.

I'll look into it. Thanks again!

 

This code for a 10F202 does almost what you want. You'd just have to strip away the bits you don't need.
It's been sitting mostly in sleep mode for over 6 months so far on a CR2032 battery so it's fairly low power.
You should be able to program it on a breadboard without buying any extras, not sure about debugging, but you should be able to get away with just using the simulator.

http://forum.allaboutcircuits.com/showpost.php?p=258763&postcount=10

 

I guess I am a little confused on how to implement this on a PCB board. This processor will be implemented on a PCB that I will have to fab. I will be using a surface mount package.

I like having debug capabilities mainly because it's a pain not to be able to watch variables when something goes wrong. Since this PIC doesn't seem like to have in-circuit debugging, I'll need to buy the AC162059 header.

Can anyone confirm this? I've worked with larger pics and this is my first time using a pic with such a low pin count and very limited resources.

 

I'm not into the debugger thing either, you could be done with it before the header shows up.

Unless you have an ICD2, an AC164110 - RJ-11 to ICSP Adapter would also be needed. Just plug the header board into a breadboard until the prototyping is finished. Then just xfer code over to the smt device with a programming adapter AC163020, or make ICSP pads available on the final board.

 

Thanks guys. You've really pointed me in the right direction. I'll have to come up with an interface to debug and program this device from my PCB as I feel naked without having the ability to debug

I'm not a programming/PIC master just yet!

 

I've decided to forgo debugging and just install a header for ICSP programming. Thanks for all the help!

 

This code for a 10F202 does almost what you want. You'd just have to strip away the bits you don't need.
It's been sitting mostly in sleep mode for over 6 months so far on a CR2032 battery so it's fairly low power.
You should be able to program it on a breadboard without buying any extras, not sure about debugging, but you should be able to get away with just using the simulator.

http://forum.allaboutcircuits.com/showpost.php?p=258763&postcount=10

Thanks! This will be a great reference when I actually start coding!

 

Hi guys,

I came up with a basic schematic. I am going to breadboard it in a couple of days before I design it on my PCB. Can I please get a quick check? My main concern is the isolation of my ICSPCLK for programming and the same pin as a signal to the other pic during non-progamming mode. Is a 10k resistor enough isolation for when the chip will be in programming mode?

Any tips or suggestions will be greatly appreciated. I have attached the schematic and some reference documents I used. Thanks!

 

With the 10k resistor heading toward the other load, as long as the ICSP pin is connected on the PIC side of the resistor, it shouldn't be a problem.

I've programmed PICs that had LEDs on the PGC and PGD (RB6 and RB7) without problems, though I prefer to make them switchable with a jumper to remove for programming.

 

I did something like this awhile back (short & long switch detection) and would be happy to share some 10F200 (assembly language) code, if you're interested.

Cheerful regards, Mike

<added>

The main program loop might look something like this pseudo C code example;

;  // all about circuits forum example
;
;  unsigned char swnew = 0;     // fresh switch sample
;  unsigned char swold = 0;     // switch state latch
;  unsigned char swtmr = 0;     // 5-second switch timer
;
;  #define newpress     swnew.3 == 1 && swold.3 == 0
;  #define newrelease   swnew.3 == 0 && swold.3 == 1
;  #define speaker      gpio.2
;  #define output       gpio.0
;
;  while(1)                     //
;  { delay_ms(50);              // 50-msec sample/debounce interval
;    swnew = ~gpio;             // sample active lo switches (GP3)
;    if(newpress)               // if "new press"
;    { swold.3 = 1;             // update switch state latch
;      swtmr = 5000/50;         // start 5 second timer
;      beep1();                 // send "new press" beep
;    }
;    if(newrelease)             // if "new release"
;    { swold.3 = 0;             // update switch state latch
;      swtmr = 0;               // reset switch timer
;    }
;    if(swtmr)                  // if switch timer running
;    { swtmr--;                 // decrement it and
;      if(swtmr == 0)           // if 5 second timeout
;      { beep2();               // send double beep and
;        output ^= 1;           // toggle output
;      }
;    }
;  }

 

One could drop the input switch down to the MCLR pin, much like the LPC board schematic and use the vacated pin for the mcu control.

 

I'd second that, you have chosen GP2 which is the only pin which doesn't support wake on change, but you may as well use GP3 which is input only.

 

There's an internal pull-up for GP3/MCLR on the 10F200 when it's configured as an input, which is kinda' nice.

 

Thanks for all the replies guys. Simple design yet I learned a lot so far.

Markd77, good catch on the button input pin for the PIC. Not being able to wake up on change would have been a nightmare. Changing it right now! Will put the BUTTON on GP3 (MCLR line).

MMcLaren, should I get rid of the 5K pullup on the button side and use the internal pull up on the MCLR line? Looks like the pull up is around 34kΩ at Vdd = 5.5 V. Also, thanks for the code! This will definitely come in handy!

nickelflipper, thanks for the schematic. They are doing something similar to what I will be doing.

Also looks like I can take care of switch debouncing in code instead of adding extra caps and resistors for it. Cool!

 

To save even more power consumption you can have it sleep while waiting for your switch to press, then have it commence your main program once a pulse from the switch has been detected. This is possible through the Interrupt On Change (IOC) function in the PIC, which will be explained further in the datasheet of your PIC. The code below demonstrates a simple example of how this might work using the PIC12F629. I measured the consumption current and it remained a consistent 100nA (10E-9 A), which is negligible for any battery.

//
//        IOCSwitchTest2_12F629.C
//

#include <htc.h>
#include <pic12f6x.h>
#define _XTAL_FREQ 4000000

/***** CONFIGURATION *****/
// External reset, no code or data protect, No Brownout Detect,
// No watchdog, Power-Up Timer Enabled, 4MHz Int Clock
__CONFIG(MCLREN & UNPROTECT & BORDIS & WDTDIS & PWRTEN & INTIO);

#define LED GPIO4        // Indicator LED on GP1
#define nLED 4            // LED on pin #1
#define BUTTON GPIO2    // Pushbutton on GP3 (active low)
#define nBUTTON 2

void main()
{
    int i;        // Counter variable
    TRISIO = ~(1<<nLED);        // configure LED pin (only) as output
    IOCB|=1<<nBUTTON;        // Set IOC with GP2
    GPIE = 1;        // Enable GPIO Interrupts

    while(1)
    {        
        __delay_ms(10);
        if(!GPIO2)
        {
            for(i=0;i<4;i++)        // Blink 4 times
            {
                LED = 1;
                _delay(100000);
                LED = 0;
                _delay(100000);
            }
        }
        GPIF = 0;        // Clear GPIO OVF
        SLEEP();        // Sleep until IOC occurs
            
    }
}

 

To save even more power consumption you can have it sleep while waiting for your switch to press, then have it commence your main program once a pulse from the switch has been detected. This is possible through the Interrupt On Change (IOC) function in the PIC, which will be explained further in the datasheet of your PIC. The code below demonstrates a simple example of how this might work using the PIC12F629. I measured the consumption current and it remained a consistent 100nA (10E-9 A), which is negligible for any battery.

//
//        IOCSwitchTest2_12F629.C
//

#include <htc.h>
#include <pic12f6x.h>
#define _XTAL_FREQ 4000000

/***** CONFIGURATION *****/
// External reset, no code or data protect, No Brownout Detect,
// No watchdog, Power-Up Timer Enabled, 4MHz Int Clock
__CONFIG(MCLREN & UNPROTECT & BORDIS & WDTDIS & PWRTEN & INTIO);

#define LED GPIO4        // Indicator LED on GP1
#define nLED 4            // LED on pin #1
#define BUTTON GPIO2    // Pushbutton on GP3 (active low)
#define nBUTTON 2

void main()
{
    int i;        // Counter variable
    TRISIO = ~(1<<nLED);        // configure LED pin (only) as output
    IOCB|=1<<nBUTTON;        // Set IOC with GP2
    GPIE = 1;        // Enable GPIO Interrupts

    while(1)
    {        
        __delay_ms(10);
        if(!GPIO2)
        {
            for(i=0;i<4;i++)        // Blink 4 times
            {
                LED = 1;
                _delay(100000);
                LED = 0;
                _delay(100000);
            }
        }
        GPIF = 0;        // Clear GPIO OVF
        SLEEP();        // Sleep until IOC occurs
            
    }
}

Thanks for the code. Yes that is my main course of action for this. PIC powers up. Goes directly into sleep. Button press executes a wake up on change event and program goes directly into main.