 |
 |
| View previous topic :: View next topic |
| Author |
Message |
demcast
Guest
|
| PIC10F202 wake up on pin change |
 Posted: Fri Sep 23, 2005 7:01 pm |
 |
|
How would you 'word' in CCS PIC C a pin change interrupt if there are no available #INT directives for the PIC10F202? I was using the HTech PIC C before and all I had to do was:
| Code: | while(1) //loop forever
{
switch(GPIO & 0b00001010)
{
case 0b00000000: //GP3 = LOW
pulseIROutput(); //GP1 = LOW
isLowBatt();
break;
case 0b00000010: //GP3 = LOW
pulseIROutput(); //GP1 = HIGH
break;
case 0b00001000: //GP3 = HIGH
isLowBatt(); //GP1 = LOW
break;
case 0b00001010: //GP3 = HIGH
//GP1 = HIGH
//do nothing
SLEEP();
}//switch
}//while(1) |
Everything was worked fine, and to think that was not even the full version. Now that I got the PCWH version of CCS PIC C Compiler, I found that the while(1) and the switch-case combination does not detect the pin change in GP3 (or PIN_B3). Any suggestions? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 23, 2005 8:20 pm |
|
|
| Quote: | | Everything was worked fine, and to think that was not even the full version |
Right, but the compilers have differences in the way they handle
items that are not part of standard C.
You should post a test program because undoubtedly, the problem
will have to do with the pin configuration, or the TRIS, or the way in
which GPIO is declared. By a test program, I mean a program
that contains a main(), an #include <10F202.H>, any #use statements,
and is compilable without errors if dropped into an MPLAB project.
I don't have the PCB compiler, but because pin GP3 is muxed with
the MCLR function, it's likely that the 10F202.H file has a #fuses
setting of NOMCLR in it. If so, you need to add it to your #fuses
statement to configure GP3 as an i/o pin.
Also, in CCS, a SFR register such as GPIO is declared with a #byte
statement. Example:
#byte GPIO = 6 |
|
|
demcast
Joined: 23 Sep 2005
Posts: 2
Location: Southern CA
|
|
| Posted: Sat Sep 24, 2005 10:37 am |
|
|
Thanks for the reply.
| PCM programmer wrote: | | You should post a test program because undoubtedly, the problem will have to do with the pin configuration, or the TRIS, or the way in which GPIO is declared. |
I would if I could, unfortunately it's a proprietory program I'm working on.
| Quote: | | ...because pin GP3 is muxed with the MCLR function, it's likely that the 10F202.H file has a #fuses setting of NOMCLR in it. If so, you need to add it to your #fuses statement to configure GP3 as an i/o pin. |
I did, I had as the .h files enumerated: | Code: | #fuses NOMCLR,NOWDT,NOPROTECT
#byte GPIO = 0x06 |
I was also looking at the list files for both (HTECH and CCS), HTECH had some extra lines that looked like it was looping until the GPIO changed and as soon as it did, it went through the switch. On the CCS, it looked like it was going through the main while loop and somehow missing the changes in the GPIO. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Sep 24, 2005 11:56 am |
|
|
| Quote: | | I would if I could, unfortunately it's a proprietory program I'm working on. |
Err... a test program with maybe 6 lines inside main() is not proprietary.
But in any case, I only have the PCM and PCH compilers. I don't have
PCW or PCWH (which have PCB), so I can't do any test compilations
so my main method of helping people won't work in your case.
Perhaps someone else can help. |
|
|
Guest
|
|
| Posted: Sat Sep 24, 2005 1:02 pm |
|
|
| PCM programmer wrote: | | Err... a test program with maybe 6 lines inside main() is not proprietary. |
hmm.. I can do that, here's more than 6 lines:
| Code: | #include<10F202.h>
#fuses NOMCLR,NOPROTECT,NOWDT
#use delay(clock=4000000)
#byte GPIO=0x06
void pulseIR(void){
output_high(PIN_B0);
output_high(PIN_B2);
delay_ms(10);
output_low(PIN_B2);
delay_ms(30);
delay_ms(100);
output_low(PIN_B0);
}
void lowBatt(void){
while(PIN_B1){
output_high(PIN_B0);
delay_ms(100);
output_low(PIN_B0);
delay_ms(300);
}
}
void main() {
SETUP_TIMER_0(RTCC_INTERNAL);
SET_TRIS_B(0b00001010); //PIN_B3 & PIN_B1 are input pins
while(1){
SLEEP();
switch(GPIO&0b00001010){
case 0b00000000:
pulseIR();
lowBatt();
break;
case 0b00000010: //PIN_B3 is to pulse the IR
pulseIR();
break;
case 0b00001000: //PIN_B2 is to monitor battery
lowBatt();
break;
case 0b00001010:
}
}
} |
| Quote: | | ... I only have the PCM and PCH compilers. I don't have PCW or PCWH (which have PCB) |
And that's the problem, most of the examples used #INT directives to control the interrupts. The PIC10F2xx have a Wake-Up-On-Change capability and I'm not sure how to use that in the CCS compiler. Thanks for the reply though. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
| Re: PIC10F202 wake up on pin change |
| Posted: Sat Sep 24, 2005 7:09 pm |
|
|
I don't know the PIC10 series chips but your problem was a nice challenge to start looking into them.
When executing your problem with the MPLAB simulator in CCS version 3.235 it looks like all registers are configured correctly for a wake-up-on-change:
- TRISIO bit 1 and 3 are set to '1'.
- GPWU = 0 (wake-up-on-pin-change = enabled)
Only the configuration word is totally wrong: Despite your #fuse settings the watchdog is enbled and the GP3 is used as MCLR.
Searching this forum I found the following thread: http://www.ccsinfo.com/forum/viewtopic.php?t=22709
Here is explained that CCS generates the wrong address for the config register.
From the end of my v2.235 hex file:you can see this has still a wrong address (0x1FFE) i.s.o. of the 0x0FFF as defined by Microchip.
Change this to:
Or another workaround that I found was to read the *.hex file with the File/Import function in MPLAB, strangely this reads the config word correctly.
I've reported this bug to CCS.
One other remark on your program:
| PIC12F20x datasheet chapter 9.9.2 wrote: | Caution: Right before entering Sleep,
read the input pins. When in Sleep, wakeup
occurs when the values at the pins
change from the state they were in at the
last reading. If a wake-up on change
occurs and the pins are not read before reentering
Sleep, a wake-up will occur
immediately even if no pins change while
in Sleep mode. |
Assuming the state of your pins is 0b00001010 before entering sleep the first time your example program will fail by entering an infinite loop. |
|
|
demcast
Joined: 23 Sep 2005
Posts: 2
Location: Southern CA
|
| Re: PIC10F202 wake up on pin change |
| Posted: Mon Sep 26, 2005 10:14 am |
|
|
I'll check into this one, and by the version number, did you mean the CCS IDE or the MPLAB IDE?
| Quote: | | Right before entering Sleep, read the input pins. When in Sleep, wakeup occurs when the values at the pins change from the state they were in at the last reading. |
I think that's it! That's the missing asm part in the CCS list file. In the HTech list file, there was this loop that kept running and kept comparing to the GPIO register. Everytime it did, it MOVWF to 0xa, see below: | Code: | MOVF 0x6, W
ANDLW 0xa
MOVWF 0xa
CLRF 0xb
MOVF 0xb, W
BTFSC 0x3, 0x2
GOTO 0x1c0 //start of the switch
GOTO 0x1ca // start of this loop |
Now, how would I be able to make CCS to do this loop? I could probably use a while loop before the switch. At any rate, thanks for the reply, it actually help me move another step forward.  |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
