 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mds
Joined: 06 Nov 2005
Posts: 29
|
| 18f2520 input_state not working |
 Posted: Mon Aug 09, 2010 12:16 am |
 |
|
Hi all,
Could someone verify for me a problem with 18f2520 and the input_state(PIN_B1) function not working correctly?
I have two identical boards one with an 18f252 and one with an 18f2520
Programmed with the same code with only one difference. One with 18f252 headers the other 18f2520 headers.
It seems my routine that uses the input_state read function does not reflect the port pin state correctly on the 18f2520.
thanks
pcwh ver 4.106 |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Aug 09, 2010 2:28 am |
|
|
I think your problem is somewhere else.
Tried a really 'minimal' test:
| Code: |
#include <18F252.h>
#fuses HS,NOWDT,NODEBUG,NOLVP
#use delay(clock=20000000)
void main()
{
int8 value;
setup_adc(NO_ANALOGS);
value = input_state(PIN_A0);
value = input_state(PIN_B0);
while (TRUE) {
delay_cycles(1);
}
}
|
Compiled first with 252, then with 2520 selected.
| Code: |
.................... value = input_state(PIN_A0);
0018: CLRF 05
001A: BTFSC F80.0
001C: INCF 05,F
.................... value = input_state(PIN_B0);
001E: CLRF 05
0020: BTFSC F81.0
0022: INCF 05,F
|
Code is the same, and identical.
I have replaced the 252, with 2520's, in quite a few projects, and had no problems from this function.
There are several 'erratas' for the 2520, especially around the UART, and MSSP, depending on what silicon version you have. Is it possible you are getting clobbered by one of these?.
What pin is involved?. Remember that on the 252, a lot more pins are selectable as analog inputs, and wake up set this way, unless you are reconfiguring these.
Best Wishes |
|
|
mds
Joined: 06 Nov 2005
Posts: 29
|
|
| Posted: Mon Nov 01, 2010 9:02 pm |
|
|
Finally able to get back to this problem and have a look at it.
| Code: |
case 'p': ///power
tmpb=input_state(pwr_gps);
tmpb=~tmpb;
fprintf(pc,"%d",tmpb);
break; //end case 'p'
|
I have broken my original command fprintf(pc,"%d",~input_state(pwr_gps);
line into pieces to aid debug.
A command comes in over the serial port (a "p") and this switch function deals with it.
| Code: |
.................... tmpb=input_state(pwr_gps);
1E7C: MOVLB 1
1E7E: BCF xB7.0
1E80: BTFSC F81.1
1E82: BSF xB7.0
.................... tmpb=~tmpb;
1E84: BTG xB7.0
|
Using debug to break @ 1E7E tmpb=1 which is correct.
As soon as I execute 1E7E however, tmbp becomes 0.
thoughts? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Tue Nov 02, 2010 3:06 am |
|
|
It would do.
That too is 'correct'.
| Code: |
.................... tmpb=input_state(pwr_gps);
1E7C: MOVLB 1
1E7E: BCF xB7.0 //Set variable to zero - It _will_ be zero here
1E80: BTFSC F81.1 //Now test the input bit
1E82: BSF xB7.0 //If bit was set, re-set the variable
.................... tmpb=~tmpb;
1E84: BTG xB7.0
|
The way the code works, it _clears_ the variable, and then if the input bit is set, sets the bottom bit. Hence when 1E7E is executed, the variable _will_ be cleared. Correct operation.
However it should then be set again, when the input bit is tested.
The only reason it'd remain cleared at line 1E84, is if the input is 'seen' as zero.
Best Wishes |
|
|
|
|
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
